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

[Jean Mahoney <[e-mail]>]

IANA,

On https://www.iana.org/assignments/_6tisch/, please update the 
following registry name (add "Unsupported"):

    OLD:  Constrained Join Protocol (CoJP) Configuration Codes

    NEW:  Constrained Join Protocol (CoJP) Unsupported Configuration Codes

Best regards,

RFC Editor/jm

On 5/11/21 4:57 AM, Mališa Vučinić wrote:
> 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
>      
>      
>