Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-core-new-block-10

[Francesca Palombini]

Hi Pete,

Thanks for the thoughtful review! Good catches, and happy to see the document 
improved.

Authors – please go ahead and submit the update including these changes, so I 
can push the button and move it forward.

Thanks,
Francesca

From: "mohamed.boucad...@orange.com" 
Date: Wednesday, 28 April 2021 at 06:52
To: Pete Resnick 
Cc: "last-c...@ietf.org" , "gen-art@ietf.org" 
, "draft-ietf-core-new-block@ietf.org" 
, "c...@ietf.org" 
Subject: RE: [Last-Call] Genart last call review of draft-ietf-core-new-block-10
Resent from: 
Resent to: , , Bormann 
, , , , 
Francesca Palombini 
Resent date: Wednesday, 28 April 2021 at 06:52

Hi Pete,

OK with the proposed editorial change. Fixed in the local copy.

Thank you.

Cheers,
Med

De : last-call [mailto:last-call-boun...@ietf.org] De la part de Pete Resnick
Envoyé : mercredi 28 avril 2021 01:11
À : BOUCADAIR Mohamed TGI/OLN 
Cc : last-c...@ietf.org; gen-art@ietf.org; 
draft-ietf-core-new-block@ietf.org; c...@ietf.org
Objet : Re: [Last-Call] Genart last call review of draft-ietf-core-new-block-10


Thanks for the followup. Just to close the loop on some of these:

On 26 Apr 2021, at 5:31, 
mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote:

In section 4.4:

I find this paragraph confusing:

The requested missing block numbers MUST have an increasing block
number in each additional Q-Block2 Option with no duplicates. The
server SHOULD respond with a 4.00 (Bad Request) to requests not
adhering to this behavior.

So, given the SHOULD in the second sentence, it appears that the MUST
in the first sentence doesn't apply to the server (i.e., to enforce
this), but rather to the client doing the request. You should
probably say it that way.

[Med] Yes. This text should be linked to the previous paragraph when the client 
issues the request for missing blocks. Anyway, I agree it is better to be 
explicit here. Fixed.

Excellent. Here's a purely editorial suggestion; entirely up to you whether to 
use it:

The missing block numbers requested by the client MUST have an

increasing block number in each additional Q-Block2 Option with no

duplicates.

Also, the SHOULD in the second sentence is
not entirely clear to me: Are you saying that the server can choose
to use some other response code, or are you saying that the server
can accept the request and do something interesting with it?

[Med] The latter. Normally the server must discard such request but given that 
one of the target use cases for this spec is DDoS mitigation, servers may be 
tolerant.

Ah, OK, then what you have is correct as-is.

In section 4.3:

In several response code definitions:

The token used MUST be any token that was received in a request
using
the same Request-Tag.

That doesn't really parse well. I think you either mean "The token
used MUST be a token" or you mean "The token used can be any token".

[Med] The second para of this section specifies that all block requests must 
use the same Request-Tag. The 4th para indicates that each of these block 
requests will use a new token. The server must use one of these tokens when 
replying.

Updated the text as follows:

NEW:
The token used MUST be one of the tokens that were received in a request for 
this block-wise exchange.

I like it.

In section 7.2:

For the server receiving NON Q-Block1 requests, it SHOULD send
back a
2.31 (Continue) Response Code on receipt of all of the
MAX_PAYLOADS
payloads to prevent the client unnecessarily delaying.
Otherwise...

When you say "Otherwise", Do you mean, "For other payloads"? Either
way, you should probably change that to make it clear.

[Med] Changed to: "If not all of the MAX_PAYLOADS payloads were received, ..."

Perfect.

All of the others look fine. Thanks again for the quick reply.

Cheers,

pr

--
Pete Resnick 
https://www.episteme.net/<https://protect2.fireeye.com/v1/url?k=4f76cc35-10edf576-4f768cae-861fcb972bfc-1147fe9a31398186&q=1&e=ede0ae9f-ec03-476d-a29a-c0628cdb9626&u=https%3A%2F%2Fwww.episteme.net%2F>
All connections to the world are tenuous at best

_



Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc

pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler

a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.



This message and its attachments may contain confidential or privileged 
information that may be protected by law;

they should not be distributed, used or copied without authorisation.

If y

Re: [Gen-art] Genart telechat review of draft-ietf-ace-oscore-profile-17

[Francesca Palombini]

Hi Elwyn,

Thank you very much for the in depth review! We have incorporated your changes 
in the newly submitted v-18 
https://datatracker.ietf.org/doc/html/draft-ietf-ace-oscore-profile-18 , but 
you can also see the specific changes in the github: 
https://github.com/ace-wg/ace-oscore-profile/commit/c98ea9c53994aaa85add5c4a3436a14935fa0471
 

Answers inline.

Thanks again,
Francesca

On 23/03/2021, 23:29, "Elwyn Davies via Datatracker"  wrote:

Reviewer: Elwyn Davies
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

.

Document: draft-ietf-ace-oscore-profile-17
Reviewer: Elwyn Davies
Review Date: 2021-03-23
IETF LC End Date: 2020-07-20
IESG Telechat date: 2021-03-25

Summary:
Ready with nits.  A very great improvement on the previously reviewed 
version. 
Thanks.

FP: Thank you!

Major issues:
None

Minor issues:

Would it be useful to provide some advice on the length of salts and IDs to 
go
with the advice on length of nonces?  There is some in s3.3 of RFC 8613 but
some other reference might be helpful, maybe placed in s3.2.1. and/or s4.

FP: This draft does not have any other requirements on salts and IDs than RFC 
8613. The IDs need not be long, but unique. The salt need not even be unique. 
According to RFC 5869 Section 3.1 “HKDF is defined to operate with or without 
salt”. However, the use of salt adds to the strength of HKDF. “Ideally, the 
salt value is a random (or pseudorandom) string of the length HashLen.” But the 
salt going into HKDF is composed of the master salt and the nonces. It 
therefore suffices with nonces of length HashLen/2 generated by the peers as 
described in this draft, independent of salt.

Nits/editorial comments:

