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
