Re: analysis of YANG vs. RELAX NG

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Nov 27, 2007 at 11:54:23AM -0800, Lisa Dusseault wrote:

> Another question to answer, is why is having a data model (an ontology) not 
> enough?  The question of needing a standard data model must be separated 
> from the need for a custom modeling language.  Some of the justifications 
> I've seen so far for a modeling language have really been justifying only a 
> standard data model.

Different areas happen to use different terminology. What you call a
data model is what network management people happen to call an
information model, see RFC 3444. I don't care which terminology we use
in this discussion as long as we happen to understand the same thing
when we use the same words.

> Of course using XML as the data format doesn't, by itself, give enough of a 
> common data model for 3rd-party NetConf tools to understand arbitrary data. 
> NetConf probably does need a common data model, perhaps defining how IDs 
> are expressed and what a container is, what is a netconf "object" that can 
> be operated on.
>
> But a common data model does not need to depend on a modeling language at 
> all.  Put it differently: a sufficiently strong common data model can work 
> with multiple modeling languages without harming interoperability.  Thus, 
> having a standard data model that is independent of the modeling language 
> can be a real win for clarity and robustness and somewhat more proof 
> against changing stylistic preferences.

The network management world is used to automated processes and the
number of MIB modules in existences may serve as a proof that people
do find benefits from using machine readable definitions. OK, to be
fair, I must admit that SNMP is almost unusable with generic tools
without at least translating OIDs into something textual. But there is
of course much more you get out of concrete machine readable data
models since they can drive large (and annoying and error prone) parts
of implementation processes.

> The commonest approach for IETF protocols that deal with an ontology is to 
> define the data model in English, limiting the ways the data can be 
> expressed to something that becomes essentially self-describing (the name 
> of a new thing/object, and its contents or value, can be derived from the 
> document without seeing a specific schema).  LDAP is one of the clearest 
> examples of this.  An LDAP agent can handle custom content because it 
> follows the expected data model. There's no need, in LDAP, for a special 
> language to describe new attributes.  The iCalendar and vCard formats are 
> the same.  SNMP is really different in having a special language to learn, 
> and using that in specs.

I would call the "iCalendar apprach" semi-formal and this is likely
true for the others you mention as well. My understanding is that
iCalendar does in fact use some ABNF plus several other "conventions",
i.e., certain naming and structuring rules, value notation rules,
quoting rules and so on. So there is somewhat formalized content but I
also agree that the overall format is not as strict as the SMIv2 or
YANG or RelaxNG or XSD (just to name a few ;-).

I believe the key difference is simply the number of definitions
network management people happen to deal with. The complete
configuration of high-end routers involves significantly more than
just a few 10s of knobs. I am sure people from the network device
vendor business can provide concrete numbers concerning the size of
configuration options you find on today's products in case that is
useful. Once you reach a critical threshold, you really like to have
precise machine readable specifications that can drive a tool chain
and to some extend validate definitions, automate some of the
implementation work, reduce implementation bugs, drive documentation
tools and so on.

> My experience with description languages or other formalizations is that 
> these often take the place of proper specification.  Authors think that 
> they are done when they've written the code that describes the format.  
> However, the most important aspect to a new standard schema is usually what 
> it *means*.

Sure, languages can't turn lazy people into smart people. But the IETF
is actually very good at handling this. You can't publish a protocol
by writing down just a few ABNF definitions. You can't publish a MIB
module by leaving description clauses empty. You can't publish a
protocol by just writing down message formats in ASCII art and nothing
else. The key to good specifications is simply good reviews.

I do not really want to be involved in a high-level discussion whether
formalized notations, semi-formal notations, or plain English
notations are most useful and I hope we can avoid getting into such a
discussion to save us all time and bandwidth. I suggest that the WGs
and people actually involved in a given protocol take this decision.
Personally, I happen to believe that the scale in terms of the number
of definitions you have to handle determines whether machine readable
definitions are worth the extra formalization efforts.

In the case of NETCONF, it is important to allow operators to quickly
and easily understand what configuration knobs exist on their devices,
what they mean and how to turn them. A common notation is needed for
that so that SDOs, vendors, and operators have a common language to
work with. In order to deal with the large number of knobs you find on
today's devices, I believe that a formalized notation is well worth
the effort.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
Fax:   [phone]         <http://www.jacobs-university.de/>