[C310] [IANA] Re: AUTH48 [JM]: RFC 9031 <draft-ietf-6tisch-minimal-security-15.txt> NOW AVAILABLE
Jean Mahoney <jmahoney@amsl.com> Thu, 13 May 2021 22:55 UTC
Return-Path: <jmahoney@amsl.com>
X-Original-To: c310@rfc-editor.org
Delivered-To: c310@rfc-editor.org
Received: from localhost (localhost [127.0.0.1]) by rfc-editor.org (Postfix) with ESMTP id 2BD3EF407BA; Thu, 13 May 2021 15:55:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
X-Spam-Flag: NO
X-Spam-Score: -197.999
X-Spam-Level:
X-Spam-Status: No, score=-197.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.01, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=2, SPF_PASS=-0.001, SUBJECT_IN_WHITELIST=-100, URIBL_BLOCKED=0.001, USER_IN_WELCOMELIST=-0.01, USER_IN_WHITELIST=-100] autolearn=no autolearn_force=no
Received: from rfc-editor.org ([127.0.0.1]) by localhost (rfcpa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N_4pKYSMagwz; Thu, 13 May 2021 15:55:41 -0700 (PDT)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) by rfc-editor.org (Postfix) with ESMTPS id 46ECBF40769; Thu, 13 May 2021 15:55:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id A1D1338A067; Thu, 13 May 2021 15:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSJ4WzUD7vZt; Thu, 13 May 2021 15:55:45 -0700 (PDT)
Received: from AMSs-MBP.localdomain (unknown [47.186.1.92]) by c8a.amsl.com (Postfix) with ESMTPSA id 01EF338A062; Thu, 13 May 2021 15:55:44 -0700 (PDT)
Cc: ek.ietf@gmail.com, 6tisch-ads@ietf.org, 6tisch-chairs@ietf.org, c310@rfc-editor.org, Mališa Vučinić <malisa.vucinic@inria.fr>, "rfc-editor@rfc-editor.org" <rfc-editor@rfc-editor.org>, "Simon, Jonathan" <jonathan.simon@analog.com>, pister@eecs.berkeley.edu, Michael Richardson <mcr+ietf@sandelman.ca>
References: <20210511062313.11051F407DF@rfc-editor.org> <8C9F88B3-DCA8-44F2-A020-CD1F6CD1CAAD@inria.fr>
From: Jean Mahoney <jmahoney@amsl.com>
To: iana@iana.org
Message-ID: <d6939168-2564-55a7-b485-308e9ee8be7f@amsl.com>
Date: Thu, 13 May 2021 17:55:44 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <8C9F88B3-DCA8-44F2-A020-CD1F6CD1CAAD@inria.fr>
Content-Type: multipart/alternative; boundary="------------ED95DFA7F2CFC335DFE973BC"
Content-Language: en-US
Subject: [C310] [IANA] Re: AUTH48 [JM]: RFC 9031 <draft-ietf-6tisch-minimal-security-15.txt> NOW AVAILABLE
X-BeenThere: c310@rfc-editor.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <c310.rfc-editor.org>
List-Unsubscribe: <https://www.rfc-editor.org/mailman/options/c310>, <mailto:c310-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <http://www.rfc-editor.org/pipermail/c310/>
List-Post: <mailto:c310@rfc-editor.org>
List-Help: <mailto:c310-request@rfc-editor.org?subject=help>
List-Subscribe: <https://www.rfc-editor.org/mailman/listinfo/c310>, <mailto:c310-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Thu, 13 May 2021 22:55:43 -0000
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, "rfc-editor@rfc-editor.org" <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, rfc-editor@rfc-editor.org 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 > > >
- [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tisch-m… rfc-editor
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… rfc-editor
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Mališa Vučinić
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Mališa Vučinić
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Alice Russo
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Mališa Vučinić
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Jean Mahoney
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Simon, Jonathan
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Kris Pister
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Jean Mahoney
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Erik Kline
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Jean Mahoney
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Michael Richardson
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Michael Richardson
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Pascal Thubert (pthubert)
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Jean Mahoney
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Jean Mahoney
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Mališa Vučinić
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Jean Mahoney
- Re: [C310] AUTH48 [JM]: RFC 9031 <draft-ietf-6tis… Michael Richardson
- [C310] [IANA] Re: AUTH48 [JM]: RFC 9031 <draft-ie… Jean Mahoney
- [C310] [IANA #1197193] [IANA] Re: AUTH48 [JM]: RF… Sabrina Tanamal via RT
- Re: [C310] [IANA #1197193] [IANA] Re: AUTH48 [JM]… Jean Mahoney