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

[Jean Mahoney <[e-mail]>]

Thank you!

On 5/14/21 5:51 PM, Sabrina Tanamal via RT wrote:
> Hi Jean,
>
> We've updated the following registry name:
>
> Constrained Join Protocol (CoJP) Unsupported Configuration Codes
>
> Please see
> https://www.iana.org/assignments/_6tisch
>
> Thanks,
> Sabrina
>
> On Thu May 13 22:56:14 2021, [e-mail] wrote:
>> 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]" <rfc-editor@rfc-
>>> editor.org> 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
>>>
>>>
>>>