Re: [Tsv-art] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12 Fri, 13 March 2020 23:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A05403A12DB; Fri, 13 Mar 2020 16:48: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 yskEMcO7oQz9; Fri, 13 Mar 2020 16:48:21 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EBD943A12DD; Fri, 13 Mar 2020 16:48:20 -0700 (PDT)
Received: from (unknown [xx.xx.xx.65]) by (ESMTP service) with ESMTP id 48fMpC1542z21qd; Sat, 14 Mar 2020 00:48:19 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=ORANGE001; t=1584143299; bh=aDUzVnEYcTYPbUQ/TRGLR2B939O5GUcLWP9G1D0XGFk=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=OlD2ucPq0+98WN12hSerKxiR+b7DttsdBM/00O2C2fZ8N6MMLMxu6EFTXoy2WDg03 eAllsRYi9es0w0wba+G3OpCMmazIwOKdzje7BJUawwUbidhaHwnttCq7I8dbEaTNBl tBh4Q7LTCWyROzM4CI/jAG8G+0pYxnCiFM1fJecdtD8eBnWfKVBY+fwDTP9/qILZXP fa2XYUlLKP5MI3Wj4p3gWzUyOWw77wO1mXAl7v79YTWHqsVa9LL78eRsqYffXj2ZeM UCS5LsoGd0/LgPY4M2U3QV3j+rFAptGuQOUQWJXK2a6OcN+NFziOjqBKNHgYFdhkC3 QpBYM4SpXp80g==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by (ESMTP service) with ESMTP id 48fMpB6gnpzDq7S; Sat, 14 Mar 2020 00:48:18 +0100 (CET)
From: <>
To: Joseph Touch <>, "" <>, The IESG <>
CC: "" <>, "" <>, "" <>, "" <>
Thread-Topic: [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12
Thread-Index: AQHV+ZHf2dPA7mxYUUmtCMCfS1TSIA==
Date: Fri, 13 Mar 2020 23:48:18 +0000
Message-ID: =?utf-8?q?=3C340=5F1584143298=5F5E6C1BC2=5F340=5F169=5F1=5FDA91D?= =?utf-8?q?669=2E71EAC=25dominique=2Ebarthel=40orange=2Ecom=3E?=
References: <>
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: <CB1A75BA9AECB44CB8E1096C7BE07519@adroot.infra.ftgroup>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Tsv-art] [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: Fri, 13 Mar 2020 23:48:23 -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 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.

Best regards,


Le 12/02/20 16:08, « lp-wan on behalf of Joseph Touch via Datatracker »
< on behalf of> a écrit :

>Reviewer: Joseph Touch
>Review result: Almost Ready
>This document has been reviewed as part of the transport area review
>ongoing effort to review key IETF documents. These comments were written
>primarily for the transport area directors, but are copied to the
>authors and WG to allow them to address any issues raised and also to the
>discussion list for information.
>When done at the time of IETF Last Call, the authors should consider this
>review as part of the last-call comments they receive. Please always CC
> if you reply to or forward this review.
>I found no transport issues with this document.
>However, this document normatively cites
>which does have some transport issues of concern. I am listing them here
>because of the dependency between the two documents.
>In particular, ietf-lpwan-ipv6-static-context-hc overlooks the case where
>IP header indicates a packet longer than the UDP header, a case that is
>currently being developed for UDP header options in TSVWG. This other
>claims that both UDP and IPv6 length fields can be computed from the
>data, but this is not the case when the IP header indicates a packet end
>that of the UDP header. See draft-tsvwg-udp-options for more information.
>There are no changes needed to this document to address this length
>issue, but
>the normative dependency in this doc is the reason for indicatin this
>as "Almost Ready".
>lp-wan mailing list


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.