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

[t.petch <[e-mail]>]

---- 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.

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.

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
>