Re: [lp-wan] [Last-Call] [Tsv-art] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12
Joseph Touch <touch@strayalpha.com> Fri, 20 March 2020 15:23 UTC
Return-Path: <touch@strayalpha.com>
X-Original-To: lp-wan@ietfa.amsl.com
Delivered-To: lp-wan@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E11983A0A53; Fri, 20 Mar 2020 08:23:22 -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 CjX7od_fDAKn; Fri, 20 Mar 2020 08:23:20 -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 80AAA3A0A4A; Fri, 20 Mar 2020 08:23:14 -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=L5ckF/HXgv5KHRrCo2ywQZY3gcP+eqyhPArgRw+i/XI=; b=lT/AxrvPMTBc6ctmrOV5ieIHP Us/OKiMmKjRbqBew9glW5KZ4QhF+jDmKB77HCwWJbIcJnceBBiFUSPKqbPlfRkv/yn1KgXj0BQaKz q9o0sVqQr2ScwI7TrYecu5tMUFRUPjfrIZMIpSS08poF0Vxm6A9awRYySuFiUPwTykRBPf0eZxuEo btdOYp3wPmK6IJbFGXnX7GLZVtLta+C5RmJGKDoTloQA9bkHMsKxtCW/6U8puVT9OrGt6jEVNAB/4 23ZxMoNM1DiOsjTpkL6rsOApTFW8WLxSqmZg7MKvKYUNhhhz9PtV52A/NT+QsaH48b0S/Gk+5j4BX kq9uULvEA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:53073 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 1jFJUK-0001oK-Jv; Fri, 20 Mar 2020 11:23:13 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_D7D494F4-2BE0-403E-B2F2-334111659C73"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <20350_1584600280_5E7314D8_20350_426_1_DA98D1CE.72223%dominique.barthel@orange.com>
Date: Fri, 20 Mar 2020 08:23:07 -0700
Cc: "draft-ietf-lpwan-coap-static-context-hc.all@ietf.org" <draft-ietf-lpwan-coap-static-context-hc.all@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, Mirja Kuehlewind <ietf@kuehlewind.net>, The IESG <iesg@ietf.org>, "lp-wan@ietf.org" <lp-wan@ietf.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>, "draft-ietf-lpwan-ipv6-static-context-hc@ietf.org" <draft-ietf-lpwan-ipv6-static-context-hc@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>
Message-Id: <2539076A-99CD-44B3-9903-25E42ACB5603@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> <30843_1584487855_5E715DAF_30843_429_4_DA971B0C.72109%dominique.barthel@orange.com> <27E35DC7-C83E-4C6C-984A-3AC1C183BC28@kuehlewind.net> <9DF137B7-2861-4ADA-9C8B-22DFE7022EAD@strayalpha.com> <F3327431-EBBF-450C-802F-E8D0E29F20D5@kuehlewind.net> <20350_1584600280_5E7314D8_20350_426_1_DA98D1CE.72223%dominique.barthel@orange.com>
To: dominique.barthel@orange.com
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/lp-wan/1w51oilFtYc1XJk1rolQnAAZynw>
Subject: Re: [lp-wan] [Last-Call] [Tsv-art] Tsvart last call review of draft-ietf-lpwan-coap-static-context-hc-12
X-BeenThere: lp-wan@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Low-Power Wide Area Networking \(LP-WAN\), also known as LPWA or Low-Rate WAN \(LR-WAN\)" <lp-wan.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lp-wan/>
List-Post: <mailto:lp-wan@ietf.org>
List-Help: <mailto:lp-wan-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lp-wan>, <mailto:lp-wan-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Mar 2020 15:23:24 -0000
Hi, Dominique, See below. My concern is whether UDP length can be compressed or not on a per-packet basis in SCHC. Joe > On Mar 18, 2020, at 11:44 PM, dominique.barthel@orange.com wrote: > > Hello Joe, all, > ... > Second, let me be transparent. > My goal is to publish the specification of the * generic * SCHC mechanism > as soon as possible. > Frankly, I wish Section 10 (the application of the generic SCHC mechanism > to UDP/IPv6) were a separate draft, so I would not have to worry about it > * right now *. > Since Section 10 shall remain a part of the generic SCHC draft, I’m trying > to find the quickest exit route from the issues the draft currently has. > I’d rather not being dragged into specifying the details of what SCHC must > do in the presence of a UDP Length that cannot be straightforwardly > recomputed out of the IPv6 Length. That’s actually quite easy and thus it should not delay anything. > I’d rather just state clearly that Section 10, as currently written, > *only* applies to the case where the UDP Length can be straightforwardly > recomputed out of the IPv6 Length, and leave for another draft to deal > with the opposite case. - Section 7.5.8 should not include UDP length as an example of compute-*; it might even be useful to include the following as a caveat: Note that UDP length is not an example of this type of field. In many conventional uses, UDP length is “IP length - IP header length”, but this is not strictly required by RFC 768 and there are emerging uses for cases where the lengths are not related this way [draft-ietf-tsvwg-udp-options]. - Section 10.10 The UDP length may or may not be related to the IP length, as noted in Section 7.5.8. A currently developing use of UDP options relies on UDP length being shorter than “IP length - IP header length”. In this case, the UDP options might be compressible but the UDP length is not computable from the UDP option fields alone. > (Why am I saying this? I’m guessing that there are situations where a > protocol analyser understands all the fields/options/bytes between the > IPv6.Length pointer and the UDP.Length pointer and SCHC conveys all these > fields/options/bytes to the receiver. Then, UDP.Length might still be > recomputed, admitedly not straightforwardly, out of IPv6.Length and the > received fields/options/bytes.) That’s not the case for UDP options. > Therefore, I would rather not write in this draft that “it MUST NOT be > compressed as computable otherwise”, as Joe suggests in his email March > 18th 14:6 UTC, included below. See above; it doesn't need to say MUST NOT. It can leave the door open to alternatives, but I’d at suggest at least hinting that they might not exist. > If you agree with this premise, here are the proposed changes in > ietf-lpwan-ipv6-static-context-hc (RFC8724-to-be) > > In a nutshell > - clean up the “generic SCHC” specification from any hint that UDP Length > can be recomputed. These hints are not necessary to understand the generic > SCHC algorithm anyway. Agreed, e.g., esp. for 7.5.8 > - In Section 10 and Appendix A, which are the only ones pertaining to UDP, > specify that these recommendations/examples only apply when the UPD length > can be straightforwardly recomputed out of IPv6 length. OK, so this depends on how the compression works - which I need your help with. Is it possible to compress when they “match” and not compress when they don’t? If so, then sure - say that. If not, then I would suggest erring on the side of assuming that UDP length cannot be compressed in any examples given - even perhaps adding a note to explain why. > Proposed edits, in order of appearance in the draft > > Abstract > OLD_TEXT > This document defines a generic header compression mechanism and its > application to compress IPv6/UDP headers. > NEW_TEXT > This document defines a generic header compression mechanism and its > application to compress basic IPv6/UDP headers. That depends on whether or not you can do as I note above, i.e., compress or not compress that one field on a per-packet basis. If not, then leave the original text and simply don’t compress the UDP length field. > Section 7.3.8 > OLD_TEXT > Because the field is uniquely identified by its Field ID (e.g., UDP > length), > NEW_TEXT > Because the field is uniquely identified by its Field ID (e.g., IPv6 > length), OK > > OLD_TEXT > Examples of fields that know how to recompute themselves are UDP length, > IPv6 length and UDP checksum. > NEW_TEXT > An example of fields that know how to recompute themselves is IPv6 length. Grammar suggestion: An example of a field that knows how to recompute itself is IPv6 length. > Section 10 > OLD_TEXT > 10. SCHC Compression for IPv6 and UDP Headers > NEW_TEXT > 10. SCHC Compression for basic IPv6 and UDP Headers Again, unless UDP length can be compressed/not on a per-packet basis, leave as-is. > OLD_TEXT > This section lists the IPv6 and UDP header fields and describes how > they can be compressed. An example of a set of Rules for UDP/IPv6 > header compression is provided in Appendix A. > NEW_TEXT > This section shows an application of the generic SCHC C/D mechanism (see > Section 7) > for compressing basic IPv6 and UDP headers. > This section only applies to UDP/IPv6 packets where the UDP length can be > straighforwardly recomputed from the IPv6 length. An example of such a set > of Rules is provided in Appendix A. > Sytems MUST NOT apply compression Rules implemented with the > recommendations from Section 10 unless they verify that the UDP length can > be straighforwardly recomputed from the IPv6 length. Again, unless UDP length can be compressed/not on a per-packet basis, leave as-is. > Section 10.10 UDP Length Field > OLD_TEXT > The UDP length can be computed from the received data. The TV is not > set, the MO is set to "ignore", and the CDA is set to "compute-*". > NEW_TEXT > Providing the condition described at the beginning of Section 10 is met, > the UDP length can be computed from the received data. The TV is not set, > the MO is set to "ignore", and the CDA is set to "compute-*”. See my suggestion above. > Section 12.1.1 > OLD_TEXT > This property is true for IPv6 Length, UDP Length, and UDP Checksum, for > which the compute-* CDA is recommended by this document. > NEW_TEXT > This property is true for IPv6 Length, UDP Length, and UDP Checksum, for > which the compute-* CDA is recommended by this document, under the > conditions described at the beginning of Section 10. OK. > > Appendix A > OLD_TEXT > This section gives some scenarios of the compression mechanism for > IPv6/UDP headers. > NEW_TEXT > This section provides an example of a Rule set for compressiing basic > IPv6/UDP headers, where the UDP length can be straightforwardly recomputed > out of IPv6 length. Again, see my caveat. > > Would this work for you? Comments welcome. > Thanks > > Dominique > > > > Le 18/03/20 16:03, « Mirja Kuehlewind » <ietf@kuehlewind.net <mailto:ietf@kuehlewind.net>> a écrit : > >> That’s the better wording! >> >> >>> On 18. Mar 2020, at 15:55, Joseph Touch <touch@strayalpha.com> wrote: >>> >>> >>> >>>> On Mar 18, 2020, at 5:50 AM, Mirja Kuehlewind <ietf@kuehlewind.net> >>>> wrote: >>>> >>>>> 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. >>>> >>>> I think this last statement (“protocol parser checks the UDP >>>> and IPv6 lengths for consistency”) is the important point that needs >>>> to be explicitly mention in the document! >>> >>> That way of phrasing it is dangerous - it implies that when the values >>> differ there is some sort of error. >>> >>> It would be more in line with current TSV efforts to standardize UDP >>> options to say “UDP length can be compressed when it *can* be computed >>> from the IP length” and that “it MUST NOT be compressed as computable >>> otherwise”. >>> >>> Joe >> > > > _________________________________________________________________________________________________________________________ > > 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. > > -- > last-call mailing list > last-call@ietf.org <mailto:last-call@ietf.org> > https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>
- [lp-wan] Tsvart last call review of draft-ietf-lp… Joseph Touch via Datatracker
- Re: [lp-wan] Tsvart last call review of draft-iet… dominique.barthel
- Re: [lp-wan] [Last-Call] Tsvart last call review … Benjamin Kaduk
- Re: [lp-wan] [Last-Call] Tsvart last call review … Joseph Touch
- Re: [lp-wan] [Last-Call] Tsvart last call review … dominique.barthel
- Re: [lp-wan] [Last-Call] Tsvart last call review … dominique.barthel
- Re: [lp-wan] [Tsv-art] [Last-Call] Tsvart last ca… Joseph Touch
- Re: [lp-wan] [Last-Call] Tsvart last call review … dominique.barthel
- Re: [lp-wan] [Tsv-art] [Last-Call] Tsvart last ca… dominique.barthel
- Re: [lp-wan] [Tsv-art] [Last-Call] Tsvart last ca… Joseph Touch
- Re: [lp-wan] [Tsv-art] [Last-Call] Tsvart last ca… Mirja Kuehlewind
- Re: [lp-wan] [Tsv-art] [Last-Call] Tsvart last ca… Joseph Touch
- Re: [lp-wan] [Tsv-art] [Last-Call] Tsvart last ca… Mirja Kuehlewind
- Re: [lp-wan] [Tsv-art] [Last-Call] Tsvart last ca… dominique.barthel
- Re: [lp-wan] [Last-Call] [Tsv-art] Tsvart last ca… Joseph Touch
- Re: [lp-wan] [Last-Call] [Tsv-art] Tsvart last ca… dominique.barthel
- Re: [lp-wan] [Last-Call] [Tsv-art] Tsvart last ca… Joseph Touch
- Re: [lp-wan] [Last-Call] [Tsv-art] Tsvart last ca… Suresh Krishnan
- Re: [lp-wan] [Tsv-art] [Last-Call] Tsvart last ca… Joseph Touch