Re: [Tsv-art] [Last-Call] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12 Wed, 18 March 2020 00:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 660003A0C7E; Tue, 17 Mar 2020 17:22:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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, 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 1GDvsCeXVjXI; Tue, 17 Mar 2020 17:22:07 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 76F123A0C7B; Tue, 17 Mar 2020 17:22:07 -0700 (PDT)
Received: from (unknown [xx.xx.xx.69]) by (ESMTP service) with ESMTP id 48hrMK3rgXz1yVw; Wed, 18 Mar 2020 01:22:05 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1584490925; bh=BlzRdCDVZJKjrrI9cUwu+yyZMkhSckF+GEYRSz9CLfs=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=m6NGKMiFN4nKM3EqKrn88wi/RBkLubTdkdGKENolj1b1j1JYS26kw64GRGqTAO2xm DltgzDZ83qCNsEaJpr22KbSY+nwp4kLmFtJFvM0LDNa+Nn3H5X6n8baw2ErRh57OZe qZ9I1aTgC8MgTr54aa3t8mAKRkyJvKevr9H4rw3YBSGAkjnvF5BDPYCKLbuBzkkUtJ hfpLXkR6AfVuKZ+maXrdR0R4PuApaqN51drc7uBpk0QZkEOx5LwENPR1cDt6twy+VO axK4gENBS4va1eSV6rpWQSYaKKgBpzp7fAGAdUOrSdrNVRjTAj1FQ4WhAZFu8PZPn7 qaPJiVqbMZZyg==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by (ESMTP service) with ESMTP id 48hrMK2Xm9zyQG; Wed, 18 Mar 2020 01:22:05 +0100 (CET)
From: <>
To: Joseph Touch <>
CC: Benjamin Kaduk <>, "" <>, "" <>, The IESG <>, "" <>, "" <>, "" <>
Thread-Topic: [Tsv-art] [Last-Call] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12
Thread-Index: AQHV/LQaHENU4N5wiUa3yli2FIiqS6hNaZ2AgAATeAA=
Date: Wed, 18 Mar 2020 00:22:04 +0000
Message-ID: =?utf-8?q?=3C18523=5F1584490925=5F5E7169AD=5F18523=5F418=5F6=5FD?= =?utf-8?q?A9727F0=2E72166=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?= =?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?= <>
In-Reply-To: <>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_DA9727F072166dominiquebarthelorangecom_"
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: Wed, 18 Mar 2020 00:22:32 -0000

You are totally right.
I suggest to add that Section 10 only applies to UDP headers without options.
Does that work?


De : Joseph Touch <<>>
Date : Wednesday 18 March 2020 01:12
À : Dominique Barthel <<>>
Cc : Benjamin Kaduk <<>>, "<>" <<>>, "<>" <<>>, The IESG <<>>, "<>" <<>>, "<>" <<>>, "<>" <<>>
Objet : Re: [Tsv-art] [Last-Call] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12

On Mar 17, 2020, at 4:30 PM,<> wrote:

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.

Agreed. The issue is that UDP length can’t be reconstructed UNLESS it matches the end of packet indicated by the IP length.

In any other case, claiming it can be reconstructed is an error and should not be allowed.

That appears to be a flaw in the claim that UDP length can be computed. It’s just not true in all cases.



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.