YANG Data Model for MPLS LDP
draft-ietf-mpls-ldp-yang-09

Notification list changed to Nicolai Leymann <n.leymann@telekom.de>, Tarek Saad <tsaad.net@gmail.com>, Loa Andersson <loa@pi.nu> from Nicolai Leymann <n.leymann@telekom.de>, Tarek Saad <tsaad.net@gmail.com>

[Ballot comment]
Thank you for addressing my DISCUSS about the YANG model. My current ballot is now 'no objection' to publish this document.

Regards

-éric

---- below for archiving only -- ignore ----

Thank you for addressing my previous comments (especially around the IPv6 support).

But, I am now balloting a DISCUSS because I-D.ietf-rtgwg-policy-model  MUST be a normative reference as it is referenced by the YANG modules of this document. I.e., this document cannot be published _BEFORE_ I-D.ietf-rtgwg-policy-model ... Else, it will be useless.

Regards

-éric


-----

Thank you for the work put into this document.

I fully support Ben Kaduk's DISCUSS about IPv6 (about why IPv6 is in the extended section 6.1.2).  I would have balloted a DISCUSS if Ben haven't balloted before me.

Also concerned about Suresh's question about the "rw ipv4 (or ipv6)" in section 6.2.1. and 6.2.2. and other places. Thank you, though, for the IPv6 example in Appendix A.

Answers to my COMMENTs below will be welcome,

Regards,

-éric
== COMMENTS ==

-- Section 4 --
Why having the YANG subtrees for IPv4 and IPv6 different order of their subtrees in ietf-mpls-ldp/mpls-ldp/address-families/ipv[46] ?

-- Section 5.1.2 --
Another difference about IPv4 and IPv6 in the tree: IPv6 has an "enable" leaf but IPv4 does not. Why is that ?

-- Section 5.2.1.1. --
In the text "this document recommends an operator to pick a routable IPv4 unicast address as an LSR Id", what is meant by "routable" ? Globally routable ? Domain routable ?

Also, it is expected that design recommendations are done in a document about data model?

[Ballot comment]
Thanks for the updates in the -08.
While many of us are uneasy about relegating IPv6 support to be an
"extended feature", the new structure places IPv4 and IPv6 (when present)
as siblings, and it's clear that LDPv6 just isn't very widely deployed at the moment,
so this status is tolerable.

I'm still concerned that the semantics of the "password" field (even though there
is an associated algorithm-type) are not clearly specified, but I've been persuaded
to reduce that from a Discuss point to just a Comment.  I'm coming at this from the
mindset where the YANG model is a multi-vendor abstraction that gives me a unified
configuration interface across all my systems, and takes care of mapping the standardized
parameters to the local configuration state.  When TCP-MD5 or TCP-AO is in use, I fully
expect the actual key material to be managed by some automated system, so that the
human operator is not in the normal path for configuring the key material, but it still
seems like the key-management infrastructure should have a single understanding for
what "the key material" is, and be able to pass that directly to the YANG-based control
surface and have things work, regardless of which vendor implementation is in use.
The current specification and discussion of how the TCP-MD5 config is per-vendor makes
me concerned that the YANG abstraction will be "leaky", in that (e.g.) some vendors won't
let me configure a binary key, or I'll need to use a differently formatted string for one device
vs. another.

[Ballot discuss]
Thank you for addressing my previous comments (especially around the IPv6 support).

But, I am now balloting a DISCUSS because I-D.ietf-rtgwg-policy-model  MUST be a normative reference as it is referenced by the YANG modules of this document. I.e., this document cannot be published _BEFORE_ I-D.ietf-rtgwg-policy-model ... Else, it will be useless.

Regards

-éric

[Ballot discuss]
[updating Discuss to reflect points addressed by the -08; COMMENT unchanged from -07]

Please include some justification for why LDP IPv6 is considered an
"extended feature" (which is particularly surprising given that Section
2 classifies "IP" to refer to both IPv4 and IPv6 together).

