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@xxxxxxxx> 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@xxxxxxxx > https://www.ietf.org/mailman/listinfo/gen-art
