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.