General: The RFC Editor conforms rigorously to American practice and allows
only the use of double quote marks (") in the text when marking strings as
quotations and such like.  The document makes extensive but not totally
consistent, use of single quotes to flag up field names and such like (e.g.,
'nonce1').  In practice these are unnecessary, but may be replaced by the 
RFC
Editor if left in place.  Personally. I think most of them can be removed. 
NB
this does not affect CBOR items such as h'1645.

FP: We have now removed all single quotes "'" and replaced them with the 
XML2RFC v3 supported . We will make sure to follow RFC Editor 
recommendations about this.

General: There are lots of usages of 'CBOR diagnostic notation without the 
tag
and value abbreviations'.  An abbreviation would reduce the verbiage.

FP: Fair point, we have added this to the terminology.

General: It is slightly confusing to have Nonce 1/N1/nonce1 and Nonce
2/N2/nonce2 used in the document.  Am I right in thinking Nonce 1 and N1 are
the same with nonce1  being the name of the JSON/CBOR parameter used to 
carry
the value?  A few words of clarrification would help.

FP: There is a difference between the three: Nonce 1 is the name of the field, 
N1 is the value, nonce1 is the parameter's label. If you have suggestion on 
where to add this, that would be helpful.

Abstract/s1:  It would be useful to introduce the name of the profile
(coap_oscore) up front.  It rather sneaks out in s3.

FP: Good point, added.

s1, para 2: Need to expand CBOR on first use.

FP: Usually yes, but because here it is used as the expansion of COSE, we used 
the RFC Editor abbreviation expansion, which keeps CBOR non-expanded.

s2, end of para 3: s/as well/instead/? or s/as well/alternatively/.

FP: Ok, replaced with alternatively.

s2, para 7 and s6, bullet 2: s/e.g. expiration./for example, expiration./

FP: Ok, fixed.

s3.1, para 3 and last para: s/reported/shown/

FP: Ok, fixed.

s3.1, Figure 2 and Figure 3: Appendix F.3 of draft-ietf-ace-oauth-authz 
reports
that req_aud was replaced by audence at version 19 of the document.

FP: Good catch! Fixed.

s3.2, second set of bullets:  Need to expand HMAC and HKDF on first use (not
well-known in RFC Editor list).  It would also be useful to put a pointer to
section 11.1 of RFC 8152 here to indicate the allowed HKDF algorithms.

FP: Agreed. We have added it to the terminology section (to expand it) and 
added a reference to it. Also added the pointer to COSE.

s3.2, 2nd para after 2nd set of bullets: s/The applications needs/The
application needs/

FP: Ok, fixed.

s3.2, 3rd para after 2nd set of bullets: s/parameeter/parameter/

FP: Fixed.

s3.2, 4th para after 2nd set of bullets: s/the use of CBOR web token/the 
use of
a 

[Gen-art] Genart last call review of draft-ietf-lamps-ocsp-nonce-03

[Francesca Palombini via Datatracker]

Reviewer: Francesca Palombini
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-lamps-ocsp-nonce-03
Reviewer: Francesca Palombini
Review Date: 2020-09-02
IETF LC End Date: 2020-09-02
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is basically ready for publication, but has nits that
should be fixed before publication.

Major issues: -

Minor issues: -

Nits/editorial comments:

Section 1:
OLD:
This extension was
   previously defined in section 4.1.1 of [RFC6960]
NEW:
This extension was
   previously defined in section 4.4.1 of [RFC6960]

Section 2:
The message format for the OCSP request and response is defined in
   the [RFC6960].  It also defines the standard extensions for OCSP
   messages based on the extension model employed in X.509 version 3
   certificates (see [RFC5280]).

"It" in the second sentence is ambiguous, I think it would be better to replace
with "[RFC6960]".



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-ace-oscore-profile-11

[Francesca Palombini]

Hi Elwyn,

Thank you so much for your review. We have now worked on all your comments in a 
pull request, and will soon submit an update to the document. All the nits are 
adressed in two commits: 
https://github.com/ace-wg/ace-oscore-profile/commit/a7f9483e96107a678b80217ba0b2d3dcfb488192
  and 
https://github.com/ace-wg/ace-oscore-profile/commit/855c34865120a1f09c28ebe6dce93acedb1f3e04
 . Detailed comments inline, prefaced with [FP].

Thanks again for the good comments,
Francesca

On 22/07/2020, 00:56, "Elwyn Davies via Datatracker"  wrote:

Reviewer: Elwyn Davies
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

.

Document: draft-ietf-ace-oscore-profile-11
Reviewer: Elwyn Davies
Review Date: 2020-07-21
IETF LC End Date: 2020-07-20
IESG Telechat date: Not scheduled for a telechat

Summary:  Almost ready.  There is one minor issue that needs sorting out 
and a
fair number of nits.  Overall I have to say that I found it difficult to 
keep
clear in my mind what messages were fully encrypted and which ones were 
sent en
clair and which are in some intermediate class.  The authors might wish to 
go
back over the document from the point of a naive reader to ensure that it is
clear for implementers.

Major issues:
None

Minor issues:
s2, para 5:  Where does the 'input salt' come from?  The term is not used
anywhere else in this document and  isn't defined or mentioned in either
dreft-ace-oauth-authz or RFC 8613.

[FP]: Right, as Ben mentioned, this was the result of an update to the name of 
the term. The input salt is used as one of the inputs to the OSCORE Master 
Salt. I have now rephrased to clarify that "salt" contains in fact an input to 
the OSCORE Master Salt. 
(https://github.com/ace-wg/ace-oscore-profile/commit/07ced6a4f908491d7d70c8c2d6fca7596e3801d4
 )

Nits/editorial comments:
s1:  Need to expand CoAP on first use.

[FP]: Ok.

s1: Need to expand CBOR on first use.

[FP]: Actually, because CBOR appears on first use as the first term of COSE, I 
have not expanded it in this location. I have added a normative reference to 
CBOR in the terminology and expanded it there.

s1.2, CDDL:  It would useful to mention that the predefined type names from
CDDL, especially bstr for byte strings and tstr for text strings,  are used
extensively in the document.

[FP]: Thanks for the suggestion, now added.

s2, para 1: s/overview on how/overview of how/

[FP]: Ok.

s2, para 1: s/as well as OSCORE setup/as well as the OSCORE setup/

[FP]: Ok.

s2, para 2: s/that's/that is/

[FP]: Ok.

s2, para 8: Need to expand AEAD on first use.

[FP]: Ok.

s2 and Figure 1:  It would be helpful to the reader if Figure 1 and its
descriptive paragraph was placed closer to the beginning of s2.  Otherwise
things like Client C' need more explanation to point the reader at the 
figure.

[FP]: I have kept Figure 1 at the end of the section, but I have now removed 
all instances of "Client C", since they don't make sense before seeing the 
picture, as you rightly noted.

s2, para 3:

This says:
To determine the AS in charge of a resource hosted at the RS, the client C 
MAY
send an initial Unauthorized Resource Request message to the RS. The RS then
denies the request and sends the address of its AS back to the client C as
specified in section 5.1 of [I-D.ietf-ace-oauth-authz]. The access token
request and response MUST be confidentiality-protected and ensure 
authenticity

I found the combination of the Unauthorized Requst and the
confidentiality-protected etc confusing.  If the last sentence does apply to
the Unuthorized Request it would be helpful to make it clear that this is 
not
just a generic statement but does apply to the Unauthorized Request as well.

[FP]: Ok, thank you for pointing it out. I have now clarified in the beginning 
of the paragraph that the access token request is different from the 
Unauthorized Request.

Figure1:  For consistency the first line should say Unauthorized Rsource
Request.  I would also suggest explaining the mapping between what is said 
in
the text and the terms 'Ceation Hints' and 'Access Information' used in the
figure.

[FP]: Ok about the Unauthorized Resource Request. I have not explained further 
about the mapping between the overview text and the figure, as I do not want to 
go into too much detail there, but I have clarified that the names of messages 
come from the framework.

s3.1, para after Figure 2:  The term 'audience' appears in this paragraph
without any context ind

[Gen-art] Genart last call review of draft-ietf-rtgwg-policy-model-15

[Francesca Palombini via Datatracker]

Reviewer: Francesca Palombini
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-rtgwg-policy-model-15
Reviewer: Francesca Palombini
Review Date: 2020-06-16
IETF LC End Date: None
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is basically ready but has one minor issue, described in
the review.

Minor issues:

In the last paragraph of Section 4 there are a number of non-normative may,
should, must. I believe the last "should" at least could be normative:

>  Also, implementations should have validation to assure
>  that there is no recursion amongst nested routing policies.

(More of a question than an issue) I was surprised that all but one references
were considered normative. Is that common to consider the RFC that appear in
the model as normative references for the document?

Note that for the version reviewed, the Yang Validation for
draft-ietf-rtgwg-policy-model-15 failed: err : Data model "ietf-if-extensions"
not found.



___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [6lo] Genart last call review of draft-ietf-6lo-minimal-fragment-08

[Francesca Palombini]

Looks good Pascal. Thanks for your quick update!

Francesca

On 31/01/2020, 10:55, "Pascal Thubert (pthubert)"  wrote:

Hello Francesca:

Many thanks for your review : )

 
> Summary: This draft is basically ready for publication. However, I 
noticed the
> normative reference to an informative document, draft-ietf-lwig-6lowpan-
> virtual-reassembly (ref. 'LWIG-VRB'), which is problematic, since this 
draft is
> on the standard track.

