Re: [Gen-art] Gen-ART Review of draft-ietf-6lo-dispatch-iana-registry-06

[Gabriel Montenegro <[e-mail]>]

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!