Re: [Gen-art] Genart last call review of draft-ietf-babel-dtls-05

[David Schinazi]

Thanks Dan. I've pushed a commit with your suggestions:
https://github.com/jech/babel-drafts/commit/8d6a6fc05ce4c621b38d2c7621c4157300380078

We'll upload -06 at the end of this round of comments.

David

On Tue, Jun 25, 2019 at 11:41 AM Dan Romascanu  wrote:

> Thanks for the quick reply.
>
> See in-line.
>
> regards,
>
> Dan
>
>
> On Tue, Jun 25, 2019 at 9:29 PM David Schinazi 
> wrote:
>
>> Hello Dan, and thanks for your review. Comments inline.
>>
>> 1. In section 2.1:
>>>
>>> > The default port
>>>for Babel over DTLS is registered with IANA as the "babel-dtls" port
>>>(UDP port TBD, see Section 4), and the port exchanging unencrypted
>>>Babel traffic is registered as the "babel" port (UDP port 6696).
>>>
>>> A reference would be desirable here.
>>>
>>
>> What reference do you have in mind? This paragraph already has a
>> reference to Section 4 (IANA Considerations).
>>
>
> the section in the Babel spec that defines the "babel" port (UDP port
> 6696, see )
>
>
>
>>
>>> 2. In section 2.4
>>>
>>> > Nodes MUST silently ignore any unprotected
>>>packet sent over unicast.  When parsing an unprotected packet, a node
>>>MUST silently ignore all TLVs that are not of type Hello.  Nodes MUST
>>>also silently ignore any unprotected Hello with the Unicast flag set.
>>>
>>> Is the last sentence necessary? Is this case not covered by the
>>> statement in
>>> the first sentence?
>>>
>>
>> The Unicast flag is a bit in the Babel packet. This statement instructs
>> nodes
>> to ignore a Hello TLV which was received over multicast but has the
>> unicast flag set.
>>
>
> Thanks for the clarification.
>
>
>> Thanks,
>> David
>>
>>
>
___
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-babel-dtls-05

[Dan Romascanu]

Thanks for the quick reply.

See in-line.

regards,

Dan


On Tue, Jun 25, 2019 at 9:29 PM David Schinazi 
wrote:

> Hello Dan, and thanks for your review. Comments inline.
>
> 1. In section 2.1:
>>
>> > The default port
>>for Babel over DTLS is registered with IANA as the "babel-dtls" port
>>(UDP port TBD, see Section 4), and the port exchanging unencrypted
>>Babel traffic is registered as the "babel" port (UDP port 6696).
>>
>> A reference would be desirable here.
>>
>
> What reference do you have in mind? This paragraph already has a
> reference to Section 4 (IANA Considerations).
>

the section in the Babel spec that defines the "babel" port (UDP port 6696,
see )



>
>> 2. In section 2.4
>>
>> > Nodes MUST silently ignore any unprotected
>>packet sent over unicast.  When parsing an unprotected packet, a node
>>MUST silently ignore all TLVs that are not of type Hello.  Nodes MUST
>>also silently ignore any unprotected Hello with the Unicast flag set.
>>
>> Is the last sentence necessary? Is this case not covered by the statement
>> in
>> the first sentence?
>>
>
> The Unicast flag is a bit in the Babel packet. This statement instructs
> nodes
> to ignore a Hello TLV which was received over multicast but has the
> unicast flag set.
>

Thanks for the clarification.


> Thanks,
> David
>
>
___
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-babel-dtls-05

[David Schinazi]

Hello Dan, and thanks for your review. Comments inline.

1. In section 2.1:
>
> > The default port
>for Babel over DTLS is registered with IANA as the "babel-dtls" port
>(UDP port TBD, see Section 4), and the port exchanging unencrypted
>Babel traffic is registered as the "babel" port (UDP port 6696).
>
> A reference would be desirable here.
>

What reference do you have in mind? This paragraph already has a
reference to Section 4 (IANA Considerations).


