A YANG Module for IS-IS Reverse Metric
draft-ietf-lsr-yang-isis-reverse-metric-06

[Ballot comment]
Thanks to Vijay Gurbani for their General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/vTI3euK_FgI2nI-8482WikVehC8).

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2.2. , paragraph 11, nit:
> eudo-node LSP for this interface. Otherwise it will only increment the metric
>                                  ^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Otherwise".

Section 2.2. , paragraph 15, nit:
> ic announcements from neighbors. By default reverse metric handling is disab
>                                  ^^^^^^^^^^
Did you mean: "By default,"?

These URLs point to tools.ietf.org, which is being deprecated:
* https://tools.ietf.org/html/rfcXXXX
* https://tools.ietf.org/html/draft-ietf-isis-yang-isis-cfg-42
* https://tools.ietf.org/wg/lsr/

[Ballot comment]
Hi Chris,

Thanks for this YANG module.

Nit:
- Copyright statement in the YANG module should presumably be updated to 2021, to match the revision entry.

A few comments on the YANG model:
- For the interface config, reverse-metric turns up twice in the path.  You could perhaps drop it from the
  grouping so that it only appears once?
- Would it be helpful to make the top level reverse-metric container have presence?  This might make more
  sense if constraints are ever added to validate that a metric is specified at the top level, or under at
  least one of the levels.
- Am I right in assuming that that the level-1/level-2 config is effectively hierarchical and would override
  the config under the reverse-metric grouping?  E.g., is it allowed to specify a metric at the top level,
  and the whole-lan flag only under the level-1?  If so, would it be helpful to document this hierarchical
  behaviour in the description for the fields?
- There is a default assigned to exclude-te-metric, but no default assigned to whole-lan and allow-unreachable.
  If the config is not hierarchical, then should these all have defaults? If the config is hierarchical then
  perhaps they should not have any defaults, and the use statement for the top level reverse-metric grouping
  should refine them with default values?  Assuming that the descriptions make their hierarchical nature
  clear?

Security Considerations:
Would it also be helpful to include a reference back to the security considerations of the base ISIS YANG
module, since the concerns that apply to metrics there would seem to mostly also apply here.

References:
- Probably need to add XML and JSON references or otherwise change the requests to edit-config or RESTCONF requests.
- XML reference can be as per RFC 8342, JSON should probably be to RFC 7951.

A.1.  Example Enable XML
Suggest retitling to: Enablement Example Using XML YANG Instance Data"

A.2.  Example Use XML
Suggest retitling to: "Usage Example using XML YANG Instance Data"

A.3.  Example JSON
Suggest retitling to: "Usage Example using JSON YANG Instance Data"

Thanks,
Rob

[Ballot comment]
Thanks for the simple and easy-to-read document!
My comments are pretty minor.

Section 2.2

    grouping reverse-metric-if-config-data {
      description "IS-IS reverse metric config data.";
      container reverse-metric {
        description "IS-IS reverse metric data.";
        uses reverse-metric-data;
        leaf exclude-te-metric {
          type boolean;
          default false;
          description
            "If true and there is a TE metric defined for this
              interface then do not send the TE metric sub-TLV in the
              reverse metric TLV.";
          reference "RFC8500, Section 3.5";
        }
      }
    }

    grouping tlv16-reverse-metric {
      description "IS-IS reverse metric TLV data.";
      container reverse-metric {
        description "IS-IS reverse metric TLV data.";
        uses reverse-metric-data;
        leaf te-metric {
          type uint32;
          description
            "The TE metric value from the sub-TLV if present.";
          reference "RFC8500, Section 3.5";
        }
      }
    }

Please confirm that Section 3.5 of RFC 8500 is the right reference for
both of these; I didn't really see much there that lined up well with
these descriptions.

      container reverse-metric {
        description "Announce a reverse metric to neighbors.";
        uses reverse-metric-if-config-data;
        container level-1 {
          description
            "Announce a reverse metric to level-1 neighbors.";
          uses reverse-metric-if-config-data;
        }
        container level-2 {
          description
            "Announce a reverse metric to level-2 neighbors.";
          uses reverse-metric-if-config-data;
        }
      }

Are the interactions between the toplevel
"reverse-metric-if-config-data" and the per-level uses of that grouping
adequately specified by the core draft-ietf-isis-yang-isis-cfg such that
we don't need to repeat them here?  (I think it probably is.)

Section 4

  These are the subtrees and data nodes and their sensitivity/
  vulnerability:

I think the intent of the security considerations template is that we
specifically talk about what bad things would happen if some
unauthorized entity was writing values to the ("config true") nodes, or
reading values from the ("config false") nodes.  The current text here
seems to just be listing the nodes without saying what happens if
they're misconfigured or the contents are leaked to an unauthorized
party.  (On first glance, it seems like the security considerations of
RFC 8500 basically cover everything that we would need to say.  It's
short, so we could repeat the content, or we could say that these YANG
nodes correspond directly to the RFC 8500 functionality and the
considerations of the functionality are described in RFC 8500.)

Section 5

The core NETCONF/RESTCONF RFCs may not need to be classified as
normative (we only reference them from the security considerations
boilerplate), but there's not much harm in leaving them here.

Appendix A

Thank you for including the examples!

[Ballot comment]
whole-lan is only applicable to multi-access interfaces.  I was expecting something similar to how "priority" is defined (in the main module), but I can't find that here.  Am I missing something?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-lsr-yang-isis-reverse-metric-04. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

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

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

a new namespace will be registered as follows:

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

As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

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

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

a new YANG module will be registered as follows:

Name: ietf-isis-reverse-metric
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-isis-reverse-metric
Prefix: isis-rmetric
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.

The IANA Functions Operator understands 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.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist

The following Last Call announcement was sent out (ends 2021-11-15):

From: The IESG
To: IETF-Announce
CC: acee@cisco.com, draft-ietf-lsr-yang-isis-reverse-metric@ietf.org, jgs@juniper.net, lsr-chairs@ietf.org, lsr@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (YANG Module for IS-IS Reverse Metric) to Proposed Standard


The IESG has received a request from the Link State Routing WG (lsr) to
consider the following document: - 'YANG Module for IS-IS Reverse Metric'
  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 2021-11-15. 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 module for managing the reverse metric
  extension to the Intermediate System to Intermediate System intra-
  domain routeing information exchange protocol (IS-IS).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lsr-yang-isis-reverse-metric/



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

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

      A Standards Track RFC is being requested and is indicated in the
      title page header. This is a standards track RFC since it includes a YANG model for reverse metric which augments the IETF standard IS-IS YANG model.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
   
    The document defines YANG model that augments the base ietf-isis.yang
    model. It provides augmentations supporting configuration and
    operational data for the IS-IS reverse metric functionality as described
    in RFC 8500.

Working Group Summary:
 
    The document has been reviewed by the YANG experts in the LSR working
    group and has been reviewed by both the YANG doctors and routing area
    directorate.
     
Document Quality:
 
    The document is a fairly simple extension to the existing IS-IS YANG
    model. IS-IS experts have been quieried to validate that it meets the
    requirments for IS-IS reverse metric configuration and operational
    state.

Personnel:

      Acee Lindem is the Document Shepherd.
      John Scudder is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

    The document shepherd has reviewed each revision of the document and
    participated in the ensuing discussions.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

    No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

    No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

    None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

    No.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

    There is consensus from the WG and others outside the WG that
    this document can progress.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

    All nits are resolved.

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

    The document has gone through a YANG doctor review.

(13) Have all references within this document been identified as either normative or informative?

    Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

    No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

    No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

    No.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

    The IANA considerations for YANG models are pretty standard with
    a URI and YANG model name allocation requested.
   
(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

    None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

    Yes.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

  The YANG model has been validated using https://www.yangcatalog.org/yangvalidator/draft-validator
 

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

      A Standards Track RFC is being requested and is indicated in the
      title page header. This is a standards track RFC since it includes a YANG model for reverse metric which augments the IETF standard IS-IS YANG model.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
   
    The document defines YANG model that augments the base ietf-isis.yang
    model. It provides augmentations supporting configuration and
    operational data for the IS-IS reverse metric functionality as described
    in RFC 8500.

Working Group Summary:
 
    The document has been reviewed by the YANG experts in the LSR working
    group and has been reviewed by both the YANG doctors and routing area
    directorate.
     
Document Quality:
 
    The document is a fairly simple extension to the existing IS-IS YANG
    model. IS-IS experts have been quieried to validate that it meets the
    requirments for IS-IS reverse metric configuration and operational
    state.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

    The document shepherd has reviewed each revision of the document and
    participated in the ensuing discussions.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

    No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

    No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

    None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

    No.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

    There is consensus from the WG and others outside the WG that
    this document can progress.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

    All nits are resolved.

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

    The document has gone through a YANG doctor review.

(13) Have all references within this document been identified as either normative or informative?

    Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

    No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

    No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

    No.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

    The IANA considerations for YANG models are pretty standard with
    a URI and YANG model name allocation requested.
   
(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

    None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

    Yes.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

  The YANG model has been validated using https://www.yangcatalog.org/yangvalidator/draft-validator
 

Closed request for Last Call review by RTGDIR with state 'Overtaken by Events': Review opened for a specific assignment. Cannot assign to that reviewer (Himanshu not showing up in list)

Closed request for Last Call review by RTGDIR with state 'Overtaken by Events': Review opened for a specific assignment. Cannot assign to that reviewer (Himanshu not showing up in list)

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
   
    The document defines YANG model that augments the base ietf-isis.yang
    model. It provides augmentations supporting configuration and
    operational data for the IS-IS reverse metric functionality as described
    in RFC 8500.

Working Group Summary:
 
    The document has been reviewed by the YANG experts in the LSR working
    group and has been reviewed by both the YANG doctors and routing area
    directorate.
     
Document Quality:
 
    The document is a fairly simple extension to the existing IS-IS YANG
    model. IS-IS experts have been quieried to validate that it meets the
    requirments for IS-IS reverse metric configuration and operational
    state.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

    The document shepherd has reviewed each revision of the document and
    participated in the ensuing discussions.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

    No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

    No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

    None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

    No.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

    There is consensus from the WG and others outside the WG that
    this document can progress.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

    All nits are resolved.

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

    The document has gone through a YANG doctor review.

(13) Have all references within this document been identified as either normative or informative?

    Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

    No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

    No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

    No.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

    The IANA considerations for YANG models are pretty standard with
    a URI and YANG model name allocation requested.
   
(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

    None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

    Yes.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

  The YANG model has been validated using https://www.yangcatalog.org/yangvalidator/draft-validator
 

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

      A Standards Track RFC is being requested and is indicated in the
      title page header.


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:
   
    The document defines YANG model that augments the base ietf-isis.yang
    model. It provides augmentations supporting configuration and
    operational data for the IS-IS reverse metric functionality as described
    in RFC 8500.

Working Group Summary:
 
    The document has been reviewed by the YANG experts in the LSR working
    group and has been reviewed by both the YANG doctors and routing area
    directorate.
     
Document Quality:
 
    The document is a fairly simple extension to the existing IS-IS YANG
    model. IS-IS experts have been quieried to validate that it meets the
    requirments for IS-IS reverse metric configuration and operational
    state.

Personnel:

      Acee Lindem is the Document Shepherd.
      Alvaro Retana is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

    The document shepherd has reviewed each revision of the document and
    participated in the ensuing discussions.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

    No.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

    No.

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

    None.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

    Yes.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

    No.


(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

    There is consensus from the WG and others outside the WG that
    this document can progress.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise 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.

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

    All nits are resolved.

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

    The document has gone through a YANG doctor review.

(13) Have all references within this document been identified as either normative or informative?

    Yes.

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

    No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

    No.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

    No.

(17) 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 protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

    The IANA considerations for YANG models are pretty standard with
    a URI and YANG model name allocation requested.
   
(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

    None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

    Yes.

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) 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 RFC8342?

  The YANG model has been validated using https://www.yangcatalog.org/yangvalidator/draft-validator