YANG Data Model for L3VPN Service Delivery
draft-wu-l3sm-rfc8049bis-11

[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