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

"Pete Resnick" <resnick@episteme.net> Thu, 22 August 2019 20:06 UTC

Return-Path: <resnick@episteme.net>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B28D120C2A; Thu, 22 Aug 2019 13:06:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_jErQLLaHfj; Thu, 22 Aug 2019 13:06:00 -0700 (PDT)
Received: from episteme.net (episteme.net [216.169.5.102]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6969D120C6E; Thu, 22 Aug 2019 13:06:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by episteme.net (Postfix) with ESMTP id 0050489EB98D; Thu, 22 Aug 2019 15:05:56 -0500 (CDT)
Received: from episteme.net ([127.0.0.1]) by localhost (episteme.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZH7y7rbuxEZ; Thu, 22 Aug 2019 15:05:53 -0500 (CDT)
Received: from [172.16.1.10] (episteme.net [216.169.5.102]) by episteme.net (Postfix) with ESMTPSA id 43ABD89EB984; Thu, 22 Aug 2019 15:05:53 -0500 (CDT)
From: Pete Resnick <resnick@episteme.net>
To: dominique.barthel@orange.com
Cc: gen-art@ietf.org, lp-wan@ietf.org, draft-ietf-lpwan-ipv6-static-context-hc.all@ietf.org, ietf@ietf.org
Date: Thu, 22 Aug 2019 15:05:52 -0500
X-Mailer: MailMate (1.12.5r5635)
Message-ID: <E14EDA10-6095-4648-A52D-1C360E27A4FF@episteme.net>
In-Reply-To: <2745_1566481911_5D5E9DF7_2745_475_4_D9846380.64301%dominique.barthel@orange.com>
References: <156514759648.27348.12561362180401012932@ietfa.amsl.com> <2745_1566481911_5D5E9DF7_2745_475_4_D9846380.64301%dominique.barthel@orange.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/q-ISMhSlnT-oY7TfXxkzhEAKZJA>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-lpwan-ipv6-static-context-hc-21
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Aug 2019 20:06:09 -0000

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

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

> Le 07/08/19 05:13, « Pete Resnick via Datatracker » 
> <noreply@ietf.org> 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