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