> 2. In section 2.4
>
> > Nodes MUST silently ignore any unprotected
>packet sent over unicast.  When parsing an unprotected packet, a node
>MUST silently ignore all TLVs that are not of type Hello.  Nodes MUST
>also silently ignore any unprotected Hello with the Unicast flag set.
>
> Is the last sentence necessary? Is this case not covered by the statement
> in
> the first sentence?
>

The Unicast flag is a bit in the Babel packet. This statement instructs
nodes
to ignore a Hello TLV which was received over multicast but has the unicast
flag set.

Thanks,
David
___
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-babel-dtls-05

[Dan Romascanu via Datatracker]

Reviewer: Dan Romascanu
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-babel-dtls-05
Reviewer: Dan Romascanu
Review Date: 2019-06-25
IETF LC End Date: 2019-07-04
IESG Telechat date: Not scheduled for a telechat

Summary:

The document is Ready from a Gen-ART perspective. A couple of unclear /
redundant statements are mentioned in the 'nits/editorial comments' bullet
below.

Major issues:

Minor issues:

Nits/editorial comments:

1. In section 2.1:

> The default port
   for Babel over DTLS is registered with IANA as the "babel-dtls" port
   (UDP port TBD, see Section 4), and the port exchanging unencrypted
   Babel traffic is registered as the "babel" port (UDP port 6696).

A reference would be desirable here.

2. In section 2.4

> Nodes MUST silently ignore any unprotected
   packet sent over unicast.  When parsing an unprotected packet, a node
   MUST silently ignore all TLVs that are not of type Hello.  Nodes MUST
   also silently ignore any unprotected Hello with the Unicast flag set.

Is the last sentence necessary? Is this case not covered by the statement in
the first sentence?


___
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-lamps-pkix-shake-08

[Alissa Cooper]

Apologies, I thought the concern remained about the TBD identifiers in the 
document.
Alissa

