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

From: Pete Resnick via Datatracker <[email-masked]>
Date: Tue, 06 Aug 2019 20:13:16 -0700

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.

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 21 Aug 2019 21:03:53 -0400

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 <[email-masked]> wrote:
> 
> Reviewer: Pete Resnick
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: <[email-masked]>
Date: Thu, 22 Aug 2019 13:51:50 +0000

Hello Pete,

Please accept our sincere thanks for your time reviewing and commenting on
this draft.
Your comments do help us shape a better draft.
Please see answers and questions inlined in your text.
Best regards

Dominique

Le 07/08/19 05:13, « Pete Resnick via Datatracker » <[email-masked]> a

>to be fragmented. If you're fragmenting, it's not optional, is it?
DB: some LPWAN technologies have their own fragmentation technique (e.g.
NB-IoT), and as part of their Profile, they might want to specify that
SCHC Fragmentation shall not be used.
In such a case, even though fragmentation is needed, SCHC Fragmentation is
not used.
How about
OLD TEXT
If the SCHC Packet is to be fragmented, the optional SCHC Fragmentation
MAY be applied to the SCHC Packet.
NEW TEXT
If needed by the underlying layer, the optional SCHC Fragmentation MAY be
applied to the SCHC Packet.

>versed in this topic, but it wasn't for me.
[DB] your proposed rephrasing is not quite accurate. We are looking for a
Rule that
has a function for all of the header fields and *no more* than the header
fields in the packet being compressed. This is reflected in the detailed
algorithm.
Regarding an overview statement, how about changing
OLD TEXT
the set of Rules is browsed to identify which Rule will be used to
compress the packet header.
The Rule is selected by matching the Fields Descriptions to the packet
header. The detailed steps are the following:
NEW TEXT
the general idea is to find in the Rule set a Rule that has a matching
Field Descriptor (given the DI and FP) for exactly each and every header
field of the packet being compressed. The detailed algorithm is the
following:

Also, I realised we use the word "steps" at two indentation levels. I
suggest we change
OLD TEXT
The compression/decompression process follows several steps
NEXT TEXT
The compression/decompression process follows several phases

>happens if you find more than one? That should probably be specified.
DB: indeed, this specification does not prevent multiple Rules from
matching. We have kept silent about this in order to keep the text small
and to avoid ensuing discussions.
But since you're asking, how about adding the following?
NEW TEXT
This specification does not prevent multiple Rules from matching. Whether
a multiple match is allowed or not, and what to do in the case where
multiple Rules match, is left to the implementation. A long as the same
Rule set is installed at both ends, this degree of freedom does not
constitute an interoperability issue.

>followed by the 16-bit value.
[DB] I don't quite understand his proposal. Is it a two-sized approach (4
bits and 24 bits), or a three-sized approach (4, 12 and 24 bits). In the
former case, we pay a high cost for value sizes 15 and upward. In the
latter case, the intermediate size (12 bits) is only applicable to value
size 15 (or 15-31?). I like the three-sized approach and suggest we don't
change our current spec. We expect the 4 and 12 bits encodings to be used
most of the time, and added the 24 bits encoding as a safety net.

>Sending a compressed header may also require F/R, couldn't it? Seems to
DB: you're right, in a pure logic sense. The aim of "may" was to attract
attention to the likeliness that fragmentation be required. Another
reviewer suggested 
OLD TEXT
Sending an uncompressed header may require SCHC F/R.

NEW TEXT
Sending an uncompressed header is likely to require SCHC F/R.

>"OPTIONAL", in the 2119 sense. Is there a reason they're not?
DB: True, thanks for catching this. The second one should be capital
letters.

>mean, "You can ignore the rest of section 8"? That seems unnecessary to
DB: thanks for your opinion on this. We will remove this sentence.

>in order to avoid someone being inordinately cute (or stupid).
DB: Definitely true, this was a shortcoming of ours. We'll change this
text to say "increment by 1" or "increase by 1" as suggested.

>appears in many places in section 8.
DB: True. I haven't paid enough attention to the use of capital OPTIONAL,
overall. I will give it another pass.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: "Pete Resnick" <[email-masked]>
Date: Thu, 22 Aug 2019 15:05:52 -0500

Thanks for the changes. Followup comments inline below; trimming the 
ones that already look fine.

> field of the packet being compressed. The detailed algorithm is the

I would use "all and only those header fields that appear in the packet" 
instead of "each and every header field of the packet". The phrase "each 
and every" is so idiomatic in English that I think the native English 
speakers might misread it. But otherwise I think this is fine.

>> 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

Three sizes is fine, but I thought that you should have:

- 0 to 14 : 4 bits
- 15 to 254 : 12 bits, 0b1111 followed by the value in 8 bits
- 255 to 65535 : 24 bits, 0xff followed by the value in 16 bits

Why do you need the 4 extra bits?

> overall. I will give it another pass.

The places where it's appropriate are places where an implementer needs 
to take notice that they have to implement the cases with and without 
the feature.

As I said above, all of your other changes look great. Thanks for taking 
my comments into account.

pr
-- 
Pete Resnick http://www.episteme.net/
All connections to the world are tenuous at best