We need to define the format/semantics of the md5-key string (e.g., is
it hex? base64{url,}?) either directly or by reference (as the YANG
doctor notes).  Using a crypto-type in the base model as opposed to
only as an extension would probably be appropriate, as
would adding a note that tcp-md5 is obsoleted by TCP-AO.

[Ballot comment]
Thank you for the work put into this document.

I fully support Ben Kaduk's DISCUSS about IPv6 (about why IPv6 is in the extended section 6.1.2).  I would have balloted a DISCUSS if Ben haven't balloted before me.

Also concerned about Suresh's question about the "rw ipv4 (or ipv6)" in section 6.2.1. and 6.2.2. and other places. Thank you, though, for the IPv6 example in Appendix A.

Answers to my COMMENTs below will be welcome,

Regards,

-éric
== COMMENTS ==

-- Section 4 --
Why having the YANG subtrees for IPv4 and IPv6 different order of their subtrees in ietf-mpls-ldp/mpls-ldp/address-families/ipv[46] ?

-- Section 5.1.2 --
Another difference about IPv4 and IPv6 in the tree: IPv6 has an "enable" leaf but IPv4 does not. Why is that ?

-- Section 5.2.1.1. --
In the text "this document recommends an operator to pick a routable IPv4 unicast address as an LSR Id", what is meant by "routable" ? Globally routable ? Domain routable ?

Also, it is expected that design recommendations are done in a document about data model?

[Ballot comment]
Thanks to all contributors and working group members who worked on this
document.

---------------------------------------------------------------------------

The front page contains six authors' names, while the "Authors' Addresses"
section at the end of the document contains 10. To avoid complications in
AUTH48, please clearly move all but six (or, preferably, five -- see RFC 7322
section 4.1.1) such names to the "Contributors" section.

---------------------------------------------------------------------------

I share Ben's concerns regarding the way these models treat IPv4 as
"basic" functionality, and IPv6 as "extended" functionality.
See https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for the current
IAB guidance on IPv6 in IETF protocols.

---------------------------------------------------------------------------

>      FEC-Label bindings:
>          FEC 203.0.113.1/32:
>            advertised: local-label 16000
>              peer 192.0.2.1:0
>              peer 192.0.2.2:0
>              peer 192.0.2.3:0
>            received:
>              peer 192.0.2.1:0, label 16002, used-in-forwarding=Yes
>              peer 192.0.2.2:0, label 17002, used-in-forwarding=No
>          FEC 203.0.113.2/32:
>              . . . .
>          FEC 198.51.100.0/24:
>              . . . .
>
>      Address bindings:
>          Addr 192.0.2.10:
>            advertised
>          Addr 192.0.2.1:
>            received, peer 192.0.2.1:0
>          Addr 192.0.2.2:
>            received, peer 192.0.2.2:0
>          Addr 192.0.2.3:
>            received, peer 192.0.2.3:0
>
>                                Figure 12

Please update this example to use IPv6, or add an example that shows IPv6.
Refer again to the IAB statement cited above for details.

[Ballot discuss]
The YANG doctor last call review of the -06 notes that these modules are
in violation of the expectations of RFC 8349 (at least w.r.t. defining a
new identity for the control-plane protocol and possibly more).  This
document should either be brought into compliance or explain why it
diverges.

The YANG doctor's comments about default values for "local"
configuration (e.g., graceful-restart configuration) causing the global
configuration to never take effect should also be addressed.

Please include some justification for why LDP IPv6 is considered an
"extended feature" (which is particularly surprising given that Section
2 classifies "IP" to refer to both IPv4 and IPv6 together).

We need to define the format/semantics of the md5-key string (e.g., is
it hex? base64{url,}?) either directly or by reference (as the YANG
doctor notes).  Using a crypto-type would probably be appropriate, as
would adding a note that tcp-md5 is obsoleted by TCP-AO.

