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

Thank you for addressing my DISCUSS and COMMENT points.

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?

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.

Per the Gen-ART review, I support Roman's DISCUSS and Benjamin's DISCUSS point concerning IPv6. Please respond to the Gen-ART review.

I support the DISCUSSes and comments by Ben, Roman, and Adam.

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.

I support Roman's discuss.

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)