Extensions to OSPF for Advertising Prefix Administrative Tags
draft-ietf-lsr-ospf-admin-tags-29

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-lsr-ospf-admin-tags and RFC 9825, changed IESG state to RFC Published)

[Ballot discuss]
Please do not fret. I have two DISCUSS points, both of which should be fairly easy to take care of.

Section 7.2, paragraph 12
>      augment "/rt:routing/rt:control-plane-protocols/"
>            + "rt:control-plane-protocol/ospf:ospf/"
>            + "ospf:areas/ospf:area/ospf:ranges/ospf:range" {
>        when "derived-from-or-self(../../../../../"
>          + "rt:type, 'ospf:ospf')" {
>          description
>            "This augments the OSPF routing protocol area range
>            configuration.";
>        }
>        description
>          "This augments the OSPF protocol area range configuration
>          with administrative tags. The configured tags will be
>          advertised with summary prefix when it is active.";
>        container admin-tags {
>          when "../ospf:advertise = 'true'";
>          leaf-list admin-tag {
>            type uint32;
>            description
>              "Administrative tags.";
>          }
>          description
>            "OSPF prefix administrative tags.";
>        }
>      }
>
>      augment "/rt:routing/rt:control-plane-protocols/"
>            + "rt:control-plane-protocol/ospf:ospf/"
>            + "ospf:areas/ospf:area/ospf:ranges/ospf:range" {
>        when "derived-from-or-self(../../../../../"
>          + "rt:type, 'ospf:ospf')" {
>          description
>            "This augments the OSPF routing protocol area range
>            configuration.";
>        }
>        description
>          "This augments summary route configuration with
>          administrative tags.";
>          leaf-list admin-tag {
>            type uint32;
>            description
>              "Administrative tags.";
>          }
>      }


I am not clear on the difference between these two augment statements. Both augment statements seem the same to me, even as they add different data nodes. Can they not be collapsed? While I do not expect tools such as pyang or yanglint to catch this, it will most likely cause one of the statements to be removed.

Section 7.2, paragraph 1
>    The following is the YANG module:

This YANG model is normatively including modules from RFC 8349, 9129, 6991, and 9507. While there is a normative reference for RFC 9129, the others are missing in the "Normative References" section. Please add.

[Ballot discuss]
Please do not fret. I have two DISCUSS points, both of which should be fairly easy to take care of.

Section 7.2, paragraph 12
>      augment "/rt:routing/rt:control-plane-protocols/"
>            + "rt:control-plane-protocol/ospf:ospf/"
>            + "ospf:areas/ospf:area/ospf:ranges/ospf:range" {
>        when "derived-from-or-self(../../../../../"
>          + "rt:type, 'ospf:ospf')" {
>          description
>            "This augments the OSPF routing protocol area range
>            configuration.";
>        }
>        description
>          "This augments the OSPF protocol area range configuration
>          with administrative tags. The configured tags will be
>          advertised with summary prefix when it is active.";
>        container admin-tags {
>          when "../ospf:advertise = 'true'";
>          leaf-list admin-tag {
>            type uint32;
>            description
>              "Administrative tags.";
>          }
>          description
>            "OSPF prefix administrative tags.";
>        }
>      }
>
>      augment "/rt:routing/rt:control-plane-protocols/"
>            + "rt:control-plane-protocol/ospf:ospf/"
>            + "ospf:areas/ospf:area/ospf:ranges/ospf:range" {
>        when "derived-from-or-self(../../../../../"
>          + "rt:type, 'ospf:ospf')" {
>          description
>            "This augments the OSPF routing protocol area range
>            configuration.";
>        }
>        description
>          "This augments summary route configuration with
>          administrative tags.";
>          leaf-list admin-tag {
>            type uint32;
>            description
>              "Administrative tags.";
>          }
>      }


I am not clear on the difference between these two augment statements. Both augment statements seem the same to me, even as they add different data nodes. Can they not be collapsed? While I do not expect tools such as pyang or yanglint to catch this, it will most likely cause one of the statements to be removed.

Section 7.2, paragraph 1
>    The following is the YANG module:

This YANG model is normatively including RFC 8349, 9129, 6991, 9507. While there is a normative reference for RFC 9129, the others are missing in the "Normative References" section. Please add.

