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

[Kris Pister <[e-mail]>]

I approve this RFC for publication

ksjp

On Tue, May 11, 2021 at 1:19 PM Jean Mahoney <[e-mail]> wrote:

> Mališa,
>
> Thank you for your quick response. We have updated the document with your
> feedback:
>
>    https://www.rfc-editor.org/authors/rfc9031.txt
>    https://www.rfc-editor.org/authors/rfc9031.pdf
>    https://www.rfc-editor.org/authors/rfc9031.html
>    https://www.rfc-editor.org/authors/rfc9031.xml
>    https://www.rfc-editor.org/authors/rfc9031-diff.html (all changes)
>    https://www.rfc-editor.org/authors/rfc9031-auth48diff.html (AUTH48
> changes)
>
> We have also updated the terms "layer-2" and "layer-3" to "Layer 2" and
> "Layer 3" to match changes in RFC 9030.
>
> We will await further word from you and your coauthors regarding other
> AUTH48 changes and/or approval.
>
> Best regards,
>
> RFC Editor/jm
>
>
> On 5/11/21 9:44 AM, Mališa Vučinić wrote:
>
> Dear Jean, dear Alice,
>
> Here is a list of changes I would like to make at this stage.
>
> Section 5
> OLD:
> The pledge is still able to parse the contents of the received EBs and i synchronize to the network, as EBs are not encrypted [RFC8180].
> NEW:
> The pledge is still able to parse the contents of the received EBs and synchronize to the network, as EBs are not encrypted [RFC8180].
>
> Section 6.1.1.
> DELETE:
> One example is the 6TiSCH Minimal Scheduling Function [RFC9033].
>
> Section 8.3.3.
> OLD:
> failed JRC to rejoin through out-of-band means during the process of JCR reinitialization
> NEW:
> failed JRC to rejoin through out-of-band means during the process of JRC reinitialization
>
> Section 9
> OLD:
> The data cap can be configured by the JRC by including a join rate parameter i in the Join Response,
> NEW:
> The data cap can be configured by the JRC by including a join rate parameter in the Join Response,
>
> - It seems that the normative language in IANA section 11.1 is missing and that the other two IANA subsections are not aligned. Following changes are requested:
>     - Move the sentences containing normative language to the end of their corresponding paragraph (applies to 11.2 and 11.3). E.g:
>          - OLD: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the encoding.
>          - NEW: This is a descriptive name that enables easier reference to the item. It is not used in the encoding. The name MUST be unique.
>     - Add the following statements in their corresponding paragraphs:
>         - Section 11.1:
>             - Name: The name MUST be unique.
>             - Label: The label MUST be unique.
>             - Description: The description MUST be unique.
>         - Section 11.2:
>             - Algorithm: The algorithm MUST be unique.
>             - Description: The description MUST be unique.
>
> - Figure 3: Extend the arrow of “E2E OSCORE” all the way from "Client" to "Server".
>
> - Please add the following persons to the acknowledgments in alphabetic order merging with the existing list:
>     - Linda Dunbar
>     - Vijay Gurbani
>     - Hilarie Orman
>     - Benjamin Kaduk
>     - Roman Danyliw
>     - Mirja Kühlewind
>     - Barry Leiba
>     - Alvaro Retana
>     - Adam Roach
>     - Éric Vyncke
>     - John Mattsson
>
> - Please use “Amsüss” instead of “Amsuss” in Christian Amsüss’ name in the acknowledgments.
>
> That would be all at this points, thanks!
>
> Mališa
>
> On 11/05/2021 08:21, "[e-mail]" <[e-mail]> <[e-mail]> <[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> <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
>
>
>
>