Re: analysis of YANG vs. RELAX NG

[Jon Saperia <[e-mail]>]

On Nov 28, 2007, at 3:38 AM, Juergen Schoenwaelder wrote:

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

Juergen, there is one additional point/requirement for a solution  
related to the number of objects you suggest.  That is the rate of  
change, not be the standards body, in this case since we are talking  
about configuration information, but by the vendors.  With each new  
technology, hardware platform, software revision and potentially  
firmware revision, a vendor will need to modify the 'knobs'.  This is  
where the formalized notation in my view has a strong payback.
>
> /js
>
> -- 
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: [phone]         Campus Ring 1, 28759 Bremen, Germany
> Fax:   [phone]         <http://www.jacobs-university.de/>
>
>

Thanks,
/jon
----
Jon Saperia
[e-mail]
(mobil)	617-201-2655
(office)	978-461-0249