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

Laurent Toutain <laurent.toutain@imt-atlantique.fr> Fri, 06 March 2020 07:51 UTC

Return-Path: <laurent.toutain@imt-atlantique.fr>
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 F16EC3A0940; Thu, 5 Mar 2020 23:51:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=imt-atlantique.fr
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 0PQmDfCY4T6A; Thu, 5 Mar 2020 23:51:29 -0800 (PST)
Received: from zproxy110.enst.fr (zproxy110.enst.fr [137.194.2.192]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F294E3A0942; Thu, 5 Mar 2020 23:51:28 -0800 (PST)
Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id 7362681EEC; Fri, 6 Mar 2020 08:51:26 +0100 (CET)
Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10032) with ESMTP id OWozGwpWSFN8; Fri, 6 Mar 2020 08:51:25 +0100 (CET)
Received: from localhost (localhost [IPv6:::1]) by zproxy110.enst.fr (Postfix) with ESMTP id DB13C81915; Fri, 6 Mar 2020 08:51:25 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.10.3 zproxy110.enst.fr DB13C81915
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=imt-atlantique.fr; s=50EA75E8-DE22-11E6-A6DE-0662BA474D24; t=1583481085; bh=/OHJBf5qBTRpa+nABcm70icFQCuIH7Ro5i7cbnutWhc=; h=MIME-Version:From:Date:Message-ID:To; b=CdNrzt/JGXhj1w+UC8vUhI/s0qx4Wk+oEskI27+7/3wI/QOrGwMPLVnt95V0nobBQ Qw8xXVnbYiIHIDjP6JKX5Y6ThoAngZnSdXi/Ji2foZcEWbdl3zCevfxRxhNDb6wvZK kvD0nFFoGgs62MKz4pNVEPEPfoOHEq4lp5fFIO5Y=
X-Virus-Scanned: amavisd-new at zproxy110.enst.fr
Received: from zproxy110.enst.fr ([IPv6:::1]) by localhost (zproxy110.enst.fr [IPv6:::1]) (amavisd-new, port 10026) with ESMTP id GTILrE7KfEBG; Fri, 6 Mar 2020 08:51:25 +0100 (CET)
Received: from mail-yw1-f44.google.com (mail-yw1-f44.google.com [209.85.161.44]) by zproxy110.enst.fr (Postfix) with ESMTPSA id 75F9E81F0C; Fri, 6 Mar 2020 08:51:25 +0100 (CET)
Received: by mail-yw1-f44.google.com with SMTP id o186so1460395ywc.1; Thu, 05 Mar 2020 23:51:25 -0800 (PST)
X-Gm-Message-State: ANhLgQ3d6N/wtPFBxvKtOjAJQWuQUsNKOw63icKtP+Wo/Nucz7y74d48 LTkdzeN0MD8dQ4bEA3cSp2iV0t0mludYpFCCT14=
X-Google-Smtp-Source: ADFU+vuk1zzKfDgI9Cy+0nRild8lvHbNkdsGQWYEHtuvuAz6J+2uEB9TNPSpaP9Nnaifhm8oS5XW16LKS0vM/O1mXfE=
X-Received: by 2002:a25:4cc:: with SMTP id 195mr2300061ybe.249.1583481084234; Thu, 05 Mar 2020 23:51:24 -0800 (PST)
MIME-Version: 1.0
References: <158134757509.4049.18293449395965880444@ietfa.amsl.com> <CAAbr+nSgQjD1o==i5rPQgAv7mA8buWueCUMkHnt=Ls=s09QXwQ@mail.gmail.com> <f63d996b-f13f-e574-65f0-fdd091b1c5fb@tenghardt.net>
In-Reply-To: <f63d996b-f13f-e574-65f0-fdd091b1c5fb@tenghardt.net>
From: Laurent Toutain <laurent.toutain@imt-atlantique.fr>
Date: Fri, 06 Mar 2020 08:50:46 +0100
X-Gmail-Original-Message-ID: <CABONVQYgc_Mtuxh4rzsyhAg_DJmTMWfd2Wn9f3nqdVKdY77__g@mail.gmail.com>
Message-ID: <CABONVQYgc_Mtuxh4rzsyhAg_DJmTMWfd2Wn9f3nqdVKdY77__g@mail.gmail.com>
To: Theresa Enghardt <ietf@tenghardt.net>
Cc: Ana Minaburo <ana@ackl.io>, gen-art@ietf.org, lp-wan <lp-wan@ietf.org>, last-call@ietf.org, draft-ietf-lpwan-coap-static-context-hc.all@ietf.org, lpwan-chairs@ietf.org, Ricardo Andreasen <randreasen@fi.uba.ar>, Xavier Lagrange <xavier.lagrange@imt-atlantique.fr>
Content-Type: multipart/alternative; boundary="00000000000088d19405a02aeb98"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/Wmb-azGY0hAi5zow0LARThWfPuk>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-lpwan-coap-static-context-hc-12
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: Fri, 06 Mar 2020 07:51:33 -0000

