Hi Acee, Thank you for your reply. We have updated the document accordingly and marked your approval on the AUTH48 status page for this document (see https://www.rfc-editor.org/auth48/rfc9825).
We will await approval from Yingzhen 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 23, 2025, at 11:27 AM, Acee Lindem <acee.i...@gmail.com> wrote: > > Hi Sarah, > > I approve this version with the correction of one typo (attached). > > Thanks, > Acee > <rfc9825-orig.diff.html> > > >> On Jul 23, 2025, at 9:03 AM, Sarah Tarrant <starr...@staff.rfc-editor.org> >> wrote: >> >> Hi Acee, >> >> Thank you so much for taking a second, careful look at the diff. I've made >> the "Sub-TLV" changes you requested and have no further questions. >> >> We will await approvals from each you and Yingzhen 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 22, 2025, at 3:13 AM, Acee Lindem <acee.i...@gmail.com> wrote: >>> >>> Hi Sarah, >>> >>> You didn't apply my last changes correctly. "Sub-TLV" should be capitalized >>> when used as a specific sub-TLV, i.e., a proper noun. See the attached >>> diff. >>> >>> Thanks, >>> Acee >>> <rfc9825-orig.diff.html> >>> >>> >>> >>>> On Jul 21, 2025, at 12:36 PM, Sarah Tarrant >>>> <starr...@staff.rfc-editor.org> 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