Moved both this and the reference to recoverable frags to informational. 
They are just illustrative anyway.

> 
> Major issues: -
> 
> Minor issues: -
> 
> Nits/editorial comments:
> 
> * Last paragraph of Section 5, I suggest a minor reformulation for 
clarity.
> 
> OLD:
>An associated
>caveat is that on a half duplex radio, if node A sends the next
>fragment at the same time as node B forwards the previous fragment to
>a node C down the path then node B will miss the next fragment.
> NEW:
>An associated
>caveat is that on a half duplex radio, if node A sends the next
>fragment at the same time as node B forwards the previous fragment to
>a node C down the path then node B will miss the next fragment from 
node
> A.
> 

Applied, and published 09. Please let me know if we are all set now? 


Again, many thanks, Francesca!

Pascal


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-6lo-minimal-fragment-08

[Francesca Palombini via Datatracker]

Reviewer: Francesca Palombini
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-6lo-minimal-fragment-08
Reviewer: Francesca Palombini
Review Date: 2020-01-30
IETF LC End Date: 2020-01-31
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is basically ready for publication. However, I noticed the
normative reference to an informative document,
draft-ietf-lwig-6lowpan-virtual-reassembly (ref. 'LWIG-VRB'), which is
problematic, since this draft is on the standard track.

Major issues: -

Minor issues: -

Nits/editorial comments:

* Last paragraph of Section 5, I suggest a minor reformulation for clarity.

OLD:
   An associated
   caveat is that on a half duplex radio, if node A sends the next
   fragment at the same time as node B forwards the previous fragment to
   a node C down the path then node B will miss the next fragment.
NEW:
   An associated
   caveat is that on a half duplex radio, if node A sends the next
   fragment at the same time as node B forwards the previous fragment to
   a node C down the path then node B will miss the next fragment from node A.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart telechat review of draft-ietf-pce-lsp-control-request-09

[Francesca Palombini via Datatracker]

Reviewer: Francesca Palombini
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-pce-lsp-control-request-09
Reviewer: Francesca Palombini
Review Date: 2019-09-30
IETF LC End Date: None
IESG Telechat date: 2019-10-03

Summary: This draft is ready for publication as a Standards Track RFC

Major issues: N/A

Minor issues: N/A

Nits/editorial comments: N/A

Thanks for addressing all my comments for v-08!

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-pce-lsp-control-request-08

[Francesca Palombini]

Hi Dhruv,

Yes, that looks good to me, I agree with the changes and I'm fine with letting 
the RFC editor figure the last nit out. Thanks!

Francesca

On 06/09/2019, 11:46, "Dhruv Dhody"  wrote:

Hi Francesca,

Thanks for your review. Few thoughts...

On Mon, Aug 26, 2019 at 5:44 PM Francesca Palombini via Datatracker
 wrote:
>
> Reviewer: Francesca Palombini
> Review result: Ready with Issues
>
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
>
> For more information, please see the FAQ at
>
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>
> Document: draft-ietf-pce-lsp-control-request-08
> Reviewer: Francesca Palombini
> Review Date: 2019-08-26
> IETF LC End Date: 2019-08-28
> IESG Telechat date: Not scheduled for a telechat
>
> Summary: This draft is almost ready for publication, but has minor 
issues/open
> points that should be fixed before publication.
>
> Major issues: N/A
>
> Minor issues / questions:
>
> * Section 3: At the end of season 3, you indicate that this new flag has 
no
> meaning in PCRpt and PCInitiate messages. RFC8231 defines that the SRP 
Object
> MAY be carried in PCErr as well, shouldn't there be such requirements 
(MUST be
> set to 0, MUST be ignored on reception) for PCErr?
>

I agree. I suggest to make this generic, something like - "The C Flag
has no meaning in other PCEP messages that carry SRP object and the
flag MUST be set to 0 on transmission and MUST be ignored on receipt."

> * In the following text (Section 4): "The PCE SHOULD NOT
>send control request for LSP which is already delegated to the PCE,
>i.e. if the D Flag is set in the PCUpd message, then C Flag SHOULD
>NOT be set." Why is there a SHOULD NOT instead of MUST NOT? In which
>situation could it be acceptable or useful to request control for a
>delegated LSP?
>

It wont be useful, but if received it would be silently ignored. It
does not rise up to a high level of error and I suspect that is why
authors used SHOULD.

> Nits/editorial comments:
>

Thanks for these, just one comment ...

> * Terminology should also include a sentence about the reader being 
familiar
> with at least RFC8231.
>
> * Terminology could also include what SRP stand for.
>
> * Section 3. When introducing SRP, it would have been helpful to the 
reader to
> reference section 7.2 of RFC8231.
>
> * Section 3. "PCE sets the C Flag to 1 to indicate that, it wishes" -- 
remove
> ","
>
> * Section 3. "MUST be ignored on receipt" -- "MUST be ignored on 
reception"
>

I have noticed 'on receipt' in many of our documents. We should leave
this one for the RFC-EDITOR maybe...

> * Section 4. When introducing the D flag, it would have been helpful to 
the
> reader to reference section 7.3 of RFC8231.
>
> * Section 4. "Note that, the PCUpd message with C Flag set is received" --
> "Note that, if the PCUpd message with C Flag set is received"
>
> (Please keep my address in the To: field if you want to make sure I see 
any
> response to this thread)
>
> Thanks,
> Francesca
>

