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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

On 22 Aug 2019, at 8:51, dominique.barthel@xxxxxxxxxx wrote:

Le 07/08/19 05:13, « Pete Resnick via Datatracker » <noreply@xxxxxxxx> a
écrit :

Section 7.1 or 7.3:

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

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
you'd want 28 bits instead of 24. The larger sizes could simply be 0xFF
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.

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?

8.2.4:

"The W field is optional" - Is OPTIONAL not appropriate here? If so, this
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.

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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux