YANG Data Model for OSPF Application-Specific Link Attributes and Flexible Algorithm
draft-ietf-lsr-ospf-flex-algo-yang-08

[Ballot discuss]
Hi Yingzhen and Acee,

Thank you for the effort put into this document.

The same DISCUSS/COMMENT points I raised for the IS-IS spec at https://mailarchive.ietf.org/arch/msg/lsr/ydQQNGc5m4cFrDpH7CYOWP3tEKU/ apply here as I well. I’m not repeating those and I trust the outcome of that thread will be factorized for this document.

Please find below comments that are specific to this spec.

# Mirror the registries

All IANA-maintained modules do not mirror exactly the same content as the registry. There are deviations in the descriptions and references.

For example,

    identity algo-spf {
      base algo-type;
      description
        "Shortest Path First (SPF) algorithm based on link metric.";
      reference
        "RFC 8665: OSPF Extensions for Segment Routing";
    }

while the registry includes

“Shortest Path First (SPF) algorithm based on link metric. This is the standard shortest path algorithm as computed by the IGP protocol. Consistent with the deployed practice for link-state protocols, Algorithm 0 permits any node to overwrite the SPF path with a different path based on its local policy.”

Or

    identity te-default-metric {
      base metric-type;
      description
        "Traffic Engineering Default Metric as defined in RFC 5305
          Section 3.7 and Traffic Engineering Metric as defined in
          RFC3630, Section 2.5.5.";
      reference
        "RFC 3630: OSPF Traffic Engineering
          RFC 5305: IS-IS Traffic Engineering
          RFC 9350: IGP Flexible Algorithm";
    }

while the registry includes only “[RFC9350, Section 5.1]”

# Removal of IANA-maintained modules

RFC9907 says:

The authors MUST include a note to the RFC
  Editor requesting that the appendix with the initial version of the
  module be removed before publication as RFC and that RFC IIII is
  replaced with the RFC number that is assigned to the document.
  Initial versions of IANA-maintained YANG modules that are published
  in RFCs may be misused despite the appropriate language to refer to
  the IANA registry to retrieve the up-to-date module.  This is
  problematic for interoperability, e.g., when values are deprecated or
  are associated with a new meaning.

Can we please add the missing notes?

# Instructions to generate the identifiers: IGP Algorithm Types

CURRENT:
  When a value is added to the "IGP Algorithm Types" registry, a new
  "identity" statement needs to be added to the "iana-igp-algo-types"
  YANG module.  The name of the "identity" MUST be the name as provided
  in the registry.  The "identity" statement should have the following
  sub-statements defined:

## There is no name in the registry.

## Even if we extract some name from the description, copying it as it is would lead to illegal identifiers. An instruction about replacing spaces with “-“ would be needed at minimum.

## What about simply asking for the name to be the outcome of prefixing “type-” with the decimal registered value?

## Please avoid the use the normative language in the IANA considerations

# Idem for the other IANA modules

# Link Attribute Application IDs

CURRENT:
  When a value is added to the "Link Attribute Application IDs"
  registry, a new "identity" statement needs to be added to the "iana-
  igp-link-attr-apps" YANG module.  The name of the "identity" MUST be
  the name as provided in the registry.  The "identity" statement
  should have the following sub-statements defined:

There is a name column but the name is, example, “RSVP-TE (R-bit)”. Following the instruction above would lead to illegal identifier.

Please update so that the instruction is clear and lead to legal identifiers.

[Ballot comment]
# Type

As you know, RFC 9907 says the following:
  An IANA-maintained YANG module may use the "identityref" data type
  approach (e.g., [RFC8675]) or an "enumeration" data type approach
  (e.g., [RFC9108]).  See Section 4.11.1 for a guidance on which data
  type to use.  The decision about which type to use should be made
  based upon specifics related to the intended use of the IANA-
  maintained YANG module.  For example, identities are useful if the
  registry entries are organized hierarchically, possibly including
  multiple inheritances.  The reasoning for the design choice MUST be
  documented in the companion specification that registers an IANA-
  maintained YANG module.

Is there any specific reason why identity is used for the various modules, instead of enumerations? Can we please include that in the doc?

As a side note, the use of enum would allow an easy mapping as the decimal value can be mirrored in the “value” statement.


#  No need to include the following as this is what IANA-maintained module is about.

CURRENT:
  This module is maintained by IANA and will be updated if and when
  there is any change to the registry.

# For all IANA-maintained modules, please add a reference that points to the IANA registry

For example, the first module would need to have the following right before the revision