Thanks again for your review.

Regards,
Dhruv


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-pce-lsp-control-request-08

[Francesca Palombini via Datatracker]

Reviewer: Francesca Palombini
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-pce-lsp-control-request-08
Reviewer: Francesca Palombini
Review Date: 2019-08-26
IETF LC End Date: 2019-08-28
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is almost ready for publication, but has minor issues/open
points that should be fixed before publication.

Major issues: N/A

Minor issues / questions:

* Section 3: At the end of season 3, you indicate that this new flag has no
meaning in PCRpt and PCInitiate messages. RFC8231 defines that the SRP Object
MAY be carried in PCErr as well, shouldn't there be such requirements (MUST be
set to 0, MUST be ignored on reception) for PCErr?

* In the following text (Section 4): "The PCE SHOULD NOT
   send control request for LSP which is already delegated to the PCE,
   i.e. if the D Flag is set in the PCUpd message, then C Flag SHOULD
   NOT be set." Why is there a SHOULD NOT instead of MUST NOT? In which
   situation could it be acceptable or useful to request control for a
   delegated LSP?

Nits/editorial comments:

* Terminology should also include a sentence about the reader being familiar
with at least RFC8231.

* Terminology could also include what SRP stand for.

* Section 3. When introducing SRP, it would have been helpful to the reader to
reference section 7.2 of RFC8231.

* Section 3. "PCE sets the C Flag to 1 to indicate that, it wishes" -- remove
","

* Section 3. "MUST be ignored on receipt" -- "MUST be ignored on reception"

* Section 4. When introducing the D flag, it would have been helpful to the
reader to reference section 7.3 of RFC8231.

* Section 4. "Note that, the PCUpd message with C Flag set is received" --
"Note that, if the PCUpd message with C Flag set is received"

(Please keep my address in the To: field if you want to make sure I see any
response to this thread)

Thanks,
Francesca

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-netvc-testing-08

[Francesca Palombini via Datatracker]

Reviewer: Francesca Palombini
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-netvc-testing-08
Reviewer: Francesca Palombini
Review Date: 2019-06-02
IETF LC End Date: 2019-06-04
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is basically ready for publication, but has nits that
should be fixed before publication.

Major issues: N/A

Minor issues: N/A

Nits/editorial comments:

