Hi Med, These two citation changes have been taken care of and we’ve updated your status to “Approved” at the AUTH48 status page (see below). 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.
The files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9907.txt https://www.rfc-editor.org/authors/rfc9907.pdf https://www.rfc-editor.org/authors/rfc9907.html https://www.rfc-editor.org/authors/rfc9907.xml The related diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9907-diff.html (comprehensive) https://www.rfc-editor.org/authors/rfc9907-rfcdiff.html (comprehensive side by side) https://www.rfc-editor.org/authors/rfc9907-auth48diff.html (AUTH48 changes to date) https://www.rfc-editor.org/authors/rfc9907-auth48rfcdiff.html (AUTH48 changes side by side) https://www.rfc-editor.org/authors/rfc9907-lastdiff.html (last version to this) https://www.rfc-editor.org/authors/rfc9907-lastrfcdiff.html (last version side by side) The AUTH48 status page is viewable here: https://www.rfc-editor.org/auth48/rfc9907 > 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 Feb 25, 2026, at 9:38 AM, [email protected] wrote: > > Hi Megan, > > There are two broken citations that we need to fix as follows: > > (1) > > OLD: > An example of "revision" statements that are generated following the > guidance in Section 4.30.3.1 is provided below: > > NEW: > An example of "revision" statements that are generated following the > guidance in Section 5.3.2 is provided below: > > (2) > > OLD: > The following example shows how to generate the "revision" statements > following the guidance in Section 4.30.3.1: > > NEW: > The following example shows how to generate the "revision" statements > following the guidance in Section 5.3.2: > > Other than that, this version looks good to me. > > Assuming these changes are implemented, I approve the publication of the > document. > > Thank you for your effort and patience with us. > > Cheers, > Med > >> -----Message d'origine----- >> De : Megan Ferguson <[email protected]> >> Envoyé : mercredi 25 février 2026 17:14 >> À : Qin Wu <[email protected]>; Mahesh >> Jethanandani <[email protected]> >> Cc : Sandy Ginoza <[email protected]>; BOUCADAIR >> Mohamed INNOV/NET <[email protected]>; netmod- >> [email protected]; RFC Editor <[email protected]>; Andy Bierman >> <[email protected]>; [email protected]; maqiufang (A) >> <[email protected]>; [email protected]; >> [email protected] >> Objet : Re: [AD] [IANA] AUTH48: RFC-to-be 9907 <draft-ietf-netmod- >> rfc8407bis-28> for your review >> >> >> Hi Qin and Mahesh, >> >> FYI - We have marked both of you as “Approved” on the AUTH48 >> status page: Qin per the message below, and Mahesh as the >> remaining text pending AD approval has been removed. >> >> Once we have approval from Mohamed and we receive confirmation >> that >> https://fra01.safelinks.protection.outlook.com/?url=https%3A%2F%2F >> wiki.ietf.org%2Fgroup%2Fops%2Fyang-security- >> guidelines&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C04746f7 >> f7dbc48a8004e08de7488e0c6%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7 >> C0%7C639076329195104087%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOn >> RydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy >> fQ%3D%3D%7C0%7C%7C%7C&sdata=UWSeBl2TxGq21GIXceVTX3xYCoJAxPfJ%2Fi4u >> KU0w9kg%3D&reserved=0? has been updated as previously discussed, >> we will be able to move this document forward in the publication >> process. >> >> For your convenience, links to the files are below (no changes >> from our last email on 20 February). > > ____________________________________________________________________________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu > ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
