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.
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>
