Why NETCONF needs a data modeling language

[Andy Bierman <[e-mail]>]

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.

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

A protocol-specific data model definition is much more
than an XML instance document description.  NETCONF needs
its own MIB language, just like SNMP needs SMIv2.

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.

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

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.

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.

If they are just using XML to define fairly static protocol PDUs,
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.  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.

For more information on how NETCONF uses XML, see sec. 1.2 of:
http://www.ietf.org/internet-drafts/draft-bierman-ncx-smi-00.txt


Andy