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

From: Loa Andersson <[email-masked]>
Date: Thu, 05 Feb 2015 18:51:51 +0800

Folks,

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?

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: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 5 Feb 2015 07:27:05 -0500

> On Feb 5, 2015:5:51 AM, at 5:51 AM, Loa Andersson <[email-masked]> wrote:
> 
> Folks,
> 

	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.

	--Tom

> If it is correct why is it superior to what we did for SNMP, one MIB-module for each protocol?
> 
> _______________________________________________
> Rtg-yang-coord mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtg-yang-coord
>

---

From: Loa Andersson <[email-masked]>
Date: Fri, 06 Feb 2015 13:07:29 +0800

Tom,

> code or actually putting them into products so that we can see how they actually

I thought there were activities going on to define an overall IETF yang
model, right? If we say we approach this in an iterative way would the
overall yang-model be the outcome of that process, rather than an input
to it. Or do I miss something?

/Loa

--

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 6 Feb 2015 11:32:48 -0500

> On Feb 6, 2015:12:07 AM, at 12:07 AM, Loa Andersson <[email-masked]> wrote:
> 
> Tom,
> 

	There is no such thing as an overall model; we have models that fit
together.  The hope is that the output is a model, but assuming it will never
evolve is very much an old way of thinking about how modern software engineering
works. Artifacts are ephemeral and adapt/evolve or are sidelined quickly. 

	--Tom

---

From: Loa Andersson <[email-masked]>
Date: Sun, 08 Feb 2015 18:26:12 +0800

Tom,

> works. Artifacts are ephemeral and adapt/evolve or are sidelined quickly.

What is the exact difference between "overall model" and "models that
fit together", isn't the essence of "fitting together" some sort of
overall-ness?

This seems to be what e.g. the LIME charter says - "...it is the
intention that the generic information and data models produced by
the working group should be applicable to multiple layers and
technologies in a technology agnostic fashion..."

/Loa

--

---

From: t.petch <[email-masked]>
Date: Wed, 11 Feb 2015 12:44:34 +0000

---- Original Message -----
From: "Thomas D. Nadeau" <[email-masked]>
To: "Loa Andersson" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 05, 2015 12:27 PM
> code or actually putting them into products so that we can see how
they actually

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

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 11 Feb 2015 13:20:20 +0000

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

> 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

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 11 Feb 2015 08:26:12 -0500

> On Feb 11, 2015:8:20 AM, at 8:20 AM, Dean Bogdanovic <[email-masked]> wrote:
> 
> 
	
	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.

> 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 provi…

	+1.

	--Tom

---

From: Qin Wu <[email-masked]>
Date: Thu, 12 Feb 2015 03:54:37 +0000

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

base model
standard extension model

Dean

[Qin]: Good point.