RE: Blog: YANG Really Takes Off in the Industry

"Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com> Mon, 08 December 2014 17:30 UTC

Return-Path: <mehmet.ersue@nsn.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428A41ACD1F for <ietf@ietfa.amsl.com>; Mon, 8 Dec 2014 09:30:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjSvoBvCWIoZ for <ietf@ietfa.amsl.com>; Mon, 8 Dec 2014 09:30:23 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4541ACD24 for <ietf@ietf.org>; Mon, 8 Dec 2014 09:30:22 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.14.3/8.14.3) with ESMTP id sB8HUG5I023945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 8 Dec 2014 17:30:16 GMT
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id sB8HUFxG014799 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 8 Dec 2014 18:30:15 +0100
Received: from DEMUMBX005.nsn-intra.net ([169.254.5.147]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 18:30:15 +0100
From: "Ersue, Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
To: ext Benoit Claise <bclaise@cisco.com>, "Thomas D. Nadeau" <tnadeau@lucidvision.com>
Subject: RE: Blog: YANG Really Takes Off in the Industry
Thread-Topic: Blog: YANG Really Takes Off in the Industry
Thread-Index: AQHQEsn1FuyBIMwpDECHY0gn5FBfrJyF728w
Date: Mon, 08 Dec 2014 17:30:15 +0000
Message-ID: <E4DE949E6CE3E34993A2FF8AE79131F8195867DD@DEMUMBX005.nsn-intra.net>
References: <54770BA5.5060603@cisco.com> <809EFD2B-A845-46B7-A394-A9C9E5393CD5@piuha.net> <547874D6.1090001@cisco.com> <7890AE32-F7A9-4C32-9C3D-8251E70B1F29@lucidvision.com> <54857027.6080107@cisco.com>
In-Reply-To: <54857027.6080107@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.157]
Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8195867DDDEMUMBX005nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 42747
X-purgate-ID: 151667::1418059817-0000658F-45FAF531/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/8zK1zMIL0JeQVsSKV_H2w2CH32M
Cc: IETF-Discussion list <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 08 Dec 2014 17:30:28 -0000

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:ietf-bounces@ietf.org] 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 <bclaise@cisco.com<mailto:bclaise@cisco.com>> 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 "Rtg-yang-coord@ietf.org" <Rtg-yang-coord@ietf.org><https://www.ietf.org/mailman/listinfo/rtg-yang-coord> 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