YANG Data Model for L3VPN Service Delivery

Note: This ballot was opened for revision 07 and is now closed.

Alvaro Retana Discuss

Discuss (2017-11-29 for -09)
[Given that this document is returning to the IESG, I’m updating my DISCUSS (after IETF 100 and to (hopefully) clarify.]

The basis of this DISCUSS is that this document defines a non-backwards-compatible update to the module in rfc8049, which is not in compliance with the YANG module update process specified in rfc7950 (YANG 1.1).

My interpretation of the discussions in the netmod WG (on the list and during the in-person meeting at IETF 100) is that the WG recognizes that this document presents a case to change the process — but so far it has only agreed on there being a problem, and not on any path forward [A].  There is at least one proposal [B] on the table, but no clear and formal intention from the WG on whether that is in fact the solution, part of it, or anything else.

It would be enough for me to clear this DISCUSS if the netmod WG reached (at least initial) consensus on a path forward.  Other solutions require following rfc7950: either by changing the module name, or by keeping the name and following the specification on how to update a module. [I realize that the latter may not be possible.]

It seems to me that tooling and implementation/deployment considerations around having the same module name are the leading reasons towards looking for alternate solutions and not complying with rfc7950 in this case.  Given the very few dependents on this module (just one!) [C], I think it could be palatable to everyone to change the module name and move on with the updated process separately.

I am also holding this DISCUSS because I don’t think it is a good precedent for the IESG to approve a document that doesn’t follow a standard procedure — regardless of the reasons.  I believe that if the IESG approves this document (without a proper Update to the procedures in rfc7950, or at least a WG-agreed plan to do so) then it will have to consider breaking (or at least bending) the rules for any other module — and even for any other document that doesn’t want to comply with what is standardized already…. Note that I’m not suggesting that the IESG will have to break/bend the rules for everyone, but that it will have to at least consider other requests.

In summary… To be clear, I believe YANG is an important technology for the IETF and the Internet and the last thing I want to do is stand in the way of getting more modules our faster.  However, the process is in place for a reason and breaking it (without a viable alternative) is not the right way forward.  This DISCUSS is clearly for the IESG to consider, as the authors seem to just be caught in the middle.  Instead of making an example of this document, I strongly suggest that the name be changed so the document can be published without compromising the standards process — the update to the rfc7950 process can then be considered separately.

[A] https://mailarchive.ietf.org/arch/msg/netmod/IOMNpqPqhGKxR1MEUB7tQmv3KiA/?qid=185ce790ada5150129831ec488ebad81

[B] https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update 

[C] https://www.yangcatalog.org/yang-search/impact_analysis.php?modules[]=ietf-l3vpn-svc@2017-10-11.yang&recurse=0&rfcs=1&show_subm=1&show_dir=both

(Benoît Claise) Yes

Warren Kumari (was No Objection) Yes

Comment (2017-12-05)
No email
send info
I have sympathy for both sides of this discussion, but, after significant thought, I'm balloting Yes - I think that the conversation has moved onto more steering / guiding principles, and is no longer really about this document.

We run a constant battle between doing what is "right", and being slaves to process - while this document does not comply with RFC7950, I believe that:
A: it is the "right thing" to do from a practical point
B: it follows the spirit of 7950 (at least, my interpretation thereof)
C: this is a special case 

This document / discussion has moved into the keeping the IETF relevant area, existential discussions, etc. My position is intended (at least partially) reflect this.

Note again that I have sympathy for both sides of this discussion, that this was not taken lightly, and that this is an (IMO) exceptional case.

(Alia Atlas) No Objection

(Ben Campbell) No Objection

Comment (2017-10-25 for -07)
No email
send info
-1.2: The document contains lower case versions of 2119 keywords.  If those are correct, please use the updated boilerplate from 8174.

- There are a number of lines that are too long in the YANG tree diagrams. (Check IDNits for details.)

Alissa Cooper No Objection

Comment (2017-10-25 for -07)
No email
send info
The Gen-ART reviewer's comments primarily address text that did not change in the bis, but they are worth consideration in any event.

(Spencer Dawkins) No Objection

(Suresh Krishnan) (was Discuss) No Objection

Comment (2017-10-30 for -09)
No email
send info
Thanks for addressing my DISCUSS points.

(Mirja Kühlewind) No Objection

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

(Kathleen Moriarty) No Objection

Comment (2017-10-24 for -07)
No email
send info
I mostly skimmed this document focusing on the changes, so I may have missed something.  In looking at Section 6.1.4, are there privacy considerations needed for the identifiers?  This might not have been a consideration at the original time of publication.

Thanks for addressing the SecDir review:

(Adam Roach) No Objection

Comment (2017-10-25 for -07)
No email
send info
Section 6.11.1 says it's showing a snippet for a "dual stack" setup; however, it appears to contain only IPv4 information rather than both IPv4 and IPv6 information. Has some portion of this snippet been inadvertently omitted from this version?


Some of the new sections of the YANG model are indented in a way that is inconsistent with the rest of the model (e.g., they use deeper indentation than the surrounding model text), making them more difficult to read. I suggest combing through the new changes to make sure they're consistent with regards to indentation and line wrapping.


           leaf rate-limit {
            type uint8;
            units percent;
             "To be used if the class must be rate-limited.
             Expressed as percentage of the service bandwidth.";

Using a uint8 here for percentage seems to provide pretty coarse-grained control. Was the use of a floating point value considered?

(I have the same question for 'guaranteed-bw-percent')

Deborah Brungard (was Discuss) Abstain

Comment (2017-12-05)
No email
send info
Thanks for addressing my discuss points on backward compatibility.
I still remain concerned on the wisdom of retaining the same
name for the module, hence my abstain ballot.