Re: analysis of YANG vs. RELAX NG

[Juergen Schoenwaelder <[e-mail]>]

On Tue, Nov 27, 2007 at 01:03:55PM +0100, Martin Bjorklund wrote:

> "Rohan Mahy" <[e-mail]> wrote:
> > I read through the YANG I-D (draft-bjorklund-netconf-yang-00) and
> > thought immediately that all of the problems the draft is trying to
> > address looked very suitable to use RELAX NG as a schema language.
> > Looking at section F.2 (Why not RELAX NG) I did not see any specific
> > examples motivating the apparently contradictory statements that Relax
> > is not expressive enough and Relax is too expressive.
> 
> What we mean with this is that generic XML schema languages such as
> RelaxNG and XSD are designed to specify the grammar for (almost) any
> XML instance document.  For example they both support mixed content
> and XML attributes, neither of which we use in YANG.  You could of
> course just state that these constructs MUST NOT be used.

It might be important form some people on this list who are not too
heavily involved in the network management activities of the IETF to
know some of the history and experience with the IETF's SMI data
modeling language very widely used to write MIB modules (within the
IETF, by other SDOs, and a large number of device vendors; in 2005, I
counted ~170 IETF modules, ~480 Cisco modules, and ~100 Juniper
modules with a rough total of 32,000 object definitions [1]).

Back in the old times when SNMP came up, the language of the day was
called ASN.1. When the SMI became formalized (after it turned out that
plain textual descriptions are too difficult to be understood by
tools), something now called an adapted subset of ASN.1 was
created. The idea was to take ASN.1, forbit those constructs that are
somehow not useful in the SNMP context, and add some new constructs
via ASN.1 macros that carry the stuff needed for SNMP data
modeling. Since then, the SMI has become pretty much its own language
and almost all SNMP tools I have seen in the last decade actually do
not use generic ASN.1 parsers to parse MIB modules. There are several
reasons for this which I will not go into here. The experience,
however, has been that creating an "adapted subset" of ASN.1 (1987)
turned out to be no money or energy saver and there are still today
questions popping up whether some constructs are legal which you can't
easily answer since you need the 1987 spec of ASN.1 and then find the
"right" interpretation of it. (Note that the whole macro notation
meanwhile got dropped from ASN.1.)

I think it is important to consider the long term implications of
creating adapted subsets of other languages in the IETF. NETCONF needs
a data modeling language and framework that must be long term stable
and easy to use. I personally believe that designing a domain specific
language for NETCONF has large benefits since we can optimize the
language for what is needed for NETCONF, make the language simple to
read, ensure the language works well in the IETF process (max 76 ASCII
character lines, compact for plain text email discussions), and we can
have long term stability and full chance control in the IETF.

/js

[1] J. Schoenwaelder, Characterization of SNMP MIB Modules,
    Proc. 9th IFIP/IEEE International Symposium on Integrated Network
    Management, 2005

[2] K. McCloghrie, D. Perkins, J. Schoenwaelder, Structure of
    Management Information Version 2 (SMIv2), STD0058, April 1999

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