[lp-wan] FWD: Draft SCHC for CoAP -Title

Ana Minaburo <ana@ackl.io> Thu, 03 June 2021 09:10 UTC

Return-Path: <ana@ackl.io>
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 6B2153A30F8 for <lp-wan@ietfa.amsl.com>; Thu, 3 Jun 2021 02:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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=ackl-io.20150623.gappssmtp.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 hngB0TbkO3e5 for <lp-wan@ietfa.amsl.com>; Thu, 3 Jun 2021 02:10:41 -0700 (PDT)
Received: from mail-il1-x131.google.com (mail-il1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFDFE3A30F6 for <lp-wan@ietf.org>; Thu, 3 Jun 2021 02:10:40 -0700 (PDT)
Received: by mail-il1-x131.google.com with SMTP id x9so4874578ilp.4 for <lp-wan@ietf.org>; Thu, 03 Jun 2021 02:10:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ackl-io.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:cc; bh=AC+7ueFUUKDwhecZuhyYckvjoWqcryjRmoOprK61XUM=; b=KPYW3YvN23FlcbXsddKVgMnEcYqNqK65LVJrt67Uh3qvjyhhrRa+7gV9uMzsrCi/le 1hKpB4kBYinlnwpqXu/b8yuqtCEJUeJ1DwSRoiZFmxGTcC3UbnkW0dljkAUN+IMRqa8I wfB7VO6+5HkS4HBvdnTocrRwHnjh0LAK5mbO3EdxL2P9stw2f3seLdBr7pXfBqQNGNiT eeVYv2okxJx3KmNGEBTgbrw70CmXNoZeI/LtbdJ70lrqcAu2W4FMltBjO2V+z4s/ZHP3 /c7fCHwmkPV2352C8iZnfozveGdXZXFtv4Mu2AQyEmRN0bLkDrZT0aSrBF5az5xxAvv4 UDkw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=AC+7ueFUUKDwhecZuhyYckvjoWqcryjRmoOprK61XUM=; b=M/iM14ySUytmM7jrjpYPmbYyNMDSuEcjYzC/6V+J/dUiIhm//XkAih/T3f1B5r1zks U79xZQatOthud8NMcNXI9iU3Mml85QKIkGIdbHc2vQ1zGQiIeGkAAZ0SISvkEvh0nOL7 agAvHcHr7sXCp+PI9+Zm93GMKTcw/hY2zJkGjx2dNIwr3S2+XIAqVMw8k2eNY5wkUWU7 cBcB/0acy+T3G79TsGMkATKp+Koelnkx6dkoUuE6b2353r7pAs8a+yYBfdvuhWsOONEX 2P5i363kfzhNKmUKTF4unhdpQCpqPWQUA+0F1iyPyWHGdXic6DIQLuqPqxQvcHf+0sIa 9LXg==
X-Gm-Message-State: AOAM530nuYmfgISEg4ZYm2Opgnuq3MQzb1o5XXPnvyLvcDFoLDfo8STR R++lYx9kYN5h7L3v4dyT0fNotH3XevlNeoyENhnIyBXrcdKOfw==
X-Google-Smtp-Source: ABdhPJyTCyt421UFuWGfOklOcaqHkBgpgN/Pqr++O/9fBl9xLFu9EDHZaZyWi4Ne64i7kiqX9VEYXCJBXBca5AEsDok=
X-Received: by 2002:a92:da4f:: with SMTP id p15mr18858138ilq.200.1622711439222; Thu, 03 Jun 2021 02:10:39 -0700 (PDT)
MIME-Version: 1.0
From: Ana Minaburo <ana@ackl.io>
Date: Thu, 03 Jun 2021 11:10:11 +0200
Message-ID: <CAAbr+nQJzZ242B9EhzqgaW40VMA=iXhpn743wC1PdQE2kDzZ=Q@mail.gmail.com>
To: "lp-wan@ietf.org" <lp-wan@ietf.org>, "laurent.toutain@imt-atlantique.fr" <laurent.toutain@imt-atlantique.fr>, "randreasen@fi.uba.ar" <randreasen@fi.uba.ar>
Cc: "ana@ackl.io" <ana@ackl.io>, "Eric Vyncke (evyncke)" <evyncke@cisco.com>
Content-Type: multipart/alternative; boundary="000000000000e880c405c3d8f204"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lp-wan/TJgxQxJ_sRv1vXgixMntQa1zPtI>
Subject: [lp-wan] FWD: Draft SCHC for CoAP -Title
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: Thu, 03 Jun 2021 09:10:47 -0000

Dear Dominique, Carles, and Pascal, and all,

I take this discussion out from the RFC-Editor Subject, if not I will be
lost again.

We agree to eliminate the term LPWAN from the title during the interim
meeting, and I've answered the RFC-Editor with this option that I like:
Full-extended:
"Static Context Header Compression and Fragmentation (SCHC) for Constrained
Application Protocol (CoAP)"
Full-abbreviated:
"SCHC for CoAP"

I'm afraid I have to disagree with Dominique's proposition in two things.
First, starting with Compression, the title is ambiguous because it can be
interpreted as data compression and no header compression. Second, I'm not
sure SCHC is a framework, or neither it becomes one.

Dominique proposition: "Compression of the Constrained Application Protocol
(CoAP) using the Static Context Header Compression and fragmentation (SCHC)
framework"

Cheers,
Ana

---

>From: Pascal Thubert (pthubert) <pthubert@cisco.com>
>Date: Wed, Jun 2, 2021 at 11:14 AM
>Subject: RE: [AD] Re: AUTH48 [LB]: RFC 8824
<draft-ietf-lpwan-coap-static->context-hc-19.txt> NOW AVAILABLE
>To: dominique.barthel@orange.com <dominique.barthel@orange.com>, >
ana@ackl.io <ana@ackl.io>, Eric Vyncke (evyncke) <evyncke@cisco.com>
>Cc: lp-wan@ietf.org <lp-wan@ietf.org>, laurent.toutain@imt-atlantique.fr
><laurent.toutain@imt-atlantique.fr>, randreasen@fi.uba.ar
><randreasen@fi.uba.ar>
>
>
>Perfect!
>
>>From: Carles Gomez Montenegro <carlesgo@entel.upc.edu>
>>Date: Wed, Jun 2, 2021 at 11:02 AM
>>Subject: Re: [lp-wan] [AD] Re: AUTH48 [LB]: RFC 8824 <draft-ietf-lpwan-
>>coap-static-context-hc-19.txt> NOW AVAILABLE
>>To: <dominique.barthel@orange.com>
>>Cc: Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org>, >>
ana@ackl.io <ana@ackl.io>, Eric Vyncke (evyncke) <evyncke@cisco.com>, >>
lp-wan@ietf.org <lp-wan@ietf.org>, laurent.toutain@imt-atlantique.fr
>><laurent.toutain@imt-atlantique.fr>, randreasen@fi.uba.ar
>><randreasen@fi.uba.ar>
>>
>>
>>Hello Dominique, (all,)
>>
>>I support your proposal below!
>>
>>In my opinion, it addresses nicely the comment being considered.
>>
>>Cheers,
>>
>>Carles
>>
>>
>>
>>
>>
>>
>>>From: <dominique.barthel@orange.com>
>>>Date: Tue, Jun 1, 2021 at 5:14 PM
>>>Subject: RE: [AD] Re: AUTH48 [LB]: RFC 8824
<draft-ietf-lpwan-coap->>>static-context-hc-19.txt> NOW AVAILABLE
>>>To: Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org>, >>>
ana@ackl.io <ana@ackl.io>, Eric Vyncke (evyncke) <evyncke@cisco.com>
>>>Cc: lp-wan@ietf.org <lp-wan@ietf.org>, laurent.toutain@imt-atlantique.fr
>>><laurent.toutain@imt-atlantique.fr>, randreasen@fi.uba.ar
>>><randreasen@fi.uba.ar>
>>>
>>>
>>>Hello authors, all,
>>>
>>>Following our interim meeting today, here is my contribution to
>>>comment 3 by RFC Ed
>>>> 3) <!-- [rfced] Abstract and subsequent:  "SCHC compression",
>>>>where
>>>> used generally as a noun, looks odd.  We suggest rephrasing where
>>>>appropriate.
>>>>
> >>>We see that RFC 8724 defines "SCHC" as "Static Context Header
>>>> Compression and fragmentation".  Because this document defines
>>>>"SCHC"
>>>>as "Static Context Header Compression", "SCHC compression"
>>>>would then
>>>> read as "Static Context Header Compression compression".
>>>>
>>>> Should we expand "SCHC" as "Static Context Header
>>>>Compression and
>>>> fragmentation" per RFC 8724, instead of using the current "Static
>>>> Context Header Compression"?  That would solve the "Static
>>>>Context Header Compression compression" situation. -->
>>>
>>>This document should not redefine SCHC.
>>>Hence, I propose the following
>>>- Full title
>>>"Compression of the Constrained Application Protocol (CoAP) using >>>the
Static Context Header Compression and fragmentation (SCHC) >>>framework"
>>>- Abstract
>>>"This draft defines how to compress the Constrained Application
>>>Protocol (CoAP) using the Static Context Header Compression and
>>>fragmentation (SCHC) framework. SCHC defines a header >>>compression
mechanism tailored for Constrained Devices."
 >>>- Introduction, 2nd paragraph
>>>"[RFC8724] defines the SCHC famework, which includes a header
>>>compression mechanism for the LPWAN network, based on a static
>>>context."
>>>
>>>With the above changes, which are consistent with RFC8724 and are
>>>inline with the RFC Editors suggestion, "SCHC compression" no >>>longer
looks odd, and the 25 instances can remain unchanged.
>>>
>>>Best regards
>>>
>>>Dominique
>>>