* The document is missing the IANA section and Security Considerations section.
Although they do not apply (as the shepherd noted), these sections are
required. (See https://tools.ietf.org/html/rfc7322#section-4.8.5 and
https://tools.ietf.org/html/rfc7322#section-4.8.3)

* Outdated reference: A later version (-09) exists of
draft-ietf-netvc-requirements-08

All following comments are suggestions that would have helped a non-expert
reader (feel free to disregard):

* Section 2 - Subjective testing is mentioned in the first sentence with no
introduction. Although quite clear, a short definition or a reference to
literature would have been helpful.

* Section 2, second to last paragraph - The text is somewhat not well
formulated. "... even if the group agrees that a particular test is
important... then the test should be discarded. This ensures that only
important tests be done; in particular, the tests that are important to
participants" I understand that the paragraph was meant to underline the
necessity of selecting tests that participants can/will complete in a timely
fashion. But the formulation is not great: the group agrees on a particular
test is important, but if it is not completed it is not important?

* There are several acronym across the document that could have been expanded
on first use, or used a reference to the definition: PMF, PSNR, PSNR-HVS-M, CQP

* Section 3.7 - "This metric is focused on quality degradation due compression
and rescaling" missing "to"

* Section 5.2 - It would have been good to explicitly write out here what the
parenthesis after each test indicates (resolution, bit depth, etc)

* Section 5.2.2 - "High bit depth" could you quantify more precisely what high
is here?

* Section 5.2.4 and 5.2.5 - Does "old version" mean this should be seen as
deprecated?

(Please keep my address in the To: field if you want to make sure I see any
response to this thread)

Thanks,
Francesca

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-housley-hkdf-oids-01

[Francesca Palombini via Datatracker]

Reviewer: Francesca Palombini
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-housley-hkdf-oids-01
Reviewer: Francesca Palombini
Review Date: 2019-04-08
IETF LC End Date: 2019-04-22
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is ready for publication as an Informational RFC

Major issues: N/A

Minor issues: N/A

Nits/editorial comments: N/A

Other: IANA registration does not require the document to be on Standard track,
AFAIK. Is there a reason to go for Proposed Standard rather than Informational
in this doc? (Also considering RFC7107 is informational)


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04

[Francesca Palombini via Datatracker]

Reviewer: Francesca Palombini
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04
Reviewer: Francesca Palombini
Review Date: 2019-03-13
IETF LC End Date: 2019-03-18
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is ready for publication as a Proposed Standard RFC.

Major issues: --

Minor issues: --

Nits/editorial comments: --


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [bess] Genart last call review of draft-ietf-bess-evpn-df-election-framework-06

[Francesca Palombini]

Hi Jorge,

Thanks for your update. I am ok with the resolution of the nits / editorial, 
thank you.

After looking more into the updating issue, I think that the main question here 
is: do you consider that this will be widely deployed? (As in, you would expect 
future deployments to widely implement these mechanisms?) 

In answer to Adrian you wrote:
"The intend is definitively not to update RFC7432 but to specified new 
procedures, that was the agreement so far. In other words, this work does not 
mandate an upgrade of all the systems supporting RFC7432. The RFC7432 are still 
fine. Maybe we need to rephrase that sentence? "

I just want to clarify that saying that your doc updates RFC7432 doesn't mean 
that it becomes mandatory for all the systems.
I understand that you do not want to upgrade all the systems that already 
support RFC7432. But from my understanding an update to a document can also be 
an extension or optional mechanism (which is what you have here), which is 
considered to be an important addition to the existing RFC. We have an example 
in the CoRE wg with RFC7252 (Constrained Application Protocol) which is updated 
by RFC7959 (Block-Wise Transfers in the Constrained Application Protocol), 
which is an optional features, but which specifies:

   A CoAP implementation that does not support these options generally
   is limited in the size of the representations that can be exchanged,
   so there is an expectation that the Block options will be widely used
   in CoAP implementations.  Therefore, this specification updates
   RFC 7252.

This is the only "open point" I have left, and is more of a question than a 
strong concern. I cc Martin for more input, but if we don't get any, this will 
be my Gen-ART review of v-07. Then it's up to the IESG to say what's the right 
way.

Thanks for all your work!
Francesca

On 19/12/2018, 11:19, "Rabadan, Jorge (Nokia - US/Mountain View)" 
 wrote:

Hi Francesca,

Thank you very much for your review.
Please see in-line how we are resolving your comments in the next revision 
(07, to be published asap).

Thanks.
Jorge

-Original Message-
From: BESS  on behalf of Francesca Palombini 

Date: Friday, December 14, 2018 at 5:13 PM
To: "gen-art@ietf.org" 
Cc: "draft-ietf-bess-evpn-df-election-framework@ietf.org" 
, "i...@ietf.org" 
, "b...@ietf.org" 
Subject: [bess] Genart last call review of 
draft-ietf-bess-evpn-df-election-framework-06

Reviewer: Francesca Palombini
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
    
    Document: draft-ietf-bess-evpn-df-election-framework-06
Reviewer: Francesca Palombini
Review Date: 2018-12-14
IETF LC End Date: 2018-12-18
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is basically ready for publication, but has nits 
that
should be fixed before publication.

Major issues: N/A

Minor issues:

I agree with the reviewers comments saying that this document should 
update
RFC7432 and RFC8124. In particular, quoting RFC2232
(https://tools.ietf.org/html/rfc2223#section-12):

   [...] A document that
   merely updates an earlier document cannot stand on its own; it is
   something that must be added to or inserted into the previously
   existing document, and has limited usefulness independently.  The
   terms Supercedes and Replaces are no longer used.

   Updates

  To be used as a reference from a new item that cannot be used
  alone (i.e., one that supplements a previous document), to refer
  to the previous document.  The newer publication is a part that
  will supplement or be added on to the existing document; e.g., an
  addendum, or separate, extra information that is to be added to
  the original document.

(Yes, RFC2232 is obsolete, but I could not find the same text in the 
more
recent RFC7322)

[JORGE] I think this document "can stand on its own" and it is "useful 
independently" of RFC7432, although the latter document is a normative 
reference of course. Please see the resolution to Adrian's comment: 
https://www.ietf.org/mail-archive/web/bess/current/msg03760.html 
Martin, please let us know if you are

[Gen-art] Genart last call review of draft-ietf-bess-evpn-df-election-framework-06

[Francesca Palombini]

Reviewer: Francesca Palombini
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-bess-evpn-df-election-framework-06
Reviewer: Francesca Palombini
Review Date: 2018-12-14
IETF LC End Date: 2018-12-18
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is basically ready for publication, but has nits that
should be fixed before publication.

Major issues: N/A

Minor issues:

I agree with the reviewers comments saying that this document should update
RFC7432 and RFC8124. In particular, quoting RFC2232
(https://tools.ietf.org/html/rfc2223#section-12):

   [...] A document that
   merely updates an earlier document cannot stand on its own; it is
   something that must be added to or inserted into the previously
   existing document, and has limited usefulness independently.  The
   terms Supercedes and Replaces are no longer used.

   Updates

  To be used as a reference from a new item that cannot be used
  alone (i.e., one that supplements a previous document), to refer
  to the previous document.  The newer publication is a part that
  will supplement or be added on to the existing document; e.g., an
  addendum, or separate, extra information that is to be added to
  the original document.

(Yes, RFC2232 is obsolete, but I could not find the same text in the more
recent RFC7322)

Nits/editorial comments:

  "but they do not require
   any changes to the EVPN Route exchange and have minimal changes to
   their content per se."

* what does their refer to?

* Section 2.2.2: expand MAC-VRF on first usage for readability (or add a
reference to its definition)

* Figure 3: add a definition for ANY STATE (the figure is clear, but for
consistency I would add that in the text as well)

* Figure 3: add "or" between VLAN_CHANGE, RCVD_ES, LOST_ES (again, not
necessary, suggested for readability of the figure)

* Section 3.1: the term "re-entering" needs clarifying: I would consider a loop
as re-entering the state, but from bullet 8. it seems like you don't.

* suggestion for figure 4 (otherwise it looks like there are 2 fields Bitmap of
1B each):

  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Type=0x06 | Sub-Type(0x06)| RSV |  DF Alg |Bitmap ~
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 ~   |Reserved   |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

* Section 3.2: why was Bit 0 left unassigned in Bitmap?

* IANA considerations: I think you want to specify that the policy for Alg 31
is Experimental use (right now the text describing the policy only says "RFC
required", with no distinction for different values).


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-stir-passport-shaken-04

[Francesca Palombini]

Thanks Chris, these changes address my review comments.

Francesca

On 04/11/2018, 19:55, "Chris Wendt"  wrote:

Thank Francesca for the review.  Comments inline.

> On Nov 2, 2018, at 12:14 PM, Francesca Palombini 
 wrote:
> 
> Reviewer: Francesca Palombini
> Review result: Ready with Issues
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-stir-passport-shaken-04
> Reviewer: Francesca Palombini
> Review Date: 2018-11-02
> IETF LC End Date: 2018-11-02
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This draft is on the right track but has open issues, described 
in the
> review.
> 
> Major issues:
> 
> * This draft defines the new claim "origid" for the Personal Attestation 
Token
> used in the SHAKEN framework, but does not give any privacy considerations
> about it and its use. [RFC6973] suggests that the privacy considerations 
of
> IETF protocols be documented. As required by [RFC7258], work on IETF 
protocols
> needs to consider the effects of pervasive monitoring and mitigate them 
when
> possible. I don't know SHAKEN well enough to comment on privacy issues on 
that,
> but this draft, as part of the IETF work, should have privacy 
considerations,
> particularly considering the "origid" claim.


Here is my proposed privacy consideration section, looking for any comments 
if this addresses things properly given the nature of SIP privacy in general.

Privacy Considerations 

As detailed in {{RFC3261}} Section 26 as well as {{RFC3323}}, SIP as a 
protocol inherently carries identifying information of both the initiator or 
'caller' as well as the terminating party or 'callee'. 'origid', as defined in 
SHAKEN {{ATIS-174}} and described in this document is intended to be an 
opaque and unique identifier that is used by an originating telephone service 
provider to trace and identify where within their network (e.g. from a gateway 
or a particular service within their network) the call was initiated, so that 
either bad actors that may be either trying to illegitamately spoof identities 
or making fraudulent calls can be identified and likely stopped or held 
responsibiliy for the fraudulent activities.  While the opaqueness of the 
'origid' identifier is intended to keep any direct or implied information 
regarding the origination of a set of calls that may have the same 'origid' to 
a minimum, it should be recognized that potential patterns whether intended or 
not may be able to be discovered.

> 
> Minor issues:
> 
> * Section 4: the term "verified association" is not defined in this 
document,
> nor in [RFC8225], nor in the SHAKEN spec referenced. Is there a way to 
clarify
> what is meant by it? It could be a reference.

I’ve included a new terminology text as follows to address above comment 
and comment below:

   In addition, the following terms are used in this document:

   o  Verified association: is typically defined as an authenticated
  relationship with a device that initiated a call, for example, a
  subscriber account with a specific SIM card or set of SIP
  credentials.

   o  PASSporT: Defined in [RFC8225] is a JSON Web Token defined
  specifically for securing the identity of an initiator of personal
  communication.  This document defines a specific extension to
  PASSporT.

> 
> Nits/editorial comments:
> 
> * Terminology: I would have appreciated a short sentence mentioning 
[RFC8225]
> in the Terminology section.

see above

> 
> * Section 9: [RFC8224] appears without link.

fixed

> 
> * Acknowledgements: "The authors would like
>   acknowledge the work of the ATIS/SIP Forum IP-NNI Task Force to
>   develop the concepts behind this document." -> The authors would like to
>   acknowledge …
> 
fixed

> I do not repeat nits and editorials reported by Adam Roach in his review 
of
> this version of the document (11-19-2018,
> https://mailarchive.ietf.org/arch/msg/stir/HxVSCLPGfSgwFuvqLkWSVNI0PtQ )
> 

I have addressed these issues and plan to submit with list consensus on 
above text.




___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-stir-passport-shaken-04

[Francesca Palombini]

Reviewer: Francesca Palombini
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-stir-passport-shaken-04
Reviewer: Francesca Palombini
Review Date: 2018-11-02
IETF LC End Date: 2018-11-02
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is on the right track but has open issues, described in the
review.

Major issues:

* This draft defines the new claim "origid" for the Personal Attestation Token
used in the SHAKEN framework, but does not give any privacy considerations
about it and its use. [RFC6973] suggests that the privacy considerations of
IETF protocols be documented. As required by [RFC7258], work on IETF protocols
needs to consider the effects of pervasive monitoring and mitigate them when
possible. I don't know SHAKEN well enough to comment on privacy issues on that,
but this draft, as part of the IETF work, should have privacy considerations,
particularly considering the "origid" claim.

Minor issues:

* Section 4: the term "verified association" is not defined in this document,
nor in [RFC8225], nor in the SHAKEN spec referenced. Is there a way to clarify
what is meant by it? It could be a reference.

Nits/editorial comments:

* Terminology: I would have appreciated a short sentence mentioning [RFC8225]
in the Terminology section.

* Section 9: [RFC8224] appears without link.

* Acknowledgements: "The authors would like
   acknowledge the work of the ATIS/SIP Forum IP-NNI Task Force to
   develop the concepts behind this document." -> The authors would like to
   acknowledge ...

I do not repeat nits and editorials reported by Adam Roach in his review of
this version of the document (11-19-2018,
https://mailarchive.ietf.org/arch/msg/stir/HxVSCLPGfSgwFuvqLkWSVNI0PtQ )

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-dnsop-attrleaf-fix-04

[Francesca Palombini]

Reviewer: Francesca Palombini
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-dnsop-attrleaf-fix-04
Reviewer: Francesca Palombini
Review Date: 2018-09-24
IETF LC End Date: 2018-09-25
IESG Telechat date: Not scheduled for a telechat

Summary:

This draft is basically ready for publication, but has nits that should be
fixed before publication.

Major issues:

N/A

Minor issues:

N/A

Nits/editorial comments:

I give some proposal for clarification here, feel free to take them or leave
them. The idnits tool however produced several output, I would suggest to fix
those before publication.

   The use of underscored node names is specific to each RRTYPE that is
   being scoped.

As an non-expert in the area, I would have appreciate a ref to a document
introducing RRTYPE.

   This section provides a generic approach for changes to existing
   specifications that define straightforward use of underscored node
   names, when scoping the use of a "TXT" RRset.

Same for "TXT" RRset.

   An effort has been made to locate existing drafts that
   do this, register the global underscored names, and list them in this
   document.

Since the effort has been done, I would have appreciated the full list here.

   An
   effort has been made to locate existing drafts that do this, register
   the global underscored names, and list them in this document.

Same as previous comment.

   An effort has been made to locate
   existing drafts that do this and register the associated 'protocol'
   names.

Same as previous.

3.1. and 3.2. is the formatting of the updated sections (after "And is to be
updated to the new text:") wanted? Why not use the same format as in 3.3., with
OLD and NEW?

   +  Those registered by IANA in the "Service Name and Transport
Protocol Port Number Registry [RFC6335]"

Move the end quote after Registry.

   +  Those listed in "Enumservice Registrations [RFC6117].

Missing end quote after Registrations.

   " Signaling Trust Anchor Knowledge in DNS Security Extensions

Remove the space after the quote.

 John Levine, Bob Harold, Joel Jaeggli, Ondřej Sury and Paul

In Acknowledgements, one name is not encoded correctly.

>From running the idnits tool (https://tools.ietf.org/tools/idnits/), several
comments, warnings and one error were raised, which I snipped and pasted below
as a summary:

  -- The draft header indicates that this document updates RFC, but the
  abstract doesn't seem to mention this, which it should. (see
  https://www.ietf.org/id-info/checklist) --> I see that the abstract generally
  mentions "the existing specifications that use underscore naming", but I
  think to make this correct, it should explicitely list them as well.

  -- The document seems to lack a disclaimer for pre-RFC5378 work (See the
  Legal Provisions document at https://trustee.ietf.org/license-info for more
  information.)

  == Unused Reference: several documents are included in the list of
  references, but no explicit reference was found in the text --> if my
  editorial comments are taken, they should fix this one.

  ** Downref: Normative reference to an Informational RFC: RFC 7553

  -- Obsolete informational reference (is this intentional?): RFC 3921
 (Obsoleted by RFC 6121)

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] [core] Genart last call review of draft-ietf-core-object-security-13

[Francesca Palombini]

Hi Joel,

Thanks for your review! I now have updated the draft with improvements from 
your comments, see inline. Hope this clarifies.

Thanks,
Francesca

> -Original Message-
> From: core  On Behalf Of Joel Halpern
> Sent: den 20 juli 2018 04:08
> To: gen-art@ietf.org
> Cc: draft-ietf-core-object-security@ietf.org; i...@ietf.org; c...@ietf.org
> Subject: [core] Genart last call review of draft-ietf-core-object-security-13
> 
> Reviewer: Joel Halpern
> Review result: Ready
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-ietf-core-object-security-13
> Reviewer: Joel Halpern
> Review Date: 2018-07-19
> IETF LC End Date: 2018-07-30
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: this document is ready for publication as a Proposed Standard
> RFC.
> My minor concerns from draft -08 have been addressed.
> 
> Major issues: N/A
> 
> Minor issues:
> Section 7.2 is about sequence numbers.  The first sentence in 7.2 
> discusses
> Nonces.  Then the discussion switches to sequence numbers?  My guess is
> that the Nonce is left over from previous text?
> 

Actually, the first sentence discusses nonces since they are constructed from 
Partial IVs, which are basically the Sequence Numbers. I added this precision, 
at the end of the second sentence.

OLD:  An AEAD nonce MUST NOT be used more than once per AEAD key. The 
uniqueness of (key, nonce) pairs is shown in Appendix D.3, and in particular 
depends on a correct usage of Partial IVs.

NEW: An AEAD nonce MUST NOT be used more than once per AEAD key. The uniqueness 
of (key, nonce) pairs is shown in Appendix D.3, and in particular depends on a 
correct usage of Partial IVs (which encode the Sender Sequence Numbers, see 
Section 5).

> Nits/editorial comments:
> In the first paragraph of 3.3, the text reads:
>   The requirement that Sender ID SHALL be unique in the set of all security
>   contexts using the same Master Secret, Master Salt, and ID Context
>   guarantees unique (key, nonce) pairs, which avoids nonce reuse.
> Unfortunately, that is not a grammatical sentence.
> 
> 

I think this sentence was too long to be readable, so I tried to split it up. 
Hopefully it makes more sense now.

NEW: This means that Sender ID SHALL be unique in the set of all security 
contexts using the same Master Secret, Master Salt, and ID Context; such a 
requirement guarantees unique (key, nonce) pairs, which avoids nonce reuse.

> ___
> core mailing list
> c...@ietf.org
> https://www.ietf.org/mailman/listinfo/core

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-insipid-logme-marking-11

[Francesca Palombini]

Reviewer: Francesca Palombini
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-insipid-logme-marking-11
Reviewer: Francesca Palombini
Review Date: 2018-07-06
IETF LC End Date: 2018-07-10
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is on the right track but has open issues, described in the
review.

Major issues: -

Minor issues: The following are, in order of importance, the issues I have.
Following, I tried to point out the specific details in the doc, which, when
specified, might refer to one of those more general issues.

*A) Although the scenarios shown (4.1.2.x and 5.1.x) are very descriptive and
useful, it is quite difficult to extrapolate from the examples what is the
required behavior of UAs or proxies supporting the "log me" marking. For
example, Section 4.5.2.5 really gives requirements/rules on Proxy 1 (from the
originating Network), although from the way the document is structured, at
first glance one could think the section is about terminating network
requirements. Some rules are given in Section 4.2 and 4.3, but they seem to
cover only the stateless interaction. I think some additional text (possibly
introducing stateful processing, i.e. the first paragraph of 4.5.2 at the same
time) with rules for stateful processing is missing and could be added there.

*B) It is said in the doc that UAs or intermediaries MAY mark dialogs that are
"related" to the originally marked dialog. A pointer to what dialogs are
related to each other would be useful: from the doc, the example is REFER
relates to INVITE, and INVITE relates to REFER, any else? is there a section in
a specification that could be referenced, or a "rule" given (for example
dependent on local-UUID value, or other)?

*C) About error cases (section 5) I have several concerns:

- I don't see anywhere that those two described (marker missing from a
previously marked dialog and marker appearing mid dialog) are the
comprehensive list of error cases. Is that correct? What if a marker
disappear and then reappears? Is the intermediary supposed to keep logging
(because the marker did not appear mid-dialog) or not?

- The document explains that detecting error cases is difficult, and only
possible for stateful intermediaries. I'd like to see explicit requirements
for stateful intermediaries to be able to detect errors, and that such
requirements cover the comprehensive list of error cases described above.

- I seem to understand that the only consequence of an "error" case (for
the only 2 cases listed so far) is "stop logging and stop marking". Is that
correct? What about previously logged messages in the dialog? Should those
be kept? Deleted? It is not specified. This could be part of some security
considerations.

*D) I don't think Section 4.5.2.1.1 is at the right place. I think such a
section would fit better in the error handling section (Section 5) to explain
why some "missing markers" are errors while others aren't. Also, it actually
shows an example where log in marking is in fact supported by the originating
UA, so it should definitely not be under section 4.5.2.1, at worse it should be
under 4.5.2.2 (that is probably just an overlook).

*E) Terminology section missing: the drafts including the terminology are
referenced in the document, but it would have been good to have a section in
the beginning (sub-section of introduction is common) mentioning which ones
these are. At least RFC7989, possibly also RFC8123.

*F) I would suggest a reformulation of the rules in 4.2 and 4.3 to have a
separation: originating endpoint rules, then terminating endpoint rules for 4.2
and stateless intermediary, stateful intermediary in 4.3. This is just a
suggestion for better readability in my opinion, feel free to disregard.