Hi Theresa,

Thank you again for your in-depth review. We have published a version 13
with the modifications, see below:

On Mon, Mar 2, 2020 at 2:10 PM Theresa Enghardt <ietf@tenghardt.net> wrote:

> Dear Ana,
>
> Thank you for the responses to my comments and for the improvements to the
> document.
>
> Please find responses to some of your points and some suggestions inline:
> On 25.02.20 23:26, Ana Minaburo wrote:
>
>
> Minor issues:
>>
>> Abstract
>> To make the abstract more self-contained, I suggest adding a brief
>> description
>> of what SCHC is, then stating explicitly that so far SCHC has been
>> defined for
>> UDP and IPv6, and this document defines it for CoAP. Then the abstract
>> can keep
>> the two examples of how CoAP presents some unique challenges for using
>> SCHC,
>> but it should clearly say that these are examples, as Section 3 later
>> lists
>> more differences. Finally, perhaps it's worth making the last sentence
>> more
>> concrete to say how the document addresses these challenges. Maybe
>> something
>> like: The document gives guidance on how to apply SCHC to flexible
>> headers and
>> how to leverage the asymmetry for more efficient compression rules.
>>
>> Ana: Thanks for this input, the new version of the abstract is:
>
> "This draft defines the way SCHC (Static Context Header Compression)
> header compression can be applied to CoAP protocol. SCHC is a header
> compression mechanism adapted for constrained devices. SCHC uses a static
> description of the header to reduce the redundancy and the size of the
> information in the header. While the RFC8724 describes the SCHC compression
> and fragmentation framework, and its application for IPv6/UDP headers, this
> document applies the use of SCHC for CoAP headers. The CoAP header
> structure differs from IPv6 and UDP one since CoAP uses a flexible header
> with a variable number of options, themselves of variable length. The CoAP
> protocol messages format is asymmetric: the request messages have a header
> format different from the one in the response messages. This specification
> gives guidance on how to apply SCHC to flexible headers and how to leverage
> the asymmetry for more efficient compression Rules."
>
> TE: Thanks, this makes the abstract much more self-contained. Some
> suggested nits here:
> "can be applied to CoAP protocol" --> "can be applied to the CoAP protocol"
> "While the RFC8724 describes" --> "While RFC8724 describes"
> "differs from IPv6 and UDP one" --> "differs from IPv6 and UDP" or
> "differs from the IPv6 and UDP one"
>
> LT: Done

>
> "The context(s) is(are) known by both ends before transmission." - As
>> someone
>> not yet familiar with SCHC, it would be really helpful to have one or two
>> sentences here explaining how this usually works. Are the contexts
>> typically
>> configured on the devices when installing the application? Are contexts
>> exchanged out of band and/or using some kind of protocol exchange?
>>
>> Ana: The way the context is configured or exchanged is out of the scope
> of this document because we are trying to explain the problem of CoAP
> header compression.
>
> TE: I see. Could you briefly point this out in the document, i.e., say
> "The way the context is configured or exchanged is out of the scope for
> this document", please?
>
>
> LT: Done

