ietf
[Top] [All Lists]

Re: Blog: YANG Really Takes Off in the Industry

2014-12-08 03:52:05
Hi Tom,
----- Original Message -----
From: "Ted Lemon" <Ted(_dot_)Lemon(_at_)nominum(_dot_)com>
To: "Dean Bogdanovic" <deanb(_at_)juniper(_dot_)net>
Cc: "IETF-Discussion list" <ietf(_at_)ietf(_dot_)org>
Sent: Tuesday, December 02, 2014 2:59 AM
Subject: Re: Blog: YANG Really Takes Off in the Industry


On Dec 1, 2014, at 8:54 PM, Dean Bogdanovic <deanb(_at_)juniper(_dot_)net> 
wrote:
this is one part I don't understand. Why adding another language would
make them less agile?

If the yang model isn't a good representation of what is being modeled,
it can cause more harm than good.   Same problem exists with MIBs.

<tp>

The difference is that MIBs are written in a much simpler language; what
object should there be, its syntax and status (index, read-only,
read-write) and that's about it (even augmentation tends to confuse many
people).  I have never yet met a MIB module that I could not reverse
engineer to determine the design, even the requirements.

YANG is different, it is capable of much more complicated things and
occasionally it is unclear what it does mean (something that surfaces on
the netmod WG list now and again).  What I think I see happening is what
happened when programming languages became more widely used, an
inability to keep things as simple as they could be, resulting in code
whose purpose was unclear, that was error-prone and hard to understand
or maintain.  Not an issue with SMI.

The YANG models of the IETF seem to be diving into complex code from
which it is hard to discern what the purpose is, and the fact that most
of the exemplars are written by those highly expert in YANG, and so use
the wide range of constructs available, does not help.

Perhaps the IESG should require that any IETF YANG data model must be
accompanied by an information model so that we can debate what should be
done independently of deciding how to do it.  After all, this is a
stricture that has been imposed on the I2RS WG.
Having information models (IM) before data models (DM) is the right theoretical approach. And I pushed that approach in the past, when YANG was not the data modeling of choice for configuration. I mean before the Writable MIB Module IESG Statement <https://www.ietf.org/iesg/statement/writable-mib-module.html>

However, I don't think it's appropriate any longer.
- what is the language for IM: text, UML, pseudo-code?
- when I discussed IM for DM with some operators, the answers were along these lines: "no IMs please, give me something that I can work with, so vendor-neutral DMs. And btw, this is urgent."
- as Alia mentioned, IM before DM didn't work too well for I2RS

In conclusion, at the time were DMs are urgent, I agree with Alia:

   "I'd rather see a section in the YANG model that describes the
   information and relationships - and then the pyang tree and the
   detailed model."

Regards, Benoit

Tom Petch








When different implementations of the same thing use different base
assumptions, it can be difficult to come up with a management model that
is congruent with all of the different base assumptions and is still
useful.   I wouldn't say it's impossible, but it's a good bet that a
poorly thought out model or a model that is based on experience with a
single implementation will fail in this regard.


.