Hi Mahesh, I haven’t actually submitted a PR yet - I will do soon.
We’ll continue with publication in the meantime. Thanks, Sandy Ginoza RFC Production Center > On Mar 11, 2026, at 12:24 PM, Megan Ferguson <[email protected]> > wrote: > > 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]