NEW:
    Reference
      “Interior Gateway Protocol (IGP) Parameters, IGP Algorithm Types
        (https://www.iana.org/assignments/igp-parameters/igp-parameters.xhtml#igp-algorithm-types)";

# No need to supply default actions; only needed when you need customization from IANA

CURRENT:
  When the "iana-igp-algo-types" YANG module is updated, a new
  "revision" statement with a unique revision date must be added in
  front of the existing revision statements.  The "revision" statement
  MUST contain both "description" and "reference" substatements as
  follows.

  The "description" substatement captures what changed in the revised
  version.  Typically, the description enumerates the changes such as
  updpates to existing entries (e.g., update a description or a
  reference) or notes which identities were added or had their status
  changed (e.g., deprecated, discouraged, or obsoleted).

  The "reference" substatement points specifically to the published
  module (i.e., IANA_FOO_URL_With_REV).  It may also point to an
  authoritative event triggering the update to the YANG module.  In all
  cases, this event is cited from the underlying IANA registry.  If the
  update is triggered by an RFC, that RFC must also be included in the
  "reference" substatement.

RFC9907 says:

  -- Optional:

  -- Include only text that needs to be customized for the module.
  -- Text that does not require customization should be
  -- omitted.

  -- Notes tagged with "--" include instructions for authors.  These
  -- notes must not be copied.

  Unassigned and Reserved Values:

  -- To be completed only if unassigned and/or reserved values
  -- (which may include experimental values) should be included
  -- in the module.  These values are typically not included.

  Description Substatements:

  -- To be completed only if the default actions described in
  -- Section 5.3.2 of RFC 9907 are to be overridden.
  -- Specify whether instructions apply to "revision" statements,
  -- "identity" statements, or both.

  Reference Substatements:

  -- To be completed only if the default actions described in
  -- Section 5.3.2 of RFC 9907 are to be overridden.
  -- Specify whether instructions apply to "revision" statements,
  -- "identity" statements, or both.

  Naming Considerations:

  -- If a name in the IANA registry does not comply with the
  -- YANG naming conventions, add details how IANA can generate
  -- legal identifiers.  For example, if the name begins with
  -- a number, indicate a preference to spell out the number when
  -- used as an identifier.

Cheers,
Med

IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-lsr-ospf-flex-algo-yang-05. If any part of this review is inaccurate, please let us know.

We have questions about the third and fourth actions requested in the IANA Considerations section of this document.

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

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

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

Four new namespaces will be registered as follows:

ID: yang:iana-igp-algo-types
URI: urn:ietf:params:xml:ns:yang:iana-igp-algo-types
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

ID: yang:iana-igp-metric-types
URI: urn:ietf:params:xml:ns:yang:iana-igp-metric-types
Filename: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

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

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

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

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

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

Four new YANG modules will be registered as follows:

Name: iana-igp-algo-types
File: [ TBD-at-Registration ]
Maintained by IANA? Y
Namespace: urn:ietf:params:xml:ns:yang:iana-igp-algo-types
Prefix: iana-algo-types
Module:
Reference: [ RFC-to-be ]

Name: iana-igp-metric-types
File: [ TBD-at-Registration ]
Maintained by IANA? Y
Namespace: urn:ietf:params:xml:ns:yang:iana-igp-metric-types
Prefix: iana-metric-types
Module:
Reference: [ RFC-to-be ]

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

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

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

Third, in the IGP Algorithm Types registry located at:

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

A new note will be added to the top of the registry as follows:

When this registry is modified, the YANG module "iana-algo-types" Section 2 must be updated as defined in [ RFC-to-be ].

IANA Question --> Should [ RFC-to-be ] also be added to the references for the IGP Algorithm Types registry?

Fourth, in the IGP Metric-Type registry located at:

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

A new note will be added to the top of the registry as follows:

When this registry is modified, the YANG module "iana-metric-types" Section 2 must be updated as defined in [ RFC-to-be ].

IANA Question --> Should [ RFC-to-be ] also be added to the references for the IGP Metric-Type registry?

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 2026-03-30):

From: The IESG
To: IETF-Announce
CC: chopps@chopps.org, draft-ietf-lsr-ospf-flex-algo-yang@ietf.org, gunter@vandevelde.cc, lsr-chairs@ietf.org, lsr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (YANG Data Model for OSPF Application-Specific Link Attributes and Flexible Algorithm) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'YANG Data Model for OSPF
Application-Specific Link Attributes and
  Flexible Algorithm'
  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 2026-03-23. 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


  This document defines a YANG data model to support OSPF Application-
  Specific Link Attributes and Flexible Algorithm.  It also specifies
  the initial version of IANA-maintained YANG modules for IGP Algorithm
  Types and IGP Metric-Type.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospf-flex-algo-yang/



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

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.


