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

["Pascal Thubert (pthubert)" <[e-mail]>]

Perfect!

> -----Original Message-----
> From: [e-mail] <[e-mail]>
> Sent: mardi 1 juin 2021 17:15
> To: Pascal Thubert (pthubert) <[e-mail]>; [e-mail]; Eric
> Vyncke (evyncke) <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]
> Subject: RE: [AD] Re: AUTH48 [LB]: RFC 8824 <draft-ietf-lpwan-coap-
> static-context-hc-19.txt> NOW AVAILABLE
> 
> 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:[e-mail]] On Behalf Of Pascal Thubert
> (pthubert)
> Sent: lundi 31 mai 2021 14:31
> To: [e-mail]; Eric Vyncke (evyncke) <[e-mail]>
> Cc: [e-mail]; [e-mail];
> [e-mail]
> 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: [e-mail] <[e-mail]>
> > Sent: mercredi 26 mai 2021 23:54
> > To: [e-mail]; [e-mail];
> > [e-mail]
> > Cc: [e-mail]; [e-mail];
> > [e-mail]; Pascal Thubert (pthubert) <[e-mail]>
> > 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, [e-mail] 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
> [e-mail]
> 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.