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
