Re: [lp-wan] New Version Notification for draft-pelov-lpwan-architecture-00.txt

Olivier Gimenez <ogimenez@semtech.com> Wed, 03 February 2021 12:00 UTC

Return-Path: <ogimenez@semtech.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 2402C3A0934 for <lp-wan@ietfa.amsl.com>; Wed, 3 Feb 2021 04:00:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=semtech.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 Md5e6wz90-MT for <lp-wan@ietfa.amsl.com>; Wed, 3 Feb 2021 04:00:02 -0800 (PST)
Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.115]) (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 715F83A0930 for <lp-wan@ietf.org>; Wed, 3 Feb 2021 04:00:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semtech.com; s=k1; t=1612353601; i=@semtech.com; bh=aB713eUK/J4ZelMs7b1wpr+U+dIMUBeFAuVzP+s6q3M=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=bZ8yMHCe73Aipt9RB71FNIkhxRVeO13vmCA1sUwZ+co7aYjfHjOwl+C0vx7EswHQ1 vqHbbIBadF3p0pkuBuoKNcPV6/OjJkEki/c4UsI/DmqkMyfmJcwkSA8nFYSiUlzpfh stZwQOKCc20kL8PiTyy/ljfz1VzgsmFfgetXlR8QzbvI1HcgrwsBAby4hG+9O2xc6/ JMxdNTZe2I7v5DYGFhs2hqfzKO7VyY23W5rFWpGzq3QuSuFzfwMgZ0X/z88rPEIuLe 418WzxLtR7/rZGo+lrL/RzCakrRULH7eYHArmzUg1NeB4FcQ2mFIYmR2pDXngxpn/j LPSwb4c4hTlDA==
Received: from [100.112.132.72] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-4.bemta.az-b.us-west-2.aws.symcld.net id 88/5A-61492-0409A106; Wed, 03 Feb 2021 12:00:00 +0000
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkk+JIrShJLcpLzFFi42LxUPvxWNdhglS CwdwN7BZbvrazW7yZZe/A5DFj/XpmjyVLfjIFMEWxZuYl5VcksGZc2DKNueBTH1NF16nFLA2M C7uZuhi5OIQE7jNK9N7+xgzhPGeUuHzvM5Szg1Hizu5V7F2MnBxsAjoS/5/PYgWxRQQsJdp2t jKC2MICkRIX/95mgohHSbQ2dLFB2EYSvbNaweIsAioS1w/OZAGxeQWsJO4++8kIseA8o0T70R 1gCzgFAiUePLsP1swoICbx/dQasGZmAXGJW0/mg9kSAgISS/acZ4awRSVePv7HCjJIQmAas8S xTcuhivgl5h2+zgphK0jsm/2CEWJQokTTzU5miCsEJU7OfAJ2kZCAokTrtIXMExjFZiHZNwtJ yywkLbMYOYDimhLrd+lDlChKTOl+yA5ha0i0zpnLjiy+gJF9FaNFUlFmekZJbmJmjq6hgYGuo aGRrqGxka6RiZFeYpVukl5psW55anGJLpBbXqxXXJmbnJOil5dasokRGMspBS2fdjA2vPmgd4 hRkoNJSZS345dkghBfUn5KZUZicUZ8UWlOavEhRhkODiUJ3me9UglCgkWp6akVaZk5wLQCk5b g4FES4TXqA0rzFhck5hZnpkOkTjHGckx4OXcRM8fBo/OA5Lufi4Hkx1VLgOR3MPn6LYhs+gAi N89dCiSPgEghlrz8vFQpcV7RfqChAiBDM0rz4FbCUuglRlkpYV5GBgYGIZ6C1KLczBJU+VeM4 hyMSsK8x0FO48nMK4G77BXQ0UxAR3/cKgZydEkiQkqqgcn5Fq/EpqePF7NP9Thm7lKvsvB69k P3B6+dNRd8arns03VMc5VSW7ah5dXEmC3z5sgdjtUtS37BfSVDRmr/Pc0Pmb/naFUy1P9xn28 1Y/Iq34Xxdtt+3v2+tuCCTfQqMSEPpT0cT3I6Jiwou2SeUetu9iRr58WAuVm7Fl6dwDY11NWq 7tua/SuEoo4cDt0eHDYh+YDhQ+X87sVf5KbGzNj8Mv5L1PQfy3mTrponRXjMe/FFm//01xt3X n0qX8LK/a7o17ELL1cvL8oOmXnjpVvHyoRl7xqt48oXRmmX/yqJibur3bb4yPrPTcGtZcEZJ6 /clVAofCl6z/FXS03PjBfqin99ku9aPqiIP5zryL1ZiaU4I9FQi7moOBEAaheZxBwEAAA=
X-Env-Sender: ogimenez@semtech.com
X-Msg-Ref: server-22.tower-345.messagelabs.com!1612353598!2420761!1
X-Originating-IP: [72.38.248.227]
X-SYMC-ESS-Client-Auth: outbound-route-from=pass
X-StarScan-Received:
X-StarScan-Version: 9.60.3; banners=semtech.com,-,-
X-VirusChecked: Checked
Received: (qmail 25117 invoked from network); 3 Feb 2021 11:59:59 -0000
Received: from s72-38-248-227.static.datacom.cgocable.net (HELO ca01exedge1.semnet.dom) (72.38.248.227) by server-22.tower-345.messagelabs.com with ECDHE-RSA-AES256-SHA384 encrypted SMTP; 3 Feb 2021 11:59:59 -0000
Received: from CA01MAIL1.semnet.dom (10.2.50.40) by ca01exedge1.semnet.dom (10.2.110.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1034.26; Wed, 3 Feb 2021 06:59:56 -0500
Received: from ca01mail2.semnet.dom (10.2.50.41) by CA01MAIL1.semnet.dom (10.2.50.40) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1034.26; Wed, 3 Feb 2021 06:59:56 -0500
Received: from ca01mail2.semnet.dom ([fe80::fdc8:c457:b09e:605d]) by ca01mail2.semnet.dom ([fe80::fdc8:c457:b09e:605d%22]) with mapi id 15.01.1034.026; Wed, 3 Feb 2021 06:59:56 -0500
From: Olivier Gimenez <ogimenez@semtech.com>
To: Alexander Pelov <a@ackl.io>, lp-wan <lp-wan@ietf.org>
Thread-Topic: [lp-wan] New Version Notification for draft-pelov-lpwan-architecture-00.txt
Thread-Index: AQHW7ldb3LqJ4JYeiU+iuKPiBI3sSqpGXWbQ
Date: Wed, 03 Feb 2021 11:59:55 +0000
Message-ID: <6d91d06c1f77413ea571348842d811b4@semtech.com>
References: <161105507653.5725.12647528354362993169@ietfa.amsl.com> <CACQW0EozELa8N1z3_y2JQ8hf8UEaoWUQEoDdeun5SSLD2JoOEQ@mail.gmail.com> <CACQW0Epd8SEBXsqXnO77=0-OiXJT=S10HS_FWCLVeZAs-AbqPA@mail.gmail.com>
In-Reply-To: <CACQW0Epd8SEBXsqXnO77=0-OiXJT=S10HS_FWCLVeZAs-AbqPA@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXG9naW1lbmV6XGFwcGRhdGFccm9hbWluZ1wwOWQ4NDliNi0zMmQzLTRhNDAtODVlZS02Yjg0YmEyOWUzNWJcbXNnc1xtc2ctNTE3MTdmNWEtNjYxNy0xMWViLWI3OWItYzg1Yjc2MWM1MDU3XGFtZS10ZXN0XDUxNzE3ZjViLTY2MTctMTFlYi1iNzliLWM4NWI3NjFjNTA1N2JvZHkuaHRtbCIgc3o9IjE4NzY3IiB0PSIxMzI1NjgyNzE5MTMwODU3NzgiIGg9IkM5ekIwb1hma1dTVE9heEhZRmp2SnZHWHB6OD0iIGlkPSIiIGJsPSIwIiBibz0iMSIvPjwvbWV0YT4=
x-dg-rorf: true
x-originating-ip: [10.136.88.94]
Content-Type: multipart/alternative; boundary="_000_6d91d06c1f77413ea571348842d811b4semtechcom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/D7110N2mENuc_wNp4qZ-_5YsGFc>
Subject: Re: [lp-wan] New Version Notification for draft-pelov-lpwan-architecture-00.txt
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: Wed, 03 Feb 2021 12:00:05 -0000

Hi Alex,

Thank you for the document. Here are my comments:

1.  Introduction
For instance, as represented figure Figure 1
The first word “figure” should be removed

For instance, as represented figure Figure 1, IP compression and
fragmentation may be managed by the network SCHC instance and end-to-
end compression between the device and the application. The former
can itself be split in two instances since encryption hides the field
structure.

I think that “can itself be split in two instances “ applies to the SCHC instance in the App, not in network layer so “former” should be “latter”.
Nevertheless it might be better to be explicit there:
 *The SCHC instance at application layer is can* be split in two instances *as* encryption hides the field
structure.

Figure1: There is a type in “Network SCHC”, it is written “CSHC”

the LPWAN woeking group
Typo: in “working”


2.  Definitions
If the chapter is empty, should we remove it?
Otherwise I think that we should reference the RFC8376

3.  Global architecture
If SCHC compressed packet is too large to be send in a single L2
   frame, fragmentation will apply

Compression might not always apply, it has to be defined in the LPWAN-over-foo profile. So I would change the “will apply” in “can apply”.

On the other direction, when a packet SCHC arrives, the ruleID is
used to find the rule.
“packet SCHC” => “SCHC packet”

Its nature allows to select if it is a
compression or fragmentation rule.
I am not sure that it works as described, but rather:
The SCHC Reassembly checks if the SCHC packet rule match its own table:
- If it does: it reassembles the fragments before providing the reassemble SCHC message to the SCHC Decompressor
- Otherwise: the SCHC packet is directly provided to the SCHC Decompressor
Cf RFC8724 figure 3. It might worth to copy all figure 3 and its associated comment.

Figure 2:
I think that F/R and C/D should be split and not at the same level
Please use “rules” instead of “r”, easier to understand

To enable rule synchronization between both ends, a common rule
   representation must be defined.
Should we explicitly mention that this synchronisation is not (yet) defined ? I had this question several times while writing SCHC-over-LoRaWAN


Figure 3: The figure is not clear to me: again the C/D and F/R are mixed, and we should draw the Device and the App

The RM is a application using the Internet to exchange information,
   therefore:
The rule manager can use Internet, it is not mandatory

The RM traffic may be itself compressed by SCHC, especially if
   CORECONF is used, [I-D.ietf-lpwan-coap-static-context-hc] can be
   used.
If feel it confusing, maybe:
The RM traffic may be compressed by SCHC, especially if
CORECONF is used *as* [I-D.ietf-lpwan-coap-static-context-hc] can be *employed*.

Olivier

From: lp-wan <lp-wan-bounces@ietf.org> On Behalf Of Alexander Pelov
Sent: 19 January 2021 12:36
To: lp-wan <lp-wan@ietf.org>
Subject: Re: [lp-wan] New Version Notification for draft-pelov-lpwan-architecture-00.txt

Dear all,

For a full disclosure, Acklio might potentially have an IPR related to section 4 of the SCHC Architecture draft. Please keep in mind that I am not a lawyer.
We'll be following standard IETF practices for the licensing terms.

Best regards,
Alexander



On Tue, Jan 19, 2021 at 12:22 PM Alexander Pelov <a@ackl.io<mailto:a@ackl.io>> wrote:
Dear all,

With our second meeting in this new year, we wanted to start the discussion on one of the topics we've been having for some time now - the SCHC Architecture.

An initial draft was submitted and we can discuss it and the evolution during the interim today.

Cheers,
Pascal, Ana and Alex

---------- Forwarded message ---------
From: <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>>
Date: Tue, Jan 19, 2021 at 12:17 PM
Subject: New Version Notification for draft-pelov-lpwan-architecture-00.txt
To: Alexander Pelov <a@ackl.io<mailto:a@ackl.io>>, Ana Minaburo <ana@ackl.io<mailto:ana@ackl.io>>, Pascal Thubert <pthubert@cisco.com<mailto:pthubert@cisco.com>>



A new version of I-D, draft-pelov-lpwan-architecture-00.txt
has been successfully submitted by Alexander Pelov and posted to the
IETF repository.

Name:           draft-pelov-lpwan-architecture
Revision:       00
Title:          Static Context Header Compression (SCHC) Architecture
Document date:  2021-01-19
Group:          Individual Submission
Pages:          6
URL:            https://www.ietf.org/archive/id/draft-pelov-lpwan-architecture-00.txt
Status:         https://datatracker.ietf.org/doc/draft-pelov-lpwan-architecture/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-pelov-lpwan-architecture
Htmlized:       https://tools.ietf.org/html/draft-pelov-lpwan-architecture-00


Abstract:
   This document defines the SCHC architecture.




Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.

The IETF Secretariat


To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal.