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