[Ballot discuss]
Hear hear! I have two DISCUSS topics, both of which should be fairly easy to take care of.

Section 7.2, paragraph 12
>      augment "/rt:routing/rt:control-plane-protocols/"
>            + "rt:control-plane-protocol/ospf:ospf/"
>            + "ospf:areas/ospf:area/ospf:ranges/ospf:range" {
>        when "derived-from-or-self(../../../../../"
>          + "rt:type, 'ospf:ospf')" {
>          description
>            "This augments the OSPF routing protocol area range
>            configuration.";
>        }
>        description
>          "This augments the OSPF protocol area range configuration
>          with administrative tags. The configured tags will be
>          advertised with summary prefix when it is active.";
>        container admin-tags {
>          when "../ospf:advertise = 'true'";
>          leaf-list admin-tag {
>            type uint32;
>            description
>              "Administrative tags.";
>          }
>          description
>            "OSPF prefix administrative tags.";
>        }
>      }
>
>      augment "/rt:routing/rt:control-plane-protocols/"
>            + "rt:control-plane-protocol/ospf:ospf/"
>            + "ospf:areas/ospf:area/ospf:ranges/ospf:range" {
>        when "derived-from-or-self(../../../../../"
>          + "rt:type, 'ospf:ospf')" {
>          description
>            "This augments the OSPF routing protocol area range
>            configuration.";
>        }
>        description
>          "This augments summary route configuration with
>          administrative tags.";
>          leaf-list admin-tag {
>            type uint32;
>            description
>              "Administrative tags.";
>          }
>      }


I am not clear on the difference between these two augment statements. Both augment statements seem the same to me, even as they add different data nodes. Can they not be collapsed? While I do not expect tools such as pyang or yanglint to catch this, it will most likely cause one of the statements to be removed.

Section 7.2, paragraph 1
>    The following is the YANG module:

This YANG model is normatively including RFC 8349, 9129, 6991, 9507. While there is a normative reference for RFC 9129, the others are missing in the "Normative References" section. Please add.

[Ballot comment]
Section 7.2, paragraph 9
>      reference
>        "RFC XXXX";

You are missing the title of RFC XXXX here.

Section 8, paragraph 1
>    The YANG modules specified in this document define a schema for data
>    that is designed to be accessed via network management protocols such
>    as NETCONF [RFC6241] or RESTCONF [RFC8040].  The lowest NETCONF layer
>    is the secure transport layer, and the mandatory-to-implement secure
>    transport is Secure Shell (SSH) [RFC6242].  The lowest RESTCONF layer
>    is HTTPS, and the mandatory-to-implement secure transport is TLS
>    [RFC8446].

The template has been updated slightly for this paragraph. Please see draft-ietf-netmod-rfc8407bis, Section 3.7.1 for the latest text for this paragraph.
Finally, a non-blocking comment. It would have been really helpful for an implemter to be able to see an example on how to use this mode.

The IANA review of this document seems to not have concluded yet.

[Ballot comment]
Thanks for this document. I have just a few questions and comments, below.

- In Section 4, "An OSPF router supporting this specification MAY be able to advertise and propagate multiple tags." Does "propagate" have some well-known meaning in OSPF that is different from "flood"? Because I assume that any OSPF router MUST flood (propagate!) whatever it's given. (I do see paragraph 4, which hints that the answer is "yes in OSPF 'propagate' always means 'between areas'" but I'd appreciate a confirmation.)

- In Section 4, "Depending on the application, the number of tags supported by the OSPF routers in the OSPF routing domain MAY limit deployment of that application." That seems like a misuse of RFC 2119 MAY -- aren't you just stating a possibility, not giving permission for an implementation choice?

- In Section 4, "When tags are advertised for AS External or NSSA LSA prefixes, the existing tag in the OSPFv2 and OSPFv3 AS-External-LSA and NSSA-LSA encodings MUST be utilized for the first tag." I almost never do this, but... couldn't this be a SHOULD? The case I can think of where you might want to use the Administrative Tag Sub-TLV even as the first tag, is in some future time when Administrative Tag Sub-TLV is ubiquitous and you are looking toward deprecating the old encoding. I suppose a new RFC could be written at that time, to permit the variance, but why not just allow it here with a SHOULD?

