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