Re: [Rtg-yang-coord] naive question ??

["Thomas D. Nadeau" <[e-mail]>]

> On Feb 11, 2015:8:20 AM, at 8:20 AM, Dean Bogdanovic <[e-mail]> wrote:
> 
> 
> On Feb 11, 2015, at 7:44 AM, t.petch <[e-mail]> wrote:
> 
>> ---- Original Message -----
>> From: "Thomas D. Nadeau" <[e-mail]>
>> To: "Loa Andersson" <[e-mail]>
>> Cc: <[e-mail]>
>> Sent: Thursday, February 05, 2015 12:27 PM
>>> 
>>>> On Feb 5, 2015:5:51 AM, at 5:51 AM, Loa Andersson <[e-mail]> wrote:
>>>> 
>>>> I have what might be a naive question.
>>>> 
>>>> People have told me that in Yang we want to separate functionality
>> from
>>>> technology, i.e. we will look at OAM, management, routing, signaling
>>>> and traffic engineering as aggregate functions and build our tree
>> based
>>>> on that.
>>>> 
>>>> Now if we are to model thing that are closely related e.g. MPLS OAM,
>>>> signaling, routing and traffic engineering, does that mean that we
>> have
>>>> to work at separate pieces of the yang tree and repeat this for
>> every
>>>> piece of the technology?
>>> 
>>> I think you can do a model dedicated to MPLS OAM.  The analogy is
>>> pretty much similar to how MIBs are created. You can import bits or
>>> objects from all over the place to create things, or you can recreate
>> them
>>> in place.   There is a trade-off about modularity versus
>> time-to-completion
>>> here and I very much am not in favor of being zealous one way or the
>> other.
>>> 
>>> We also need to very much take an iterative process around these
>> models:
>>> they are not set in stone, and we should iterate on them to modify,
>> adapt
>>> and update them as necessary.  With that in mind, we've been
>> encouraging people to
>>> just starting writing them as best as possible and implementing either
>> prototype
>>> code or actually putting them into products so that we can see how
>> they actually
>>> operate in the wild.
>> 
>> Loa
>> 
>> I do not think the question naive, but I do think it a management
>> question, rather than a technical one.  And as a wise consultant kept
>> reminding me (the consumate technician:-), there are management
>> solutions to technical problems but never technical solutions to
>> management ones.
>> 
>> Like structuring and restructuring IETF working groups, there are many
>> ways to make it work but it is about management, not technology (or
>> functionality).  So I would prefer a YANG module that matches the skills
>> of a Working Group, not needing cross-WG review.
> 
> Matching YANG models with WG is nice to have, but not always possible, as some models (e.g. access control list) don't have a WG to fit in. I believe some other models will come up as well. As long there is an active WG, the modeling work should be done within that group.
	
	And that is my point exactly. We should not be spinning up special WGs to do Yang models; its unnecessary.  The added process overhead is not worth it.  If there is another WG like netmod/conf/ops area/whatever that roughly makes sense put it there. If there is not enough management bandwidth, go ahead and (temporarily?) add another chair or secretary.  IMHO we need to stop focusing on spinning up new WGs, and instead focus on actually getting work done regardless of where.

> I think that the problem with MIB Modules was and is a lack of knowledge
>> of management in general and of SNMP in particular, within any working
>> group (e.g. IDR) and that is likely to be true with YANG but at least a
>> WG should be familiar with the technology and have a sense of which
>> elements to include in a data or information model, even if the WG lacks
>> the skills to turn it into YANG.
>> 
>> SNMP does have conformance which made it possible to create the one MIB
>> Module with basic, intermediate and advanced subsets.  YANG lacks that
>> but has if-feature which I see as complicated, easy to get wrong both in
>> terms of getting the statement correct with respect to the logic that
>> has been agreed, and in choosing when to use it or not.  (A bit like
>> novice programmers who learn that when two or three statements appear
>> more than once, they can be replaced by a procedure or function, making
>> the code shorter and harder to understand and maintain).  I suspect that
>> if-feature is much over-used and that the cost of that will become
>> apparent in a few years time.
> 
> One of YANG strong sides is the extensibility and augmentation. If-feature is very useful, but it should be carefully used. A much better way to design YANG models is using following
> 
> base model
> standard extension model
> proprietary extension model
> 
> With base model, a basic set of features is described. That model can be then imported into another model, like standard or proprietary extension model, and augmented with more features. This provides easier to read and maintenance of the code. Take a look at draft-ietf-netmod-acl-model for example.
> 
> Dean

	+1.

	--Tom



> 
>> 
>> Tom Petch
>> 
>>> --Tom
>>> 
>>> 
>>>> First, is this correctly understood or do I have to go back and
>> discuss
>>>> this again with the people proposing it?
>>>> 
>>>> If it is correct why is it superior to what we did for SNMP, one
>> MIB-module for each protocol?
>>>> 
>>>> Are the decisions taken or is the jury still out?
>>>> 
>>>> /Loa
>>>> --
>>>> 
>>>> 
>>>> Loa Andersson                        email: [e-mail]
>>>> Senior MPLS Expert                          [e-mail]
>>>> Huawei Technologies (consultant)     phone: [phone]
>>>> 
>>>> _______________________________________________
>>>> Rtg-yang-coord mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>>> 
>>> 
>>> _______________________________________________
>>> Rtg-yang-coord mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>>> 
>> 
>> _______________________________________________
>> Rtg-yang-coord mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
> 
>