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

Mirja Kuehlewind <> Wed, 18 March 2020 12:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5985C3A1546; Wed, 18 Mar 2020 05:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TZCsxuc-gw-c; Wed, 18 Mar 2020 05:50:09 -0700 (PDT)
Received: from ( [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 (Postfix) with ESMTPS id 85BD83A1536; Wed, 18 Mar 2020 05:50:08 -0700 (PDT)
Received: from ([2003:de:e723:9a00:e850:5cca:b30:2030]); authenticated by running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1jEY95-0008Ur-CN; Wed, 18 Mar 2020 13:50:03 +0100
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Mirja Kuehlewind <>
In-Reply-To: =?utf-8?q?=3C30843=5F1584487855=5F5E715DAF=5F30843=5F429=5F4=5F?= =?utf-8?q?DA971B0C=2E72109=25dominique=2Ebarthel=40orange=2Ecom=3E?=
Date: Wed, 18 Mar 2020 13:50:02 +0100
Cc: Benjamin Kaduk <>, Joseph Touch <>, "" <>, "" <>, The IESG <>, "" <>, "" <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> =?utf-8?q?=3C340=5F1584143298=5F5E6C1BC2=5F340=5F169=5F1=5FDA91D669=2E71EAC?= =?utf-8?q?=25dominique=2Ebarthel=40orange=2Ecom=3E?= =?utf-8?q?=3C20200317211335=2EGR50174=40kduck=2Emit=2Eedu=3E_=3C30843=5F158?= =?utf-8?q?4487855=5F5E715DAF=5F30843=5F429=5F4=5FDA971B0C=2E72109=25dominiq?= =?utf-8?q?ue=2Ebarthel=40orange=2Ecom=3E?=
X-Mailer: Apple Mail (2.3445.104.11)
X-HE-SMSGID: 1jEY95-0008Ur-CN
Archived-At: <>
Subject: Re: [Tsv-art] [Last-Call] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 18 Mar 2020 12:50:29 -0000

Hi Dominique,

Quickly chiming in here. Please see below for one comment.

> On 18. Mar 2020, at 00:30, wrote:
> Hello Benjamin,
> See my comment to your point, inlined.
> Dominique 
> Le 17/03/20 22:13, « Benjamin Kaduk » <> a écrit :
>> On Fri, Mar 13, 2020 at 11:48:18PM +0000,
>> wrote:
>>> Hello all,
>>> This is the response by the ietf-lpwan-ipv6-static-context-hc co-authors
>>> to the observation below by Joseph Touch.
>>> You are right that Section 10 of ietf-lpwan-ipv6-static-context-hc only
>>> shows how to compress IPv6/UDP packets that have no extensions.
>>> However, the SCHC specification in Section 7.1 states
>>> "It is assumed that
>>>   there is a protocol parser alongside SCHC that is able to identify
>>>   all the fields encountered in the headers to be compressed, and to
>>>   label them with a Field ID."
>>> Furthermore, Section 7.3 states
>>> "If any
>>>         header field of the packet being examined cannot be matched
>>>         with a Field Description with the correct FID, the Rule MUST be
>>>         disregarded.  If any Field Description in the Rule has a FID
>>>         that cannot be matched to one of the header fields of the
>>>         packet being examined, the Rule MUST be disregarded."
>>> It follows that, if an IPv6 packet does contain the new UDP TLVs
>>> introduced by draft-tsvwg-udp-options, it will not match a Rule destined
>>> to compress the IPv6/UDP headers and that does not have these TLVs as
>>> part
>>> of the Field Descriptors.
>>> Therefore, it will no be compressed by that Rule and will not be
>>> decompressed with a wrong UDP Length at the receive end.
>>> By contrast, if a Rule destined to compress the IPv6/UDP headers does
>>> have
>>> these UDP TLVs as part of the Field Descriptors, it is responsible for
>>> reconstructing the UDP Length properly. This can be achieved by means
>>> already provided by SCHC, such as sending the value over the wire or
>>> matching it to an expected constant, etc.
>>> In conclusion, the SCHC compression mechanism, if properly implemented,
>>> is
>>> fully compatible with draft-tsvwg-udp-options.
>> This "if properly implemented" seems pretty critical.  Do we need to leave
>> a reminder that implementations have to know about UDP TLVs in order to
>> properly identify all fields in the headers to be compressed?
> 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!


> See my example in a separate mail.
>> -Ben
> _________________________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> _______________________________________________
> Tsv-art mailing list