[Ballot comment]
(resending ballot as I didn't select "No Objection" on the position)

Thank you to Robert Sparks for the GENART review.

** Consider if it would make the document more readable to name the registry group since there are three OSPF Parameter registry groups.  For example:

OLD
  The following values should be allocated from the "OSPF Extended
  Prefix TLV Sub-TLV" Registry [RFC7684]:

NEW
The following values should be allocated from the "OSPF Extended Prefix TLV Sub-TLV" Registry [RFC7684] in the "Open Shortest Path First v2 (OSPFv2) Parameters" group.

OLD
  The following values should be allocated from the "OSPFv3 Extended-
  LSA Sub-TLV" Registry [RFC8362]:
NEW
The following values should be allocated from the "OSPFv3 Extended-LSA Sub-TLV" Registry [RFC8362] in the "Open Shortest Path First v2 (OSPFv2) Parameters" group:

OLD
  The following values should be allocated from the "OSPFv3 SRv6
  Locator LSA Sub-TLVs" Registry [RFC9513]:
NEW
The following values should be allocated from the "OSPFv3 SRv6 Locator LSA Sub-TLVs" Registry [RFC9513] in the "Open Shortest Path First v2 (OSPFv2) Parameters" group:

[Ballot comment]
Thank you to Robert Sparks for the GENART review.

** Consider if it would make the document more readable to name the registry group since there are three OSPF Parameter registry groups.  For example:

OLD
  The following values should be allocated from the "OSPF Extended
  Prefix TLV Sub-TLV" Registry [RFC7684]:

NEW
The following values should be allocated from the "OSPF Extended Prefix TLV Sub-TLV" Registry [RFC7684] in the "Open Shortest Path First v2 (OSPFv2) Parameters" group.

OLD
  The following values should be allocated from the "OSPFv3 Extended-
  LSA Sub-TLV" Registry [RFC8362]:
NEW
The following values should be allocated from the "OSPFv3 Extended-LSA Sub-TLV" Registry [RFC8362] in the "Open Shortest Path First v2 (OSPFv2) Parameters" group:

OLD
  The following values should be allocated from the "OSPFv3 SRv6
  Locator LSA Sub-TLVs" Registry [RFC9513]:
NEW
The following values should be allocated from the "OSPFv3 SRv6 Locator LSA Sub-TLVs" Registry [RFC9513] in the "Open Shortest Path First v2 (OSPFv2) Parameters" group:

[Ballot comment]
## Nits

### Contact IESG?

```
766   URI: urn:ietf:params:xml:ns:yang:ietf-ospf-admin-tags
767   Registrant Contact: The IESG.
768   XML: N/A, the requested URI is an XML namespace
```

Is this one of the registries that requires the IESG to be the contact point?

It would be nice to specify a better point of contact where possible, see:

https://www.rfc-editor.org/rfc/rfc6087#section-5

[Ballot comment]
Mostly nits:

Section 1:  Spell out AS, LSA on first use.  Consider an acronym list.
Section 4, para 2:  'speficified' should be 'specified'.
Section 8, para 1:  '(subtle denial or service)' should be '(subtle denial of service)'

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-lsr-ospf-admin-tags-23. If any part of this review is inaccurate, please let us know.

IANA has questions about the actions requested in the IANA Considerations section of this document.

IANA understands that, upon approval of this document, there are five actions which we must complete.

First, in the OSPF Extended Prefix TLV Sub-TLV registry in the Open Shortest Path First v2 (OSPFv2) Parameters registry group located at:

https://www.iana.org/assignments/ospfv2-parameters/

a single new sub-TLV will be registered as follows:

Value: [ TBD-at-Registration ]
Description: Administrative Tag Sub-TLV
Reference: [ RFC-to-be ]

IANA Comment -> IANA strongly prefers not to include the term “TLV” or “sub-TLV” in the Description field when the registry already states such. Could this description be updated to be just "Administrative Tag" in the IANA Considerations section?

Second, in the OSPFv3 Extended-LSA Sub-TLV registry in the Open Shortest Path First v3 (OSPFv3) Parameters registry group located at:

https://www.iana.org/assignments/ospfv3-parameters/

a single new sub-TLV will be registered as follows:

Value: [ TBD-at-Registration ]
Description: Administrative Tag Sub-TLV
L2BM:
Reference: [ RFC-to-be ]

IANA Question -> What should the value for L2BM be for this new registration? In addition, same comment as above; could this description be updated to just "Administrative Tag"?

Third, in the OSPFv3 SRv6 Locator LSA Sub-TLVs registry also in the Open Shortest Path First v3 (OSPFv3) Parameters registry group located at:

https://www.iana.org/assignments/ospfv3-parameters/

a single new sub-TLV will be registered as follows:

Value: [ TBD-at-Registration ]
Description: Administrative Tag Sub-TLV
Reference: [ RFC-to-be ]

IANA Question --> Same comment as above; could this description be updated to just "Administrative Tag"?

Fourth, in the ns registry in the IETF XML Registry group located at:

https://www.iana.org/assignments/xml-registry/

a single new namespace will be registered as follows:

ID: yang:ietf-ospf-admin-tags
URI: urn:ietf:params:xml:ns:yang:ietf-ospf-admin-tags
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

As this document requests a registration in an Expert Review or Specification Required (see RFC 8126) registry, we have completed the required Expert Review via a separate request.

Fifth, in the YANG Module Names registry in the YANG Parameters registry group located at:

https://www.iana.org/assignments/yang-parameters/

a single new YANG module will be registered as follows:

Name: ietf-ospf-admin-tags
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-ospf-admin-tags
Prefix: ospf-admin-tags
Module:
Reference: [ RFC-to-be ]

While the YANG module name will be registered after the IESG approves the document, the YANG module file will be posted after the RFC Editor notifies us that the document has been published.

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2025-01-08):