> On Jun 25, 2019, at 12:28 PM, Joel M. Halpern  wrote:
> 
> The latest version (which I reviewed yesterday) has the assignments.
> Joel
> 
> On 6/25/19 12:27 PM, Alissa Cooper wrote:
>> Joel, thanks for your reviews. I entered a No Objection ballot. I trust that 
>> the identifier assignments will work out with NIST.
>> Alissa
>>> On Mar 31, 2019, at 1:28 AM, Joel M. Halpern  wrote:
>>> 
>>> Maybe a note that the assignment will take place once the drafts are 
>>> approved, and that the RFC should coordiante with the authors and NIST on 
>>> this?  (I presume we have done this before, and we do not have the problem 
>>> we have in some other cases of "no number until RFC" / "no RFC until 
>>> number".)
>>> 
>>> Yours,
>>> Joel
>>> 
>>> On 3/31/19 1:21 AM, Russ Housley wrote:
> On Mar 30, 2019, at 5:55 AM, Joel Halpern via Datatracker 
>  wrote:
> 
> Reviewer: Joel Halpern
> 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-lamps-pkix-shake-08
> Reviewer: Joel Halpern
> Review Date: 2019-03-30
> IETF LC End Date: 2019-04-10
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary: This document is almost ready for publication as a Proposed 
> Standard
> 
> Major issues:
>One of the key points of this RFC seems to be to assign the 
> identifiers for
>the use of the two SHAKE variants.  It is thus confusing that the
>identifiers end with "TBD", and thus are not defined in this document.
 They will be assigned by NIST once they are sure that these are the 
 identifiers that we want.  This is much the same as we do when IANA is ti 
 assign the identifier.
 Russ
>>> 
>>> ___
>>> Gen-art mailing list
>>> Gen-art@ietf.org
>>> https://www.ietf.org/mailman/listinfo/gen-art

___
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-lamps-pkix-shake-08

[Joel M. Halpern]

The latest version (which I reviewed yesterday) has the assignments.
Joel

On 6/25/19 12:27 PM, Alissa Cooper wrote:

Joel, thanks for your reviews. I entered a No Objection ballot. I trust that 
the identifier assignments will work out with NIST.

Alissa


On Mar 31, 2019, at 1:28 AM, Joel M. Halpern  wrote:

Maybe a note that the assignment will take place once the drafts are approved, and that the RFC 
should coordiante with the authors and NIST on this?  (I presume we have done this before, and we 
do not have the problem we have in some other cases of "no number until RFC" / "no 
RFC until number".)

Yours,
Joel

On 3/31/19 1:21 AM, Russ Housley wrote:

On Mar 30, 2019, at 5:55 AM, Joel Halpern via Datatracker  
wrote:

Reviewer: Joel Halpern
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-lamps-pkix-shake-08
Reviewer: Joel Halpern
Review Date: 2019-03-30
IETF LC End Date: 2019-04-10
IESG Telechat date: Not scheduled for a telechat

Summary: This document is almost ready for publication as a Proposed Standard

Major issues:
One of the key points of this RFC seems to be to assign the identifiers for
the use of the two SHAKE variants.  It is thus confusing that the
identifiers end with "TBD", and thus are not defined in this document.

They will be assigned by NIST once they are sure that these are the identifiers 
that we want.  This is much the same as we do when IANA is ti assign the 
identifier.
Russ


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




___
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-lamps-pkix-shake-08

[Alissa Cooper]

Joel, thanks for your reviews. I entered a No Objection ballot. I trust that 
the identifier assignments will work out with NIST.

Alissa

> On Mar 31, 2019, at 1:28 AM, Joel M. Halpern  wrote:
> 
> Maybe a note that the assignment will take place once the drafts are 
> approved, and that the RFC should coordiante with the authors and NIST on 
> this?  (I presume we have done this before, and we do not have the problem we 
> have in some other cases of "no number until RFC" / "no RFC until number".)
> 
> Yours,
> Joel
> 
> On 3/31/19 1:21 AM, Russ Housley wrote:
>>> On Mar 30, 2019, at 5:55 AM, Joel Halpern via Datatracker 
>>>  wrote:
>>> 
>>> Reviewer: Joel Halpern
>>> 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-lamps-pkix-shake-08
>>> Reviewer: Joel Halpern
>>> Review Date: 2019-03-30
>>> IETF LC End Date: 2019-04-10
>>> IESG Telechat date: Not scheduled for a telechat
>>> 
>>> Summary: This document is almost ready for publication as a Proposed 
>>> Standard
>>> 
>>> Major issues:
>>>One of the key points of this RFC seems to be to assign the identifiers 
>>> for
>>>the use of the two SHAKE variants.  It is thus confusing that the
>>>identifiers end with "TBD", and thus are not defined in this document.
>> They will be assigned by NIST once they are sure that these are the 
>> identifiers that we want.  This is much the same as we do when IANA is ti 
>> assign the identifier.
>> Russ
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

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

Re: [Gen-art] review of draft-ietf-roll-efficient-npdao-10.txt

[Alissa Cooper]

Francis, thank you for your review. I entered a No Objection ballot.

Alissa

> On May 13, 2019, at 8:47 AM, Francis Dupont  wrote:
> 
> 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: Ready
> Reviewer: Francis Dupont
> Review Date: 2019/05/11
> IETF LC End Date: 2019/05/21
> IESG Telechat date: unknown
> 
> Summary: Ready
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments: 
> - ToC page 2: bad padding in 2. and 2.1. titles in text format.
> 
> - ToC page 2 and many other places: there is a problem with the
>  "acknowledgement" word spelling: correct spelling is "acknowledgment"
>  but the term is used both in the protocol including in the ToC and
>  in the document for its acknowledgments usual section.
> 
>  I propose if the other protocol documents use the UK "acknowledgement"
>  spelling to keep it for similar usages. In all cases the section title
>  should be in US spelling so Acknowledgments.
> 
> - 4.1 page 7, 4.4 5. page 12 and A.1 5. page 18: i.e. -> i.e.,
> 
> - 4.3.1 page 10: atleast -> at least
> 
> - 4.3.3 page 10: seqeunce -> sequence
> 
> - 4.5.2 page 12: signalling -> signaling
> 
> - 5 page 14 title: Acknowledgements -> Acknowledgments
> 
> - from 6 page 14 to 6.3 page 16: Acknowledgement -> Acknowledgment
> 
> - 6.1, 6.2 and 6.3 pages 15 and 16: there is a problem with the textual
>  rendering of qualities: I got "oBit number..." without a space between
>  the "o" and the entry name "Bit number".
> 
> - authors page 21: please consider China -> PR China or simply move
>  from country names to ISO IS 3166 2 letter codes (for instance
>  France -> FR)?
> 
> Regards
> 
> francis.dup...@fdupont.fr
> 
> PS: as they are mostly aesthetic points there is no need to address them
> by a new draft and BTW the RFC Editor can handle them.
> 
> ___
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art

___
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-mpls-egress-protection-framework-05

[Yimin Shen]

Hi Peter,

Thanks very much for your detailed review for this draft! We will fix these 
issues in the next version.

Thanks,

-- Yimin Shen

On 6/21/19, 12:50 AM, "Peter Yee via Datatracker"  wrote:

Reviewer: Peter Yee
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


.

Document: draft-ietf-mpls-egress-protection-framework-05
Reviewer: Peter Yee
Review Date: 2019-06-20
IETF LC End Date: 2019-06-17
IESG Telechat date: Not scheduled for a telechat

Summary: Ready with Nits.  I didn't really find any substantial issues with 
the
document, although I admit this one is quite out of my area of expertise.  
I'm
reduced to making sure it sounds logical (it does) and trying to reduce the
(future) burden on the RFC Editor.

Major issues:

Minor issues:

Nits/editorial comments:

General:

For each occurrence of "e.g." and "i.e.", make sure that it is followed by a
comma and a single space.  There are some occurrences of double spaces and
pretty much no commas.

Change "aka." to "aka" or to "a.k.a."

Specific:

Page 1, Abstract, 3rd sentence: change "context based" to "context-based".

Page 3, section 1, 2nd paragraph, 1st sentence: change "repair based" to
"repair-based".  Insert "and" before "[RFC7812]" or put the sequence of
references inside of parentheses.

Page 3, section 1, 2nd paragraph, 2nd sentence: delete the comma and "i.e."
after "PLR".  Put "point of local repair" in brackets.  Delete the comma and
"i.e." after "MP" and place "merge point" inside brackets.

Page 7, section 4, 1st bullet item: append a comma after the first 
occurrence
of "MP2P".

Page 7, section 4, 4th bullet item, 2nd sentence: insert "on a" before
"per-service-destination".

Page 9, 1st bullet item: change "Or" to "or".

Page 10, 1st partial paragraph, last sentence: change "It" to "it".

Page 10, section 5.4, 2nd paragraph, 3rd sentence: delete extraneous space
between "{E, P1}" and the following comma.

Page 11, section 5.7 title: change "context based" to "context-based".

Page 14, item 3, 4th sentence: change "any-cast" to "anycast".

Page 14, item 3, last sentence: I can't parse the end of that sentence.  Do 
you
want one or the other of "to" and "in", or is there a word or words missing 
in
there?

Page 15, 1st paragraph, 1st sentence: append "of" after "AS'".  And I'll 
just
say that that's a very labored construction to avoid using "ASs" or "AS's" 
in
the sentence.  It took be a while to parse what was meant.

Page 16, 1st full paragraph, 1st sentence: insert "the" before "PLR".

Page 18, 1st paragraph, last sentence: change the first occurrence of "in" 
to
"if".

Page 19, 1st partial paragraph, 1st full sentence: change "Figure-3" to 
"Figure
3" to match the figure's actual labeling.

Page 21, section 8, 1st sentence: append a comma after "far".

Page 25, section 11, 2nd paragraph, 2nd sentence: insert "of" before 
"trust".




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