Hi Mahesh, Thanks for the updates!
We had a few slight tweaks to propose: I believe Sandy added as a PR (apologies, I don’t have access). To summarize the changes (and perhaps add/tweak a few things in the PR): 1) We accidentally suggested adding the expansion of NETCONF at the second use: we’d like to move the expansion to the first use in the template, fix a spelling typo on “Protocl”, and add “the” before “Network Configuration”: Current: The "[module-name]" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. ... The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular Network Configuration Protocl (NETCONF) or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. Suggested: The "[module-name]" YANG module defines a data model that is designed to be accessed via YANG-based management protocols, such as the Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040]. ... 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. 2) Two words (are that —> that are) got transposed here: Current: You must evaluate whether the data model contains any readable data nodes (those are all the "config false" nodes, but also all other nodes, because they can also be read via operations like get or get-config) are that particularly sensitive or vulnerable... Suggested: You must evaluate whether the data model contains any readable data nodes (those are all the "config false" nodes, but also all other nodes, because they can also be read via operations like get or get-config) that are particularly sensitive or vulnerable… 3) We have removed a comma before “because” here: Current: -- data nodes (those are all the "config false" nodes, but also all -- other nodes, because they can also be read via operations like get... Suggested: -- data nodes (those are all the "config false" nodes, but also all -- other nodes because they can also be read via operations like get… Please let us know any questions about the above and when the updates have been completed. As the above seems to be wrapping up, we’ve moved this document to AUTH48-DONE and will move it forward in the publication process at this time. Thank you all for your time and attention during AUTH48. Megan Ferguson RFC Production Center > On Mar 9, 2026, at 4:52 PM, Mahesh Jethanandani <[email protected]> > wrote: > > Hi Megan, > > Thanks for providing the diffs. I am sorry. It was not obvious to me that you > were waiting on me. > > I have gone ahead and made the changes. Please let me know if the latest > version on the wiki matches the document and satisfies the ask. > > Cheers. > >> On Mar 9, 2026, at 8:39 AM, Megan Ferguson <[email protected]> >> wrote: >> >> Hi Mahesh, >> >>> Once we get word that the wiki page has been updated to match the document, >>> we can move forward in the publication process. For convenience, I’ve >>> copied the list of updates below the file links in this message. >> >> I think this is all we are waiting to hear back about before moving forward >> to publication. When checking >> https://wiki.ietf.org/group/ops/yang-security-guidelines?, it doesn’t appear >> that the following changes have yet been made: >> >> >>> Issue #3: The wiki page update to make >>> https://wiki.ietf.org/group/ops/yang-security-guidelines? match the >>> template in the document: >>> >>> Note that we have added this as an “approver” on the AUTH48 status page at >>> https://www.rfc-editor.org/auth48/rfc9907 to ensure we match up differences >>> between the doc and that page prior to publication. >>> >>> In addition to updating to point to this document’s RFC number (once it is >>> published), we think the following still need to be updated on the wiki >>> page prior to publication (also viewable in the diff at >>> https://www.rfc-editor.org/authors/rfc9907-wiki-diff.html): >>> >>> Current (at wiki): >>> The Network Configuration Access Control Model (NACM) [RFC8341] provides >>> the means to restrict access for particular NETCONF or... >>> >>> Perhaps (to match document): >>> The Network Configuration Access Control Model (NACM) [RFC8341] provides >>> the means to restrict access for particular Network Configuration Protocol >>> (NETCONF) or... >>> >>> Current (at wiki): >>> All writable data nodes are likely to be sensitive... >>> >>> Perhaps (to match document): >>> All writable data nodes are likely to be reasonably sensitive… >>> >>> Current (at wiki): >>> ...e.g., ones that might be protected by a "nacm:default-deny-write”... >>> >>> Perhaps (to match document): >>> ...e.g., ones that are protected by a "nacm:default-deny-write”… >>> >>> Current (at wiki): >>> ...or get-config) are particularly sensitive or vulnerable… >>> >>> Perhaps (to match document): >>> ...or get-config) that are particularly sensitive or vulnerable… >>> >>> Current (at wiki): >>> ...readable data nodes are ones that might be protected by a… >>> >>> Perhaps (to match document): >>> ...readable data nodes are ones that are protected by a… >>> >>> Current (at wiki): >>> ...then add this text to remind the specific sensitivity… >>> >>> Perhaps (to match document): >>> ...then add this text as a reminder of the specific sensitivity… >> >> Thank you. >> >> Megan Ferguson >> RFC Production Center >> >>> On Mar 8, 2026, at 8:33 PM, Mahesh Jethanandani <[email protected]> >>> wrote: >>> >>> Hi Sandy, >>> >>> My sense from the discussion on this thread is that there is no appetite >>> for making any more changes to the draft. I am sorry. >>> >>> Your examples would still be helpful, and we can discuss other ways to >>> educate YANG developers on the right way to add a reference statement, >>> including putting some of those examples on a wiki. >>> >>> Is the draft otherwise ready tor publication? >>> >>> Cheers. >>> >>>> On Feb 20, 2026, at 11:51 AM, Sandy Ginoza <[email protected]> >>>> wrote: >>>> >>>> Hi Mahesh, >>>> >>>> Thanks for your thoughtful reply. To clarify, we understand that the >>>> examples were not discussed in the working group and would be happy to >>>> provide some examples for discussion at a later date (separately from this >>>> document). >>>> >>>> Thanks, >>>> Sandy Ginoza >>>> RFC Production Center >>>> >>>> >>>> >>>>> On Feb 20, 2026, at 10:59 AM, Mahesh Jethanandani >>>>> <[email protected]> wrote: >>>>> >>>>> Since there seems to be a strong desire to fix this, Kent, as a shepherd, >>>>> would you have a problem pulling this document out of the RFC Editor >>>>> queue, having a quick discussion in the WG around just this change, doing >>>>> a short consensus call and sending it back to me. No other change should >>>>> be entertained at this point. >>>>> >>>>> In the above example, in my opinion (as a individual contributor) >>>>> >>>>> - a reference should be provided when referring to a RFC, rather than >>>>> burying it in the description statement. That reference should come in >>>>> the form of a “RFC XXXX: <Title of the RFC> >>>>> - a Section should be referenced by its number >>>>> >>>>> Having the title of the draft helps those who do not have a map of RFC >>>>> numbers to titles. YANG modules outside the draft, do not have luxury of >>>>> the Normative/Informative References sections being available handily. >>>> >>> >>> >>> Mahesh Jethanandani >>> [email protected] >>> >>> >>> >>> >>> >>> >> > > > Mahesh Jethanandani > [email protected] > > > > > > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
