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:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FAE53A0C6C; Tue, 17 Mar 2020 17:15:53 -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 U0JDlWKuSEFi; Tue, 17 Mar 2020 17:15:51 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DEDA93A0C50; Tue, 17 Mar 2020 17:15:50 -0700 (PDT)
Received: from (unknown [xx.xx.xx.7]) by (ESMTP service) with ESMTP id 48hrD50W3Wz2xvl; Wed, 18 Mar 2020 01:15:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1584490549; bh=yVX0P7A2Dt0COisHoLet/E/vVlTVPst+6XmEKSvIZjI=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=BXBe8r9CqkAzy4+EtAt52PYS9VwPcslJ2hTNVcDgqaNKM9yAY0914nisPrLhRsDdQ PDNZ8nJ9s2HKroj6ma1qN7iCXmxZr6m8vyTK4GbHxGP+Tz+/nXpqUu9SDHqIcEbJqn wlzxVpFnT68FDxGiz0r14NYq7b0YlqB0G5KHYL36wG4ILBXkLiYTXFpmc4sBstxD+G NXAj0PCwo9UN6aGBJHBt0onp6xyFJ9q0ylcUV+CP349OZG2KGgl90Sy6Ft5oHV7O9c biZ8q8f66872tki8IJQaFr+3FYBy5vsF5PWVtWMW9VcjpoMjuL8B4NLz9kzCSYExRp nPBZpriAV7qHQ==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by (ESMTP service) with ESMTP id 48hrCt6ZKpz2xCS; Wed, 18 Mar 2020 01:15:38 +0100 (CET)
From: <>
To: Joseph Touch <>, Benjamin Kaduk <>
CC: "" <>, The IESG <>, "" <>, "" <>, "" <>, "" <>
Thread-Topic: [Last-Call] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12
Thread-Index: AQHV/LpZHENU4N5wiUa3yli2FIiqSw==
Date: Wed, 18 Mar 2020 00:15:37 +0000
Message-ID: =?utf-8?q?=3C11291=5F1584490548=5F5E71682A=5F11291=5F107=5F1=5FD?= =?utf-8?q?A971C41=2E72114=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: multipart/alternative; boundary="_000_DA971C4172114dominiquebarthelorangecom_"
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:16:17 -0000

Hello Joe,

See my responses to your points, inlined.

In addition, one comment:
This draft describes the generic SCHC mechanism.
Section 10 describes how SCHC can be applied to compress UDP/IPv6 headers in their simplest form.
Please note Section 10.8 that says "This document does not provide recommendations on how to compress IPv6 extension headers".
I could easily add a Section 10.12 to say "This document only describes how to compress UDP headers without options".
Would that work?


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

> My concern is Section 7.5.8.  How can both the IP and UDP lengths both be computed unless both depend directly on the link packet size?
[DB] they obviously can if the UDP packet at hand has no options (that's the "directly" part of your question). If the UDP header includes TLVs, things get trickier. Read next.

> AFAICT, With UDP options, the UDP length cannot be computed that way. The default rules need to take that into account.
[DB] In the example I showed in my other mail, I dealt with the UDP Length by sending the length in extenso over the wire. This example was meant to show that there is a way to handle UDP headers that include options.
There might be better ways, which compress better than this one, but at least I showed a correct one.

> I.e., you don’t need the UDP option TLVs if you don’t compress that area, but compression definitely needs to restore the UDP length as distinct from and unrelated to the IP length.
[DB] Yes, and I showed a way of achieving this.
[DB] Teaser:  Depending on the options present in the UDP header, a Rule night be able to do better than just sending the UDP length over the wire (or simple variations like sending a few least significant bits of the length, etc).
For example, if a UDP header only contains TLV-type of options, a CDA could rebuild the UDP length using the length of the options themselves and IPv6.Length.
Whether the compression gain is worth the code complexity remains to be seen, but the generic SCHC mechanism does not prevent one from doing that.
This is left for the "a-better-SCHC-compression-of-UDP-with-options" draft.


On Mar 17, 2020, at 2:13 PM, Benjamin Kaduk <<>> wrote:

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?



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.