Skip to main content

A YANG Data Model for MPLS Base
draft-ietf-mpls-base-yang-17

Revision differences

Document history

Date Rev. By Action
2024-01-26
17 Gunter Van de Velde Request closed, assignment withdrawn: Carlos Martínez Last Call OPSDIR review
2024-01-26
17 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'Overtaken by Events': Cleaning up stale OPSDIR queue
2020-12-14
17 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2020-11-20
17 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2020-11-12
17 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2020-11-10
17 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2020-11-10
17 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2020-11-10
17 (System) IANA Action state changed to In Progress from Waiting on Authors
2020-10-29
17 (System) IANA Action state changed to Waiting on Authors from In Progress
2020-10-26
17 (System) RFC Editor state changed to EDIT
2020-10-26
17 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2020-10-26
17 (System) Announcement was received by RFC Editor
2020-10-26
17 (System) IANA Action state changed to In Progress
2020-10-26
17 Cindy Morgan IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2020-10-26
17 Cindy Morgan IESG has approved the document
2020-10-26
17 Cindy Morgan Closed "Approve" ballot
2020-10-26
17 Cindy Morgan Ballot approval text was generated
2020-10-26
17 Cindy Morgan Ballot writeup was changed
2020-10-26
17 Deborah Brungard Ballot approval text was changed
2020-10-26
17 Tarek Saad New version available: draft-ietf-mpls-base-yang-17.txt
2020-10-26
17 (System) New version approved
2020-10-26
17 (System) Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Vishnu Beeram , Kamran Raza , Xufeng Liu
2020-10-26
17 Tarek Saad Uploaded new revision
2020-10-23
16 Robert Wilton
[Ballot comment]
Discuss cleared.

I also have some comments on the YANG module itself:

  feature mpls {
    description
      "Indicates …
[Ballot comment]
Discuss cleared.

I also have some comments on the YANG module itself:

  feature mpls {
    description
      "Indicates support for MPLS switching.";
    reference
      "RFC3031";
  }

Is the MPLS feature really required?  I.e. is it plausible that a device would implement this YANG module without supporting MPLS switching?  If not, then just implementing the module should probably be sufficient without a separate feature.

Alternatively, it might be worth looking at the ISIS YANG module that define a feature to control with ISIS can be administratively controlled.  E.g. draft-ietf-isis-yang-isis-cfg-42, feature admin-control.  On a related point:

    augment /rt:routing:
      +--rw mpls {mpls}?
          ...
          +--rw interface* [name]
            +--rw name                      if:interface-ref
            +--rw enabled?                  boolean
            +--rw maximum-labeled-packet?  uint32

Is the "enabled" leaf definitely required here?  Isn't having the interface under the MPLS list sufficient to indicate that MPLS is enabled?  If you really want this leaf then I would change its name to "enable" rather than "enabled", change it's default to true, and consider putting it under a feature like admin-control from the ISIS YANG module.


    augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route:
      +--ro mpls-enabled?        boolean {mpls}?
      +--ro local-label?          rt-types:mpls-label {mpls}?
      +--ro destination-prefix?  -> ../local-label {mpls}?
      +--ro route-context?        string {mpls}?

Is "local-label" clearly enough associated with MPLS in the IP RIB?  E.g. should this be mpls-local-label, or under an mpls container?
Presumably the mpls-enabled leaf shouldn't appear under the MPLS RIB?  It might be cleaner to split this into two augments, one for the MPLS RIB, and one for other RIBS.


The mpls-operations-type is defined, but not actually used by this module.  I wanted to check that this is expected.  I also note that the operations-type doesn't include a "no-operation" case statement which I thought might potentially be useful (but I'm not an MPLS expert).

Regarding  grouping label-blocks:

Ben's comment is right that the must statements associated with the start-label/end-label have the wrong sense.  There should also only be one of them (since they would always fail/pass in unison), and I would recommend just keeping the end-label must statement.

I wasn't sure whether the unique statement is really helpful.  Am I right in assuming that the blocks should be disjoint and non overlapping? If so, the unique statement doesn't achieve this, and although it could probably be done in a must statement, it would be tricky to express and get right.  However, if this is a constraint then it would certainly be helpful for the description of label-block to mention this.

Regarding grouping rib-active-route-mpls-input:

I know that this has been discussed with yang-doctors and the authors of the base RIB YANG module that is being extended but seeing the YANG I'm not quite sure we have the best outcome, since users of the RPC would be required to specify both destination-address and local-label as input parameters.  Possibly a better choice would to make this a choice so that a client could query either using a destination-address or a local-label (with both using the same type definition)?
2020-10-23
16 Robert Wilton [Ballot Position Update] Position for Robert Wilton has been changed to No Objection from Discuss
2020-10-20
16 Roman Danyliw
[Ballot comment]
Thanks for the clear introduction of how this models was designed (Section 2.2 and 2.3) and builds on prior work.

Thank you for …
[Ballot comment]
Thanks for the clear introduction of how this models was designed (Section 2.2 and 2.3) and builds on prior work.

Thank you for addressing my DISCUSS and COMMENT points.
2020-10-20
16 Roman Danyliw [Ballot Position Update] Position for Roman Danyliw has been changed to No Objection from Discuss
2020-10-19
16 (System) Sub state has been changed to AD Followup from Revised ID Needed
2020-10-19
16 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2020-10-19
16 Tarek Saad New version available: draft-ietf-mpls-base-yang-16.txt
2020-10-19
16 (System) New version approved
2020-10-19
16 (System) Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Xufeng Liu , Kamran Raza , Vishnu Beeram
2020-10-19
16 Tarek Saad Uploaded new revision
2020-09-10
15 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2020-09-10
15 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2020-09-10
15 Robert Wilton
[Ballot discuss]
Hi,

Thank for you this YANG module.  It is great to see IETF progressing publishing more YANG configuration/management models, to thank you for …
[Ballot discuss]
Hi,

Thank for you this YANG module.  It is great to see IETF progressing publishing more YANG configuration/management models, to thank you for the time and effort that you have put into this.

I support Roman's discuss regarding the security considerations, but would also like to add one of my own:

In my experience, having some instance data examples (e.g., see Appendix D of RFC 8022) greatly helps readers understand the structure of the YANG module and get a good feel for how the YANG model is used.  Was adding instance data examples considered for this document?  Do the authors that think it would be possible to add some examples?

I've also added some comments on the YANG model below that probably need to be addressed but I didn't want to overload the main discuss point.

Regards,
Rob
2020-09-10
15 Robert Wilton Ballot discuss text updated for Robert Wilton
2020-09-10
15 Robert Wilton
[Ballot discuss]
Hi,

Thank for you this YANG module.  It is great to see IETF progressing publishing more YANG configuration/management models, to thank you for …
[Ballot discuss]
Hi,

Thank for you this YANG module.  It is great to see IETF progressing publishing more YANG configuration/management models, to thank you for the time and effort that have put into this.

I support Roman's discuss regarding the security considerations, but would also like to add one of my own:

In my experience, having some instance data examples (e.g., see Appendix D of RFC 8022) greatly helps readers understand the structure of the YANG module and get a good feel for how the YANG model is used.  Was adding instance data examples considered for this document?  Do the authors that think it would be possible to add some examples?

I've also added some comments on the YANG model below that probably need to be addressed but I didn't want to overload the main discuss point.