Detailed Comments:

   This document defines a new header field parameter "logme" for the
   "Session-ID" header field.

Good with a reference for "Session-ID" header field, at the end of this
sentence. ---

   as a "log me" parameter since the session identifier is typically
   passed through SIP B2BUAs or other intermediaries, as per the
   Session-ID requirement REQ3 in ([RFC7206]).  The "logme" parameter

For B2BUA, see point E.
---

   Marking starts with a dialog-initiating request and continues for the
   lifetime of the dialog, and applies to each request and response in
   that dialog.

Can a ref be added for which are the "dialog-initiating request"? Or put it in
terminology (p

[Gen-art] Genart telechat review of draft-ietf-ippm-2330-ipv6-05

[Francesca Palombini]

Reviewer: Francesca Palombini
Review result: Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ippm-2330-ipv6-05
Reviewer: Francesca Palombini
Review Date: 2018-05-30
IETF LC End Date: 2018-04-25
IESG Telechat date: 2018-06-21

Summary: This draft is ready for publication as an Informational RFC.

Major issues: N/A

Minor issues: N/A

Nits/editorial comments: N/A


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-ippm-2330-ipv6-04

[Francesca Palombini]

Hi Al,

Thanks for addressing my comments, it looks good.

Francesca

> -Original Message-
> From: MORTON, ALFRED C (AL) 
> Sent: den 23 maj 2018 15:39
> To: Francesca Palombini ; gen-
> a...@ietf.org
> Cc: i...@ietf.org; i...@ietf.org; draft-ietf-ippm-2330-ipv6@ietf.org
> Subject: RE: Genart last call review of draft-ietf-ippm-2330-ipv6-04
> 
> Hi Francesca,
> one last item to resolve, we should be good now.
> see below,
> Al
> 
> > -----Original Message-
> > From: Francesca Palombini [mailto:francesca.palomb...@ericsson.com]
> > Sent: Friday, April 27, 2018 3:44 AM
> > To: MORTON, ALFRED C (AL) ; gen-art@ietf.org
> > Cc: i...@ietf.org; i...@ietf.org;
> > draft-ietf-ippm-2330-ipv6@ietf.org
> > Subject: RE: Genart last call review of draft-ietf-ippm-2330-ipv6-04
> >
> > Hi Al,
> >
> > Thanks for your reply.
> > I cut selected parts of the email to detail some of my comments, see
> > inline.
> >
> > Francesca
> >
> ...snip...
> > > > To be consistent with the first bullet of the list above ("It
> > > > includes a valid IP header: see below for version-specific
> > > > criteria."), I would rephrase the text above with something on the lines
> of:
> > > >
> > > > "For an IPvX (...) packet to be standard-formed, the IPvX-specific
> > > > criteria for a valid IP header are:"
> > > [acm]
> > > Your wording suggestion dropped the clear indication of a requirement.
> > > We are using the RFC2119 terms consistently for requirements.
> > >
> >
> > I was trying to point out that the first part of the section (first
> > bullet
> > list) does not use RFC2119 terms. I read the second bullet list as a
> > "sub- list" of the first one, which is why I was suggesting removing
> > the REQUIRED term. Or you could rephrase the first list to use REQUIRED
> too.
> > Anyway, this is nit-picking. Feel free to disregard.
> >
> [acm]
> I see your point now, and I changed the sentence introducing the initial (IP
> version-agnostic list) to read:
> 
> A packet is standard-formed if it meets all of the following REQUIRED 
> criteria:

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] Genart last call review of draft-ietf-ippm-2330-ipv6-04

[Francesca Palombini]

Hi Al,

Thanks for your reply.
I cut selected parts of the email to detail some of my comments, see inline. 

Francesca

> > (About MUST, was there any specific reason not to use the updated
> > boilerplate referencing RFC8174?)
> >
> [acm]
> You mean the Requirements Language RFC has been updated?
> News to me.  Will fix. Seems like the Nits check should catch that.
> Also, it can't be 8174 alone, the definitions of the terms has not changed.
> 

I think it does for Standard track docs.
Yes, I did mean the boilerplate that *also* references RFC8174 (which you can 
find in RFC8174) :) 

