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. > > --> > > 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." 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." "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? "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." b) For the "Some of the readable data nodes" paragraph, this sentence (from the template) is not present. Is this intentional? "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. > > 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. > > > > 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