Document: draft-ietf-lsr-ospf-flex-algo-yang-03
Reviewer: Christian Hopps

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## 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 was a limited WG participation due in part to lack of excitement for YANG
module development.

    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)?

N/A.

    ## 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, the document does not need external WG or Org reviews.

The doc was reviewed by routing directorate, and comments were addressed.

    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.

Document was reviewed by YANG doctors, 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]?

Unknown on validation tools. There are examples provided. The module augments
the base OSPF YANG module and doesn't change NMDA compliance.

    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.

No extra checks.

    ## 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?

Document is Ready. There are a couple minor grammar edits that can be
addressed during RFC editor. No need for a new version of the doc though.

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

    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. All YANG modules for OSPF are standards track documents.

    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.

All authors polled and none indicated knowledge of IPR.

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

The latest run of ID nits indicates 'NOT RECOMMENDED' should be listed as one of
the RFC2119 words. Other nits are not-applicable.

    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.

Doesn't update other docs.

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

Has a standard YANG document IANA section.

The document also defines an IANA maintained YANG module, "iana-algo-types",
that defines YANG identities based on the IANA registry "IGP Algorithm Types".
Similarly, the document defines a second IANA maintained YANG module,
"iana-metric-types", which defines YANG identities based on values in the IANA
registry "IGP Metric-Type". Sufficient guidance for maintaining these new
documents is provided.

    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]: https://www.ietf.org/about/groups/iesg/ [2]:
    https://www.rfc-editor.org/rfc/rfc4858.html [3]:
    https://www.rfc-editor.org/rfc/rfc7942.html [4]:
    https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]:
    https://www.rfc-editor.org/rfc/rfc8342.html [6]:
    https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]:
    https://www.rfc-editor.org/info/bcp79 [8]:
    https://www.ietf.org/tools/idnits/ [9]:
    https://www.rfc-editor.org/rfc/rfc3967.html [10]:
    https://www.rfc-editor.org/info/bcp97 [11]:
    https://www.rfc-editor.org/rfc/rfc8126.html [12]:
    https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]:
    https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]:
    https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]:
    https://authors.ietf.org/en/content-guidelines-overview [16]:
    https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
    [17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.


Document: draft-ietf-lsr-ospf-flex-algo-yang-03
Reviewer: Christian Hopps

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## 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 was a limited WG participation due in part to lack of excitement for YANG
module development.

    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)?

N/A.

    ## 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, the document does not need external WG or Org reviews.

The doc was reviewed by routing directorate, and comments were addressed.

    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.

Document was reviewed by YANG doctors, 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]?

Unknown on validation tools. There are examples provided. The module augments
the base OSPF YANG module and doesn't change NMDA compliance.

    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.

No extra checks.

    ## 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?

Document is Ready. There are a couple minor grammar edits that can be
addressed during RFC editor. No need for a new version of the doc though.

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

    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. All YANG modules for OSPF are standards track documents.

    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.

All authors polled and none indicated knowledge of IPR.

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

The latest run of ID nits indicates 'NOT RECOMMENDED' should be listed as one of
the RFC2119 words. Other nits are not-applicable.

    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.

Doesn't update other docs.

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

Has a standard YANG document IANA section.

The document also defines an IANA maintained YANG module, "iana-algo-types",
that defines YANG identities based on the IANA registry "IGP Algorithm Types".
Similarly, the document defines a second IANA maintained YANG module,
"iana-metric-types", which defines YANG identities based on values in the IANA
registry "IGP Metric-Type". Sufficient guidance for maintaining these new
documents is provided.

    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]: https://www.ietf.org/about/groups/iesg/ [2]:
    https://www.rfc-editor.org/rfc/rfc4858.html [3]:
    https://www.rfc-editor.org/rfc/rfc7942.html [4]:
    https://trac.ietf.org/trac/ops/wiki/yang-review-tools [5]:
    https://www.rfc-editor.org/rfc/rfc8342.html [6]:
    https://trac.ietf.org/trac/iesg/wiki/ExpertTopics [7]:
    https://www.rfc-editor.org/info/bcp79 [8]:
    https://www.ietf.org/tools/idnits/ [9]:
    https://www.rfc-editor.org/rfc/rfc3967.html [10]:
    https://www.rfc-editor.org/info/bcp97 [11]:
    https://www.rfc-editor.org/rfc/rfc8126.html [12]:
    https://www.rfc-editor.org/rfc/rfc2026.html#section-5 [13]:
    https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1 [14]:
    https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2 [15]:
    https://authors.ietf.org/en/content-guidelines-overview [16]:
    https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
    [17]: https://datatracker.ietf.org/doc/downref/