IETF Logo Mail Archive

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

Joseph Touch <touch@strayalpha.com> Tue, 17 March 2020 22:06 UTC

Return-Path: <touch@strayalpha.com>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52693A0885; Tue, 17 Mar 2020 15:06:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8nLkTVNjHys; Tue, 17 Mar 2020 15:06:12 -0700 (PDT)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 250A83A0899; Tue, 17 Mar 2020 15:06:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; 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=FVSVISI/x/0ErXMnehFVuAnQK94+X93Iv/DUKHERMzA=; b=S2qRY16G3UBJGT0ey53AWifAg g3Og5zLMt6zq5Em0sUfr3yrImCatG79hce90nXPM84f7JSox/y4jdPryd2JzpQQYqANJkVx5zqzyc HenUQ8fn/j+jZ0MQgVwFZA4Yb5dwxnA9JDuujBpffRho7Cwf5+pZSw6yFvRf6c9efeibfQZL9FsRo k+yEUMQ5xL5astQSH+n2NtoygS64ss7jxMOd3lkpuyfUOTkWF5VToNBzKq9FV4+G5TEg+lurpaJ9E JXwx4viF7bM1GtHokKyNykeaerTvMSlEKWwlBo2QHUns4NV6TqsKXFwAdrXgZGxknQo00hQjjQJ95 2Imh4c9Eg==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:60775 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1jEKLe-003B6w-VW; Tue, 17 Mar 2020 18:06:11 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_8DA3C136-5B50-4678-A39A-745B8AAB71B3"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <20200317211335.GR50174@kduck.mit.edu>
Date: Tue, 17 Mar 2020 15:06:06 -0700
Cc: dominique.barthel@orange.com, "tsv-art@ietf.org" <tsv-art@ietf.org>, The IESG <iesg@ietf.org>, "lp-wan@ietf.org" <lp-wan@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "draft-ietf-lpwan-coap-static-context-hc.all@ietf.org" <draft-ietf-lpwan-coap-static-context-hc.all@ietf.org>, "draft-ietf-lpwan-ipv6-static-context-hc@ietf.org" <draft-ietf-lpwan-ipv6-static-context-hc@ietf.org>
Message-Id: <734BA902-C1EB-496C-8219-BB4E9A722029@strayalpha.com>
References: <158152010913.17982.18347318138768196852@ietfa.amsl.com> <340_1584143298_5E6C1BC2_340_169_1_DA91D669.71EAC%dominique.barthel@orange.com> <20200317211335.GR50174@kduck.mit.edu>
To: Benjamin Kaduk <kaduk@mit.edu>
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 - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/UHO_pvodXOXne9IA7GkYY0PPF8A>
Subject: Re: [Tsv-art] [Last-Call] [lp-wan] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Mar 2020 22:06:15 -0000

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?

AFAICT, With UDP options, the UDP length cannot be computed that way. The default rules need to take that into account.

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.

Joe

> On Mar 17, 2020, at 2:13 PM, Benjamin Kaduk <kaduk@mit.edu> 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?
> 
> -Ben

v2.23.0 | Report a Bug | By Email