Regards,
Rob
2020-09-10
15 Robert Wilton
[Ballot comment]
I also have some comments on the YANG module itself:

  feature mpls {
    description
      "Indicates support for …
[Ballot comment]
I also have some comments on the YANG module itself:

  feature mpls {
    description
      "Indicates support for MPLS switching.";
    reference
      "RFC3031";
  }

Is the MPLS feature really required?  I.e. is it plausible that a device would implement this YANG module without supporting MPLS switching?  If not, then just implementing the module should probably be sufficient without a separate feature.

Alternatively, it might be worth looking at the ISIS YANG module that define a feature to control with ISIS can be administratively controlled.  E.g. draft-ietf-isis-yang-isis-cfg-42, feature admin-control.  On a related point:

    augment /rt:routing:
      +--rw mpls {mpls}?
          ...
          +--rw interface* [name]
            +--rw name                      if:interface-ref
            +--rw enabled?                  boolean
            +--rw maximum-labeled-packet?  uint32

Is the "enabled" leaf definitely required here?  Isn't having the interface under the MPLS list sufficient to indicate that MPLS is enabled?  If you really want this leaf then I would change its name to "enable" rather than "enabled", change it's default to true, and consider putting it under a feature like admin-control from the ISIS YANG module.


    augment /rt:routing/rt:ribs/rt:rib/rt:routes/rt:route:
      +--ro mpls-enabled?        boolean {mpls}?
      +--ro local-label?          rt-types:mpls-label {mpls}?
      +--ro destination-prefix?  -> ../local-label {mpls}?
      +--ro route-context?        string {mpls}?

Is "local-label" clearly enough associated with MPLS in the IP RIB?  E.g. should this be mpls-local-label, or under an mpls container?
Presumably the mpls-enabled leaf shouldn't appear under the MPLS RIB?  It might be cleaner to split this into two augments, one for the MPLS RIB, and one for other RIBS.


The mpls-operations-type is defined, but not actually used by this module.  I wanted to check that this is expected.  I also note that the operations-type doesn't include a "no-operation" case statement which I thought might potentially be useful (but I'm not an MPLS expert).

Regarding  grouping label-blocks:

Ben's comment is right that the must statements associated with the start-label/end-label have the wrong sense.  There should also only be one of them (since they would always fail/pass in unison), and I would recommend just keeping the end-label must statement.

I wasn't sure whether the unique statement is really helpful.  Am I right in assuming that the blocks should be disjoint and non overlapping? If so, the unique statement doesn't achieve this, and although it could probably be done in a must statement, it would be tricky to express and get right.  However, if this is a constraint then it would certainly be helpful for the description of label-block to mention this.

Regarding grouping rib-active-route-mpls-input:

I know that this has been discussed with yang-doctors and the authors of the base RIB YANG module that is being extended but seeing the YANG I'm not quite sure we have the best outcome, since users of the RPC would be required to specify both destination-address and local-label as input parameters.  Possibly a better choice would to make this a choice so that a client could query either using a destination-address or a local-label (with both using the same type definition)?
2020-09-10
15 Robert Wilton [Ballot Position Update] New position, Discuss, has been recorded for Robert Wilton
2020-09-10
15 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund
2020-09-09
15 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2020-09-09
15 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2020-09-08
15 Erik Kline
[Ballot comment]
[[ nits ]]

[ section 2.2 ]

* "represents support possible" -> "represents support for possible"?

[ section 2.3 ]

* s/Adjecency/Adjacency/

