Apparently aliases at Cisco occasionally break. Blake's permanent address is blaan...@cisco.com <mailto:blaan...@cisco.com> (included on CC of this message). He may well want to change to that address for the RFC-to-be, but I'm sure he can get the alias fixed before then, too.
Regarding 15c (below), I agree we should update the X501 reference to the superceded 2019 reference. I don't have an opinion on the YANG changes; that is Tiru's expertise. I approve the document. -d > On Mar 27, 2025, at 10:36 AM, 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. >>> --> >> >> 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
