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