Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2022-10-19
06 (System)
Received changes through RFC Editor sync (created alias RFC 9194, changed title to 'A YANG Module for IS-IS Reverse Metric', changed abstract to 'This …
Received changes through RFC Editor sync (created alias RFC 9194, changed title to 'A YANG Module for IS-IS Reverse Metric', changed abstract to 'This document defines a YANG module for managing the reverse metric extension to the Intermediate System to Intermediate System (IS-IS) intra-domain routing information exchange protocol.', changed pages to 13, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2022-10-19, changed IESG state to RFC Published)
2022-10-19
06 (System) RFC published
2022-02-14
06 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2022-02-03
06 (System) RFC Editor state changed to AUTH48
2022-01-11
06 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2022-01-10
06 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2022-01-10
06 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2022-01-10
06 (System) IANA Action state changed to In Progress from Waiting on Authors
2022-01-07
06 (System) IANA Action state changed to Waiting on Authors from In Progress
2022-01-04
06 (System) RFC Editor state changed to EDIT
2022-01-04
06 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2022-01-04
06 (System) Announcement was received by RFC Editor
2022-01-04
06 (System) IANA Action state changed to In Progress
2022-01-04
06 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent::AD Followup
2022-01-04
06 Amy Vezza IESG has approved the document
2022-01-04
06 Amy Vezza Closed "Approve" ballot
2022-01-04
06 Amy Vezza Ballot approval text was generated
2022-01-01
06 Christian Hopps New version available: draft-ietf-lsr-yang-isis-reverse-metric-06.txt
2022-01-01
06 (System) New version accepted (logged-in submitter: Christian Hopps)
2022-01-01
06 Christian Hopps Uploaded new revision
2021-12-11
05 Christian Hopps New version available: draft-ietf-lsr-yang-isis-reverse-metric-05.txt
2021-12-11
05 (System) New version accepted (logged-in submitter: Christian Hopps)
2021-12-11
05 Christian Hopps Uploaded new revision
2021-12-02
04 (System) Removed all action holders (IESG state changed)
2021-12-02
04 Cindy Morgan IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation
2021-12-02
04 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2021-11-29
04 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2021-11-29
04 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-11-29
04 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2021-11-29
04 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2021-11-29
04 Lars Eggert
[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 …
[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/
2021-11-29
04 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert
2021-11-29
04 Robert Wilton
[Ballot comment]
Hi Chris,

Thanks for this YANG module.

Nit:
- Copyright statement in the YANG module should presumably be updated to 2021, to match …
[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
2021-11-29
04 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2021-11-28
04 Roman Danyliw [Ballot comment]
I'll echo the polish Ben Kaduk suggested on structuring the security considerations of the sensitive read and write nodes in Section 4.
2021-11-28
04 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2021-11-27
04 Benjamin Kaduk
[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 …
[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!
2021-11-27
04 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2021-11-22
04 Alvaro Retana
[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 …
[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?
2021-11-22
04 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2021-11-18
04 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Hilarie Orman. Submission of review completed at an earlier date.
2021-11-17
04 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2021-11-15
04 Cindy Morgan Placed on agenda for telechat - 2021-12-02
2021-11-15
04 John Scudder Ballot has been issued
2021-11-15
04 John Scudder [Ballot Position Update] New position, Yes, has been recorded for John Scudder
2021-11-15
04 John Scudder Created "Approve" ballot
2021-11-15
04 John Scudder IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2021-11-15
04 John Scudder Ballot writeup was changed
2021-11-15
04 Tero Kivinen Request for Last Call review by SECDIR Completed: Ready. Reviewer: Hilarie Orman.
2021-11-12
04 John Scudder IESG state changed to Waiting for AD Go-Ahead from In Last Call
2021-11-12
04 Sabrina Tanamal IANA Experts State changed to Expert Reviews OK from Reviews assigned
2021-11-12
04 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2021-11-12
04 Sabrina Tanamal IANA Experts State changed to Reviews assigned
2021-11-12
04 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2021-11-12
04 Sabrina Tanamal
(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 …
(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
2021-11-03
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2021-11-03
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2021-11-03
04 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2021-11-02
04 Vijay Gurbani Request for Last Call review by GENART Completed: Ready. Reviewer: Vijay Gurbani. Sent review to list.
2021-10-29
04 Jean Mahoney Request for Last Call review by GENART is assigned to Vijay Gurbani
2021-10-29
04 Jean Mahoney Request for Last Call review by GENART is assigned to Vijay Gurbani
2021-10-28
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Hilarie Orman
2021-10-28
04 Tero Kivinen Request for Last Call review by SECDIR is assigned to Hilarie Orman
2021-10-27
04 Scott Bradner Assignment of request for Last Call review by OPSDIR to Scott Bradner was rejected
2021-10-27
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2021-10-27
04 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Scott Bradner
2021-10-25
04 Cindy Morgan IANA Review state changed to IANA - Review Needed
2021-10-25
04 Cindy Morgan
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 …
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.




2021-10-25
04 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2021-10-25
04 Cindy Morgan Last call announcement was changed
2021-10-25
04 John Scudder Last call was requested
2021-10-25
04 John Scudder Last call announcement was generated
2021-10-25
04 John Scudder Ballot approval text was generated
2021-10-25
04 John Scudder Ballot writeup was generated
2021-10-25
04 John Scudder IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-10-24
04 (System) Changed action holders to John Scudder (IESG state changed)
2021-10-24
04 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-10-24
04 Christian Hopps New version available: draft-ietf-lsr-yang-isis-reverse-metric-04.txt
2021-10-24
04 (System) New version accepted (logged-in submitter: Christian Hopps)
2021-10-24
04 Christian Hopps Uploaded new revision
2021-09-30
03 (System) Changed action holders to John Scudder, Christian Hopps (IESG state changed)
2021-09-30
03 John Scudder IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2021-08-16
03 Acee Lindem
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 …
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
 

2021-08-16
03 Acee Lindem
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 …
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
 

2021-04-16
03 John Scudder Notification list changed to acee@cisco.com, jgs@juniper.net from acee@cisco.com
2021-04-16
03 (System) Changed action holders to John Scudder (IESG state changed)
2021-04-16
03 John Scudder IESG state changed to AD Evaluation from Publication Requested
2021-03-10
03 Cindy Morgan Shepherding AD changed to John Scudder
2021-02-16
03 Luc André Burdet
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 …
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)
2021-02-16
03 Luc André Burdet
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 …
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)
2021-01-07
03 Acee Lindem
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 …
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
 

2021-01-07
03 Acee Lindem Responsible AD changed to Alvaro Retana
2021-01-07
03 Acee Lindem IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2021-01-07
03 Acee Lindem IESG state changed to Publication Requested from I-D Exists
2021-01-07
03 Acee Lindem IESG process started in state Publication Requested
2021-01-05
03 Acee Lindem
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 …
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
 

2021-01-05
03 Christian Hopps New version available: draft-ietf-lsr-yang-isis-reverse-metric-03.txt
2021-01-05
03 (System) New version accepted (logged-in submitter: Christian Hopps)
2021-01-05
03 Christian Hopps Uploaded new revision
2020-12-20
02 Min Ye Closed request for Last Call review by RTGDIR with state 'Withdrawn'
2020-12-18
02 Christian Hopps New version available: draft-ietf-lsr-yang-isis-reverse-metric-02.txt
2020-12-18
02 (System) New version accepted (logged-in submitter: Christian Hopps)
2020-12-18
02 Christian Hopps Uploaded new revision
2020-12-18
01 Acee Lindem Requested Last Call review by RTGDIR
2020-12-18
01 Acee Lindem Requested Last Call review by RTGDIR
2020-12-16
01 Ladislav Lhotka Request for Last Call review by YANGDOCTORS Completed: Ready with Issues. Reviewer: Ladislav Lhotka. Sent review to list.
2020-12-14
01 Min Ye Assignment of request for Last Call review by RTGDIR to Himanshu Shah was marked no-response
2020-12-06
01 Michael Richardson Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Michael Richardson. Sent review to list.
2020-12-06
01 Min Ye Request for Last Call review by RTGDIR is assigned to Himanshu Shah
2020-12-06
01 Min Ye Request for Last Call review by RTGDIR is assigned to Himanshu Shah
2020-11-30
01 Min Ye Request for Last Call review by RTGDIR is assigned to Michael Richardson
2020-11-30
01 Min Ye Request for Last Call review by RTGDIR is assigned to Michael Richardson
2020-11-30
01 Geoff Huston Assignment of request for Last Call review by RTGDIR to Geoff Huston was rejected
2020-11-30
01 Min Ye Request for Last Call review by RTGDIR is assigned to Geoff Huston
2020-11-30
01 Min Ye Request for Last Call review by RTGDIR is assigned to Geoff Huston
2020-11-30
01 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Ladislav Lhotka
2020-11-30
01 Mehmet Ersue Request for Last Call review by YANGDOCTORS is assigned to Ladislav Lhotka
2020-11-30
01 Acee Lindem IETF WG state changed to In WG Last Call from WG Document
2020-11-30
01 Acee Lindem Requested Last Call review by RTGDIR
2020-11-30
01 Acee Lindem Requested Last Call review by YANGDOCTORS
2020-11-30
01 Acee Lindem Changed consensus to Yes from Unknown
2020-11-30
01 Acee Lindem Intended Status changed to Proposed Standard from None
2020-11-24
01 Christian Hopps Notification list changed to acee@cisco.com because the document shepherd was set
2020-11-24
01 Christian Hopps Document shepherd changed to Acee Lindem
2020-07-28
01 Christian Hopps New version available: draft-ietf-lsr-yang-isis-reverse-metric-01.txt
2020-07-28
01 (System) New version accepted (logged-in submitter: Christian Hopps)
2020-07-28
01 Christian Hopps Uploaded new revision
2020-07-27
00 (System) Document has expired
2020-01-22
00 Christian Hopps This document now replaces draft-hopps-lsr-yang-isis-reverse-metric instead of None
2020-01-22
00 Christian Hopps New version available: draft-ietf-lsr-yang-isis-reverse-metric-00.txt
2020-01-22
00 (System) New version accepted (logged-in submitter: Christian Hopps)
2020-01-22
00 Christian Hopps Uploaded new revision