[NGO] Re: Why NETCONF needs a data modeling language

Hi Andy,

I want to comment first on one specific aspect of your message.  You talk
about XSD and Relax as if they are somehow similar in complexity. XSD is an
absolutely terrible schema definition language. It is hard to read, harder
to write, and extremely inflexible when it comes to schema extensibility.
The W3C no longer uses XSD because it is an absolutely awful PITA.  They use
Relax NG instead because it is actually pleasant to use, has a nice
extensibility model, and it is easy to learn and to use.

I have some additional comments inline.

On Nov 28, 2007 5:01 PM, Andy Bierman <ietf@andybierman.com> wrote:

> Hi,
>
> There are a few questions that the IESG and others have asked,
> which I will try to address:
>
>   Q1) Why does NETCONF need a DML at all?
>   Q2) Why is NETCONF special?
>   Q3) Why won't lots of other WGs want to define their own
>       protocol-specific DMLs?
>   Q4) Why isn't XSD or RelaxNG good enough?
>
>
>
> A1)
>
> NETCONF needs a formal description of the conceptual data
> within a NETCONF configuration database, in order to facilitate
> inter-operable implementations of NETCONF-related tools,
> such as agents, managers, and translators.

Agreed.

A textual representation is needed, to easily integrate
> semantic and syntactic information, in one file.  Translation
> or separation would introduce errors.

Letting this one sit.

> A protocol-specific data model definition is much more
> than an XML instance document description.

I agree.

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

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.

If vendors were given an information model instead of a data model,
> then they would be free to invent their own data model mappings.
> This would be a disaster for multi-vendor interoperability.
> Without a single, authoritative, precise definition of the
> syntax and semantics wrt/ NETCONF protocol handling, it is
> impossible for 3rd party application developers to even attempt
> to support NETCONF.

How do you see NETCONF playing out differently from the LDAP experience?  Do
you think that LDAP has been a success as an interoperable protocol?

> A2)
>
> NETCONF is a network management protocol, like SNMP.
> It happens to use XML encoding and Xpath filtering,
> but it is a network management protocol.  As such,
> network operators need to understand the conceptual
> management data available on a device (just like the CLI or the MIBs).
>
> XSD and RelaxNG are both complicated.

I think XSD is just plain awful and unintuitive. I'm not sure it is
complicated.  I don't think Relax NG is complicated. The specification and
the tutorial are both short and logical.

> Network operators are probably not trained programmers like
> protocol developers. There are way more operators than there
> are protocol developers, and they are much less likely to
> be involved in the standards process, than the protocol developer.

I completely agree with the statements above yet I came to the opposite
conclusion. I think operators are much more familiar and comfortable with
web standards than with MIB languages. The typical consumers of XML
documents are technical non-programmers (like most operators) and "soft"
programmers who do web programming.  A large portion of these folks are
using scripting languages like python to "screen scrape" XHTML.  That crowd
is going to be VERY comfortable with existing XML tools.

> The NETCONF WG evaluated XSD and RelaxNG last year.
> Examples of data models including the DIFFSERV Info Model
> were examined.  Nobody got excited about RNG.  For a real
> data model, RNG seemed to be just as impenetrable as XSD.
>
> Data model development in the NETCONF WG has been brutally
> slow with XSD.  XSD is a good language to use if you want
> to spend a long time learning what to do, and then spend
> a long time fixing what you did wrong.  Relatively few
> WG members have actually been able to learn either XSD or RNG.

I don't think XSD is good for anything actually.
I am extremely skeptical that anyone who spent more than a few hours was
acutally unable to learn Relax NG.
I am certainly happy to give a tutorial on the topic in Vancouver if anyone
is interested.

> Unlike other protocols that might use XML, a NETCONF data model
> is likely to be orders of magnitude larger.  So there is lots more data,
> that needs to be understood by lots of non-programmers.
>
> A3)
>
> If there are other WGs in the IETF who happen to use XML
> for representation of conceptual configuration databases,
> then I suppose they might ask for a new DML.  I suppose they
> will have to justify their request, no different than creating
> a new protocol in the first place.

At IETF, we have protocols conveying interesting data using XML coming out
our ears. For example. in the SIPPING WG we have the SIP UA profile
framework which needs some data definitions.

> If they are just using XML to define fairly static protocol PDUs,

None of these groups is interested in "fairly static" data.  They are
looking for data which is easily vendor extensible.

> then XSD or RNG should be used instead.
>
> A4)
>
> A YANG data model defines conceptual data within a NETCONF agent,
> just like SMIv2 does for SNMP.  It does not just define
> valid PDUs, like other protocols.  Instead, the specialized DML
> provides a concise description of all conceivable protocol behavior
> related to the management data.
>
> XSD and RNG do not even distinguish between read-only and read-write data.
> They are clearly not intended to be used a DMLs for conceptual
> datastores, like those found in SNMP or NETCONF.
> Instead, they describes XML instance documents.
>
> I have implemented a NETCONF agent, and IMO, 'standard' validation
> tools are useless.  Since <get> and <edit-config> allow
> an almost infinite combination of actual PDUs, the only
> thing these tools can do is identify and reject 'junk'
> namespaces and element names not supported by the agent.
> They cannot help at all with validating or automating
> NETCONF protocol operations or generating <rpc-error> responses.
>
> YANG describes NETCONF configuration databases.
> IMO, YANG is way more readable than RelaxNG, but
> that is subjective.

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.

> The SMIng WG got hung up for
> a long time trying to define objective criteria
> to evaluate DMLs, but in the end this was a total failure.

thanks,
-rohan