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

["Eric Vyncke (evyncke)" <[e-mail]>]

Good idea

-----Original Message-----
From: Pascal Thubert <[e-mail]>
Date: Monday, 31 May 2021 at 14:31
To: "[e-mail]" <[e-mail]>, Eric Vyncke <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[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

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