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

Joseph Touch <> Wed, 18 March 2020 00:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 14DE03A0C62; Tue, 17 Mar 2020 17:12:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Status: No, score=-1.318 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_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KbBUOS3uJOIV; Tue, 17 Mar 2020 17:12:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2FCDF3A0C55; Tue, 17 Mar 2020 17:12:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SnwrXMHg/+OnJ++hrWSLO6de8uFwXMMdUgamd7aEN9U=; b=N8UY95xbyixwkYQ1wxW2ThTNO shwifmz88qrmtV3n3A99lIsKNNV5y/zmmh+hj+kuAgf07wG2qgnzNH/zdYGpftvTQB69xSOSvuJIo QTzYiooa0a7tD7jevUqOSNMiPaeFdZw/+1NUP02ThPJPKKMaYQEcdXuQ7c9HGoNF7qIliESFGlmAS BqHsmYYFQnKHZrHINiaXZihaPCeGAyC61YTohgxlLBnYqm2TM/l2vWLNE9c/fpT3fyHMMD378gWTl hBzCDTIuh4JB9DtTzbzqQQgUWDSpOF7MNBby4cXNn0WY8fXSQ+a5DNsOqP9wYf2kNMv85HX0V5aC3 Xy/c6r0Rg==;
Received: from ([]:60891 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <>) id 1jEMJq-001Bc7-Hk; Tue, 17 Mar 2020 20:12:26 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_A116988B-7B3E-4398-AC48-298F49472081"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <>
In-Reply-To: =?utf-8?q?=3C30843=5F1584487855=5F5E715DAF=5F30843=5F429=5F4=5F?= =?utf-8?q?DA971B0C=2E72109=25dominique=2Ebarthel=40orange=2Ecom=3E?=
Date: Tue, 17 Mar 2020 17:12:21 -0700
Cc: Benjamin Kaduk <>, "" <>, "" <>, The IESG <>, "" <>, "" <>, "" <>
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.9.1)
X-OutGoing-Spam-Status: No, score=-0.5
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
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:12:53 -0000

> 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.