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]
