Re: [Gen-art] Genart last call review of draft-ietf-lpwan-ipv6-static-context-hc-21

Pete, thanks for your review. I referenced it in my No Objection ballot.

Alissa

> On Aug 6, 2019, at 11:13 PM, Pete Resnick via Datatracker <noreply@ietf.org> wrote:
> 
> Reviewer: Pete Resnick
> 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-lpwan-ipv6-static-context-hc-21
> Reviewer: Pete Resnick
> Review Date: 2019-08-06
> IETF LC End Date: 2019-07-19
> IESG Telechat date: Not scheduled for a telechat
> 
> Summary:
> 
> Some minor issues, but otherwise looks good to me.
> 
> My apologies for this very late review. I hope these comments are useful, but
> none of these are showstoppers in my opinion.
> 
> Major issues:
> 
> None.
> 
> Minor issues:
> 
> Section 5:
> 
>   If the SCHC
>   Packet is to be fragmented, the optional SCHC Fragmentation MAY be
>   applied to the SCHC Packet.
> 
> Don't you mean:
> 
>   If the SCHC Packet is to be fragmented, the OPTIONAL SCHC
>   Fragmentation is applied to the SCHC Packet.
> 
> or even just:
> 
>   SCHC Fragmentation is applied if the SCHC Packet is to be fragmented.
> 
> I think it's confusing to say that using SCHC is optional if the SCHC Packet is
> to be fragmented. If you're fragmenting, it's not optional, is it?
> 
> Section 7.1 or 7.3:
> 
> It took me a while to get that what you're looking for is a Rule in the list of
> Rules that has a function for *all* of the header fields given the DI and FP.
> It would be good to say some sort of overview thing like this explicitly,
> either in 7.1 or at the top of 7.3. It's possible this is obvious to someone
> versed in this topic, but it wasn't for me.
> 
> Section 7.3:
> 
> Question: Is it possible for multiple Rules to match a given packet? What
> happens if you find more than one? That should probably be specified.
> 
> Section 7.5.2:
> 
> This encoding seems to use more space than needed. I assume you kept the size
> in multiples of 4 to make it on nibble boundaries, but I don't understand why
> you'd want 28 bits instead of 24. The larger sizes could simply be 0xFF
> followed by the 16-bit value.
> 
> Nits/editorial comments:
> 
> Section 7.3:
> 
> In the last bullet of the Rule selection algorithm, it says:
> 
>   Sending an uncompressed header may require SCHC F/R.
> 
> Sending a compressed header may also require F/R, couldn't it? Seems to me this
> sentence is superfluous.
> 
> Section 8.1, second paragraph:
> 
> It seems like you'd want one or both occurrences of "optional" to be
> "OPTIONAL", in the 2119 sense. Is there a reason they're not?
> 
> I'm not sure I understand the last sentence of that paragraph. Do you simply
> mean, "You can ignore the rest of section 8"? That seems unnecessary to say.
> 
> Section 8.2.2.2:
> 
> Change:
> 
>   o  their numbers MUST increase from 0 upward, from the start of the
>      SCHC Packet to its end.
> 
> to:
> 
>   o  their numbers MUST increase by 1 from 0 upward, from the start of
>      the SCHC Packet to its end.
> 
> in order to avoid someone being inordinately cute (or stupid).
> 
> 8.2.4:
> 
> "The W field is optional" - Is OPTIONAL not appropriate here? If so, this
> appears in many places in section 8.
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art