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
