Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-straw-b2bua-rtcp-15

From: Jari Arkko <[email-masked]>
Date: Thu, 1 Dec 2016 10:30:35 +0200

Many thanks for your excellent review, Russ.

I plan to watch the resolution of the Discusses related to the unclear SHOULD NOT. (It certainly would have been a Discuss from me if a Discuss wasn’t already raised.)

At this point I do not plan to block on the document class, but looking forward to further discussion if people want to argue it.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 1 Dec 2016 11:30:29 +0200

Many thanks for your review, Russ, and for thinking about this space and what issues there might be.

I too am concerned about the issue that Russ Housley raised: bad practices in creating the freshness tokens creates a security issue. If this cannot be handled in the way that Russ initially suggested (setting a minimum number of bits) then a proper discussion of the issue and recommendations to avoid the problems need to be included in the security considerations section.

I fully recognise the point from the authors that different styles of creating the tokens result in different implications, and that setting a mere minimum number of bits may not be appropriate.

Jari

---

From: Michiko Short <[email-masked]>
Date: Thu, 1 Dec 2016 17:33:04 +0000

Ok, since answer not obvious starting thread on Kitten. 

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Thursday, December 1, 2016 1:30 AM
To: Benjamin Kaduk <[email-masked]>
Cc: Paul Miller (NT) <[email-masked]>; Michiko Short <[email-masked]>; IETF Gen-ART <[email-masked]>; [email-masked]
Subject: Re: [Gen-art] Gen-ART Review of draft-ietf-kitten-pkinit-freshness-07

Jari

---

From: Gabriel Montenegro <[email-masked]>
Date: Mon, 5 Dec 2016 21:42:07 +0000

Thanks Russ for your review.

Inline below ...

Gabriel

...
> Major Concerns: None
> 
> 
> Minor Concerns
> 
> In Section 3, it says:
> 
>    ... The values are from 0 to 255.  Values 0 and 255 are reserved
>    for future use.  These values are assigned by IANA. ...
> 
> The use of "these values" is ambiguous.  I think that you mean the values
> from 1 to 254, but based on the placement of this sentence, it could mean 0
> and 255.  Please reword to be very clear.

Reworded as follows:

s/These values/The remaining values from 1 to 254/
 
> In Section 3.1, it says:
> 
>    ... The closer to the end of the packet are the EET's, the
>    higher chance there is that a legacy node will recognize and
>    successfully process some dispatch type [RFC4944] before the EET and
>    then ignore the EET instead of dropping the entire packet.
> 
> I cannot figure out the first part of the sentence.  After reading it several
> times, I think the sentence it trying to say that placing an EET toward the
> front of the packet has a greater probability of causing the packet to be
> dropped than placing the same EET later in the packet.  Please reword.

That text now looks like this:

   ... However, a packet will get dropped by any node that does not
   understand the EET at the beginning of the packet.  Placing an EET
   toward the front of the packet has a greater probability of causing
   the packet to be dropped than placing the same EET later in the
   packet.  Placement of an EET later in the packet increases the chance
   that a legacy device will recognize and successfully process some
   dispatch type [RFC4944] before the EET.  In this case, the legacy
   device will ignore the EET instead of dropping the entire packet.
 
Hope that's clearer

> In Section 4, it says:
> 
>    [RFC5226] section 4.1 also indicates that "Specification Required"
>    implies a Designated Expert review of the public specification
>    requesting registration of the ESC Extension Type values.
> 
> s/implies/calls for/

Done

> Nits
> 
> The first paragraph of the Introduction has two sentences that begin with
> "However".  I think some minor rewording would make the intent more clear
> to all readers.

Good point, dropped the second "however". With the additional rewording you suggest below, I hope it works better.

> 
> The Introduction says:
> 
>    ...  However, in recent years with 6lowpan deployments,
>    implementations and standards organizations have started using the
>    ESC extension bytes and co-ordination between the respective
>    organizations and IETF/IANA is needed.
> 
> First: s/co-ordination/coordination/
> 
> Second: I am glad that we are seeing deployment.  That said, deployment
> itself is not a reason for coordination.  Rather, it seems that the experience
> has highlighted the need for an updated IANA registration policy.

This is what the relevant text looks like now:

   ...However, the
   octets and usage following the ESC dispatch type are not defined in
   either [RFC4944] and [RFC6282].  In recent years with 6lowpan
   deployments, implementations and standards organizations have started
   using the ESC extension octets.  This highlights the need for an
   updated IANA registration policy.
 
> In Section 3:
> s/Extended Dispatch Payload(EDP)/Extended Dispatch Payload(EDP)/

Perhaps you meant to add a space here? At any rate, we've done that already, so there is a space before the '('.
 
> In Section 4:
> s/IANA section/IANA Considerations section/

Fixed this instance as well as the one in the acks section.

Thanks!

---

From: Russ Housley <[email-masked]>
Date: Thu, 8 Dec 2016 17:04:20 -0500

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
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-6lo-dispatch-iana-registry-07
Reviewer: Russ Housley
Review Date: 2016-12-08
IETF LC End Date: 2016-12-08
IESG Telechat date: 2016-12-15

Summary: Ready

Thank you for addressing my comments on version -06 of this document.

Major Concerns: None

Minor Concerns: None

Nit:  In Section 1, paragraph 1, it says:

	... not defined in either [RFC4944] and [RFC6282].

s/and/or/

---

From: Gabriel Montenegro <[email-masked]>
Date: Thu, 8 Dec 2016 22:14:26 +0000

Thanks for the quick turnaround, Russ!

I've corrected this in my working copy. Will wait a couple more days in case there are other nits or comments coming in...

Thanks,

Gabriel

> From: Russ Housley [mailto:[email-masked]]
> Sent: Thursday, December 8, 2016 14:04
> To: [email-masked]
> Cc: IETF Gen-ART <[email-masked]>
> Subject: Gen-ART Review of draft-ietf-6lo-dispatch-iana-registry-07
> 
> 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.
>

---

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Dec 2016 15:21:57 +0200

Russ, Gabriel,

Thank you very much for the review and fixes.

I have balloted “no-objection”.

Jari