Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tisch-minimal-security-15.txt> NOW AVAILABLE

[Mališa Vučinić <[e-mail]>]

Dear Jean, dear Alice,

Many thanks for going through the doc. Here is the batch containing responses to your questions encapsulated in [MV] ... [/MV]. I will send a separate email with additional changes once I go through the document top to bottom.

@Michael: there are a couple of points inline where I mentioned you to confirm my responses.

Mališa

On 11/05/2021 08:23, "[e-mail]" <[e-mail]> wrote:

    Authors,
    
    While reviewing this document during AUTH48, please resolve (as necessary) 
    the following questions, which are also in the XML file.
    
    1) <!-- [rfced] Please provide any keywords (beyond those that appear in the
    title) for use on https://www.rfc-editor.org/search.

[MV] Please use the following keywords: bootstrapping, onboarding, oscore [/MV]
    -->
    
    
    2) <!-- [rfced]  We are having difficulty parsing the following 
    sentence in Section 3:
    
    Current:
      The PSK is a long-term secret used to protect the execution 
      of the secure join protocol specified in this document whose 
      one output are link-layer keys.
    
    Perhaps:
      The PSK is a long-term secret used to protect the execution 
      of the secure join protocol specified in this document and 
      is used to create link-layer keys.

[MV] Please use the following sentence:

"The PSK is a long-term secret used to protect the execution of the secure join protocol specified in this document; the link-layer keys are transported as part of the secure join protocol."

[/MV]
    -->
    
    
    3) <!-- [rfced]  In the following sentence in Section 7.3, is 
    perhaps "'kid' flag" instead of "k bit" meant? Also, should it 
    be "OSCORE flag bits"?
    
    Current:
       Since the pledge's OSCORE Sender ID is the empty byte string, when
       constructing the OSCORE option, the pledge sets the k bit in the
       OSCORE flag byte but indicates a 0-length 'kid'.  
    
    Perhaps:
       Since the pledge's OSCORE Sender ID is the empty byte string, when
       constructing the OSCORE option, the pledge sets the 'kid' flag in 
       the OSCORE flag bits but indicates a 0-length 'kid'.  

[MV]  Yes, this is fine, please use the proposed version.[/MV]
    -->
    
    
    4) <!--[rfced] RFC 7049 has been obsoleted by RFC 8949.
    Would you like to update this reference?
    
    Current:
       The payload of CoJP messages is encoded with CBOR [RFC7049].

[MV] Yes, please use the updated reference. [/MV]
    -->
    
    
    5) <!-- [rfced]  In the document, both "j" and "/j" are used. 
    Which is the more correct construction?
    
    For example:
    The Uri-Path option is set to "j". 
    vs. 
    [...] the Uri-Path is only "/j".


[MV]

I believe both "j" and "/j" forms should be used in the document with the following difference.

"j" should be used when referring to the value of the Uri-Path option.

"/j" should be used when referring to the absolute URI. 

That said, I noted the following discrepancy in the document that should be fixed:

Section 8.1.1: 

OLD: 
thus the Uri-Path is only "/j"

NEW:
thus the Uri-Path is only "j"

All the remaining occurrences in the text seem to be fine.

@Michael: please confirm the answer above. 

 [/MV]

    -->
    
    
    6) <!-- [rfced]  RFC 7320 has been obsoleted by RFC 8820, 
    and RFC 5785 has been obsoleted by RFC 8615. 
    Would you like to update the references in Section 8.1.1?
    
    Current:
       BCP 190 [RFC7320] provides guidelines on URI design and ownership.
       It recommends that whenever a third party wants to mandate a URL 
       to web authority that it SHOULD go under "/.well-known" (per 
       [RFC5785]).

[MV] 

Yes, please update these references. 

Also, please replace the occurrences of "URL" with "URI". 

@Michael, please confirm the updated references are fine.

[/MV]

    -->
    
    
    7) <!-- [rfced]  We have updated the following sentence to improve
    readability. Please let us know if any changes are necessary. 
    
    Original:
      If this is the case, during the process of JRC reinitialization, 
      the network administrator MUST force through out-of-band means all    
      the networks managed by the failed JRC to rejoin, through e.g. the 
      reinitialization of the 6LBR nodes and freshly generated dynamic 
      cryptographic keys and other parameters that have influence on the 
      security properties of the network.
    
    Current:
      If this is the case, the network administrator MUST force all the    
      networks managed by the failed JRC to rejoin through out-of-band 
      means during the process of JRC reinitialization, e.g., 
      reinitialize the 6LBR nodes and freshly generate dynamic 
      cryptographic keys and other parameters that influence the security 
      properties of the network.


[MV] Ok! [/MV]

    -->
    
    
    8) <!--[rfced] For Table 6 (Key Usage values), please take a look
    at this file and consider whether you'd like to remove the "Reference" 
    column in order to improve the appearance of the table in the text output
    (i.e., giving the "Name" and "Algorithm" columns more horizontal space).
    
    Alternative format of Table 6 (with sentence added above the table):
    https://www.rfc-editor.org/authors/rfc9031-table6.txt
    https://www.rfc-editor.org/authors/rfc9031-table6.html
    https://www.rfc-editor.org/authors/rfc9031-table6.pdf