From: The IESG
To: IETF-Announce
CC: chopps@chopps.org, draft-ietf-lsr-ospf-admin-tags@ietf.org, gunter@vandevelde.cc, lsr-chairs@ietf.org, lsr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Extensions to OSPF for Advertising Prefix Administrative Tags) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'Extensions to OSPF for Advertising Prefix
Administrative Tags'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2025-01-08. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  It is useful for routers in OSPFv2 and OSPFv3 routing domains to be
  able to associate tags with prefixes.  Previously, OSPFv2 and OSPFv3
  were relegated to a single tag and only for AS External and Not-So-
  Stubby-Area (NSSA) prefixes.  With the flexible encodings provided by
  OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended LSAs,
  multiple administrative tags may be advertised for all types of
  prefixes.  These administrative tags can be used for many
  applications including route redistribution policy, selective prefix
  prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection,
  and many others.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-admin-tags/



No IPR declarations have been submitted directly on this I-D.

## Document History

    1. Does the working group (WG) consensus represent the strong concurrence of
      a few individuals, with others being silent, or did it reach broad
      agreement?

There is a strong and broad consensus for publishing this document.

    2. Was there controversy about particular points, or were there decisions
      where the consensus was particularly rough?

No.

    3. Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarize the areas of conflict in separate
      email messages to the responsible Area Director. (It should be in a
      separate email because this questionnaire is publicly available.)

No.

    4. For protocol documents, are there existing implementations of the
      contents of the document? Have a significant number of potential
      implementers indicated plans to implement? Are any existing
      implementations reported somewhere, either in the document itself (as
      [RFC 7942][3] recommends) or elsewhere (where)?

Not yet; however, there are a couple existing drafts that need to use the
feature (draft-cheng-lsr-igp-shortcut-enhancement,
draft-li-lsr-igp-based-intra-domain-savnet).

    ## Additional Reviews

    5. Do the contents of this document closely interact with technologies in
      other IETF working groups or external organizations, and would it
      therefore benefit from their review? Have those reviews occurred? If yes,
      describe which reviews took place.

No.

    6. Describe how the document meets any required formal expert review
      criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
      reviews.

Rtrdir and YANG doctor reviews completed and comments were addressed.

    7. If the document contains a YANG module, has the final version of the
      module been checked with any of the [recommended validation tools][4] for
      syntax and formatting validation? If there are any resulting errors or
      warnings, what is the justification for not fixing them at this time?
      Does the YANG module comply with the Network Management Datastore
      Architecture (NMDA) as specified in [RFC 8342][5]?

Yes.

    8. Describe reviews and automated checks performed to validate sections of
      the final version of the document written in a formal language, such as
      XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

None.

    ## Document Shepherd Checks

    9. Based on the shepherd's review of the document, is it their opinion that
      this document is needed, clearly written, complete, correctly designed,
      and ready to be handed off to the responsible Area Director?

