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

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