[MV] I wasn't able to access the links above due to 404 error [/MV]

    -->
    
    
    9) <!-- [rfced]  We have tightened up the wording of the following 
    in Section 8.4.3.2. Please let us know if any changes are 
    necessary:
    
    Original:
       Upon reception and successful security processing of a link-layer 
       frame secured with a key from the new key set, a 6LN node MUST 
       then switch to sending outgoing traffic using the keys from the 
       new set for all outgoing traffic.  The 6LN node MUST remove any 
       old keys it has installed from the previous key set after a delay 
       of COJP_REKEYING_GUARD_TIME has passed after it starts using the 
       new key set.
    
    Current: 
       Upon the reception and the successful security processing of a 
       link-layer frame secured with a key from the new key set, a 6LN 
       MUST then switch to sending all outgoing traffic using the keys 
       from the new set. The 6LN MUST remove any keys it had installed 
       from the previous key set after waiting COJP_REKEYING_GUARD_TIME 
       since it started using the new key set.


[MV] The proposed change is fine. [/MV]
    -->
    
    
    10) <!--  [rfced]  We're having difficulty parsing the following
    sentence in Section 8.4.5:
    
    Original:
       For example, it is possible to include the link-layer key set 
       object, signaling a subset of keys that cannot be acted upon, or 
       the entire key set that was received.
    
    Perhaps:
       For example, it is possible to include the link-layer key set 
       object, signaling that either a subset or the entire key set that 
       was received cannot be acted upon. 

[MV] This is fine. [/MV]
    -->
    
    
    11) <!--[rfced] Would you like to add mention of RFC 6761 here, as the
    reference for the IANA registry 
    (https://www.iana.org/assignments/special-use-domain-names)?
    
    Current:
       This document allocates a well-known name under the .arpa name space
       according to the rules given in [RFC3172].
    
    Perhaps:
       This document allocates a well-known name under the .arpa name space
       according to the rules given in [RFC3172] and [RFC6761].

[MV] 

Yes, thanks.

@Michael: Please confirm.

[/MV]

    -->
    
    
    12) <!-- [rfced] The original document and the IANA registry differ as follows 
    on the registry name. Should the word "Unsupported" be present?
    If so, we will send IANA a request to update the name accordingly.
    
    This document (original):
    11.3.  CoJP Unsupported Configuration Code Registry
    [...]
      "Constrained Join Protocol Unsupported Configuration Code Registry"
    
    Compare with the IANA registry  (https://www.iana.org/assignments/_6tisch/_6tisch.xhtml#_6tisch-cojp-configuration-codes):
       Constrained Join Protocol (CoJP) Configuration Codes
    
    Section 8.4.5: Depending on your answer, there may be additional 
    changes as follows.
    
    Current:
    Table 7: Unsupported Configuration code values.
    
    Perhaps:
    Table 7: Configuration codes.
    
    
    Current:
    "CoJP Unsupported Configuration Codes" registry (Section 11.3)
    
    Perhaps:
    "CoJP Configuration Codes" registry (Section 11.3)


[MV] Yes, please use the word "Unsupported" in the name of this registry and all the corresponding table and section titles. [/MV]

[MV] 

Could you also update the registry names in Section 11 to remove the word "Registry" from the registry name and align it with the names used by IANA. 

E.g.

Section 11:

OLD:
This section defines a sub-registry within the "IPv6 over the TSCH
   mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name
   "Constrained Join Protocol Parameters Registry".

NEW:
This section defines a sub-registry within the "IPv6 over the TSCH
   mode of IEEE 802.15.4e (6TiSCH) parameters" registry with the name
   "Constrained Join Protocol (CoJP) Parameters".

[/MV]

    -->
    
    
    Thank you.
    
    RFC Editor/jm/ar
    
    
    On May 10, 2021, [e-mail] wrote:
    
    *****IMPORTANT*****
    
    Updated 2021/05/10
    
    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/rfc9031.xml
      https://www.rfc-editor.org/authors/rfc9031.html
      https://www.rfc-editor.org/authors/rfc9031.pdf
      https://www.rfc-editor.org/authors/rfc9031.txt
    
    Diff file of the text:
      https://www.rfc-editor.org/authors/rfc9031-diff.html
      https://www.rfc-editor.org/authors/rfc9031-rfcdiff.html (side-by-side)
    
    Diff of the XML: 
      https://www.rfc-editor.org/authors/rfc9031-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/rfc9031.original.v2v3.xml 
    
    XMLv3 file that is a best effort to capture v3-related format updates 
    only: 
      https://www.rfc-editor.org/authors/rfc9031.form.xml
    
    
    Tracking progress
    -----------------
    
    The details of the AUTH48 status of your document are here:
      https://www.rfc-editor.org/auth48/rfc9031
    
    Please let us know if you have any questions.  
    
    Thank you for your cooperation,
    
    RFC Editor/jm/ar
    
    --------------------------------------
    RFC9031 (draft-ietf-6tisch-minimal-security-15)
    
    Title            : Constrained Join Protocol (CoJP) for 6TiSCH
    Author(s)        : M. Vucinic, Ed., J. Simon, K. Pister, M. Richardson
    WG Chair(s)      : Pascal Thubert, Thomas Watteyne
    Area Director(s) : Erik Kline, Éric Vyncke