Re: [Gen-art] Genart last call review of draft-ietf-lpwan-coap-static-context-hc-12
Theresa Enghardt <ietf@tenghardt.net> Tue, 10 March 2020 03:26 UTC
Return-Path: <ietf@tenghardt.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 5D9BA3A0E69; Mon, 9 Mar 2020 20:26:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.078
X-Spam-Level:
X-Spam-Status: No, score=-2.078 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, T_SPF_HELO_TEMPERROR=0.01, T_SPF_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tenghardt.net
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 gXKCd8ve5A1u; Mon, 9 Mar 2020 20:26:40 -0700 (PDT)
Received: from mail.hemio.de (mail.hemio.de [136.243.12.180]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E7413A0E60; Mon, 9 Mar 2020 20:26:13 -0700 (PDT)
Received: from user.client.invalid (localhost [136.243.12.180]) by mail.hemio.de (Postfix) with ESMTPSA id B6A9EBD; Tue, 10 Mar 2020 04:26:04 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tenghardt.net; s=20170414; t=1583810771; bh=8S7LvN/ej//4evovtZn/aeEABcEta7Yz1ezjU2KBUOY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=a7tjz8U7H7bTruc/Mkwm7s94MLThC84u/LbzwQynD6P80F/scHeK111eh2FfDtC8e VCVctS69JYl3uTbQ4gaDob/EVtN5hXujfBcmHhtfuvm6Pr+MPn35NhwQk7jUjWrvgE QhCIfeXNpTVlKfvmqe8dqRaoDu7j6vlSWinB8dfInzq2LUoQQQPXA+gBYFlvk1CbGv eIgzTEN14dkjHiJoEzTKd5Ip3iPviCslGHTG6qAJrntzQus6qW/5wWPTYcBmFSd5QH bHS73mVJwkAm6o3hQnb3jU/QH3P1RpQyLC7/oIkVUWORY1pF2PX4RV0M/VywOGBpbB Vv2TnAgUZ5VKA==
To: Laurent Toutain <laurent.toutain@imt-atlantique.fr>
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>
References: <158134757509.4049.18293449395965880444@ietfa.amsl.com> <CAAbr+nSgQjD1o==i5rPQgAv7mA8buWueCUMkHnt=Ls=s09QXwQ@mail.gmail.com> <f63d996b-f13f-e574-65f0-fdd091b1c5fb@tenghardt.net> <CABONVQYgc_Mtuxh4rzsyhAg_DJmTMWfd2Wn9f3nqdVKdY77__g@mail.gmail.com>
From: Theresa Enghardt <ietf@tenghardt.net>
Message-ID: <7ba83379-9c1b-d499-4742-bdfc026a9b74@tenghardt.net>
Date: Mon, 09 Mar 2020 20:26:03 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <CABONVQYgc_Mtuxh4rzsyhAg_DJmTMWfd2Wn9f3nqdVKdY77__g@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------740F674BAEC80722D396B02C"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/kx9q7sEJm0xosaLVX8r6UfKSxLI>
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: Tue, 10 Mar 2020 03:26:49 -0000
Hi Laurent, Thanks for the new revision, which greatly improves the document. However, I have a few comments on your new text: In the text at the beginning of Section 3, you added text to give more context, which is a great idea. However, I'm not sure about the first sentence: "SCHC with CoAP will be used exactly the same way as it is applied in any protocol as IP or UDP with the difference that the fields description needs to be defined based on both headers and target values of the request and the responses." To me the last part of this sentence sounds like for CoAP you have to define a rule to match both a request and a reply packet, so you would have to match two packets (in a single rule?). Is this really the case? I thought a single rule always matches one packet, but maybe I misunderstood. In any case, could you rephrase this to make it more clear, please? Also, I saw some typos and grammar errors in Section 3: s/optmize/optimize/ s/To performs/To perform/ s/TV might be use/TV might be used/ s/Resulting in a smaller compression residue./This results in a smaller compression residue./ Some more nits in Section 7.3: s/TheSCHC/The SCHC/ s/alreadypresent/already present/ s/in section Section 4/in Section 4/ Regarding the Security Considerations, thanks for discussing this in your interim meeting and for adding text. I'll leave the judgment of whether any security aspects are still missing etc. to the Secdir reviewer and/or ADs. Regarding the text you added: On 05.03.20 23:50, Laurent Toutain wrote: > 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./ > Overall, I find this paragraph difficult to follow. What is the relationship between the first sentence and the rest of the paragraph? First you say there are not more Security Considerations, then you say that there are? Please add a sentence that provides a context for your statements. Is this a consideration that implementations need to be aware of in case variable residues are used? Or is this a suggestion to use variable length residues to make something more/less secure? What is a packet expansion? I haven't seen this term in the rest of the document. Is it a problem if they (the variable length residues or the URI elements?) cannot produce a packet expanision? This sentence is hard to parse and seems gramatically broken: "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." > // > > /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./ > "This operation may be long and energy consuming." - Which operation? The previous sentence talks about the size of an initialization vector, not about an operation. Thanks, Theresa
- [Gen-art] Genart last call review of draft-ietf-l… Theresa Enghardt via Datatracker
- Re: [Gen-art] Genart last call review of draft-ie… Ana Minaburo
- Re: [Gen-art] Genart last call review of draft-ie… Theresa Enghardt
- Re: [Gen-art] Genart last call review of draft-ie… Laurent Toutain
- Re: [Gen-art] Genart last call review of draft-ie… Theresa Enghardt
- Re: [Gen-art] Genart last call review of draft-ie… Alissa Cooper