In the peer-af-policy-container grouping's
label-policy/advertise/prefix-list, we need to say if the filter is for
inclusion or exclusion of outgoing label advertisements.
Similarly for the incoming label advertisements in the 'accept'
container (and most of the -list-ref usages?).

In the policy-container grouping's
label-policy/assign/independent-mode/prefix-list, the description
suggests that the contents will provide not just a list of prefixes that
act as a filter, but also a map from prefix to label.  This is a
qualitatively different usage than the previous occurrences of
prefix-list-ref, and it seems like a different type may be needed for
it.  Similarly for ordered-mode.

(pro-forma) This document has 6 authors, and per RFC 7322, as this is
more than five, we are supposed to consider whether that's appropriate.
Seeing nothing in the shepherd writeup or similar, I mention it here.

[Ballot comment]
Please also respond to the other YANG doctor, rtg-dir, and other
directorate reviewers' comments.

I support Roman's Discuss.

I suggest making a reference to RFC 5920 at some point, perhaps from the
security considerations.

We have several instances of a "container ipv4" that's a "container with
presence" in the jargon of RFC 7950.  As SEC AD one thing I look for is
edge cases, such as when a subset of these containers are present but
not all (and not none).  While for this specific case, it seems fairly
natural to assume that IPv4 is enabled if any are present, it does make
me wonder if the modeling is at an optimal state if there's even the
possibility for such skewed signals.  (I didn't specifically audit for
any other cases of "redundant" containers-with-presence.)

It's not entirely clear to me why we need (all of) the specialization of
structures into using inet:ipv4-address and inet:ipv6-address as opposed
to just inet:ip-address.  I do see that the latter is used in several
places already, and so assume that this was already considered; perhaps
some of the discussion/motivation could be included in the document,
though.

Section 1

  The data model is defined for following constructs that are used for
  managing the protocol:

nit: "the following".

I share the YANG doctor's concern that separating the configuration and
operational state constructs is not consistent with the NMDA model.

Section 1.1

  The "base" category contains the basic and fundamental features that
  are covered in LDP base specification [RFC5036] and constitute the
  minumum requirements for a typical base LDP deployment.  Whereas, the
  "extended" category contains all other non-base features.  All the

This statement ("all other") is not future-proof.

Section 3

  o  This module aims to address only the core LDP parameters as per
      RFC specification, as well as some widely deployed non-RFC
      features (such as label policies, session authentication etc).
      Any vendor specific feature should be defined in a vendor-specific
      augmentation of this model.

[Even for widely-deployed non-RFC features we still need to provide a
clear description of what semantics are being covered, whether
in-document or via an external reference.]

  o  This model is a VPN Forwarding and Routing (VRF)-centric model.
      It is important to note that [RFC4364] defines VRF tables and

side note: I would like the IETF to someday get to a point where "VPN"
(the 'P' is for "private") is used only for protocols/deployments that
provide confidentiality protection ("privacy") for the data being
conveyed.  We are, of course, not there now, and I cannot insist on any
change here.  But please consider whether an alternate phrasing would
suffice, that includes just the "virtual" part but not "VPN".  Since we
are mostly using "VRF" in the rest of the document, this is not as
daunting as it sometimes is...

Section 4

It might be nice to have the tree show the ipv4 and ipv6 children in
as similar an order as is possible (with the understanding that the
semantics are not affected by the order of appearance, of course).

      |  +--rw address-families
      |  |  +--rw ipv4!
      |  |  |  +--rw enable?                          boolean
      |  |  |  +--ro label-distribution-controlmode?  enumeration
      |  |  |  +--ro bindings
      |  |  |  |  +--ro address* [address]
      |  |  |  |  |  +--ro address              inet:ipv4-address
      |  |  |  |  |  +--ro advertisement-type?  advertised-received
      |  |  |  |  |  +--ro peer
      |  |  |  |  |    +--ro lsr-id?          leafref
      |  |  |  |  |    +--ro label-space-id?  leafref

