Hi Paul, This is a friendly reminder that we await your review and approval for the changes listed in the thread below. These changes are best viewed in the diff files below: https://www.rfc-editor.org/authors/rfc9761-auth48diff.html https://www.rfc-editor.org/authors/rfc9761-auth48rfcdiff.html (side-by-side diff)
Thank you, RFC Editor/mc > On Apr 1, 2025, at 2:08 PM, Madison Church <mchu...@staff.rfc-editor.org> > wrote: > > Hi Authors and *Paul, > > Thank you for your replies! We have noted your approvals on the AUTH48 status > page for this document (see https://www.rfc-editor.org/auth48/rfc9761). > > *Paul - As the Responsible AD for this document, please review and approve > the following changes. These changes are best viewed in the diff files below: > https://www.rfc-editor.org/authors/rfc9761-auth48diff.html > https://www.rfc-editor.org/authors/rfc9761-auth48rfcdiff.html (side-by-side > diff) > > 1. Changes in Paragraph 5 of Section 9.3: > > The Security Considerations Section for this document has been updated to > follow the Security Considerations Section Template in Section 3.7.1 of > rfc8407bis (see > https://www.ietf.org/id/draft-ietf-netmod-rfc8407bis-22.html#name-security-considerations-sect). > The following text appears in the template, but not in the document (the > authors have stated that this intentional): > > "Specifically, the following subtrees and data nodes have particular > sensitivities/vulnerabilities:" > > Instead, the paragraph contains the following 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." > > Please let us know if this is acceptable. > > > 2. Changes in Paragraph 4 of Section 9.4: Similar to the above, the following > text appears in the template, but not in the document (the authors have > stated that this intentional): > > "Specifically, the following subtrees and data nodes have particular > sensitivities/vulnerabilities:" > > Instead, the paragraph contains the following text: > > "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." > > Please let us know if this is acceptable. > > > 3. Normative References: Note that RFCs 6242 and 9110 have been updated to > RFCs 4252 and 9000 to match the second paragraph of the Security > Considerations Section Template in rfc8407bis (see > https://www.ietf.org/id/draft-ietf-netmod-rfc8407bis-22.html#name-security-considerations-sect). > Please let us know any objections. > > Once we receive your approval, we will send our updates along to IANA. > > Thank you! > RFC Editor/mc > > >> On Apr 1, 2025, at 1:34 AM, tirumal reddy <kond...@gmail.com> wrote: >> >> 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
