IETF Logo Mail Archive

Re: [Tsv-art] [Last-Call] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12

Mirja Kuehlewind <ietf@kuehlewind.net> Wed, 18 March 2020 15:03 UTC

Return-Path: <ietf@kuehlewind.net>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 900503A1706; Wed, 18 Mar 2020 08:03:24 -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 yQ0fK04uPHbO; Wed, 18 Mar 2020 08:03:23 -0700 (PDT)
Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 190913A1701; Wed, 18 Mar 2020 08:03:23 -0700 (PDT)
Received: from p200300dee7239a00e8505cca0b302030.dip0.t-ipconnect.de ([2003:de:e723:9a00:e850:5cca:b30:2030]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jEaE4-0006g2-Bj; Wed, 18 Mar 2020 16:03:20 +0100
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <ietf@kuehlewind.net>
In-Reply-To: <9DF137B7-2861-4ADA-9C8B-22DFE7022EAD@strayalpha.com>
Date: Wed, 18 Mar 2020 16:03:19 +0100
Cc: "<dominique.barthel@orange.com>" <dominique.barthel@orange.com>, "draft-ietf-lpwan-coap-static-context-hc.all@ietf.org" <draft-ietf-lpwan-coap-static-context-hc.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, The IESG <iesg@ietf.org>, "lp-wan@ietf.org" <lp-wan@ietf.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "draft-ietf-lpwan-ipv6-static-context-hc@ietf.org" <draft-ietf-lpwan-ipv6-static-context-hc@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F3327431-EBBF-450C-802F-E8D0E29F20D5@kuehlewind.net>
References: <158152010913.17982.18347318138768196852@ietfa.amsl.com> <340_1584143298_5E6C1BC2_340_169_1_DA91D669.71EAC%dominique.barthel@orange.com><20200317211335.GR50174@kduck.mit.edu> <30843_1584487855_5E715DAF_30843_429_4_DA971B0C.72109%dominique.barthel@orange.com> <27E35DC7-C83E-4C6C-984A-3AC1C183BC28@kuehlewind.net> <9DF137B7-2861-4ADA-9C8B-22DFE7022EAD@strayalpha.com>
To: Joseph Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1584543803;bab0aa71;
X-HE-SMSGID: 1jEaE4-0006g2-Bj
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/4lfb0bP4ghsO-qiaJ_WkvGd4FoE>
Subject: Re: [Tsv-art] [Last-Call] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Mar 2020 15:03:25 -0000

That’s the better wording!


> On 18. Mar 2020, at 15:55, Joseph Touch <touch@strayalpha.com> wrote:
> 
> 
> 
>> On Mar 18, 2020, at 5:50 AM, Mirja Kuehlewind <ietf@kuehlewind.net> wrote:
>> 
>>> Indeed, the protocol parser and the SCHC rules need to know about the UDP
>>> TLVs if one wants to compress them.
>>> But the same is true of all the other fields. I don't think this one
>>> warrants a special notice.
>>> What I insist on is that, if an implementation does not know of the UDP
>>> TLVs, it will not reconstruct an erroneous UDP Length, even for a packet
>>> that contains these TLVs, assuming that the protocol parser checks the UDP
>>> and IPv6 lengths for consistency.
>> 
>> I think this last statement (“protocol parser checks the UDP
>> and IPv6 lengths for consistency”) is the important point that needs to be explicitly mention in the document!
> 
> That way of phrasing it is dangerous - it implies that when the values differ there is some sort of error.
> 
> It would be more in line with current TSV efforts to standardize UDP options to say “UDP length can be compressed when it *can* be computed from the IP length” and that “it MUST NOT be compressed as computable otherwise”.
> 
> Joe

v2.23.0 | Report a Bug | By Email