All, We have now received all necessary approvals and consider AUTH48 complete (see https://www.rfc-editor.org/auth48/rfc9761).
Thank you for your attention and guidance during the AUTH48 process! We will prepare the document for publication at this time. Best regards, RFC Editor/mc > On Apr 14, 2025, at 1:03 PM, Madison Church <mchu...@staff.rfc-editor.org> > wrote: > > Hi Sabrina, > > The changes look good. Thank you! > > RFC Editor/mc > >> On Apr 14, 2025, at 12:11 PM, Sabrina Tanamal via RT <iana-mat...@iana.org> >> wrote: >> >> Hi Madison, >> >> These changes are complete: >> >> https://www.iana.org/assignments/acl-tls >> >> Thanks, >> Sabrina >> >> On Mon Apr 14 14:27:05 2025, mchu...@staff.rfc-editor.org wrote: >>> Resending with my correct address. >>> >>> Thank you, >>> RFC Editor/mc >>> >>>> On Apr 14, 2025, at 9:22 AM, Madison Church <mchu...@amsl.com> wrote: >>>> >>>> IANA, >>>> >>>> Please make the following capitalization changes to the Description >>>> column in the "ACL (D)TLS Paramaters" registry >>>> (https://www.iana.org/assignments/acl-tls/acl-tls.xhtml#acl-dtls- >>>> parameters): >>>> >>>> 1) pre-shared key exchange mode to Pre-shared key exchange mode >>>> 2) Cipher Suite to Cipher suite >>>> >>>> Thank you, >>>> RFC Editor/mc >>>> >>>>> On Apr 14, 2025, at 9:14 AM, Madison Church <mchu...@staff.rfc- >>>>> editor.org> wrote: >>>>> >>>>> Hi Paul, Authors, >>>>> >>>>> Paul - Thank you for your reply! We have noted your approval on the >>>>> AUTH48 status page (see https://www.rfc-editor.org/auth48/rfc9761). >>>>> >>>>> Authors - We will now ask IANA to make their updates. >>>>> >>>>> Thank you, >>>>> RFC Editor/mc >>>>> >>>>>> On Apr 9, 2025, at 7:38 AM, Paul Wouters <paul.wout...@aiven.io> >>>>>> wrote: >>>>>> >>>>>> Thanks for the reminder ping, >>>>>> >>>>>> I approve of the changes. >>>>>> >>>>>> Paul >>>>>> >>>>>> >>>>>> On Tue, Apr 8, 2025 at 12:47 PM Madison Church <mchu...@staff.rfc- >>>>>> editor.org> wrote: >>>>>> Hi Paul, >>>>>> >>>>>> This is a friendly reminder that we await your review and approval >>>>>> for the changes listed in the thread below. These changes are best >>>>>> viewed in the diff files below: >>>>>> https://www.rfc-editor.org/authors/rfc9761-auth48diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9761-auth48rfcdiff.html >>>>>> (side-by-side diff) >>>>>> >>>>>> Thank you, >>>>>> RFC Editor/mc >>>>>> >>>>>>> On Apr 1, 2025, at 2:08 PM, Madison Church <mchu...@staff.rfc- >>>>>>> editor.org> wrote: >>>>>>> >>>>>>> Hi Authors and *Paul, >>>>>>> >>>>>>> Thank you for your replies! We have noted your approvals on the >>>>>>> AUTH48 status page for this document (see https://www.rfc- >>>>>>> editor.org/auth48/rfc9761). >>>>>>> >>>>>>> *Paul - As the Responsible AD for this document, please review and >>>>>>> approve the following changes. These changes are best viewed in >>>>>>> the diff files below: >>>>>>> https://www.rfc-editor.org/authors/rfc9761-auth48diff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9761-auth48rfcdiff.html >>>>>>> (side-by-side diff) >>>>>>> >>>>>>> 1. Changes in Paragraph 5 of Section 9.3: >>>>>>> >>>>>>> The Security Considerations Section for this document has been >>>>>>> updated to follow the Security Considerations Section Template in >>>>>>> Section 3.7.1 of rfc8407bis (see https://www.ietf.org/id/draft- >>>>>>> ietf-netmod-rfc8407bis-22.html#name-security-considerations-sect). >>>>>>> The following text appears in the template, but not in the >>>>>>> document (the authors have stated that this intentional): >>>>>>> >>>>>>> "Specifically, the following subtrees and data nodes have >>>>>>> particular sensitivities/vulnerabilities:" >>>>>>> >>>>>>> Instead, the paragraph contains the following sentence: >>>>>>> >>>>>>> "The YANG module will provide insights into (D)TLS profiles of the >>>>>>> IoT devices, and the privacy considerations discussed in Section >>>>>>> 10 need to be taken into account." >>>>>>> >>>>>>> Please let us know if this is acceptable. >>>>>>> >>>>>>> >>>>>>> 2. Changes in Paragraph 4 of Section 9.4: Similar to the above, >>>>>>> the following text appears in the template, but not in the >>>>>>> document (the authors have stated that this intentional): >>>>>>> >>>>>>> "Specifically, the following subtrees and data nodes have >>>>>>> particular sensitivities/vulnerabilities:" >>>>>>> >>>>>>> Instead, the paragraph contains the following text: >>>>>>> >>>>>>> "For instance, update that the device does not support (D)TLS >>>>>>> profile can dramatically alter the implemented security policy. >>>>>>> For this reason, the NACM >>>>>>> extension "default-deny-write" has been set for all data nodes >>>>>>> defined in this module." >>>>>>> >>>>>>> Please let us know if this is acceptable. >>>>>>> >>>>>>> >>>>>>> 3. Normative References: Note that RFCs 6242 and 9110 have been >>>>>>> updated to RFCs 4252 and 9000 to match the second paragraph of the >>>>>>> Security Considerations Section Template in rfc8407bis (see >>>>>>> https://www.ietf.org/id/draft-ietf-netmod-rfc8407bis-22.html#name- >>>>>>> security-considerations-sect). Please let us know any objections. >>>>>>> >>>>>>> Once we receive your approval, we will send our updates along to >>>>>>> IANA. >>>>>>> >>>>>>> Thank you! >>>>>>> RFC Editor/mc >>>>>>> >>>>>>> >>>>>>>> On Apr 1, 2025, at 1:34 AM, tirumal reddy <kond...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> Hi Madison, >>>>>>>> >>>>>>>> Updates to the draft look good. I approve publication of the >>>>>>>> document. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> -Tiru >>>>>>>> >>>>>>>> On Tue, 1 Apr 2025 at 02:04, Madison Church <mchu...@staff.rfc- >>>>>>>> editor.org> wrote: >>>>>>>> Hi Tirumal, >>>>>>>> >>>>>>>> Thank you for your reply! We have updated the document >>>>>>>> accordingly and all of our questions have been addressed. >>>>>>>> >>>>>>>> Please review the document carefully to ensure satisfaction as we >>>>>>>> do not make changes once it has been published as an RFC. Contact >>>>>>>> us with any further updates or with your approval of the document >>>>>>>> in its current form. We will await approvals from each party >>>>>>>> listed on the AUTH48 status page prior to moving forward in the >>>>>>>> publication process. >>>>>>>> >>>>>>>> The files have been posted here (please refresh): >>>>>>>> https://www.rfc-editor.org/authors/rfc9761.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9761.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9761.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9761.xml >>>>>>>> >>>>>>>> The relevant diff files have been posted here (please refresh): >>>>>>>> https://www.rfc-editor.org/authors/rfc9761-diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9761-rfcdiff.html (side by >>>>>>>> side) >>>>>>>> https://www.rfc-editor.org/authors/rfc9761-auth48diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9761-auth48rfcdiff.html >>>>>>>> (side by side) >>>>>>>> >>>>>>>> For the AUTH48 status of this document, please see: >>>>>>>> https://www.rfc-editor.org/auth48/rfc9761 >>>>>>>> >>>>>>>> Thank you, >>>>>>>> RFC Editor/mc >>>>>>>> >>>>>>>>> On Mar 29, 2025, at 2:31 AM, tirumal reddy <kond...@gmail.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> On Sat, 29 Mar 2025 at 02:23, Madison Church <mchu...@staff.rfc- >>>>>>>>> editor.org> wrote: >>>>>>>>> Hi Authors, >>>>>>>>> >>>>>>>>> Dan - Thank you for your reply! We have noted your approval on >>>>>>>>> the AUTH48 status page (see https://www.rfc- >>>>>>>>> editor.org/auth48/rfc9761). >>>>>>>>> >>>>>>>>> Tirumal - Thank you for your response to our followup questions! >>>>>>>>> We have updated the document as requested. We have one followup >>>>>>>>> comment and updated files can be found below. >>>>>>>>> >>>>>>>>>> On Mar 28, 2025, at 4:42 AM, tirumal reddy <kond...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> Please ignore my responses to Section 9.2. Your proposed >>>>>>>>>> changes to this section look good. I mistakenly referred to >>>>>>>>>> Section 9.3 instead. >>>>>>>>> >>>>>>>>> [rfced] We updated Section 9.2 to add the "writeable/readable >>>>>>>>> data nodes" sentences per your note. We weren’t sure if this >>>>>>>>> note also included Question 1b per your first response, so we >>>>>>>>> have not added the additional text at the end of Section 9.2. >>>>>>>>> >>>>>>>>> There are no data nodes defined by the IANA maintained iana-tls- >>>>>>>>> profile. Please proceed to add the text proposed by you for >>>>>>>>> Section 9.2. >>>>>>>>> >>>>>>>>> Please review and let us know if this section (or any section in >>>>>>>>> the Security Considerations) needs any further updates. >>>>>>>>> >>>>>>>>> Updates to the draft look good to me. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> -Tiru >>>>>>>>> >>>>>>>>> >>>>>>>>>> -Tiru >>>>>>>>>> >>>>>>>>>> On Fri, 28 Mar 2025 at 14:42, tirumal reddy <kond...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> Hi Madison, >>>>>>>>>> >>>>>>>>>> Please see inline >>>>>>>>>> >>>>>>>>>> On Thu, 27 Mar 2025 at 23:06, Madison Church >>>>>>>>>> <mchu...@staff.rfc-editor.org> wrote: >>>>>>>>>> Hi Tirumal, >>>>>>>>>> >>>>>>>>>> Thank you for your reply! We have updated the document >>>>>>>>>> accordingly and have some followup queries marked with [rfced]. >>>>>>>>>> >>>>>>>>>> [rfced] Upon sending the initial AUTH48 email, we note that the >>>>>>>>>> address "blake.ander...@cisco.com" returned an "Undelivered >>>>>>>>>> Mail Returned to Sender" message. Is there an up-to-date email >>>>>>>>>> address for Blake that we can reach? >>>>>>>>>> >>>>>>>>>>>> 13) <!-- [rfced] Because of your note that the template in >>>>>>>>>>>> rfc8407bis >>>>>>>>>>>> has been used, we will update this paragraph (which appears >>>>>>>>>>>> in Sections >>>>>>>>>>>> 9.2, 9.3, and 9.4) to match Section 3.7.1 of rfc8407bis as >>>>>>>>>>>> follows. >>>>>>>>>>>> Please let us know if that is not what you intended. >>>>>>>>>>>> >>>>>>>>>>>> Original: >>>>>>>>>>>> This section follows the template defined in Section 3.7.1 of >>>>>>>>>>>> [I-D.ietf-netmod-rfc8407bis]. >>>>>>>>>>>> >>>>>>>>>>>> The YANG module specified in this document defines a schema >>>>>>>>>>>> for data >>>>>>>>>>>> can possibly be accessed via network management protocols >>>>>>>>>>>> such as >>>>>>>>>>>> NETCONF [RFC6241] or RESTCONF [RFC8040]. These network >>>>>>>>>>>> management >>>>>>>>>>>> protocols are required to use a secure transport layer and >>>>>>>>>>>> mutual >>>>>>>>>>>> authentication, e.g., SSH [RFC6242] without the "none" >>>>>>>>>>>> authentication >>>>>>>>>>>> option, Transport Layer Security (TLS) [RFC8446] with mutual >>>>>>>>>>>> X.509 >>>>>>>>>>>> authentication, and HTTPS with HTTP authentication (Section >>>>>>>>>>>> 11 of >>>>>>>>>>>> [RFC9110]). >>>>>>>>>>>> >>>>>>>>>>>> The Network Access Control Model (NACM) [RFC8341] provides >>>>>>>>>>>> the means >>>>>>>>>>>> to restrict access for particular users to a pre-configured >>>>>>>>>>>> subset of >>>>>>>>>>>> all available protocol operations and content. >>>>>>>>>>>> >>>>>>>>>>>> Perhaps (following draft-ietf-netmod-rfc8407bis-22): >>>>>>>>>>>> This section follows the template defined in Section 3.7.1 of >>>>>>>>>>>> [YANG-GUIDELINES]. >>>>>>>>>>>> >>>>>>>>>>>> The "iana-tls-profile" YANG module defines a data model that >>>>>>>>>>>> is >>>>>>>>>>>> designed to be accessed via YANG-based management protocols, >>>>>>>>>>>> such as >>>>>>>>>>>> NETCONF [RFC6241] and RESTCONF [RFC8040]. These protocols >>>>>>>>>>>> have to >>>>>>>>>>>> use a secure transport layer (e.g., SSH [RFC4252], TLS >>>>>>>>>>>> [RFC8446], and >>>>>>>>>>>> QUIC [RFC9000]) and have to use mutual authentication. >>>>>>>>>>>> >>>>>>>>>>>> The Network Configuration Access Control Model (NACM) >>>>>>>>>>>> [RFC8341] >>>>>>>>>>>> provides the means to restrict access for particular NETCONF >>>>>>>>>>>> or >>>>>>>>>>>> RESTCONF users to a preconfigured subset of all available >>>>>>>>>>>> NETCONF or >>>>>>>>>>>> RESTCONF protocol operations and content. >>>>>>>>>>>> --> >>>>>>>>>> >>>>>>>>>> Looks good to me. >>>>>>>>>>> >>>>>>>>>>> It is aligned with the Security Considerations Section >>>>>>>>>>> Template in Section 3.7.1 of >>>>>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/ >>>>>>>>>> >>>>>>>>>> [rfced] Per your reply, we have updated the document as much as >>>>>>>>>> possible to match the template in Section 3.7.1 of 8407bis. We >>>>>>>>>> have the remaining questions regarding these updates. Note that >>>>>>>>>> this diff file may be best for viewing side-by-side updates: >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9761-auth48rfcdiff.html. >>>>>>>>>> >>>>>>>>>> 1) Section 9.2: >>>>>>>>>> a) May we add the following sentences in Section 9.2 to match >>>>>>>>>> the template? >>>>>>>>>> >>>>>>>>>> "There are no particularly sensitive writable data nodes." >>>>>>>>>> "There are no particularly sensitive readable data nodes." >>>>>>>>>> >>>>>>>>>> No, sensitive writable/readable data nodes are present and the >>>>>>>>>> security/privacy considerations are explained in 4th and 5th >>>>>>>>>> paragraphs of Section 9.3. >>>>>>>>>> >>>>>>>>>> b) Would you like to add the following text at the end of >>>>>>>>>> Section 9.2 as per the template’s guidance? >>>>>>>>>> >>>>>>>>>> -- If the data model does not define any data nodes (i.e., none >>>>>>>>>> -- of the above sections or readable/writable data nodes or >>>>>>>>>> RPCs >>>>>>>>>> -- have been included), then add the following text: >>>>>>>>>> >>>>>>>>>> "The YANG module defines a set of identities, types, and >>>>>>>>>> groupings. These nodes are intended to be reused by other YANG >>>>>>>>>> modules. The module by itself does not expose any data nodes >>>>>>>>>> that >>>>>>>>>> are writable, data nodes that contain read-only state, or RPCs. >>>>>>>>>> As such, there are no additional security issues related to >>>>>>>>>> the YANG module that need to be considered." >>>>>>>>>> >>>>>>>>>> No, the YANG module defines data nodes. >>>>>>>>>> >>>>>>>>>> "Modules that use the groupings that are defined in this >>>>>>>>>> document >>>>>>>>>> should identify the corresponding security considerations. For >>>>>>>>>> example, reusing some of these groupings will expose privacy- >>>>>>>>>> related >>>>>>>>>> information (e.g., 'node-example')." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2) Section 9.3: >>>>>>>>>> In the "Some of the readable data nodes" paragraph, this >>>>>>>>>> sentence (from the template) is not present. Is this >>>>>>>>>> intentional? >>>>>>>>>> >>>>>>>>>> Yes. >>>>>>>>>> "Specifically, the following subtrees and data nodes have >>>>>>>>>> particular sensitivities/vulnerabilities:" >>>>>>>>>> >>>>>>>>>> Instead, the document has this sentence: >>>>>>>>>> "The YANG module will provide insights into (D)TLS profiles of >>>>>>>>>> the IoT devices, and the privacy considerations discussed in >>>>>>>>>> Section 10 need to be taken into account." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 3) Section 9.4: >>>>>>>>>> a) May we add the following sentence per the templates >>>>>>>>>> guidance? >>>>>>>>>> "There are no particularly sensitive readable data nodes." >>>>>>>>>> >>>>>>>>>> No. >>>>>>>>>> >>>>>>>>>> b) For the "Some of the readable data nodes" paragraph, this >>>>>>>>>> sentence (from the template) is not present. Is this >>>>>>>>>> intentional? >>>>>>>>>> >>>>>>>>>> Yes. >>>>>>>>>> "Specifically, the following subtrees and data nodes have >>>>>>>>>> particular sensitivities/vulnerabilities:" >>>>>>>>>> >>>>>>>>>> Instead, the document has the following sentences: >>>>>>>>>> "For instance, update that the device does not support (D)TLS >>>>>>>>>> profile can dramatically alter the implemented security policy. >>>>>>>>>> For this reason, >>>>>>>>>> the NACM extension "default-deny-write" has been set for all >>>>>>>>>> data nodes defined in this module." >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 4) For all sections in the Security Considerations section, may >>>>>>>>>> we update the sentence below to accurately reflect the >>>>>>>>>> template? >>>>>>>>>> >>>>>>>>>> Current: >>>>>>>>>> This module does not define any RPCs, actions, or >>>>>>>>>> notifications, and >>>>>>>>>> thus the security consideration for such is not provided here. >>>>>>>>>> >>>>>>>>>> Perhaps: >>>>>>>>>> There are no particularly sensitive RPC or action operations. >>>>>>>>>> >>>>>>>>>> Okay. >>>>>>>>>> >>>>>>>>>>>> 15) <!-- [rfced] Please review the questions below regarding >>>>>>>>>>>> references in this >>>>>>>>>>>> document. >>>>>>>>>>>> c) Re: [X501], this reference has been superseded >>>>>>>>>>>> by the 2019 version of X.501 - available here: >>>>>>>>>>>> https://www.itu.int/rec/T-REC-X.501-201910-I/en. May we >>>>>>>>>>>> update this reference >>>>>>>>>>>> to use the most current version? FYI, the URL for the >>>>>>>>>>>> 1993 version of this reference has been included in the >>>>>>>>>>>> reference. >>>>>>>>>> >>>>>>>>>> Yes, good to update. >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> -Tiru >>>>>>>>> >>>>>>>>> Please review the document carefully to ensure satisfaction as >>>>>>>>> we do not make changes once it has been published as an RFC. >>>>>>>>> Contact us with any further updates or with your approval of the >>>>>>>>> document in its current form. We will await approvals from each >>>>>>>>> author prior to moving forward in the publication process. >>>>>>>>> >>>>>>>>> The updated files have been posted here (please refresh): >>>>>>>>> https://www.rfc-editor.org/authors/rfc9761.txt >>>>>>>>> https://www.rfc-editor.org/authors/rfc9761.pdf >>>>>>>>> https://www.rfc-editor.org/authors/rfc9761.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9761.xml >>>>>>>>> >>>>>>>>> The updated diffs have been posted here (please refresh): >>>>>>>>> https://www.rfc-editor.org/authors/rfc9761-diff.html >>>>>>>>> https://www.rfc-editor.org/authors/rfc9761-rfcdiff.html (side by >>>>>>>>> side) >>>>>>>>> https://www.rfc-editor.org/authors/rfc9761-auth48diff.html >>>>>>>>> (AUTH48 updates only) >>>>>>>>> https://www.rfc-editor.org/authors/rfc9761-auth48rfcdiff.html >>>>>>>>> (side by side AUTH48 updates) >>>>>>>>> >>>>>>>>> AUTH48 status page: >>>>>>>>> https://www.rfc-editor.org/auth48/rfc9761 >>>>>>>>> >>>>>>>>> Thank you! >>>>>>>>> RFC Editor/mc -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
