Re: Blog: YANG Really Takes Off in the Industry

"Thomas D. Nadeau" <tnadeau@lucidvision.com> Mon, 08 December 2014 12:40 UTC

Return-Path: <tnadeau@lucidvision.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 A48361A70FE for <ietf@ietfa.amsl.com>; Mon, 8 Dec 2014 04:40:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.598
X-Spam-Level: *
X-Spam-Status: No, score=1.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
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 RAWsa26euVMx for <ietf@ietfa.amsl.com>; Mon, 8 Dec 2014 04:40:38 -0800 (PST)
Received: from lucidvision.com (173-13-97-18-NewEngland.hfc.comcastbusiness.net [173.13.97.18]) by ietfa.amsl.com (Postfix) with ESMTP id 844DC1A8035 for <ietf@ietf.org>; Mon, 8 Dec 2014 04:40:38 -0800 (PST)
Received: from [192.168.1.100] (173-13-97-17-NewEngland.hfc.comcastbusiness.net [173.13.97.17]) by lucidvision.com (Postfix) with ESMTP id 0830D29D5B59; Mon, 8 Dec 2014 07:40:38 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0C93D9AC-6FCF-4B0F-B8E5-A8CA2E1B4414"
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Subject: Re: Blog: YANG Really Takes Off in the Industry
From: "Thomas D. Nadeau" <tnadeau@lucidvision.com>
In-Reply-To: <54857027.6080107@cisco.com>
Date: Mon, 08 Dec 2014 07:40:42 -0500
Message-Id: <7B20A9EE-32BE-451D-AB4E-3355785800C6@lucidvision.com>
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>
To: Benoit Claise <bclaise@cisco.com>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/dFEatNBZITCzVFv7kQ-PB75siB0
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 12:40:40 -0000

	You are right that "community responsibility" is a bit nebulous. What we need to do is setup a community place or places where people can meet up online or in person (at relatively frequent intervals) to work on modeling. The open source communities do this via virtual and real "hackathons" -- which are what we've setup just as part of official IETF meetings. I set one up at the previous ODL dev meetup, and will do so going forward as well as part of a few well attended conferences. Other ideas (and help!) for these is appreciated. 

	--Tom

	
> On Dec 8, 2014:4:32 AM, at 4:32 AM, Benoit Claise <bclaise@cisco.com> wrote:
> 
> 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
>>>> 
>>> 
>> 
>