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

Mališa Vučinić <malisa.vucinic@inria.fr> Tue, 11 May 2021 14:44 UTC

Return-Path: <malisa.vucinic@inria.fr>
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 DA4F0F407BB; Tue, 11 May 2021 07:44:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at rfc-editor.org
X-Spam-Flag: NO
X-Spam-Score: -96.37
X-Spam-Level:
X-Spam-Status: No, score=-96.37 tagged_above=-999 required=5 tests=[HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=2, SPF_PASS=-0.001, SUBJECT_IN_WHITELIST=-100, URIBL_BLOCKED=0.001] 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 iY5-5w9qfJNC; Tue, 11 May 2021 07:44:36 -0700 (PDT)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by rfc-editor.org (Postfix) with ESMTPS id 77CACF407AF; Tue, 11 May 2021 07:44:35 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="5.82,291,1613430000"; d="p7s'?scan'208";a="507771804"
Received: from adsl-46-161-103156.crnagora.net (HELO [192.168.100.4]) ([46.161.103.156]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES256-GCM-SHA384; 11 May 2021 16:44:31 +0200
User-Agent: Microsoft-MacOutlook/10.11.0.180909
Date: Tue, 11 May 2021 16:44:28 +0200
From: Mališa Vučinić <malisa.vucinic@inria.fr>
To: rfc-editor@rfc-editor.org, jonathan.simon@analog.com, pister@eecs.berkeley.edu, mcr+ietf@sandelman.ca
CC: 6tisch-ads@ietf.org, 6tisch-chairs@ietf.org, pthubert@cisco.com, ek.ietf@gmail.com, c310@rfc-editor.org
Message-ID: <A94F0C78-2E71-45CB-9217-7E9F9B1F37B2@inria.fr>
Thread-Topic: AUTH48 [JM]: RFC 9031 <draft-ietf-6tisch-minimal-security-15.txt> NOW AVAILABLE
References: <20210511062119.002BEF407AA@rfc-editor.org>
In-Reply-To: <20210511062119.002BEF407AA@rfc-editor.org>
Mime-version: 1.0
Content-type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3703596268_1554876036"
Subject: Re: [C310] 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: Tue, 11 May 2021 14:44:39 -0000

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, "rfc-editor@rfc-editor.org" <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