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