Yes.

    10. Several IETF Areas have assembled [lists of common issues that their
        reviewers encounter][6]. For which areas have such issues been
        identified and addressed? For which does this still need to happen in
        subsequent reviews?

N/A.

    11. What type of RFC publication is being requested on the IETF stream
        ([Best Current Practice][12], [Proposed Standard, Internet
        Standard][13], [Informational, Experimental or Historic][14])? Why is
        this the proper type of RFC? Do all Datatracker state attributes
        correctly reflect this intent?

Proposed Standard is required since OSPF and OSPFv3 protocol encodings are
defined.

    12. Have reasonable efforts been made to remind all authors of the
        intellectual property rights (IPR) disclosure obligations described in
        [BCP 79][7]? To the best of your knowledge, have all required
        disclosures been filed? If not, explain why. If yes, summarize any
        relevant discussion, including links to publicly-available messages when
        applicable.

Yes, IPR author poll completed.

    13. Has each author, editor, and contributor shown their willingness to be
        listed as such? If the total number of authors and editors on the front
        page is greater than five, please provide a justification.

Yes.

    14. Document any remaining I-D nits in this document. Simply running the
        [idnits tool][8] is not enough; please review the ["Content Guidelines"
        on authors.ietf.org][15]. (Also note that the current idnits tool
        generates some incorrect warnings; a rewrite is underway.)

None.

    15. Should any informative references be normative or vice-versa? See the
        [IESG Statement on Normative and Informative References][16].

No.

    16. List any normative references that are not freely available to anyone.
        Did the community have sufficient access to review any such normative
        references?

None.

    17. Are there any normative downward references (see [RFC 3967][9] and [BCP
        97][10]) that are not already listed in the [DOWNREF registry][17]? If
        so, list them.

No.

    18. Are there normative references to documents that are not ready to be
        submitted to the IESG for publication or are otherwise in an unclear
        state? If so, what is the plan for their completion?

No.

    19. Will publication of this document change the status of any existing
        RFCs? If so, does the Datatracker metadata correctly reflect this and
        are those RFCs listed on the title page, in the abstract, and discussed
        in the introduction? If not, explain why and point to the part of the
        document where the relationship of this document to these other RFCs is
        discussed.

No.

    20. Describe the document shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body of the
        document. Confirm that all aspects of the document requiring IANA
        assignments are associated with the appropriate reservations in IANA
        registries. Confirm that any referenced IANA registries have been
        clearly identified. Confirm that each newly created IANA registry
        specifies its initial contents, allocations procedures, and a reasonable
        name (see [RFC 8126][11]).

Confirmed the above. No new registries are created.

    21. List any new IANA registries that require Designated Expert Review for
        future allocations. Are the instructions to the Designated Expert clear?
        Please include suggestions of designated experts, if appropriate.

None.

## Document History

    1. Does the working group (WG) consensus represent the strong concurrence of
      a few individuals, with others being silent, or did it reach broad
      agreement?

There is a strong and broad consensus for publishing this document.

    2. Was there controversy about particular points, or were there decisions
      where the consensus was particularly rough?

No.

    3. Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarize the areas of conflict in separate
      email messages to the responsible Area Director. (It should be in a
      separate email because this questionnaire is publicly available.)

No.

    4. For protocol documents, are there existing implementations of the
      contents of the document? Have a significant number of potential
      implementers indicated plans to implement? Are any existing
      implementations reported somewhere, either in the document itself (as
      [RFC 7942][3] recommends) or elsewhere (where)?

Not yet; however, there are a couple existing drafts that need to use the
feature (draft-cheng-lsr-igp-shortcut-enhancement,
draft-li-lsr-igp-based-intra-domain-savnet).

    ## Additional Reviews

    5. Do the contents of this document closely interact with technologies in
      other IETF working groups or external organizations, and would it
      therefore benefit from their review? Have those reviews occurred? If yes,
      describe which reviews took place.

No.

    6. Describe how the document meets any required formal expert review
      criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
      reviews.

Rtrdir and YANG doctor reviews completed and comments were addressed.

    7. If the document contains a YANG module, has the final version of the
      module been checked with any of the [recommended validation tools][4] for
      syntax and formatting validation? If there are any resulting errors or
      warnings, what is the justification for not fixing them at this time?
      Does the YANG module comply with the Network Management Datastore
      Architecture (NMDA) as specified in [RFC 8342][5]?

