Please ignore my responses to Section 9.2. Your proposed changes to this section look good. I mistakenly referred to Section 9.3 instead.
-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 > > >> > > >> > > Current: >> > > [X501] "Information Technology - Open Systems Interconnection - >> > > The Directory: Models", ITU-T Recommendation X.501, >> > > November 1993, >> > > <https://www.itu.int/rec/T-REC-X.501-199311-S/en>. >> >> [rfced] Please note that the question above (15c) is still outstanding. >> >> 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
