RE: Blog: YANG Really Takes Off in the Industry

["Romascanu, Dan (Dan)" <[e-mail]>]

Hi,

Success comes sometimes together with its own risks. In the case of YANG, the risk is that six months or one year from now people who enthusiastically engaged with developing YANG module will have at hand bad modules that do not meet their expectations of functionality, quality, interoperability. The pushback can then follow at the same intensity as the current embracing. To avoid this situation we need to provide answers to the problem of non-scalability of the 'Doctors' team model which is IMO real. The answer cannot be just 'let us focus on what we do in the standards track in the IETF' because much of the development of YANG modules happens out of the IETF and this is how we want it to be. We need to encourage the open source and SDOs that engage on the YANG path to develop their own Yangathon events and maybe in time their own YANG doctors teams. We need however to make clear that this is the model we recommend (rather than developing YANG modules and coming to the YANG doctors to review) and offer help in organizing these first activities and teams at their homes.

Regards,

Dan

From: ietf [mailto:[e-mail]] On Behalf Of Ersue, Mehmet (NSN - DE/Munich)
Sent: Monday, December 08, 2014 7:30 PM
To: ext Benoit Claise; Thomas D. Nadeau
Cc: IETF-Discussion list
Subject: RE: Blog: YANG Really Takes Off in the Industry

Hi Benoit, All,

to be able to reduce the necessary amount reviews and publications, I assume we need to define some categories:

- YANG models might be interesting to have but they don't need to be standardized in many cases. So, the category for Standard track RFC has to be defined with a clear criteria.
- Others may be Informational or Experimental. However for these we need to see the relevance to IETF work and necessity for publication.

The other categorization could be concerning the dispatching of YANG models within IETF:

- There are particularly important YANG models related to a specific WG. They should be developed in that WG.
- There might be others which are still important to publish but don't have any home. I would discuss them in an OPSAWG meeting and decide whether it should be published in OPSAWG or NETMOD WG
.
The other category I see is related to YANG models which should be matched to another SDO. If we think a model is e.g. related to IEEE or MEF, they should be done there and not at IETF.

There might be also other YANG models which are interesting but not related to IETF. One particular category is concerning models, which were originally Enterprise models but people would like to have an IETF publication.

In general, over time we might need to be strict to stick to the categories and the matched process per category.

That said, I would like to suggest to use the resources of the YANG doctor team for models, which are essential for the IETF at the first place, especially those seen under the category Standard track RFC.

Cheers,
Mehmet

From: ietf [mailto:[e-mail]] On Behalf Of ext Benoit Claise
Sent: Monday, December 08, 2014 10:32 AM
To: Thomas D. Nadeau
Cc: IETF-Discussion list
Subject: Re: Blog: YANG Really Takes Off in the Industry

Hi Tom,

In light of the numerous YANG models these days, there is the YANG doctors scaling issue. You're right, even if the number of YANG doctors recently increased, we need other venues to provide advice to YANG model designers. This should solve the issue of designing properly the YANG models.
On the other hand, there is a bigger issue, IMO: the proper coordination of those YANG models. This is not the YANG doctors responsibility. This can't be: see the YANG doctors scalability issue.  So who's responsibility is this? Simply asserting "it's the community responsibility" is the easy answer, but I'm afraid it will not work.

Regards, Benoit


        One of the things that came up in a number of discussions I had in Hawaii and afterwards was around the coordination and encouragement topics. A number of people commented both during these discussions (and I think someone did during one of the Netmod sessions) that the "MIB Doctor" model we are using is not going to scale out to the numbers of Yang models that are in need of advice or review, nor will be scale in terms of progressing models through the IETF's RFC process. The fact is that we simply do not have enough Yang Doctors to cover all of the models in question, despite our best efforts.   It is for this reason that I strongly encourage other venues of review and advice such as a continued "advice" or "Yangathon" session at each IETF meeting going forward, as well as encouraging a loosening of the interim WG meeting rules to encourage more meetings, as well as perhaps less formalized ones.  I also encourage the IETF to start pairing up with other organizations such as OpenDaylight, Openstack and OP-NFV and join their Yangathons there.


        -Tom



On Nov 28, 2014:8:12 AM, at 8:12 AM, Benoit Claise <[e-mail]<mailto:[e-mail]>> wrote:

Hi Jari,

Let me open the discussion.
What is important at this point in time is the coordination of those YANG models.
All of them come at the same time, and this required some urgent attention.
Focusing on the routing YANG models with "[e-mail]" <[e-mail]><https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rtg-2Dyang-2Dcoord&d=AAMFAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=EldXn4rzRf97Z5Y7A2KouM2hYYBbL5m9IMpucoilFZE&s=14IGX58lMwSyD8bOPQb_MqlsYeQ3u_s0T7YwNmjqqU0&e=> is a step in the right direction. Indeed the community needs to agree on how to model IGPs, BGP, the topology, etc...
However, the coordination should also occur with the data models developed in other IETF WGs. And the IETF might need to reach out to different SDOs/consortia.
As the operators told me: we can't afford to develop those data models independently from each others.

Regards, Benoit

Thanks for writing this article, Benoit!



The wave of new data models is obviously interesting and exciting. But I wanted to open a discussion with you all on what we should do with regards to serving this need better. Is there something that we could do better at the IETF to be able deal with this new work?



Jari