Does this imply that there is only one peer per address?  Is that going
to be a limitation for any deployment cases?

          +--rw ldp-ext:session-downstream-on-demand
          |      {session-downstream-on-demand-config}?
          |  +--rw ldp-ext:enable?      boolean

nit(?): missing '|' to connect down to ldp-ext:enable?
Similarly for ldp-ext:max-wait a few lines later, and some other
occurrences later in the document.

Section 5.1.2

Am I reading this right that (e.g.) per-interface hello-holdtime is
configurable as an extension and only the global hello-holdtime is
present in the "base" module?

Section 7

"NHLFE" is used only once in this document (and is not listed as
"well-known" at
https://www.rfc-editor.org/materials/abbrev.expansion.txt); please
expand it out.

Section 9

Is 2018 still the right copyright year for the modules themselves?

Section 9.1

    typedef ldp-address-family {
      type identityref {
        base rt:address-family;
      }

Why can't we use rt:address-family directly in the one container that
uses this?

      description
        "Duration represented as 32 bit seconds with infinite.";

nits: "32-bit" (hyphenated), "with infinity".

    typedef downstream-upstream {
      type enumeration {
        enum downstream {
          description "Downstream information.";
        }
        enum upstream {
          description "Upstream information.";
        }
      }
      description
        "Received or advertised.";
    }

nit: copy/paste on the description?

        leaf used-in-forwarding {
          type boolean;
          description
            "'true' if the lable is used in forwarding.";

nit: s/lable/label/

    grouping graceful-restart-attributes-per-peer {
      description
        "Per peer graceful restart attributes.
          On the local side, these attributes are configuration and
          operational state data. One the peer side, these attributes
          are operational state data reveiced from the peer.";

nit: s/reveiced/received/

    grouping peer-state-derived {
      description
        "The peer state information derived from the LDP protocol
          operatoins.";

nit: s/operatoins/operations/

    grouping peer-state-derived {
    [...]
      leaf next-keep-alive {
        type uint16;
        units seconds;
        config false;
        description "Time to send the next KeepAlive message.";
      }

nit: this description text sounds like it's giving an absolute time, but
given that it's a uint16 I presume it's "time [from now] until sending".

      container received-peer-state {
        config false;
        description
          "Operational state information learned from the peer.";

        uses graceful-restart-attributes-per-peer;

        container capability {
          description "Configure capability.";

This is config-false; "Configure" in the description cannot be correct,
though I suppose "Configured" could be.
(Also applies to several of the child containers' descriptions.)

      leaf up-time {
        type string;
        config false;
        description "Up time. The interval format in ISO 8601.";

We probably should have some sort of reference for ISO 8601 (though of
course it cannot actually *be* a  in the YANG module itself)

      leaf notification {
        type yang:counter64;
        description
          "The number of messages sent or received.";

Is this the same as or different than "leaf total-messages"?

              leaf label-distribution-controlmode {

nit: any reason to not hyphenate control-mode as well?

          container interfaces {
            description
              "A list of interfaces for LDP Basic Descovery.";

nit: s/Descovery/Discovery/

        container discovery {
          description
            "Neibgbor discovery configuration and operational state.";

nit: s/Neibgbor/Neighbor/

                  // ipv4
                  container hello-adjacencies {
                    config false;
                    description
                      "Containing a list of hello adjacencies.";

                    list hello-adjacency {
                      key "adjacent-address";
                      config false;
                      description "List of hello adjacencies.";

                      leaf adjacent-address {
                        type inet:ipv4-address;
                        description
                          "Neighbor address of the hello adjacency.";
                      }

I'm not an expert here, but I'm not really seeing why we need to
specialize this container for v4 vs v6 as opposed to just using
inet:ip-address and having something that's applicable to both.

                  leaf adjacent-address {
                    type inet:ipv4-address;
                    description
                      "Configures a remote LDP neighbor and enables
                        extended LDP discovery of the specified
                        neighbor.";

Given that there's a sibling leaf "enable", do we still want "and
enables" here?

Should peer/capability have a comment in its description that the
container exists to be augmented by other (extension) modules?

    notification mpls-ldp-fec-event {

Am I reading this right that we only generate notifications on 0->1 and
1->0 transitions of "number of prefixes active for a given FEC"?  Would
we ever want to know about addition/removal of prefixes that do leave
the FEC up?

Section 9.2

I can't find a pattern into which if-feature statements go into
containers used to augment things vs. the augment directives themselves.
Can we be more consistent (or am I missing the pattern)?

    feature dual-stack-transport-pereference {
      description
        "This feature indicates that the system allows to configure
          the transport connection pereference in a dual-stack setup.";

nit: s/pereference/preference/ (twice)

    feature policy-targeted-discovery-config {
      description
        "This feature indicates that the system allows to configure
          policies to control the acceptance of targeted neighbor
          discovery hello messages.";

nit: s/hello/Hello/

    typedef neighbor-list-ref {
      type string;
      description
        "A type for a reference to a neighbor address list.
          The string value is the name identifier for uniquely
          identifying the referenced address list, which contains a list
          of addresses that a routing policy can applied. The definition
          of such an address list is outside the scope of this
          document.";

If I'm reading correctly between here and where this is used, the
semantics of this are better described as "implementation-specific" --
that is, this is a label that refers to some local configured state,
specifically, a list of neighbor addresses used as an ACL.  (Emphasis on
*local* -- it seems like it does not need to interact with anything
else.)
I do sympathize with the YANG doctor, though -- as-is, this feels
underspecified.
(BTW, IP ACLs are not considered to be a security measure by the broader
security community.)
Similarly for the subsequent -list-refs.

        container interfaces {
          description
            "A list of interfaces on which forwarding is disabled.";

nit: given the separate 'ldp-disable' leaf, perhaps s/is/can be/ is in
order.
Also, the description of the list itself implies additional
functionality, of listing the interfaces used for basic discovery.

    grouping graceful-restart-augment {
      description "Augmentation to graceful restart.";

      leaf helper-enable {
        if-feature graceful-restart-helper-mode;
        type boolean;
        default false;
        description
          "Enable or disable graceful restart helper mode.";

Where is this "helper mode" documented?

    augment "/rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/"
      + "ldp:global" {
      description "Graceful forwarding nexthop augmentation.";
      uses global-forwarding-nexthop-augment;
    }

nit: I don't think "Graceful" is correct, in the description.

Why is (the augmented)
/rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:global/ldp:address-families/ipv6/label-distribution-controlmode
'config false'?  Doesn't RFC 5036 say that an LSR might support either
as a configuration option?

          leaf adjacent-address {
            type inet:ipv6-address;
            description
              "Configures a remote LDP neighbor and enables
                extended LDP discovery of the specified
                neighbor.";

As for the ipv4 case, do we still want "and enables" here?

    augment "/rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/"
      + "ldp:discovery/ldp:interfaces/ldp:interface/"
      + "ldp:address-families/ldp-ext:ipv6" {
      description "Interface address family IPv6 augmentation.";
      uses interface-address-family-ipv6-augment;

Didn't we just create .../ldp:address-families/ldp-ext:ipv6 with an
earlier augmentation in this module?  (Similarly for
/rt:routing/rt:control-plane-protocols/ldp:mpls-ldp/ldp:peers/ldp:peer/ldp:address-families/ldp-ext:ipv6
which we augment with "uses peer-af-policy-container".)

Appendix A

                "is-router": [null],

This looks weird to me ("array containing one element with value literal
null") -- why does the array come into play?

[Ballot comment]
I kind of figured out how this should work but is this formulation used in Figures 10,11 and 13 something well defined? I have not seen this before and a reread of RFC8340 did not help either

+--ro ipv4 (or ipv6)

[Ballot discuss]
[This is a preliminary Discuss placed before a full document review is complete,
to give the authors additional time to consider and respond]

The YANG doctor last call review of the -06 notes that these modules are in
violation of the expectations of RFC 8349 (at least w.r.t. defining a new identity for
the control-plane protocol and probably also w.r.t. augmenting the
"control-plane-protocol" under "/routing").  This document should either be brought
into compliance or explain why it diverges.

The YANG doctor's comments about the default values for the "local" graceful-restart configuration
causing the global configuration to never take effect also should be addressed.

The YANG doctor also noted that the "md5-key" leaf does not specify its semantics, and
is presumably sensitive (so that a crypto-type would be more appropriate).

[Ballot discuss]
Thank you for using the YANG Security Considerations template.  Could you please provide more details on which nodes are sensitive to write and read issues; and the RPC operations of concern.  For example, see draft-ietf-isis-yang-isis-cfg or draft-ietf-ospf-yang.

[Ballot comment]
A few trivial editorial nits:

* Section 1.1. Typo.  s/minumum/minimum/
* Section 1.1.  Typo. s/catogories/categories/
* Section 1.1.  Typo. s/higlighting/highlighting/
* Section 3.0.  Typo. s/grapically/graphically/
* Section 5.2.1.  Typo. s/an network-instance/a network-instance/

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

The IANA Functions Operator has completed its review of draft-ietf-mpls-ldp-yang-06. 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/

two, new namespaces will be registered as follows:

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

ID: yang:ietf-mpls-ldp-extended
URI: urn:ietf:params:xml:ns:yang:ietf-mpls-ldp-extended
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/

two, new YANG modules will be registered as follows:

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

Name: ietf-mpls-ldp -extended
File: [ TBD-at-Registration ]
Maintained by IANA? N
Namespace: urn:ietf:params:xml:ns:yang:ietf-mpls-ldp-extended
Prefix: ldp-ext
Module:
Reference: [ RFC-to-be ]

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

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

The following Last Call announcement was sent out (ends 2019-10-04):

From: The IESG
To: IETF-Announce
CC: mpls@ietf.org, db3546@att.com, mpls-chairs@ietf.org, draft-ietf-mpls-ldp-yang@ietf.org, Tarek Saad , tsaad.net@gmail.com, Nicolai Leymann
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (YANG Data Model for MPLS LDP) to Proposed Standard


The IESG has received a request from the Multiprotocol Label Switching WG
(mpls) to consider the following document: - 'YANG Data Model for MPLS LDP'
  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
ietf@ietf.org mailing lists by 2019-10-04. 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 describes a YANG data model for Multi-Protocol Label
  Switching (MPLS) Label Distribution Protocol (LDP).  The model also
  serves as the base model to define Multipoint LDP (mLDP) model.

  The YANG modules in this document conform to the Network Management
  Datastore Architecture (NMDA).




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-mpls-ldp-yang/ballot/


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

Writeup for draft-ietf-mpls-ldp-yang-06.txt

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

Proposed Standard - Standards Track indicated on the title page.
This RFC is intended to define a YANG module to manage the MPLS LDP protocol.

(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

From the Abstract:
This document describes a YANG data model for Multi-Protocol Label
Switching (MPLS) Label Distribution Protocol (LDP).  The model also
serves as the base model to define Multipoint LDP (mLDP) model.

Working Group Summary

The Working Group has reached consensus that this document is useful and should be published. This document went through multiple reviews within the working group over the course of its development. Multiple revisions were done as part of making the module adhere with the NMDA structure.
The current document represents a proper management framework for the most commonly deployed MPLS LDP features covered in various RFCs. The design of this module also takes future extensions/augmentations into considerations.
   
Document Quality

Expert review was done by YANG Doctors and by multiple WG members. All comments have been addressed, and there are currently no open issues.

Personnel

Tarek Saad 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.

The document shepherd has reviewed the specification during WG last call and subsequently checked all diffs. Comments on the mailing list were addressed in the last version. The document shepherd believes that the document is ready for publication.

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

The shepherd has no concerns about the depth and breadth of the reviews that were performed.

(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 still needs to be reviewed by the relevant directorates

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

The shepherd does not have any concerns about the document.

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

Yes.

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

Yes. There were no specific discussions or conclusions in the WG.

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

There is consensus of all people who have reviewed and contributed to the 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.

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

None errors found.
2 warnings for longer pages exceeding 58 lines per page.
1 warning for document not using any RFC 2119 keywords, yet RFC 2119 boilerplate text.
a number of warnings due to "line has weird spacing:" - it's not clear what's the warning about. It seems a tool issue
1 outdated informational reference: A later version (-06) exists of draft-ietf-mpls-mldp-yang-05
 
These nits should be addressed the next time the document is updated.

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

Appropriate expert reviews, including Yang doctors, have been done.

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

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

None.

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

None.

(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 no status change of any other documents when this document 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 5226).

The IANA considderation are clearly stated in 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 new IANA registries are being defined.

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

No formal reviews necessary.

Writeup for draft-ietf-mpls-ldp-yang-06.txt

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

Proposed Standard - Standards Track indicated on the title page.
This RFC is intended to define a YANG module to manage the MPLS LDP protocol.

(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

From the Abstract:
This document describes a YANG data model for Multi-Protocol Label
Switching (MPLS) Label Distribution Protocol (LDP).  The model also
serves as the base model to define Multipoint LDP (mLDP) model.

Working Group Summary

The Working Group has reached consensus that this document is useful and should be published. This document went through multiple reviews within the working group over the course of its development. Multiple revisions were done as part of making the module adhere with the NMDA structure.
The current document represents a proper management framework for the most commonly deployed MPLS LDP features covered in various RFCs. The design of this module also takes future extensions/augmentations into considerations.
   
Document Quality

Expert review was done by YANG Doctors and by multiple WG members. All comments have been addressed, and there are currently no open issues.

Personnel

Tarek Saad 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.

The document shepherd has reviewed the specification during WG last call and subsequently checked all diffs. Comments on the mailing list were addressed in the last version. The document shepherd believes that the document is ready for publication.

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

The shepherd has no concerns about the depth and breadth of the reviews that were performed.

(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 still needs to be reviewed by the relevant directorates

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

The shepherd does not have any concerns about the document.

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

Yes.

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

Yes. There were no specific discussions or conclusions in the WG.

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

There is consensus of all people who have reviewed and contributed to the 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.

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

None errors found.
2 warnings for longer pages exceeding 58 lines per page.
1 warning for document not using any RFC 2119 keywords, yet RFC 2119 boilerplate text.
a number of warnings due to "line has weird spacing:" - it's not clear what's the warning about. It seems a tool issue
1 outdated informational reference: A later version (-06) exists of draft-ietf-mpls-mldp-yang-05
 
These nits should be addressed the next time the document is updated.

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

Appropriate expert reviews, including Yang doctors, have been done.

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

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

None.

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

None.

(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 no status change of any other documents when this document 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 5226).

The IANA considderation are clearly stated in 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 new IANA registries are being defined.

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

No formal reviews necessary.

Request for posting confirmation emailed to previous authors: Xufeng Liu , mpls-chairs@ietf.org, Santosh Esale , Himanshu Shah , Kamran Raza , Xia Chen , Rajiv Asati

Request for posting confirmation emailed to previous authors: Santosh Esale , mpls-chairs@ietf.org, Xia Chen , Himanshu Shah , Kamran Raza , Xufeng Liu , Rajiv Asati