Yes.

    8. Describe reviews and automated checks performed to validate sections of
      the final version of the document written in a formal language, such as
      XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

None.

    ## Document Shepherd Checks

    9. Based on the shepherd's review of the document, is it their opinion that
      this document is needed, clearly written, complete, correctly designed,
      and ready to be handed off to the responsible Area Director?

Yes.

    10. Several IETF Areas have assembled [lists of common issues that their
        reviewers encounter][6]. For which areas have such issues been
        identified and addressed? For which does this still need to happen in
        subsequent reviews?

N/A.

    11. What type of RFC publication is being requested on the IETF stream
        ([Best Current Practice][12], [Proposed Standard, Internet
        Standard][13], [Informational, Experimental or Historic][14])? Why is
        this the proper type of RFC? Do all Datatracker state attributes
        correctly reflect this intent?

Proposed Standard is required since OSPF and OSPFv3 protocol encodings are
defined.

    12. Have reasonable efforts been made to remind all authors of the
        intellectual property rights (IPR) disclosure obligations described in
        [BCP 79][7]? To the best of your knowledge, have all required
        disclosures been filed? If not, explain why. If yes, summarize any
        relevant discussion, including links to publicly-available messages when
        applicable.

Yes, IPR author poll completed.

    13. Has each author, editor, and contributor shown their willingness to be
        listed as such? If the total number of authors and editors on the front
        page is greater than five, please provide a justification.

Yes.

    14. Document any remaining I-D nits in this document. Simply running the
        [idnits tool][8] is not enough; please review the ["Content Guidelines"
        on authors.ietf.org][15]. (Also note that the current idnits tool
        generates some incorrect warnings; a rewrite is underway.)

None.

    15. Should any informative references be normative or vice-versa? See the
        [IESG Statement on Normative and Informative References][16].

No.

    16. List any normative references that are not freely available to anyone.
        Did the community have sufficient access to review any such normative
        references?

None.

    17. Are there any normative downward references (see [RFC 3967][9] and [BCP
        97][10]) that are not already listed in the [DOWNREF registry][17]? If
        so, list them.

No.

    18. Are there normative references to documents that are not ready to be
        submitted to the IESG for publication or are otherwise in an unclear
        state? If so, what is the plan for their completion?

No.

    19. Will publication of this document change the status of any existing
        RFCs? If so, does the Datatracker metadata correctly reflect this and
        are those RFCs listed on the title page, in the abstract, and discussed
        in the introduction? If not, explain why and point to the part of the
        document where the relationship of this document to these other RFCs is
        discussed.

No.

    20. Describe the document shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body of the
        document. Confirm that all aspects of the document requiring IANA
        assignments are associated with the appropriate reservations in IANA
        registries. Confirm that any referenced IANA registries have been
        clearly identified. Confirm that each newly created IANA registry
        specifies its initial contents, allocations procedures, and a reasonable
        name (see [RFC 8126][11]).

Confirmed the above. No new registries are created.

    21. List any new IANA registries that require Designated Expert Review for
        future allocations. Are the instructions to the Designated Expert clear?
        Please include suggestions of designated experts, if appropriate.

None.

## Document History

    1. Does the working group (WG) consensus represent the strong concurrence of
      a few individuals, with others being silent, or did it reach broad
      agreement?

There is a strong and broad consensus for publishing this document.

    2. Was there controversy about particular points, or were there decisions
      where the consensus was particularly rough?

No.

    3. Has anyone threatened an appeal or otherwise indicated extreme
      discontent? If so, please summarize the areas of conflict in separate
      email messages to the responsible Area Director. (It should be in a
      separate email because this questionnaire is publicly available.)

No.

    4. For protocol documents, are there existing implementations of the
      contents of the document? Have a significant number of potential
      implementers indicated plans to implement? Are any existing
      implementations reported somewhere, either in the document itself (as
      [RFC 7942][3] recommends) or elsewhere (where)?

Not yet; however, there are a couple existing drafts that use the feature.

    ## Additional Reviews

    5. Do the contents of this document closely interact with technologies in
      other IETF working groups or external organizations, and would it
      therefore benefit from their review? Have those reviews occurred? If yes,
      describe which reviews took place.