[ …
[Ballot comment]
[[ nits ]]

[ section 2.2 ]

* "represents support possible" -> "represents support for possible"?

[ section 2.3 ]

* s/Adjecency/Adjacency/

[ section 2.5 ]

* "Next-hop acts as primary traffic carrying."

  May read as slightly awkward.  Consider perhaps:

  "Next-hop acts as primary for carrying traffic."

  ...or something.

* "aaugmentation" -> "augmentation"
2020-09-08
15 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2020-09-08
15 Benjamin Kaduk
[Ballot comment]
Before getting into the section-by-section comments, I'll note that
there are a few things in the YANG module itself that seem awry to …
[Ballot comment]
Before getting into the section-by-section comments, I'll note that
there are a few things in the YANG module itself that seem awry to my
untrained eye.

Section 2.2

  The 'ietf-mpls' module defines the following identities:
  [...]
  label-block-alloc-mode:

(nit?) We also define two identities based on this one; is the list of
"defines the following identities" supposed to be comprehensive (vs.
"high-level")?

  nhlfe-multiple-contents:

      A YANG grouping that describes a set of NHLFE(s) and their
      associated parameters as described in the MPLS architecture
      document [RFC3031].

(editorial) Perhaps we could say a few more words about how these NHLFEs
are related/why they are being grouped together?  (I do not recall such
grouping being specifically covered in 3031.)

  rib-mpls-properties:

      A YANG grouping for the augmentation of MPLS label forwarding data
      to the generic RIB as defined in [RFC3031].

nit(?): the "as defined in " seems more applicable to "MPLS
label forwarding data" than "generic RIB".

Section 2.3

  o  routes that cross-connect an MPLS local label to a Layer-3
      adjacency or interface - such as MPLS Segment-Routing (SR)
      Adjecency Segments (Adj-SIDs), SR MPLS Binding SIDs, etc. as
      defined in [RFC8402].

nit(?): is there a semantic difference between "MPLS SR" and "SR MPLS"
for the two types of route mentioned?

Section 2.5

  identity label-block-alloc-mode {
    description
      "Base identity label-block allocation mode.";
  }

nit: missing "for".

  grouping nhlfe-multiple-contents {
    description
      "MPLS NHLFE contents.";

nit: this description feels a little terse; is this the "generic" case
or something similar?

    leaf index {
      type string;
      description
        "A user-specified identifier utilised to uniquely
        reference the next-hop entry in the next-hop list.
        The value of this index has no semantic meaning
        other than for referencing the entry.";
    }
    leaf backup-index {
      type string;
      description
        "A user-specified identifier utilised to uniquely
        reference the backup next-hop entry in the NHLFE list.
        The value of this index has no semantic meaning
        other than for referencing the entry.";
    }

I'm not sure I understand the semantics, here -- does 'index'
authoritatively name the current entry with 'backup-index' being
effectively a pointer to a different entry?  I don't see any leafs of
type string in, e.g., rt-types:mpls-label-stack that this would be
referring to.  If the backup-index is indeed just a pointer to a
different entry, why is the string name used instead of a YANG
reference?

Also, what's a good reference for "backup" MPLS next-hops?  I don't see
the string "backup" in either RFC 3031 or 3032.

  grouping interfaces-mpls {
      [...]
      leaf name {
        type if:interface-ref;
        description
          "The name of a configured MPLS interface.";
      }

pedantic nit: is this really a "name"?

        leaf start-label {
          type rt-types:mpls-label;
          must '. >= ../end-label' {
            error-message "The start-label must be less than or equal "
                        + "to end-label";
          }

I think the sense of the YANG comparator is reversed, for both
start-label (this) and end-label (not quoted).  (Also, IIUC, it's
redundant to specify both, but harmless.)

        leaf free-labels-count {
          when "derived-from-or-self(../block-allocation-mode, "
            + "'mpls:label-block-alloc-mode-manager')";
          type yang:counter32;
          config false;
          description
            "Label-block free labels count.";

I think that counter32 is semantically the wrong type, here (and for
inuse-labels-count as well) -- IIRC the 'counter' types are for thigns
like counting a particular type of event, and only ever monotonically
increase.  Even if the free label count behaves monotonically (which is
far from clear to me), wouldn't it be decreasing, not increasing?

Also, won't it always be true that free-labels-count +
inuse-labels-count == end-label - start-label + 1?  I'm not sure why
there's a need to introduce such redundant fields and the corresponding
risk of internal inconsistency among them.

    uses rib-mpls-properties {
      /* MPLS AF aaugmentation to native MPLS RIB */

nit: s/aaugmentation/augmentation/

    uses rib-active-route-mpls-input {
      /* MPLS AF aaugmentation to native MPLS RIB */

(ditto)

Section 4

Why is the rt:simple-next-hop augmentation listed but not the
rt:next-hop-list augmentation?  IIUC they are functionally identical in
terms of the sensitivity of information content.

Also, it seems like the augmented RPC output is similarly sensitive to
the readable nodes that are already mentioned.

It looks like the main writeable nodes are the global
configuration/state, and while it's perhaps defensible to say that these
particular nodes are not sensitive, I did want to check what the
behavior would be if (e.g.) the label-blocks subtree was overwritten.
Would things just silently start using the new label block and keep
working?

Perhaps it would be too banal, but should we reference the security
considerations of 3031/3032 as applying to MPLS usage?

Section 7.1

It's not clear that we reference RFC 8402 in a normative manner
anywhere.

Section 7.2

I agree with the document shepherd that RFCs 3031 and 3032 naturally
would be classified as normative references.  Similarly, RFC 7424 is
refrenced by the YANG module itself, which usually indicates a normative
reference.
2020-09-08
15 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2020-09-08
15 Roman Danyliw
[Ballot discuss]
** Section 11.  Thanks for enumerating the sensitive read operations.  It looks like the sensitive writes aren’t described.  Wouldn’t it be a problem …
[Ballot discuss]
** Section 11.  Thanks for enumerating the sensitive read operations.  It looks like the sensitive writes aren’t described.  Wouldn’t it be a problem for arbitrary writes to occur to /rt:routing/mpls/*?  I recommend using the "template language" of "There are a number of data nodes defined in these YANG modules that are writable/creatable/deletable ... These are the subtrees and data nodes and their sensitivity/vulnerability:" to provide this easy fix.
2020-09-08
15 Roman Danyliw
[Ballot comment]
Thanks for the clear introduction of how this models was designed (Section 2.2 and 2.3) and builds on prior work.

Editorial nits:
-- …
[Ballot comment]
Thanks for the clear introduction of how this models was designed (Section 2.2 and 2.3) and builds on prior work.

Editorial nits:
-- Section 1.  Editorial.  There is a tool chain artifact which is leaving “{!RFC8349}” in the text.

-- Section 2.3.  Typo. s/Adjecency/Adjacency/

-- Section 2.5. Typo. s/aaugmentation/augmentation/
2020-09-08
15 Roman Danyliw [Ballot Position Update] New position, Discuss, has been recorded for Roman Danyliw
2020-09-07
15 Murray Kucherawy
[Ballot comment]
In Section 3, it says: "This document registers the following URIs in the IETF XML registry."  I think it should say "This document …
[Ballot comment]
In Section 3, it says: "This document registers the following URIs in the IETF XML registry."  I think it should say "This document registers the following URIs in the 'ns' sub-registry of the IETF XML registry."

I can relate to Barry's comment about "module" vs. "model".  I think I understand the difference, but I've run into this with every YANG document that's come up lately:  I think the "model" is a formal expression for a configuration of some network component, while "module" is a chunk of YANG code that describes that model, which can be evaluated (a la ABNF) against some input to validate a configuration.

I also concur with Barry's remark about BCP 14 being cited when it's not used anywhere.  This should be cleaned up (by either using it, or removing the citation).  I'm tempted to DISCUSS this, but I assume since it's easily resolved that that'll happen in due course.
2020-09-07
15 Murray Kucherawy [Ballot Position Update] New position, No Objection, has been recorded for Murray Kucherawy
2020-09-04
15 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document. I really appreciated the clear and sharp introduction. I am also trusting the Management …
[Ballot comment]
Thank you for the work put into this document. I really appreciated the clear and sharp introduction. I am also trusting the Management and routing ADs for the accuracy of the YANG module.

Please find below two minors nits

I hope that this helps to improve the document,

Regards,

-éric

== NITS ==

-- Section 1 --
s/A core routing data model is defined/A core routing YANG data model is defined/

-- Section 5 --
Naming all design team members could be more friendly.
2020-09-04
15 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2020-09-03
15 Barry Leiba
[Ballot comment]
The document sometimes says “YANG model” and sometimes “YANG module”.  It should use the correct term and be consistent, no?

I note that …
[Ballot comment]
The document sometimes says “YANG model” and sometimes “YANG module”.  It should use the correct term and be consistent, no?

I note that there is BCP 14 boilerplate here but no BCP 14 key words in the document.  The shepherd writeup notes that also and says that the shepherd wanted to discuss this with the authors... but there is no resolution to that.  Did the shepherd discuss it with the authors?  Should some “must”s become “MUST”s?  Or should the boilerplate and references be removed?

— Section 1 —

  The MPLS base model also defines a new instance of the generic RIB
  model as defined in {!RFC8349}} to store native MPLS routes.

What is the notation around RFC8349?  Does it mean something, or is it a markup artifact that needs to be fixed during editing?
2020-09-03
15 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2020-08-31
15 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2020-08-27
15 Cindy Morgan Placed on agenda for telechat - 2020-09-10
2020-08-27
15 Deborah Brungard IESG state changed to IESG Evaluation from Waiting for Writeup
2020-08-27
15 Deborah Brungard Ballot has been issued
2020-08-27
15 Deborah Brungard [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard
2020-08-27
15 Deborah Brungard Created "Approve" ballot
2020-08-27
15 Deborah Brungard Ballot writeup was changed
2020-08-20
15 Gyan Mishra Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Gyan Mishra. Sent review to list.
2020-08-19
15 (System) IESG state changed to Waiting for Writeup from In Last Call
2020-08-17
15 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2020-08-17
15 Tarek Saad New version available: draft-ietf-mpls-base-yang-15.txt
2020-08-17
15 (System) New version accepted (logged-in submitter: Tarek Saad)
2020-08-17
15 Tarek Saad Uploaded new revision
2020-08-17
14 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2020-08-17
14 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-mpls-base-yang-14. 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-mpls-base-yang-14. If any part of this review is inaccurate, please let us know.

The IANA Services 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-mpls
URI: urn:ietf:params:xml:ns:yang:ietf-mpls
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. Expert review will need to be completed before your document can be approved for publication as an RFC.

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-mpls
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-mpls
Prefix: ietf-mpls
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 Services 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
Senior IANA Services Specialist
2020-08-13
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2020-08-13
14 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martínez
2020-08-10
14 Derrell Piper Request for Last Call review by SECDIR Completed: Ready. Reviewer: Derrell Piper. Sent review to list.
2020-08-06
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Derrell Piper
2020-08-06
14 Tero Kivinen Request for Last Call review by SECDIR is assigned to Derrell Piper
2020-08-06
14 Jean Mahoney Request for Last Call review by GENART is assigned to Gyan Mishra
2020-08-06
14 Jean Mahoney Request for Last Call review by GENART is assigned to Gyan Mishra
2020-08-05
14 Cindy Morgan IANA Review state changed to IANA - Review Needed
2020-08-05
14 Cindy Morgan
The following Last Call announcement was sent out (ends 2020-08-19):

From: The IESG
To: IETF-Announce
CC: Loa Andersson , mpls@ietf.org, db3546@att.com, draft-ietf-mpls-base-yang@ietf.org, …
The following Last Call announcement was sent out (ends 2020-08-19):

From: The IESG
To: IETF-Announce
CC: Loa Andersson , mpls@ietf.org, db3546@att.com, draft-ietf-mpls-base-yang@ietf.org, mpls-chairs@ietf.org, loa@pi.nu
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (A YANG Data Model for MPLS Base) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'A YANG Data Model for MPLS Base'
  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 2020-08-19. 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 contains a specification of the MPLS base YANG model.
  The MPLS base YANG model serves as a base framework for configuring
  and managing an MPLS switching subsystem on an MPLS-enabled router.
  It is expected that other MPLS YANG models (e.g.  MPLS Label Switched
  Path (LSP) Static, LDP or RSVP-TE YANG models) will augment the MPLS
  base YANG model.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-mpls-base-yang/



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




2020-08-05
14 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2020-08-05
14 Deborah Brungard Last call was requested
2020-08-05
14 Deborah Brungard Ballot approval text was generated
2020-08-05
14 Deborah Brungard Ballot writeup was generated
2020-08-05
14 Deborah Brungard IESG state changed to Last Call Requested from Publication Requested
2020-08-05
14 Deborah Brungard Last call announcement was changed
2020-08-03
14 Ron Bonica Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Ron Bonica. Sent review to list.
2020-07-30
14 Min Ye Request for Last Call review by RTGDIR is assigned to Ron Bonica
2020-07-30
14 Min Ye Request for Last Call review by RTGDIR is assigned to Ron Bonica
2020-07-28
14 Deborah Brungard Requested Last Call review by RTGDIR
2020-06-30
14 Loa Andersson
                The MPLS working group request that

                    draft-ietf-mpls-base-yang …
                The MPLS working group request that

                    draft-ietf-mpls-base-yang

            is published a an RFC on the standards track


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


  As a YANG model this document should be published as a Standard track RFC.

 

(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 MPLS base model augments the core routing model defined in
  RFC8349 with additional data specific to MPLS technology  as described
  in MPLS Architecture RFC3031.
  RFC8349 requires specific YANG augmentations by any such routing protocol
  and these have been included.

  The MPLS base model serves as a basis for future development of MPLS
  data models covering specific MPLS feature(s) and sub-system(s). 
  The main purpose of the MPLS base is to provide building blocks for more
  complicated and data models, including different control plane protocols,
  and advanced MPLS functions.

  To this end, it is expected that the MPLS base data model will be
  augmented by other modules developed at IETF (e.g. by MPLS and TEAS
  working groups).


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

  The working group is solidly behind that the document.

Document Quality:

  We understand that there are implementations and intents to implement
  this YANG model, from a large number of vendors. However we have not
  earlier documented implementations or intent to implement.

  An implementation poll has therefore been sent to the working group
  mailing list.

  Tom Petch has done very thorough review, and had a positive influence
  on the document.

  THe document has been reviewed by the Yang Doctors several times.

Personnel:

  Loa Andersson is the Document Shepherd.
  Deborah Brungard 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.

  When this document came online the Shepherd reviewed, but at that time it
  was not clear who the shepherd would be so this was a wg chair review to look
  at what was new.
  The shepherd was appointed just prior to the wglc, but reviewed the document
  at wgap and wglc.

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

  No such concerns.

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

  The document has been reviewed bu the YANG doctors on the request of the authors
  prior to wgap and on the request of the Shepherd (via the authors) at wglc.

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

  No such concerns-

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

  All the authors and contributors have confirmed that that they are unaware
  of any IPRs.

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

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

  The working group stands behinds this document.

(10) 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 such threats.

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

  The Shepherd has not identified any other nits than what the nits tool identify
  there is a BCP 14 boiler plate in section 1.1 Terminology, but the rest of the
  document does not use any requirement language.

  Note: the Shepherd wants to discuss this with the authors since there are
  lower case musts in YANG Module, and the shepherd does not understand if
  they are equivalent to BCP 14 language.

(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 YANG doctors have reviewed the document at several occasion. No further formal
  reviews are required.

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

    Yes - all references are split into normative and informative references,
    though the Shepherd would like to understand why RFC 3031 is an informative
    reference. Especially since the definition of MPLS push, pop and swap operations
    comes from RFC 3031.
    Same goes for RFC 3032 that defines the MPLS Label Stack encoding.

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

  All the normative references are Standard Track RFCs or BCPs.


(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 downward references.

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

  There will be n o status change of any other RFC when this documents is published. 

  However the development of this draft has resulted in an errata against  RFC8349.
  For route entries that appear IPv4/IPv6 RIBs, those are keyed by address and having
  the leaf "destination-address" makes sense. However, route entries that appear in MPLS RIB
  are keyed by MPLS local label, so it would be misleading to have a leaf named 'destination-address'
  for them. Hence, an errata to relax the 'MUST' in RFC8349 will be filed by the authors of this
  document.

(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 section has been reviewed several time during the development of the
  document.

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

  No such registries created.

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

  The YANG module is checked every time the document is posted.
  The YANG module is published on github and reviews, issues are tracked under the project.
  Pyang, yanglint, and yangvalidator tools were all used to ensure the module compiles and is free of errors.
  Pyang --ietf is used to ensure YANG module is compliant with IETF RFC YANG styles.

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

  All the tools mentioned above were used to validate the YANG module is free from errors.
  YANG module is compliant with NMDA

2020-06-30
14 Loa Andersson Responsible AD changed to Deborah Brungard
2020-06-30
14 Loa Andersson IETF WG state changed to Submitted to IESG for Publication from Waiting for WG Chair Go-Ahead
2020-06-30
14 Loa Andersson IESG state changed to Publication Requested from I-D Exists
2020-06-30
14 Loa Andersson IESG process started in state Publication Requested
2020-06-30
14 Loa Andersson Changed consensus to Yes from Unknown
2020-06-30
14 Loa Andersson Intended Status changed to Proposed Standard from None
2020-06-30
14 Loa Andersson
                The MPLS working group request that

                    draft-ietf-mpls-base-yang …
                The MPLS working group request that

                    draft-ietf-mpls-base-yang

            is published a an RFC on the standards track


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


  As a YANG model this document should be published as a Standard track RFC.

 

(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 MPLS base model augments the core routing model defined in
  RFC8349 with additional data specific to MPLS technology  as described
  in MPLS Architecture RFC3031.
  RFC8349 requires specific YANG augmentations by any such routing protocol
  and these have been included.

  The MPLS base model serves as a basis for future development of MPLS
  data models covering specific MPLS feature(s) and sub-system(s). 
  The main purpose of the MPLS base is to provide building blocks for more
  complicated and data models, including different control plane protocols,
  and advanced MPLS functions.

  To this end, it is expected that the MPLS base data model will be
  augmented by other modules developed at IETF (e.g. by MPLS and TEAS
  working groups).


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

  The working group is solidly behind that the document.

Document Quality:

  We understand that there are implementations and intents to implement
  this YANG model, from a large number of vendors. However we have not
  earlier documented implementations or intent to implement.

  An implementation poll has therefore been sent to the working group
  mailing list.

  Tom Petch has done very thorough review, and had a positive influence
  on the document.

  THe document has been reviewed by the Yang Doctors several times.

Personnel:

  Loa Andersson is the Document Shepherd.
  Deborah Brungard 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.

  When this document came online the Shepherd reviewed, but at that time it
  was not clear who the shepherd would be so this was a wg chair review to look
  at what was new.
  The shepherd was appointed just prior to the wglc, but reviewed the document
  at wgap and wglc.

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

  No such concerns.

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

  The document has been reviewed bu the YANG doctors on the request of the authors
  prior to wgap and on the request of the Shepherd (via the authors) at wglc.

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

  No such concerns-

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

  All the authors and contributors have confirmed that that they are unaware
  of any IPRs.

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

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

  The working group stands behinds this document.

(10) 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 such threats.

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

  The Shepherd has not identified any other nits than what the nits tool identify
  there is a BCP 14 boiler plate in section 1.1 Terminology, but the rest of the
  document does not use any requirement language.

  Note: the Shepherd wants to discuss this with the authors since there are
  lower case musts in YANG Module, and the shepherd does not understand if
  they are equivalent to BCP 14 language.

(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 YANG doctors have reviewed the document at several occasion. No further formal
  reviews are required.

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

    Yes - all references are split into normative and informative references,
    though the Shepherd would like to understand why RFC 3031 is an informative
    reference. Especially since the definition of MPLS push, pop and swap operations
    comes from RFC 3031.
    Same goes for RFC 3032 that defines the MPLS Label Stack encoding.

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

  All the normative references are Standard Track RFCs or BCPs.


(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 downward references.

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

  There will be n o status change of any other RFC when this documents is published. 

  However the development of this draft has resulted in an errata against  RFC8349.
  For route entries that appear IPv4/IPv6 RIBs, those are keyed by address and having
  the leaf "destination-address" makes sense. However, route entries that appear in MPLS RIB
  are keyed by MPLS local label, so it would be misleading to have a leaf named 'destination-address'
  for them. Hence, an errata to relax the 'MUST' in RFC8349 will be filed by the authors of this
  document.

(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 section has been reviewed several time during the development of the
  document.

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

  No such registries created.

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

  The YANG module is checked every time the document is posted.
  The YANG module is published on github and reviews, issues are tracked under the project.
  Pyang, yanglint, and yangvalidator tools were all used to ensure the module compiles and is free of errors.
  Pyang --ietf is used to ensure YANG module is compliant with IETF RFC YANG styles.

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

  All the tools mentioned above were used to validate the YANG module is free from errors.
  YANG module is compliant with NMDA

2020-05-13
14 Loa Andersson Notification list changed to Loa Andersson <loa@pi.nu>, mpls-chairs@ietf.org, draft-ietf-mpls-base-yang@ietf.org from Loa Andersson <loa@pi.nu>
2020-05-13
14 Loa Andersson
                The MPLS working group request that

                    draft-ietf-mpls-base-yang …
                The MPLS working group request that

                    draft-ietf-mpls-base-yang

            is published a an RFC on the standards track


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


  As a YANG model this document should be published as a Standard track RFC.

 

(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 MPLS base model augments the core routing model defined in
  RFC8349 with additional data specific to MPLS technology  as described
  in MPLS Architecture RFC3031.
  RFC8349 requires specific YANG augmentations by any such routing protocol
  and these have been included.

  The MPLS base model serves as a basis for future development of MPLS
  data models covering specific MPLS feature(s) and sub-system(s). 
  The main purpose of the MPLS base is to provide building blocks for more
  complicated and data models, including different control plane protocols,
  and advanced MPLS functions.

  To this end, it is expected that the MPLS base data model will be
  augmented by other modules developed at IETF (e.g. by MPLS and TEAS
  working groups).


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

  The working group is solidly behind that the document.

Document Quality:

  We understand that there are implementations and intents to implement
  this YANG model, from a large number of vendors. However we have not
  earlier documented implementations or intent to implement.

  An implementation poll has therefore been sent to the working group
  mailing list.

  Tom Petch has done very thorough review, and had a positive influence
  on the document.

  THe document has been reviewed by the Yang Doctors several times.

Personnel:

  Loa Andersson is the Document Shepherd.
  Deborah Brungard 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.

  When this document came online the Shepherd reviewed, but at that time it
  was not clear who the shepherd would be so this was a wg chair review to look
  at what was new.
  The shepherd was appointed just prior to the wglc, but reviewed the document
  at wgap and wglc.

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

  No such concerns.

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

  The document has been reviewed bu the YANG doctors on the request of the authors
  prior to wgap and on the request of the Shepherd (via the authors) at wglc.

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

  No such concerns-

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

  All the authors and contributors have confirmed that that they are unaware
  of any IPRs.

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

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

  The working group stands behinds this document.

(10) 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 such threats.

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

  The Shepherd has not identified any other nits than what the nits tool identify
  there is a BCP 14 boiler plate in section 1.1 Terminology, but the rest of the
  document does not use any requirement language.

  Note: the Shepherd wants to discuss this with the authors since there are
  lower case musts in YANG Module, and the shepherd does not understand if
  they are equivalent to BCP 14 language.

(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 YANG doctors have reviewed the document at several occasion. No further formal
  reviews are required.

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

    Yes - all references are split into normative and informative references,
    though the Shepherd would like to understand why RFC 3031 is an informative
    reference. Especially since the definition of MPLS push, pop and swap operations
    comes from RFC 3031.
    Same goes for RFC 3032 that defines the MPLS Label Stack encoding.

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

  All the normative references are Standard Track RFCs or BCPs.


(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 downward references.

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

  There will be n o status change of any other RFC when this documents is published. 

(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 section has been reviewed several time during the development of the
  document.

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

  No such registries created.

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

  The YANG module is checked every time the document is posted.
  The YANG module is published on github and reviews, issues are tracked under the project.
  Pyang, yanglint, and yangvalidator tools were all used to ensure the module compiles and is free of errors.
  Pyang --ietf is used to ensure YANG module is compliant with IETF RFC YANG styles.

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

  All the tools mentioned above were used to validate the YANG module is free from errors.
  YANG module is compliant with NMDA

2020-05-13
14 Loa Andersson
                The MPLS working group request that

                    draft-ietf-mpls-base-yang …
                The MPLS working group request that

                    draft-ietf-mpls-base-yang

            is published a an RFC on the standards track


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


  As a YANG model this document should be published as a Standard track RFC.

 

(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 MPLS base model augments the core routing model defined in
  RFC8349 with additional data specific to MPLS technology  as described
  in MPLS Architecture RFC3031.
  RFC8349 requires specific YANG augmentations by any such routing protocol
  and these have been included.

  The MPLS base model serves as a basis for future development of MPLS
  data models covering specific MPLS feature(s) and sub-system(s). 
  The main purpose of the MPLS base is to provide building blocks for more
  complicated and data models, including different control plane protocols,
  and advanced MPLS functions.

  To this end, it is expected that the MPLS base data model will be
  augmented by other modules developed at IETF (e.g. by MPLS and TEAS
  working groups).


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

  The working group is solidly behind that the document.

Document Quality:

  We understand that there are implementations and intents to implement
  this YANG model, from a large number of vendors. However we have not
  earlier documented implementations or intent to implement.

  An implementation poll has therefore been sent to the working group
  mailing list.

  Tom Petch has done very thorough review, and had a positive influence
  on the document.

  THe document has been reviewed by the Yang Doctors several times.

Personnel:

  Loa Andersson is the Document Shepherd.
  Deborah Brungard 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.

  When this document came online the Shepherd reviewed, but at that time it
  was not clear who the shepherd would be so this was a wg chair review to look
  at what was new.
  The shepherd was appointed just prior to the wglc, but reviewed the document
  at wgap and wglc.

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

  No such concerns.

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

  The document has been reviewed bu the YANG doctors on the request of the authors
  prior to wgap and on the request of the Shepherd (via the authors) at wglc.

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

  No such concerns-

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

  All the authors and contributors have confirmed that that they are unaware
  of any IPRs.

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

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

  The working group stands behinds this document.

(10) 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 such threats.

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

  The Shepherd has not identified any other nits than what the nits tool identify
  there is a BCP 14 boiler plate in section 1.1 Terminology, but the rest of the
  document does not use any requirement language.

  Note: the Shepherd wants to discuss this with the authors since there are
  lower case musts in YANG Module, and the shepherd does not understand if
  they are equivalent to BCP 14 language.

(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 YANG doctors have reviewed the document at several occasion. No further formal
  reviews are required.

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

    Yes - all references are split into normative and informative references,
    though the Shepherd would like to understand why RFC 3031 is an informative
    reference. Especially since the definition of MPLS push, pop and swap operations
    comes from RFC 3031.
    Same goes for RFC 3032 that defines the MPLS Label Stack encoding.

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

  All the normative references are Standard Track RFCs or BCPs.


(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 downward references.

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

  There will be n o status change of any other RFC when this documents is published. 

(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 section has been reviewed several time during the development of the
  document.

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

  No such registries created.

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

  The YANG module is checked every time the document is posted.
  The YANG module is published on gihub and reviews, issues are tracked under the project.
  Pyang, yanglint, and yangvalidator tools were all used to ensure the module compiles and is free of errors.
  Pyang --ietf is used to ensure YANG module is compliant with IETF RFC YANG styles.

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

  All the tools mentioned above were used to validate the YANG module is free from errors.
  YANG module is compliant with NMDA

2020-05-07
14 Loa Andersson
                The MPLS working group request that

                    draft-ietf-mpls-base-yang …
                The MPLS working group request that

                    draft-ietf-mpls-base-yang

            is published a an RFC on the standards track


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


  As a YANG model this document should be published as a Standard track RFC.

 

(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 MPLS base model augments the core routing model defined in
  RFC8349 with additional data specific to MPLS technology  as described
  in MPLS Architecture RFC3031.
  RFC8349 requires specific YANG augmentations by any such routing protocol
  and these have been included.

  The MPLS base model serves as a basis for future development of MPLS
  data models covering specific MPLS feature(s) and sub-system(s). 
  The main purpose of the MPLS base is to provide building blocks for more
  complicated and data models, including different control plane protocols,
  and advanced MPLS functions.

  To this end, it is expected that the MPLS base data model will be
  augmented by other modules developed at IETF (e.g. by MPLS and TEAS
  working groups).


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

  The working group is solidly behind that the document.

Document Quality:

  We understand that there are implementations and intents to implement
  this YANG model, from a large number of vendors. However we have not
  earlier documented implementations or intent to implement.

  An implementation poll has therefore been sent to the working group
  mailing list.

  Tom Petch has done very thorough review, and had a positive influence
  on the document.

  THe document has been reviewed by the Yang Doctors several times.

Personnel:

  Loa Andersson is the Document Shepherd.
  Deborah Brungard 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.

  When this document came online the Shepherd reviewed, but at that time it
  was not clear who the shepherd would be so this was a wg chair review to look
  at what was new.
  The shepherd was appointed just prior to the wglc, but reviewed the document
  at wgap and wglc.

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

  No such concerns.

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

  The document has been reviewed bu the YANG doctors on the request of the authors
  prior ti wgap and on the request of the Shepherd (via the authors) at wglc.

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

  No such concerns-

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

  All the authors and contributors have confirmed that that they are unaware
  of any IPRs.

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

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

  The working group stands behinds this document.

(10) 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 such threats.

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

  The Shepherd has not identified any other nits than what the nits toll identify
  there is a BCP 14 boiler plate in section 1.1 Terminology, but the rest of the
  document does not use any requirement language.

  Note: the Shepherd wants to discuss this with the authors since there are
  lower case musts in YANG Module, and the shepherd does not understand if
  they are equivalent to BCP 14 language.

(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 YANG doctors have reviewed the document at several occasion. No further formal
  reviews are required.

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

    Yes - all references are split into normative and informative references,
    though the Shepherd would like to understand why RFC 3031 is an informative
    reference. Especially since the definition of MPLS push, pop and swap operations
    comes from RFC 3031.
    Same goes for RFC 3032 that defines the MPLS Label Stack encoding.

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

  All the normative references are Standard Track RFCs or BCPs.


(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 downward references.

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

  There will be n o stauts change of any other RFC when this documents is published. 

(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 section has been reviewed several time during the development of the
  document.

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

  No such registries created.

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

  The YANG module is checked automatically every time the document is posted.
  Need help to fill in additional info

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

  Need help to fill in this info.

2020-05-07
14 Loa Andersson
                The MPLS working group request that

                    draft-ietf-mpls-base-yang …
                The MPLS working group request that

                    draft-ietf-mpls-base-yang

            is published a an RFC on the standards track


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


  As a YANG model this document should be published as a Stardard track RFC.

 

(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 MPLS base model augments the core routing model defined in
  RFC8349 with additional data specific to MPLS technology  as described
  in MPLS Architecture RFC3031.
  RFC8349 requires specific YANG augmentations by any such routing protocol
  and these have been included.

  The MPLS base model serves as a basis for future development of MPLS
  data models covering specific MPLS feature(s) and sub-system(s). 
  The main purpose of the MPLS base is to provide building blocks for more
  complicated and data models, including different control plane protocols,
  and advanced MPLS functions.

  To this end, it is expected that the MPLS base data model will be
  augmented by other modules developed at IETF (e.g. by MPLS and TEAS
  working groups).


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

  The working group is solidly behind that the document.

Document Quality:

  We understand that there are implementations and intents to implement
  this YANG model, from a large number of vendors. However we have not
  earlier documented implementations or intent to implement.

  An implementation poll has therefore been sent to the working group
  mailing list.

  Tom Petch has done very thorough review, and had a positive influence
  on the document.

  THe document has been reviewed by the Yang Doctors several times.

Personnel:

  Loa Andersson is the Document Shepherd.
  Deborah Brungard 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.

  When this document came online the Shepherd reviewed, but at that time it
  was not clear who the shepherd would be so this was a wg chair review to look
  at what was new.
  The shepherd was appointed just prior to the wglc, but reviewed the document
  at wgap and wglc.

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

  No such concerns.

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

  The document has been reviewed bu the YANG doctors on the request of the authors
  prior ti wgap and on the request of the Shepherd (via the authors) at wglc.

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

  No such concerns-

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

  All the authors and contributors have confirmed that that they are unaware
  of any IPRs.

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

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

  The working group stands behinds this document.

(10) 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 such threats.

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

  The Shepherd has not identified any other nits than what the nits toll identify
  there is a BCP 14 boiler plate in section 1.1 Terminology, but the rest of the
  document does not use any requirement language.

  Note: the Shepherd wants to discuss this with the authors since there are
  lower case musts in YANG Module, and the shepherd does not understand if
  they are equivalent to BCP 14 language.

(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 YANG doctors have reviewed the document at several occasion. No further formal
  reviews are required.

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

    Yes - all references are split into normative and informative references,
    though the Shepherd would like to understand why RFC 3031 is an informative
    reference. Especially since the definition of MPLS push, pop and swap operations
    comes from RFC 3031.
    Same goes for RFC 3032 that defines the MPLS Label Stack encoding.

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

  All the normative references are Standard Track RFCs or BCPs.


(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 downward references.

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

  There will be n o stauts change of any other RFC when this documents is published. 

(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 section has been reviewed several time during the development of the
  document.

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

  No such registries created.

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

  The YANG module is checked automatically every time the document is posted.
  Need help to fill in additional info

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

  Need help to fill in this info.

2020-05-07
14 Loa Andersson
                The MPLS working group request that

                    draft-ietf-mpls-base-yang …
                The MPLS working group request that

                    draft-ietf-mpls-base-yang

            is published a an RFC on the standards track


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


  As a YANG model this document should be published as a Stardard track RFC.

 

(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:

  A core routing data model is defined in RFC 8349, and it provides a
  basis for the development of data models for routing protocols.  The
  MPLS base model augments core routing data model with additional data
  specific to MPLS technology as described in the MPLS architecture
  document RFC3031.

  The MPLS base model serves as a basis for future development of MPLS
  data models covering specific MPLS feature(s) and sub-system(s). 
  The main purpose of the MPLS base is to provide building blocks for more
  complicated and data models, including different control plane protocols,
  and advanced MPLS functions.

  To this end, it is expected that the MPLS base data model will be
  augmented by other modules developed at IETF (e.g. by MPLS and TEAS
  working groups).


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

  The working group is solidly behind that the document.

Document Quality:

  We understand that there are implementations and intents to implement
  this YANG model, from a large number of vendors. However we have not
  earlier documented implementations or intent to implement.

  An implementation poll has therefore been sent to the working group
  mailing list.

  Tom Petch has done very thorough review, and had a positive influence
  on the document.

  THe document has been reviewed by the Yang Doctors several times.

Personnel:

  Loa Andersson is the Document Shepherd.
  Deborah Brungard 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.

  When this document came online the Shepherd reviewed, but at that time it
  was not clear who the shepherd would be so this was a wg chair review to look
  at what was new.
  The shepherd was appointed just prior to the wglc, but reviewed the document
  at wgap and wglc.

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

  No such concerns.

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

  The document has been reviewed bu the YANG doctors on the request of the authors
  prior ti wgap and on the request of the Shepherd (via the authors) at wglc.

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

  No such concerns-

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

  All the authors and contributors have confirmed that that they are unaware
  of any IPRs.

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

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

  The working group stands behinds this document.

(10) 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 such threats.

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

  The Shepherd has not identified any other nits than what the nits toll identify
  there is a BCP 14 boiler plate in section 1.1 Terminology, but the rest of the
  document does not use any requirement language.

  Note: the Shepherd wants to discuss this with the authors since there are
  lower case musts in YANG Module, and the shepherd does not understand if
  they are equivalent to BCP 14 language.

(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 YANG doctors have reviewed the document at several occasion. No further formal
  reviews are required.

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

    Yes - all references are split into normative and informative references,
    though the Shepherd would like to understand why RFC 3031 is an informative
    reference. Especially since the definition of MPLS push, pop and swap operations
    comes from RFC 3031.
    Same goes for RFC 3032 that defines the MPLS Label Stack encoding.

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

  All the normative references are Standard Track RFCs or BCPs.


(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 downward references.

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

  There will be n o stauts change of any other RFC when this documents is published. 

(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 section has been reviewed several time during the development of the
  document.

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

  No such registries created.

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

  The YANG module is checked automatically every time the document is posted.
  Need help to fill in additional info

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

  Need help to fill in this info.

2020-05-01
14 Loa Andersson
                The MPLS working group request that

                    draft-ietf-mpls-base-yang …
                The MPLS working group request that

                    draft-ietf-mpls-base-yang

            is published a an RFC on the standards track


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


  As a YANG model this document should be published as a Stardard track RFC.

 

(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:

  A core routing data model is defined in RFC 8349, and it provides a
  basis for the development of data models for routing protocols.  The
  MPLS base model augments core routing data model with additional data
  specific to MPLS technology as described in the MPLS architecture
  document RFC3031.

  The MPLS base model serves as a basis for future development of MPLS
  data models covering specific MPLS feature(s) and sub-system(s). 
  The main purpose of the MPLS base is to provide building blocks for more
  complicated and data models, including different control plane protocols,
  and advanced MPLS functions.

  To this end, it is expected that the MPLS base data model will be
  augmented by other modules developed at IETF (e.g. by MPLS and TEAS
  working groups).


Working Group Summary:

Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

  The working group is solidly behind that the document.

Document Quality:

  We understand that there are implementations and intents to implement
  this YANG model, from a large number of vendors. However we have not
  earlier documented implementtaitons or intent to implment.

  An implementation poll has therefore been sent to the working group
  mailing list.

  Tom Petch has done very thorough review, and had a postive influnce
  on the document.

  THe document has been reviewed by the Yang Doctors several times.

Personnel:

  Loa ndersson is the Document Shepherd.
  Deborah Brungard 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.

  When this document came online the Shepherd reviewed, but at that time it
  was not cler sho the shepherd would be so this was a wg chair review to look
  at what was new.
  The shepherd was appointed just prior to the wglc, but reviewed the dcument
  at wgap and wglc.

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

  No such concerns.

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

  The document has been reviewed bu the YANG doctors on the requst of the authors
  prior ti wgap and on the request of the Shepherd (via the authors) at wglc.

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

  No such concerns-

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

  All the authors and contributors have confirmed that that they are unaware
  of any IPRs.

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

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

  The working group stands behinds this document.

(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 such threats.

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

  The Shepherd has not identified any other nits than what the nits toll identify
  there is a BCP 14 boiler plate in section 1.1 Terminolgy, but the rest of the
  document does not use any requirment language.

  Note: the SHpherd wants to discuss this with the authors since there are
  lower case musts in YANG Module, and the shepherd does not understand if
  they are equivalent to BCP 14 language.

(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 YANG doctors have reviewed the document at several occasion. No further formal
  reviews are required.

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

    Yes - all references are split into normative and informative references,
    though the Shepherd would like to understand why RFC 3031 is an informative
    refrence. Especially since the definition of MPLS puh, op and swap operations
    comes from RFC 3031.
    Same goes for RFC 3032 that defines the MPLS Label Stack encoding.

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

  All the normative refrences are Standard Track RFCs or BCPs.


(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 downward references.

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

  There will be n o stauts change of any other RFC when this documents is published. 

(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 section has been reviewed several time during the development of the
  document.

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

  No such registries created.

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

  The YANG module is checked automatiall every time the document is posted.
  Need help to fill in additional info

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

  Need help to fill in this info.

2020-03-04
14 Tarek Saad New version available: draft-ietf-mpls-base-yang-14.txt
2020-03-04
14 (System) New version approved
2020-03-04
14 (System) Request for posting confirmation emailed to previous authors: Kamran Raza , Xufeng Liu , Vishnu Beeram , Rakesh Gandhi , Tarek Saad
2020-03-04
14 Tarek Saad Uploaded new revision
2020-03-03
13 Tarek Saad New version available: draft-ietf-mpls-base-yang-13.txt
2020-03-03
13 (System) New version approved
2020-03-03
13 (System) Request for posting confirmation emailed to previous authors: Vishnu Beeram , Tarek Saad , Rakesh Gandhi , Kamran Raza , Xufeng Liu
2020-03-03
13 Tarek Saad Uploaded new revision
2020-02-18
12 Tarek Saad New version available: draft-ietf-mpls-base-yang-12.txt
2020-02-18
12 (System) New version approved
2020-02-18
12 (System) Request for posting confirmation emailed to previous authors: Vishnu Beeram , Rakesh Gandhi , Tarek Saad , Xufeng Liu , Kamran Raza
2020-02-18
12 Tarek Saad Uploaded new revision
2020-01-29
11 Loa Andersson Tag Revised I-D Needed - Issue raised by WG set.
2020-01-29
11 Loa Andersson IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call
2020-01-29
11 Loa Andersson IETF WG state changed to In WG Last Call from WG Document
2019-12-09
11 Loa Andersson The document is in IPR poll starting Dec 9 2019.
2019-12-09
11 Loa Andersson Notification list changed to Loa Andersson <loa@pi.nu>
2019-12-09
11 Loa Andersson Document shepherd changed to Loa Andersson
2019-09-12
11 Tarek Saad New version available: draft-ietf-mpls-base-yang-11.txt
2019-09-12
11 (System) New version approved
2019-09-12
11 (System) Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Xufeng Liu , Vishnu Beeram , mpls-chairs@ietf.org, Kamran Raza , Tarek Saad
2019-09-12
11 Tarek Saad Uploaded new revision
2019-08-28
10 (System) Document has expired
2019-08-18
10 Ebben Aries Request for Early review by YANGDOCTORS Completed: On the Right Track. Reviewer: Ebben Aries. Sent review to list.
2019-07-11
10 Mehmet Ersue Request for Early review by YANGDOCTORS is assigned to Ebben Aries
2019-07-11
10 Mehmet Ersue Request for Early review by YANGDOCTORS is assigned to Ebben Aries
2019-07-10
10 Tarek Saad Requested Early review by YANGDOCTORS
2019-02-24
10 Tarek Saad New version available: draft-ietf-mpls-base-yang-10.txt
2019-02-24
10 (System) New version approved
2019-02-24
10 (System) Request for posting confirmation emailed to previous authors: Vishnu Beeram , Rakesh Gandhi , Tarek Saad , Xufeng Liu , Kamran Raza
2019-02-24
10 Tarek Saad Uploaded new revision
2018-11-05
09 Tarek Saad New version available: draft-ietf-mpls-base-yang-09.txt
2018-11-05
09 (System) New version approved
2018-11-05
09 (System) Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Vishnu Beeram , Xufeng Liu , mpls-chairs@ietf.org, Kamran Raza , Tarek Saad
2018-11-05
09 Tarek Saad Uploaded new revision
2018-10-16
08 Tarek Saad New version available: draft-ietf-mpls-base-yang-08.txt
2018-10-16
08 (System) New version approved
2018-10-16
08 (System) Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Vishnu Beeram , Kamran Raza , Xufeng Liu
2018-10-16
08 Tarek Saad Uploaded new revision
2018-10-12
07 Tarek Saad New version available: draft-ietf-mpls-base-yang-07.txt
2018-10-12
07 (System) New version approved
2018-10-12
07 (System) Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Vishnu Beeram , Kamran Raza , Xufeng Liu
2018-10-12
07 Tarek Saad Uploaded new revision
2018-08-19
06 (System) Document has expired
2018-02-15
06 Tarek Saad New version available: draft-ietf-mpls-base-yang-06.txt
2018-02-15
06 (System) New version approved
2018-02-15
06 (System)
Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Raqib Jones , Bin Wen , Vishnu Beeram , Xufeng Liu , mpls-chairs@ietf.org, …
Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Raqib Jones , Bin Wen , Vishnu Beeram , Xufeng Liu , mpls-chairs@ietf.org, Xia Chen , Igor Bryskin , Kamran Raza , Tarek Saad
2018-02-15
06 Tarek Saad Uploaded new revision
2018-01-03
05 (System) Document has expired
2017-07-02
05 Tarek Saad New version available: draft-ietf-mpls-base-yang-05.txt
2017-07-02
05 (System) New version approved
2017-07-02
05 (System)
Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Kamran Raza , Vishnu Beeram , Xufeng Liu , Xia Chen …
Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Kamran Raza , Vishnu Beeram , Xufeng Liu , Xia Chen , Igor Bryskin , Bin Wen , Raqib Jones
2017-07-02
05 Tarek Saad Uploaded new revision
2017-03-12
04 Tarek Saad New version available: draft-ietf-mpls-base-yang-04.txt
2017-03-12
04 (System) New version approved
2017-03-12
04 (System)
Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Kamran Raza , Vishnu Beeram , Xufeng Liu , Xia Chen …
Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Kamran Raza , Vishnu Beeram , Xufeng Liu , Xia Chen , mpls-chairs@ietf.org, Igor Bryskin , Bin Wen , Raqib Jones
2017-03-12
04 Tarek Saad Uploaded new revision
2017-03-11
03 Tarek Saad New version available: draft-ietf-mpls-base-yang-03.txt
2017-03-11
03 (System) New version approved
2017-03-11
03 (System)
Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Kamran Raza , Vishnu Beeram , Xufeng Liu , Xia Chen …
Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Kamran Raza , Vishnu Beeram , Xufeng Liu , Xia Chen , mpls-chairs@ietf.org, Igor Bryskin , Bin Wen , Raqib Jones
2017-03-11
03 Tarek Saad Uploaded new revision
2017-03-10
02 Tarek Saad New version available: draft-ietf-mpls-base-yang-02.txt
2017-03-10
02 (System) New version approved
2017-03-10
02 (System)
Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Kamran Raza , Xufeng Liu , Vishnu Beeram , Xia Chen …
Request for posting confirmation emailed to previous authors: Rakesh Gandhi , Tarek Saad , Kamran Raza , Xufeng Liu , Vishnu Beeram , Xia Chen , mpls-chairs@ietf.org, Igor Bryskin , Bin Wen , Raqib Jones
2017-03-10
02 Tarek Saad Uploaded new revision
2017-01-09
01 (System) Document has expired
2016-07-08
01 Tarek Saad New version available: draft-ietf-mpls-base-yang-01.txt
2016-06-12
00 Loa Andersson This document now replaces draft-saad-mpls-base-yang instead of None
2016-06-12
00 Tarek Saad New version available: draft-ietf-mpls-base-yang-00.txt