>
>> "[I-D.ietf-lpwan-ipv6-static-context-hc] defines the use of a message
>> direction
>> (DI) in the Field Description, which allows a single Rule to process
>> message
>> headers differently depending of the direction." - I think here it makes
>> sense
>> to say how this point relates to the point before, that CoAP is
>> asymmetric. Is
>> this in conflict, so it makes SCHC more difficult to use for CoAP? Or
>> does this
>> just mean that the SCHC rules have to be different for CoAP?
>>
>> Ana: It is not a conflict neither more difficult nor different, as SCHC
> includes the DI in the Rule the CoAP asymmetric problem is solved. Because
> the value in DI will be used to define which fields are in which direction
> in the same Rule. So instead of describing two Rules, one for each
> direction, we only have to define one Rule for both directions, paying
> attention to give the correct field description.
>
> TE: Thanks for the explanation. Maybe here it's worth rephrasing "which
> allows a single Rule to process message headers differently depending of
> the direction" to make this more explicit.
>
>
>
>> "The direction allows splitting in two parts the possible values for each
>> direction in the same Rule." - Sentence is hard to parse. What does "the
>> direction" refer to here - a part of the rule? the direction the packet
>> is sent?
>>
>> Ana: Direction is the Request or Response format (up, down,
> bidirectional). Yes is part of the Rule and yes
> it describes the direction the packet is sent from client to server or
> from server to client, request/response format headers
>
> TE: I see. Suggested new phrasing:
> "The direction allows splitting the range of values in two parts, one for
> each direction, and allows the same rule to handle traffic in both
> directions."
>
>
> LT: Done

>
>
>> "In IPv6 and UDP, header fields have a fixed size and it is not sent." -
>> What
>> does "it" refer to here? The size?
>>
> Ana: Yes, each field in the header has a length in bits or bytes; when a
> field in the header format has a fixed length, you know it, and it has been
> defined in the protocol document.
> Example: The IPv6 version is 4-bit length and the value is 6, so in SCHC
> field description this field will have a size of 4 bits and the target
> value will be 6
>
> TE: I see. Suggested new phrasing:
> "In IPv6 and UDP, header fields have a fixed size, which is not sent."
>
> LT: Added: In IPv6 and UDP, header fields have a fixed size, defined in
the Rule, which is not sent.

>
>
>> Section 4.5
>> "Token Value size cannot be defined directly in the rule in the Field
>> Length
>> (FL).  Instead, a specific function designated as "TKL" MUST be used and
>> length
>> does not have to be sent with the residue. During the decompression, this
>> function returns the value contained in the Token Length field." - Why
>> can the
>> Token Value size (is this the length of this header field?) not be defined
>> directly? And what is this specific function "TKL" supposed to do? Is
>> there a
>> reference for it? From this sentence, it's also not clear why length does
>> have
>> to be sent.
>>
>> Ana: Token is defined through two CoAP fields, Token-Length in the
> mandatory header and Token-Value directly following the mandatory CoAP
> header.
> Token Length is processed as any protocol field. If the value does not
> change, the size can be stored in the TV and elided during the
> transmission. Otherwise, it will have to be sent in the compression residue.
> Token Value MUST not be sent as a variable-length residue to avoid
> ambiguity with Token Length. Therefore, Token Length value MUST be used to
> define the size of the residue.
> A specific function designated as "TKL" MUST be used in the Rule. During
> the decompression, this function returns the value contained in the Token
> Length field.
>
> TE: Makes sense. I suggest adding this explanation to the document.
>

LT: perfect, done

>
> I'm looking forward to the next revision.
>

For the security section after discussion in the intermin meeting, we
propose to add this:

*This document does not have any more Security consideration than the ones
already raised on {{rfc8724}}. Variable length residues may be used to
compress URI elements. They cannot produce a packet expansion either on the
LPWAN network or in the Internet network after decompression. The length
send is not used to indicate the information that should be reconstructed
at the other end, but on the contrary the information sent as a Residue.
Therefore, if a length is set to a high value, but the number of bits on
the SCHC packet is smaller, the packet must be dropped by the decompressor.*

*OSCORE compression is also based on the same compression method described
in {{rfc8427}}. The size of the Initialisation Vector residue size must be
considered carefully. A too large value has a impact on the compression
efficiency and a too small value will force the device to renew its key
more often. This operation may be long and energy consuming.*

Laurent

> Best,
> Theresa
>