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

[Jean Mahoney <[e-mail]>]

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