Hi Gunter and Peter, Thank you for your replies. We have marked your approvals on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9825).
We will await approvals from each of the parties listed at the AUTH48 status page prior to moving this document forward in the publication process. Thank you, RFC Editor/st > On Jul 21, 2025, at 12:14 PM, Peter Psenak <ppse...@cisco.com> wrote: > > Hi Sarah, > > I approve this RFC for publication. > > thanks, > Peter > > On 21/07/2025 18:36, Sarah Tarrant wrote: >> Hi Acee and AD*, >> >> AD* - please see question #7 below. We've included Acee's response and >> updated accordingly, but we still need official AD approval and/or edits. >> >>>> 7) <!--[rfced] *AD - We note that the first paragraph in the Security >>>> Considerations section does not match what appears at >>>> <https://wiki.ietf.org/group/ops/yang-security-guidelines>. >>> Acee: This is intended. There seems to be confusion here that this document >>> is primarily to standardize the YANG module. >>> >>>> Additionally, we have made some updates in this section to closer >>>> reflect the boilerplate. Please review this section and let us know >>>> if any further updates are necessary. >>>> --> >>> Acee: Ok. This is a moving target - I took the latest from >>> draft-ietf-netmod-rfc8407bis. >>> Note that Med also commented that the security protocols referenced as >>> examples >>> should be informational references. >> See Section 8 in https://www.rfc-editor.org/authors/rfc9825-auth48diff.html >> >> --- >> >> Acee - Thank you for your reply. We have updated the document accordingly. >> >> Please note that we did use the lowercase "sub-TLV" (instead of "Sub-TLV") >> to match recent past RFCs. >> >> While we await AD approval, 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/rfc9825.txt >> https://www.rfc-editor.org/authors/rfc9825.pdf >> https://www.rfc-editor.org/authors/rfc9825.html >> https://www.rfc-editor.org/authors/rfc0825.xml >> >> The relevant diff files have been posted here (please refresh): >> https://www.rfc-editor.org/authors/rfc9825-diff.html (comprehensive diff) >> https://www.rfc-editor.org/authors/rfc9825-auth48diff.html (AUTH48 changes >> only) >> >> Note that it may be necessary for you to refresh your browser to view the >> most recent version. >> >> For the AUTH48 status of this document, please see: >> https://www.rfc-editor.org/auth48/rfc9825 >> >> Thank you, >> RFC Editor/st >> >>> On Jul 20, 2025, at 5:48 AM, Acee Lindem <acee.i...@gmail.com> wrote: >>> >>> Hi RFC Editor, >>> >>> Refer to the attached RFC diff. >>> >>> >>>> On Jul 17, 2025, at 5:11 PM, rfc-edi...@rfc-editor.org wrote: >>>> >>>> Authors and AD*, >>>> >>>> While reviewing this document during AUTH48, please resolve (as necessary) >>>> the following questions, which are also in the XML file. >>>> >>>> *AD, please see question #7 below. >>>> >>>> 1) <!-- [rfced] We note that most of the recently published RFCs containing >>>> YANG modules format their titles as "A YANG Data Model for...", for >>>> example: >>>> >>>> RFC 9094 - A YANG Data Model for Wavelength Switched Optical Networks >>>> (WSONs) >>>> RFC 9093 - A YANG Data Model for Layer 0 Types >>>> RFC 9067 - A YANG Data Model for Routing Policy >>>> >>>> Please consider whether the title of this document should be updated. >>>> >>>> Current: >>>> Extensions to OSPF for Advertising Prefix Administrative Tags >>>> >>>> Perhaps: >>>> A Yang Data Model for Extensions to OSPF for Advertising Prefix >>>> Administrative Tags >>>> --> >>> No. The YANG model augmentations are ancillary to the additional function >>> provided by the OSPF administrative tags. As for you suggestion, note that >>> it is "YANG" and never "Yang". >>> >>> >>>> >>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in >>>> the title) for use on https://www.rfc-editor.org/search. --> >>> None. >>> >>>> >>>> 3) <!-- [rfced] FYI - We updated "OSPFv2 Extended Prefix LSA" to "OSPFv2 >>>> Extended >>>> Prefix Opaque LSA" to match RFC 7684. Please let us know of any objections. >>> Ok. >>> >>> >>>> --> >>>> >>>> >>>> 4) <!-- [rfced] FYI - We have added line breaks to the YANG tree >>>> diagram as well as a note and reference to RFC 8792 for the '\' >>>> line wrapping. Please review. >>>> --> >>> I don't like this - please format as specified in the attached diff. >>> >>>> >>>> 5) <!--[rfced] FYI - As the RFC 2119 and RFC 8174 keywords are not used >>>> within the YANG module, we have removed the keywords boilerplate >>>> paragraph from the module. >>>> --> >>> Ok. >>> >>> >>>> >>>> 6) <!--[rfced] Note that the YANG module has been updated per the >>>> formatting option of pyang. Please let us know of any concerns. >>>> --> >>> Ok >>> >>> >>>> >>>> 7) <!--[rfced] *AD - We note that the first paragraph in the Security >>>> Considerations section does not match what appears at >>>> <https://wiki.ietf.org/group/ops/yang-security-guidelines>. >>> This is intended. There seems to be confusion here that this document >>> is primarily to standardize the YANG module. >>> >>>> Additionally, we have made some updates in this section to closer >>>> reflect the boilerplate. Please review this section and let us know >>>> if any further updates are necessary. >>>> --> >>> Ok. This is a moving target - I took the latest from >>> draft-ietf-netmod-rfc8407bis. >>> Note that Med also commented that the security protocols referenced as >>> examples >>> should be informational references. >>> >>> >>>> >>>> 8) <!-- [rfced] Throughout the text, the following terminology appears to >>>> be used interchangeably. Please review these occurrences and let us know >>>> if/how they may be made consistent. >>>> >>>> Administrative Tag vs. admin tag vs. administrative tag >>>> Administrative Tag sub-TLV vs. Administrative Tag TLV vs. >>>> administrative tag TLV >>>> E-Inter-Area-Prefix-LSA vs. E-Inter-Area-Prefix LSA >>>> E-Intra-Area-Prefix-LSA vs. E-Intra-Area-Prefix LSA >>>> Extended Prefix TLV vs. extended prefix TLV >>>> Prefix Administrative Tag sub-TLV vs. prefix admin tag sub-TLV >>>> --> >>> Ok - I've updated all these for consistency. >>> >>> >>>> >>>> 9) <!-- [rfced] FYI - We have added expansions for the following >>>> abbreviations >>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each >>>> expansion in the document carefully to ensure correctness. >>>> >>>> Border Gateway Protocol - Link State (BGP-LS) >>>> Network Configuration Protocol (NETCONF) >>>> --> >>> Ok. >>> >>>> >>>> 10) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>> online >>>> Style Guide >>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> >>>> and let us know if any changes are needed. Updates of this nature >>>> typically >>>> result in more precise language, which is helpful for readers. >>>> >>>> Note that our script did not flag any words in particular, but this should >>>> still be reviewed as a best practice. >>> I didn't find any violations either. >>> >>> Thanks, >>> Acee >>> <rfc9825-orig.diff.html> >> > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