> > I would have appreciated a reference to a load balancing over parallel
> > paths example.
> [acm]
> ECMP is a rather well-known circumstance in IP networking today, as are
> other forms of load balancing, but I don't know of a canonical reference.
>

Ok. (This was just for my -or a generalist reader- sake, since I am not very 
knowledgeable in the area)

> > To be consistent with the first bullet of the list above ("It includes
> > a valid IP header: see below for version-specific criteria."), I would
> > rephrase the text above with something on the lines of:
> >
> > "For an IPvX (...) packet to be standard-formed, the IPvX-specific
> > criteria for a valid IP header are:"
> [acm]
> Your wording suggestion dropped the clear indication of a requirement.
> We are using the RFC2119 terms consistently for requirements.
> 

I was trying to point out that the first part of the section (first bullet 
list) does not use RFC2119 terms. I read the second bullet list as a "sub-list" 
of the first one, which is why I was suggesting removing the REQUIRED term. Or 
you could rephrase the first list to use REQUIRED too. Anyway, this is 
nit-picking. Feel free to disregard.

> [acm]
> We can add the pre-5378 disclaimer as a catch-all, but I doubt the original
> authors would make any fuss about the small amount of common text with
> 2330.
> Almes, Paxson, Mahdavi and Mathis are all gentlemen and the best of their
> time.
> 

I'm sure they are :) Just relaying what the id-nits told me.
___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

[Gen-art] Genart last call review of draft-ietf-ippm-2330-ipv6-04

[Francesca Palombini]

Reviewer: Francesca Palombini
Review result: Ready with Nits

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-ippm-2330-ipv6-??
Reviewer: Francesca Palombini
Review Date: 2018-04-23
IETF LC End Date: 2018-04-25
IESG Telechat date: Not scheduled for a telechat

Summary: This draft is basically ready for publication, but has nits that
should be fixed before publication.

Major issues: None

Minor issues: None

Nits/editorial comments:

Please note that most of the following comments are suggestions to make the
text more clear in my opinion. Feel free to disregard or fix as you prefer.

* Section 3:

"For example Neighbor Discovery
Protocol (NDP) [RFC4861] packets are transmitted with Hop Limit value
set to 255, and the validity test specifies that the Hop Limit MUST
have a value of 255 at the receiver, too.  So, while other tests may
intentionally exclude the TTL/Hop Limit value from their Type-P
definition, for this particular test the correct Hop Limit value is
of high relevance and MUST be part of the Type-P definition."

Regarding the use of MUST: The text above is not an absolute requirement of the
specification, but rather an example to a referenced document. In my opinion,
using "must" would be ok here.

(About MUST, was there any specific reason not to use the updated boilerplate
referencing RFC8174?)

* Section 3:

"Load balancing over parallel paths is one particular example where
such a class C would be more complex to determine in IPPM
measurements."

I would have appreciated a reference to a load balancing over parallel paths
example.

* Section 4:

"For an IPv4 ( [RFC0791] and updates) packet to be standard-formed,
the following additional criteria are REQUIRED:"

"For an IPv6 ([RFC8200] and updates) packet to be standard-formed, the
following criteria are REQUIRED:"

To be consistent with the first bullet of the list above ("It includes a valid
IP header: see below for version-specific criteria."), I would rephrase the
text above with something on the lines of:

"For an IPvX (...) packet to be standard-formed, the IPvX-specific criteria for
a valid IP header are:"

Also, note the space before "[RFC0791] and updates)"

* Section 4:

"An adaptation
layer enables the transfer IPv6 packets over networks having a MTU
smaller than the minimum IPv6 MTU."

NEW: "An adaptation
layer enables the transfer of IPv6 packets over networks having a MTU
smaller than the minimum IPv6 MTU."

* Section 5:

"All these changes MUST be reported."

I'd like more clarity on where they should be reported: does this mean they
MUST be reported when reporting the test results? Or on test spec? Either? Both?

* From id-nits check:

 (Using the creation date from RFC2330, updated by this document, for
 RFC5378 checks: 1998-02-23)

  -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
 have content which was first submitted before 10 November 2008.  If you
 have contacted all the original authors and they are all willing to grant
 the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
 this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
 (See the Legal Provisions document at
 https://trustee.ietf.org/license-info for more information.)

 IETF Trust Legal Provisions of 28-dec-2009, Section 6.c(iii):
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before
November 10, 2008.  The person(s) controlling the copyright in
some of this material may not have granted the IETF Trust the
right to allow modifications of such material outside the IETF
Standards Process. Without obtaining an adequate license from the
person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process,
and derivative works of it may not be created outside the IETF
Standards Process, except to format it for publication as an RFC
or to translate it into languages other than English.


___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art

Re: [Gen-art] review of draft-kivinen-802-15-ie-04.txt

[Francesca Palombini]

Francis, thanks a lot for your review.

Francesca

> -Original Message-
> From: Francis Dupont [mailto:francis.dup...@fdupont.fr]
> Sent: den 15 februari 2017 13:48
> To: gen-art@ietf.org
> Cc: draft-kivinen-802-15-ie@ietf.org
> Subject: review of draft-kivinen-802-15-ie-04.txt
> 
> I am the assigned Gen-ART reviewer for this draft. The General Area Review
> Team (Gen-ART) reviews all IETF documents being processed by the IESG for
> the IETF Chair.  Please treat these comments just like any other last call
> comments.
> 
> For more information, please see the FAQ at
> 
> .
> 
> Document: draft-kivinen-802-15-ie-04.txt
> Reviewer: Francis Dupont
> Review Date: 20170210
> IETF LC End Date: 20170214
> IESG Telechat date: 20170224
> 
> Summary: Ready
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments:
>  - ToC page 1 and 3 page 3 (title): Benefitting -> Benefiting
> 
>  - 3 page 3 (suggest):  CoRE etc, ->  CoRE, etc,
> 
>  - 4 page 3: reading the document I had a question about the "no need
>   ... to specify the internal structure" but the reason became clear
>   the next page. So I have no concern about this.
> 
> Regards
> 
> francis.dup...@fdupont.fr

___
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art