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

[[e-mail]]

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


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


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


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


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


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


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


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


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


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


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


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


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