Re: Why NETCONF needs a data modeling language

[Juergen Schoenwaelder <[e-mail]>]

On Wed, Nov 28, 2007 at 08:17:04PM -0800, Rohan Mahy wrote:

> > NETCONF needs
> > its own MIB language, just like SNMP needs SMIv2.
> 
> I don't think you've made a strong case here. You might be right, but your
> statements above do not strongly motivate a new language.

NETCONF needs a new language; whether it is a domain specific language
like YANG or an "adapted subset" of some existing XML schema language
does not change that fact that we will need a NETCONF data modeling
language and that we will need tools to understand that language.
 
> I don't think we can take it on blind faith that we need to do things in
> Netconf the way SNMP did them. I think it is very important to look at the
> reasons we thought that SNMP needed to be a certain way, but we also need to
> acknowledge that SNMP was hardly a success as a configuration protocol, and
> try to find out why. It is possible that the data model was too rigid for
> practical configuration use.

There has been a long discussion about why SNMP failed before the
NETCONF effort was started, all going back to IAB workshop [RFC 3535]
and lots of followup email discussions. I am not sure it is terrible
useful to redo this exercise. From what I recall, the rigidity of the
SMI was never mentioned as a major issue why SNMP failed to be a good
configuration protocol.

> Look at the following Relax NG in compact form, side-by-side with YANG.
> 
> container aaa {
>    container bbb {
>       leaf foo { type string; }
>       leaf bar { type uint32; }
>    }
> }
> 
> element aaa {
>    element bbb {
>       element foo { xsd:string },
>       element bar { xsd:unsignedInt }
>    }
> }
> 
> This hardly seems like a big difference to me.

I am not sure which point you are trying to make using examples that
ignore almost all NETCONF specifics. But even then, if you spell out
the additional NETCONF specific semantics which are hidden because
there are suitable defaults for the most common cases, then the YANG
example above actually expands to the following:

 container aaa {
    config true;
    status current;
    container bbb {
       status current;
       config true;
       leaf foo { 
          type string; 
          config true;
	  status current;
	  mandatory false;
       }
       leaf bar { 
          type uint32; 
          config true;
	  status current;
	  mandatory false;
       }
    }
 }

Statements like 'config true;' are essential for the processing of
NETCONF messages and also for validating content exchanged in NETCONF
messages (and this is why for example generic XML validation tools are
only of limited value for NETCONF implementors).

I am sure one can define an adapted subset of RNG which takes care of
all this and then at the end this adapted subset likely works like
YANG. However, given the SMI and ASN.1 experience, I do question

a) that doing so will lead to a large reuse of available RNG tools for
   processing NETCONF data models (since they don't know the RNG
   subset nor the semantic additions)

b) that the effort to specify such an extended subset will be less
   than the effort for defining a domain specific language like YANG

c) that the effort to implement tools understanding the adapted subset
   of RNG will be less than writing proper tools for a domain specific
   language from scratch

d) that there will be long term (say 20 year) reliable change control
   exercised by the organization that has change control over NETCONF

/js

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