Re: [Tsv-art] [Last-Call] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12 Tue, 17 March 2020 23:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA8F33A0A73; Tue, 17 Mar 2020 16:31:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8vr23qzockm7; Tue, 17 Mar 2020 16:31:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54CA03A0A53; Tue, 17 Mar 2020 16:31:03 -0700 (PDT)
Received: from (unknown [xx.xx.xx.70]) by (ESMTP service) with ESMTP id 48hqDJ0g8qz5vcK; Wed, 18 Mar 2020 00:30:56 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1584487856; bh=ogpzsZyO3KrmmdNkwfHoHKl9wtdc/8pu/Th8oJsvIi4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=cAA6VPl4VIBYzfPjMAsyNnJ+lTosusAjSmkUcGr5JxvFK5wJSLdVFIiHAGlrWKYsL SAYRVgHIP0mivQKZLL2Qze4EBv+vywma1HtKgqKc6W4uaIg5eCy1HjcgWodhbrn1Ft maMlpDmuYe6eW7pgo1l7YqXhdq1q9T/jb0y80SWIfvnb6Yez8Fjczz8d2L4fxFd+dw GWAtbQ0w2kBP+C4qH4huDD9igE26KiAzD39y6Y+iv+HNyEeDlntppTrNCUFhl+zOC0 9UZx7cnjZ/9rGGJzdp0y1kmajIRUVjDOch8BYAUB9iUp7jCONXzsyZ/7p1To4Otf3k kYM070f10+AAQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by (ESMTP service) with ESMTP id 48hqDH6hQFzDq7X; Wed, 18 Mar 2020 00:30:55 +0100 (CET)
From: <>
To: Benjamin Kaduk <>
CC: Joseph Touch <>, "" <>, The IESG <>, "" <>, "" <>, "" <>, "" <>
Thread-Topic: [Last-Call] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12
Thread-Index: AQHV/LQaHENU4N5wiUa3yli2FIiqSw==
Date: Tue, 17 Mar 2020 23:30:54 +0000
Message-ID: =?utf-8?q?=3C30843=5F1584487855=5F5E715DAF=5F30843=5F429=5F4=5FD?= =?utf-8?q?A971B0C=2E72109=25dominique=2Ebarthel=40orange=2Ecom=3E?=
References: <> =?utf-8?q?=3C340=5F1584143298=5F5E6C1BC2=5F340=5F169=5F1=5FDA91D669=2E71EAC?= =?utf-8?q?=25dominique=2Ebarthel=40orange=2Ecom=3E?= <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <C8674E71D013B0438AC7AC2A7DBBCD6D@adroot.infra.ftgroup>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Tue, 17 Mar 2020 23:31:26 -0000

Hello Benjamin,

See my comment to your point, inlined.


Le 17/03/20 22:13, « Benjamin Kaduk » <> a écrit :

>On Fri, Mar 13, 2020 at 11:48:18PM +0000,
>> 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
>> 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
>> 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,
>> 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. See my example in a separate mail.



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.