Subject: Re: [lp-wan] [AD] Re: AUTH48 [LB]: RFC 8824 <draft-ietf-lpwan-coap-static-context-hc-19.txt> NOW AVAILABLE

From: <[email-masked]>
Date: Tue, 1 Jun 2021 15:14:46 +0000

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

-----Original Message-----
From: lp-wan [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: lundi 31 mai 2021 14:31
To: [email-masked]; Eric Vyncke (evyncke) <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [lp-wan] [AD] Re: AUTH48 [LB]: RFC 8824 <draft-ietf-lpwan-coap-static-context-hc-19.txt> NOW AVAILABLE

Eric, Ana:

Would you wish to discuss this tomorrow at the interim?

Keep safe;

Pascal

> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: mercredi 26 mai 2021 23:54
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; Pascal Thubert (pthubert) <[email-masked]>
> Subject: [AD] Re: AUTH48 [LB]: RFC 8824 <draft-ietf-lpwan-coap-static- 
> context-hc-19.txt> NOW AVAILABLE
> 
> Authors, Éric (as AD),
> 
> *Éric, please reply to questions #7 and #14 below.
> 
> While reviewing this document during AUTH48, please resolve (as
> necessary) the following questions, which are also in the XML file.
> 
> 1) <!-- [rfced] Full and abbreviated (running) document title:
> We expanded the abbreviations in the full title, as they are not 
> considered well known.
> 
> Also, we had trouble following the running title as compared to the 
> full title.  May we update as suggested?
> 
> Original:
>  LPWAN Static Context Header Compression (SCHC) for CoAP ...
>  LPWAN CoAP compression
> 
> Current full title:
>  Low-Power Wide-Area Network (LPWAN) Static Context Header Compression
>          (SCHC) for the Constrained Application Protocol (CoAP)
> 
> Suggested abbreviated title:
>  LPWAN SCHC for CoAP -->
> 
> 
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear 
> in the
> title) for use on https://www.rfc-editor.org/search -->
> 
> 
> 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. -->
> 
> 
> 4) <!-- [rfced] Section 3:  We are revisiting this question as asked 
> previously.  Please clarify the meaning of "make the difference".
> 
> We had trouble following the meaning of "make the difference" in this 
> sentence.  Does it mean "determine the difference between header 
> types" or something else?
> 
> Original:
>  The field
>  description MAY define both request/response headers and target  
> values in the same Rule, using the DI (direction indicator) to make  
> the difference.
> 
> Perhaps:
>  The field
>  description MAY define both request/response headers and target  
> values in the same Rule, using the DI (direction indicator) to  
> indicate the header type.
> 
> Author reply:
> => Make the difference means that we can identify the description of 
> the request and the response using the DI. We use DI as the decision 
> maker. -
> ->
> 
> 
> 5) <!-- [rfced] Section 3.1:  We are revisiting this question as asked 
> previously.  Please let us know how this sentence should be updated - 
> our "Possibly" text, or the author's reply text (i.e., removing 
> mention of the same behavior)?
> 
> This sentence is difficult to follow.
> Are three things listed here, or does "same behavior" refer to the two 
> code format (values)?  Also, does "field Code" mean "Code field,"
> "field's code", or something else?
> 
> Original:
>  The field Code has the same behavior, the 0.0X code  format value in 
> the request, and the Y.ZZ code format in the  response.
> 
> Possibly:
>  The field Code has the same behavior: the 0.0X code format value in  
> the request and the Y.ZZ code format in the response.
> 
> Author reply:
> => Agree with your possibility of using :
> The field Code in the CoAP header has the format 0.0X in the request 
> and Y.ZZ in the response, and can be compessed as the field Type. -->
> 
> 
> 6) <!-- [rfced] Section 4.3:  "The Code field is an IANA registry" 
> reads oddly.  If the suggested text is not correct, please clarify.
> 
> Original:
>  The Code field is an IANA registry [RFC7252], and it indicates the 
> Request Method used in CoAP.
> 
> Suggested:
>  The Code field, defined in an IANA registry [RFC7252],  indicates the 
> Request Method used in CoAP. -->
> 
> 
> 7) <!-- [rfced] *[AD]:  Original Figure 5 (now Table 2):  Please 
> review the following updates to this table and the subsequent text, as 
> specified by the author in reply to our preliminary question 15), and 
> let us know if you approve.  Per the author, we changed "k=\"" to "k=" 
> and MSB(24) to MSB(16) in the table, and we changed "0x2 X 6"
> and '0x05 eth0"' to '0x2 "X6"' and '0x4 "eth0"' in the subsequent 
> text.
> 
> (We have removed the dashed lines here, so that xml2rfc will not try 
> to interpret them as comments.  It will be best to look at the diff 
> file and the text output in order to see these updates.)
> 
> Original question and author reply:
> 
> 15) Section 5.3:  The "i.e.," item is missing a quotation mark.  
> Should it be "0x05 eth0" or 0x05 "eth0"?
> 
> Original:
>  SCHC will send the second element of the URI-Path with the length  
> (i.e., 0x2 X 6) followed by the query option (i.e., 0x05 eth0").
>  => OLD
> 
> For instance, for a CORECONF path /c/X6?k="eth0" the Rule description
>    can be:
> 
>       | Field       |FL |FP|DI| Target | Match   |     CDA     |
>       |             |   |  |  | Value  | Opera.  |             |
> 
>       |Uri-Path     |   | 1|up|"c"     |equal    |not-sent     |
>       |Uri-Path     |var| 2|up|        |ignore   |value-sent   |
>       |Uri-Query    |var| 1|up|"k=\""  |MSB(24)  |LSB          |
> 
>                     Figure 5: CORECONF URI compression
> 
>    Figure 5 shows the Rule description for a URI-Path and a URI-Query.
>    SCHC compresses the first part of the URI-Path with a "not-sent" CDA.
>    SCHC will send the second element of the URI-Path with the length
>    (i.e., 0x2 X 6) followed by the query option (i.e., 0x05 eth0").
> 
> NEW
> 
>   For instance, for a CORECONF path /c/X6?k=eth0 the Rule description
>    can be:
> 
>       | Field       |FL |FP|DI| Target | Match   |     CDA     |
>       |             |   |  |  | Value  | Opera.  |             |
> 
>       |Uri-Path     |   | 1|up|"c"     |equal    |not-sent     |
>       |Uri-Path     |var| 2|up|        |ignore   |value-sent   |
>       |Uri-Query    |var| 1|up|"k="    |MSB(16)  |LSB          |
> 
> 
>                     Figure 5: CORECONF URI compression
> 
>    Figure 5 shows the Rule description for a URI-Path and a URI-Query.
>    SCHC compresses the first part of the URI-Path with a "not-sent" CDA.
>    SCHC will send the second element of the URI-Path with the length
>    (i.e., 0x2 "X6") followed by the query option (i.e., 0x4 "eth0"). 
> -->
> 
> 
> 8) <!-- [rfced] Figures 5 and 7 (now Tables 2 and 3):  As it appears 
> that "Match Opera." means "MO", we updated accordingly, per the 
> original Figure 18 (now Table 5).  Please let us know if this is 
> incorrect.
> 
> Original:
>  | Match   |
>  | Opera.  |
> 
> Currently:
>  |    MO   | -->
> 
> 
> 9) <!-- [rfced] Sections 5.4 and subsequent:  Per guidance in Section 
> 3.2 of RFC 7322 (https://www.rfc-editor.org/rfc/rfc7322.txt),
> we moved punctuation outside quotation marks where literal text (e.g., 
> "value-sent") is used.  Please let us know any concerns. -->
> 
> 
> 10) <!-- [rfced] FYI, We have converted Figures 7, 13, 18, and 21 into 
> tables (Tables 3, 4, 5, and 6).  Please let us know if any formatting 
> changes are necessary. -->
> 
> 
> 11) <!-- [rfced] Tables 3, 5, and 6 (originally Figures 7, 18, and 21):
> Please clarify the following:
> 
> * Should "MSB(7 )" be "MSB(7)"?
> 
> * Is it necessary to center "CC CCC" and right-justify "M-ID" when all 
> other cells in "Sent [bits]" columns are left-justified?
> Because most entries are left-justified, we used left justification 
> here as well.  Please let us know if special alignment is needed in 
> these cases.
> 
> * Should "M-ID" be "MID" as used elsewhere in this document?
> 
> * It appears that the instances of "var 1" in the original Figures 7 
> and 18 (now Tables 3 and 5) should be "var|1" per the formatting of 
> "var" items in the original Figures 4 and 5 (now Tables 1 and 2).  We 
> formatted accordingly.  Please note that this item also applies to the 
> original "tkl 1"s in the original Figures 18 and 21 (now Tables 5 and 
> 6); these are now "tkl|1".
> Please let us know any concerns. -->
> 
> 
> 12) <!-- [rfced] Section 7.2:  For ease of the reader, we expanded "AAD"
> as "Additional Authenticated Data", per RFC 8613.  Please let us know 
> if this is incorrect.
> 
> Original:
>  o  Class I: Integrity-protected options included in the AAD for the
>     encryption of the Plaintext but otherwise left untouched in the
>     Outer Message,
> 
> Currently:
>  Class I:  Integrity-protected options included in the Additional
>     Authenticated Data (AAD) for the encryption of the Plaintext but
>     otherwise left untouched in the Outer Message. -->
> 
> 
> 13) <!-- [rfced] Original Figures 8 and 10 (now Figures 5 and 7):
> We changed the two instances of "OxFF" to "0xFF".  Please let us know 
> if this is incorrect.
> 
> Original:
>  | Options (IU)             |                | OxFF  |
> ...
>  | Options (IU)             |                | OxFF  |
> 
> Currently:
>  | Options (IU)             |                | 0xFF  |
> ...
>  | Options (IU)             |                | 0xFF  | -->
> 
> 
> 14) <!-- [rfced] *[AD]:  We removed the original "Thus only the first 
> ..."
> sentence per the author's reply to our preliminary question 23).
> Please review, and let us know if you approve.
> 
> Original question:
> 
> Section 7.2:  It appears that one or more words are missing in this 
> sentence.  Please clarify "the first variable-length of the 
> Ciphertext".
> 
> Original (the entire paragraph is included for context):
>  As defined in [RFC5116], this Ciphertext is the encrypted Plaintext's  
> concatenation of the authentication tag.  Note that Inner Compression  
> only affects the Plaintext before encryption.  Thus only the first  
> variable-length of the Ciphertext can be reduced.  The authentication  
> tag is fixed in length and is considered part of the cost of  
> protection.
> 
> Author reply:
>  => NEW
> As defined in [RFC5116], this Ciphertext is the encrypted Plaintext's  
> concatenation of the authentication tag.  Note that Inner Compression  
> only affects the Plaintext before encryption.  The authentication  
> tag, fixed in length and not be compressed, is considered as part of 
> the cost of protection. -->
> 
> 
> 15) <!-- [rfced] Original Figures 12, 22, and 23 (now Figures 9, 16, 
> and 17):  Should the following lengths be expressed in bytes, bits, or 
> something else?
> 
> Original:
>  Original msg length:   10
> ...
>  Compressed msg length: 2
> ...
>  Compressed msg length: 6
> 
> Possibly:
>  Original message length:   10 bytes
> ...
>  Compressed message length: 2 bytes
> ...
>  Compressed message length: 6 bytes -->
> 
> 
> 16) <!-- [rfced] Section 7.3:  We see what appears to be conflicting 
> information in the different descriptions of the original Figure 18, 
> which is now Table 5.  We have moved Table 5 so that it appears closer 
> to its first citation, but this makes the conflicting information more 
> noticeable.
> 
> Please let us know how the following should be clarified (e.g., "Outer 
> SCHC Rules" vs. "possible set of Outer Rules" vs. "Outer Rule of 
> Figure 18 is").  We ask because, for example, the title of Figure 18 
> (now Table 5) is the plural "Outer SCHC Rules", but the original "The 
> Outer Rule of Figure 18 is" does not make it clear which of the rules 
> shown in Table 5 is being discussed.
> 
> Original:
>  The Outer SCHC Rules (Figure 18) must process the OSCORE Options  
> fields.
> ...
>  Figure 18 shows a possible set of Outer Rules to compress the Outer  
> Header.
> ...
>  The Outer Rule of Figure 18 is applied to the example GET Request and  
> CONTENT Response. -->
> 
> 
> 17) <!-- [rfced] Original Figures 19 and 20 (now Figures 14 and 15):
> Please confirm that "tkn" (and not "tkl") is correct in these figures.
> 
> Original:
>  Compression Residue:
>  0b 0001 010 0100 0100 (15 bits -> 2 bytes with padding)
>      mid tkn piv  kid
> ...
>  Compression Residue:
>  0b0001 010 (7 bits -> 1 byte with padding)
>    mid  tkn -->
> 
> 
> 18) <!-- [rfced] Section 7.3:  We had trouble following this sentence.
> For example, the title of Figure 21 (now Table 6) is the plural 
> "SCHC-CoAP Rules (No OSCORE)"; if the text should not be "Rules 
> yield", should a particular Rule be specified here?  If the suggested 
> text is not correct, please clarify.
> 
> Original:
>  Figure 21 Rule yields the SCHC compression results in Figure 22 for  
> request, and Figure 23 for the response.
> 
> Suggested (assuming that "Rule" should be plural, and noting that
>   figures and tables have been renumbered):
>  The Rules in Table 6 yield the SCHC compression results as shown in  
> Figure 16 for the request and Figure 17 for the response. -->
> 
> 
> Thank you.
> 
> RFC Editor/lb/jm
> 
> 
> On 5/26/21 4:40 PM, [email-masked] wrote:
> 
> *****IMPORTANT*****
> 
> Updated 2021/05/26
> 
> RFC Author(s):
> --------------
> 
> Instructions for Completing AUTH48
> 
> Your document has now entered AUTH48.  Once it has been reviewed and 
> approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies 
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
> 
> You and you coauthors are responsible for engaging other parties 
> (e.g., Contributors or Working Group) as necessary before providing 
> your approval.
> 
> Planning your review
> ---------------------
> 
> Please review the following aspects of your document:
> 
> *  RFC Editor questions
> 
>    Please review and resolve any questions raised by the RFC Editor
>    that have been included in the XML file as comments marked as
>    follows:
> 
>    <!-- [rfced] ... -->
> 
>    These questions will also be sent in a subsequent email.
> 
> *  Changes submitted by coauthors
> 
>    Please ensure that you review any changes submitted by your
>    coauthors.  We assume that if you do not speak up that you
>    agree to changes submitted by your coauthors.
> 
> *  Content
> 
>    Please review the full content of the document, as this cannot
>    change once the RFC is published. Please pay particular attention to:
>    - IANA considerations updates (if applicable)
>    - contact information
>    - references
> 
> *  Copyright notices and legends
> 
>    Please review the copyright notice and legends as defined in
>    RFC 5378 and the Trust Legal Provisions
>    (TLP – https://trustee.ietf.org/license-info/).
> 
> *  Semantic markup
> 
>    Please review the markup in the XML file to ensure that elements of
>    content are correctly tagged.  For example, ensure that <sourcecode>
>    and <artwork> are set correctly.  See details at
>    <https://xml2rfc.tools.ietf.org/xml2rfc-doc.html>.
> 
> *  Formatted output
> 
>    Please review the PDF, HTML, and TXT files to ensure that the
>    formatted output, as generated from the markup in the XML file, is
>    reasonable.  Please note that the TXT will have formatting
>    limitations compared to the PDF and HTML.
> 
> 
> Submitting changes
> ------------------
> 
> To submit changes, please reply to this email with one of the 
> following, using ‘REPLY ALL’ as all the parties CC’ed on this message 
> need to see your changes:
> 
> An update to the provided XML file
>  — OR —
> An explicit list of changes in this format
> 
> Section # (or indicate Global)
> 
> OLD:
> old text
> 
> NEW:
> new text
> 
> You do not need to reply with both an updated XML file and an explicit 
> list of changes, as either form is sufficient.
> 
> We will ask a stream manager to review and approve any changes that 
> seem beyond editorial in nature, e.g., addition of new text, deletion 
> of text, and technical changes.  Information about stream managers can 
> be found in the FAQ.  Editorial changes do not require approval from a 
> stream manager.
> 
> 
> Approving for publication
> --------------------------
> 
> To approve your RFC for publication, please reply to this email s 
> tating that you approve this RFC for publication.  Please use ‘REPLY ALL’
> as all the parties CC’ed on this message need to see your approval.
> 
> 
> Files
> -----
> 
> The files are available here:
>    https://www.rfc-editor.org/authors/rfc8824.xml
>    https://www.rfc-editor.org/authors/rfc8824.html
>    https://www.rfc-editor.org/authors/rfc8824.pdf
>    https://www.rfc-editor.org/authors/rfc8824.txt
> 
> Diff file of the text:
>    https://www.rfc-editor.org/authors/rfc8824-diff.html
> 
> For your convenience, we have also created an alt-diff file that will 
> allow you to more easily view changes where text has been deleted or
> moved:
>    https://www.rfc-editor.org/authors/rfc8824-alt-diff.html
> 
> Diff of the XML:
>    https://www.rfc-editor.org/authors/rfc8824-xmldiff1.html
> 
> The following files are provided to facilitate creation of your own 
> diff files of the XML.
> 
> Initial XMLv3 created using XMLv2 as input:
>    https://www.rfc-editor.org/authors/rfc8824.original.v2v3.xml
> 
> XMLv3 file that is a best effort to capture v3-related format updates
> only:
>    https://www.rfc-editor.org/authors/rfc8824.form.xml
> 
> 
> Tracking progress
> -----------------
> 
> The details of the AUTH48 status of your document are here:
>    https://www.rfc-editor.org/auth48/rfc8824
> 
> Please let us know if you have any questions.
> 
> Thank you for your cooperation,
> 
> RFC Editor
> 
> --------------------------------------
> RFC8824 (draft-ietf-lpwan-coap-static-context-hc-19)
> 
> Title            : LPWAN Static Context Header Compression (SCHC) for
> CoAP
> Author(s)        : A. Minaburo, L. Toutain, R. Andreasen
> WG Chair(s)      : Alexander Pelov, Pascal Thubert
> Area Director(s) : Erik Kline, Éric Vyncke
> 
> 

_______________________________________________
lp-wan mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lp-wan

_________________________________________________________________________________________________________________________

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.

---

From: "Carles Gomez Montenegro" <[email-masked]>
Date: Wed, 2 Jun 2021 11:32:26 +0200

Hello Dominique, (all,)

I support your proposal below!

In my opinion, it addresses nicely the comment being considered.

Cheers,

Carles

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 2 Jun 2021 09:14:44 +0000

Perfect!

> From: [email-masked] <[email-masked]>
> Sent: mardi 1 juin 2021 17:15
> To: Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; Eric
> Vyncke (evyncke) <[email-masked]>
> Subject: RE: [AD] Re: AUTH48 [LB]: RFC 8824 <draft-ietf-lpwan-coap-
> static-context-hc-19.txt> NOW AVAILABLE
> 
> Hello authors, all,
> 
> (SCHC) framework. SCHC defines a header compression mechanism tailored
> for Constrained Devices."
> Subject: Re: [lp-wan] [AD] Re: AUTH48 [LB]: RFC 8824 <draft-ietf-lpwan-
> coap-static-context-hc-19.txt> NOW AVAILABLE
> 
> Eric, Ana:
> 
> > only affects the Plaintext before encryption.  The authentication tag,
> > fixed in length and not be compressed, is considered as part of the
> > cost of protection. -->
> >
> >
> _________________________________________________________________________
> ________________________________________________
> 
> 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,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;