No.

    6. Describe how the document meets any required formal expert review
      criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type
      reviews.

Rtrdir and YANG doctor reviews completed and comments were addressed.

    7. If the document contains a YANG module, has the final version of the
      module been checked with any of the [recommended validation tools][4] for
      syntax and formatting validation? If there are any resulting errors or
      warnings, what is the justification for not fixing them at this time?
      Does the YANG module comply with the Network Management Datastore
      Architecture (NMDA) as specified in [RFC 8342][5]?

Yes.

    8. Describe reviews and automated checks performed to validate sections of
      the final version of the document written in a formal language, such as
      XML code, BNF rules, MIB definitions, CBOR's CDDL, etc.

None.

    ## Document Shepherd Checks

    9. Based on the shepherd's review of the document, is it their opinion that
      this document is needed, clearly written, complete, correctly designed,
      and ready to be handed off to the responsible Area Director?

Yes.

    10. Several IETF Areas have assembled [lists of common issues that their
        reviewers encounter][6]. For which areas have such issues been
        identified and addressed? For which does this still need to happen in
        subsequent reviews?

N/A.

    11. What type of RFC publication is being requested on the IETF stream
        ([Best Current Practice][12], [Proposed Standard, Internet
        Standard][13], [Informational, Experimental or Historic][14])? Why is
        this the proper type of RFC? Do all Datatracker state attributes
        correctly reflect this intent?

Proposed Standard is required since OSPF and OSPFv3 protocol encodings are
defined.

    12. Have reasonable efforts been made to remind all authors of the
        intellectual property rights (IPR) disclosure obligations described in
        [BCP 79][7]? To the best of your knowledge, have all required
        disclosures been filed? If not, explain why. If yes, summarize any
        relevant discussion, including links to publicly-available messages when
        applicable.

Yes, IPR author poll completed.

    13. Has each author, editor, and contributor shown their willingness to be
        listed as such? If the total number of authors and editors on the front
        page is greater than five, please provide a justification.

Yes.

    14. Document any remaining I-D nits in this document. Simply running the
        [idnits tool][8] is not enough; please review the ["Content Guidelines"
        on authors.ietf.org][15]. (Also note that the current idnits tool
        generates some incorrect warnings; a rewrite is underway.)

None.

    15. Should any informative references be normative or vice-versa? See the
        [IESG Statement on Normative and Informative References][16].

No.

    16. List any normative references that are not freely available to anyone.
        Did the community have sufficient access to review any such normative
        references?

None.

    17. Are there any normative downward references (see [RFC 3967][9] and [BCP
        97][10]) that are not already listed in the [DOWNREF registry][17]? If
        so, list them.

No.

    18. Are there normative references to documents that are not ready to be
        submitted to the IESG for publication or are otherwise in an unclear
        state? If so, what is the plan for their completion?

No.

    19. Will publication of this document change the status of any existing
        RFCs? If so, does the Datatracker metadata correctly reflect this and
        are those RFCs listed on the title page, in the abstract, and discussed
        in the introduction? If not, explain why and point to the part of the
        document where the relationship of this document to these other RFCs is
        discussed.

No.

    20. Describe the document shepherd's review of the IANA considerations
        section, especially with regard to its consistency with the body of the
        document. Confirm that all aspects of the document requiring IANA
        assignments are associated with the appropriate reservations in IANA
        registries. Confirm that any referenced IANA registries have been
        clearly identified. Confirm that each newly created IANA registry
        specifies its initial contents, allocations procedures, and a reasonable
        name (see [RFC 8126][11]).

Confirmed the above. No new registries are created.

    21. List any new IANA registries that require Designated Expert Review for
        future allocations. Are the instructions to the Designated Expert clear?
        Please include suggestions of designated experts, if appropriate.

None.

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  The document has been in the pipeline for sometime and is there is complete
  consensus. Adding the YANG augmentations, as well as more pressing LSR WG
  business is to blame for the delay.

  Admin tags for prefixes are available for IS-IS and this has been pending
  for OSPF for a long time.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  Based on discussions on the LSR WG list, we removed both tags for OSPF
  interfaces since they are already have administrative groups (RFC 9492).
  Additionally, we removed the 64-bit tags since no one has implemented them
  for IS-IS.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No. 

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  Not yet - however, we have several drafts requiring admin tags in OSPF (e.g.,
  https://datatracker.ietf.org/doc/draft-li-lsr-igp-based-intra-domain-savnet/).
 

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  N/A - this is a simple OSPF extension not requiring outside reviews.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  There has been both RTGDIR and YANG Doctor reviews on this document and
  all comments have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

    Yes.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  N/A

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

  N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    Proposed Standard is required since OSPF and OSPFv3 protocol encodings are
    defined.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    Yes. There are only three authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    None.
   

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    The IANA extensions for defined Sub-TLVs are straight-forward and extend
    existing registries.

    The YANG augmentation model URI and name IANA updates are similar to
    other augmentations.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    None.

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  The document has been in the pipeline for sometime and is there is complete
  consensus. Adding the YANG augmentations, as well as more pressing LSR WG
  business is to blame for the delay.

  Admin tags for prefixes are available for IS-IS and this has been pending
  for OSPF for a long time.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  Based on discussions on the LSR WG list, we removed both tags for OSPF
  interfaces since they are already have administrative groups (RFC 9492).
  Additionally, we removed the 64-bit tags since no one has implemented them
  for IS-IS.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No. 

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  Not yet - however, we have several drafts requiring admin tags in OSPF (e.g.,
  https://datatracker.ietf.org/doc/draft-li-lsr-igp-based-intra-domain-savnet/).
 

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  N/A - this is a simple OSPF extension not requiring outside reviews.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  There has been both RTGDIR and YANG Doctor reviews on this document and
  all comments have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

    Yes.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  N/A

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

  N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    Proposed Standard is required since OSPF and OSPFv3 protocol encodings are
    defined.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    Yes. There are only three authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    None.
   

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    The IANA extensions for defined Sub-TLVs are straight-forward and extend
    existing registries.

    The YANG augmentation model URI and name IANA updates are similar to
    other augmentations.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    None.

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  There document has been in the pipeline for sometime and is there is complete
  consensus. Adding the YANG augmentations, as well as more pressing LSR WG
  business is to blame for the delay.

  Admin tags for prefixes are available for IS-IS and this has been pending
  for a long time.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  Based on discussions on the LSR WG list, we removed both tags for OSPF
  interfaces since they are already have administrative groups (RFC 9492).
  Additionally, we removed the 64-bit tags since no one has implemented them
  for IS-IS.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No. 

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  Not yet - however, we have several drafts requiring admin tags in OSPF (e.g.,
  https://datatracker.ietf.org/doc/draft-li-lsr-igp-based-intra-domain-savnet/).
 

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  N/A - this is a simple OSPF extension not requiring outside reviews.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  There has been both RTGDIR and YANG Doctor reviews on this document and
  all comments have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

    Yes.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  N/A

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

  N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    Proposed Standard is required since OSPF and OSPFv3 protocol encodings are
    defined.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    Yes. There are only three authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    None.
   

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    The IANA extensions for defined Sub-TLVs are straight-forward and extend
    existing registries.

    The YANG augmentation model URI and name IANA updates are similar to
    other augmentations.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    None.

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  There document has been in the pipeline for sometime and is there is complete
  consensus. Adding the YANG augmentations, as well as more pressing LSR WG
  business is to blame for the delay.

  Admin tags for prefixes are available for IS-IS and this has been pending
  for a long time.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  Based on discussions on the LSR WG list, we removed both tags for OSPF
  interfaces since they are already have administrative groups (RFC 9492).
  Additionally, we removed the 64-bit tags since no one has implemented them
  for IS-IS.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No. 

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  Not yet - however, we have several drafts requiring admin tags in OSPF (e.g.,
  https://datatracker.ietf.org/doc/draft-li-lsr-igp-based-intra-domain-savnet/).
 

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  N/A - this is a simple OSPF extension not requiring outside reviews.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  There has been both RTGDIR and YANG Doctor reviews on this document and
  all comments have been addressed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

    Yes.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  N/A

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

  N/A

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    Proposed Standard is required since OSPF and OSPFv3 protocol encodings are
    defined.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    Yes.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.

    Yes. There are only three authors.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    None.
   

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    N/A

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    No

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    No.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    The IANA extensions for defined Sub-TLVs are straight-forward and extend
    existing registries.

    The YANG augmentation model URI and name IANA updates are similar to
    other augmentations.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    None.