Subject: Why NETCONF needs a data modeling language

From: Andy Bierman <[email-masked]>
Date: Wed, 28 Nov 2007 17:01:37 -0800

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

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 28 Nov 2007 20:17:04 -0800

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.

> such as agents, managers, and translators.

Agreed.

> or separation would introduce errors.

Letting this one sit.

> than an XML instance document description.

I agree.

> NETCONF needs

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.

> impossible for 3rd party application developers to even attempt

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?

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

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

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

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

> 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

thanks,
-rohan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Nov 2007 12:34:46 +0100

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

> 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: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Phil Shafer <[email-masked]>
Date: Thu, 29 Nov 2007 08:14:45 -0500

"Rohan Mahy" writes:
>The W3C no longer uses XSD because it is an absolutely awful PITA.

Are you saying that w3c has stopped using xsd?  Can you
point me to a reference for that?

Thanks,
 Phil

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 29 Nov 2007 08:12:16 -0800

Hi Phil,

Organically as a practical matter, new work in W3C that uses XML is
definitely using Relax NG.  I don't think there is an official policy
statement or something like that.  A telling example is the XHTML2.0 spec
(work in progresss) at http://www.w3.org/TR/xhtml2/ . It is supposed to have
Normative schema in RNG (Sect B+C), XSD (Sect D+E), and DTD (Sect F+G).
Only Relax is filled in. I have spoken with folks active in other W3 working
groups and they report a similar pattern.

thanks,
-rohan

---

From: Chris Cross <[email-masked]>
Date: Thu, 29 Nov 2007 11:49:01 -0500

Rohan,
Some would argue that the XHTML2 document is a special case, as it has 
been a W3C political PITA ;-) Can you provide another example?

Chris

"Rohan Mahy" <[email-masked]> wrote on 11/29/2007 11:12:16 AM:

> definitely using Relax NG.  I don't think there is an official 
> policy statement or something like that.  A telling example is the 
> XHTML2.0 spec (work in progresss) at http://www.w3.org/TR/xhtml2/ . 
> It is supposed to have Normative schema in RNG (Sect B+C), XSD (Sect
> D+E), and DTD (Sect F+G).  Only Relax is filled in. I have spoken 
> with folks active in other W3 working groups and they report a 
> similar pattern. 
> 
> thanks,
> -rohan

---

From: Phil Shafer <[email-masked]>
Date: Thu, 29 Nov 2007 12:18:08 -0500

>groups and they report a similar pattern.

This only means that the author's of xhtml2 like rng more than xsd
(and dtd).  I surely don't blame them, but the fact that there's a
section for xsd conflicts your statement that "W3C no longer uses XSD".

In my world, we've seen no requests for rng.  No idea why.  I know
the WSDL world drinks XSD for breakfast, and are probably the heavy
users.  Me, I still think XSD is a "write-only" language.

Anyway, this is way off topic.....

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 30 Nov 2007 18:10:15 +0100 (CET)

Hi Rohan,

> This hardly seems like a big difference to me.

I take the liberty to slightly modify this example into:

    container aaa {
      container bbb {
        leaf ifAdminStatus {
          type string;
          description
            "The desired state of the interface.";
          mandatory true;
        }
        leaf ifOperStatus {
          type string;
          description
            "The current operational state of the interface.";
          config false;
        }
      }      
    }
    
It's still a bit simplified, e.g. the type is just a string; it should
really be an enumeration.

The plain RNC is then:

    element aaa {
      element bbb {
        element ifAdminStatus { type xsd:string }?,
        element ifOperStatus  { type xsd:string }?
      }
    }

First of all, these two examples may look similar, but they have
different meaning.  The YANG example defines objects in the
(configuration) data tree.  The RelaxNG example defines a pattern
which is used to validate some XML instance document.

Anyway, if we want to make this RNC as extensible as the corresponding
YANG version, we follow the recommendations in chapter 12 of the book:

    element aaa = aaa-content
    
    aaa-content =
      element bbb {
        bbb-content
      }
    
    bbb-content =
      element ifAdminStatus {
        ifAdminStatus-content
      }?,
      element ifOperStatus {
        ifOperStatus-content
      }?
    
    ifAdminStatus-content =
      type xsd:string
    
    ifOperStatus-content =
      type xsd:string

Next, we add the YANG specific annotations:

    element aaa = aaa-content
    
    aaa-content =
      element bbb {
        bbb-content
      }
    
    bbb-content =
      [
        yang:mandatory [ "true" ]
        yang:description [ "The desired state of the interface." ]
      ]
      element ifAdminStatus {
        ifAdminStatus-content
      }?,
      [
        yang:description [ 
          "The current operational state of the interface."
        ]
      ]
      element ifOperStatus {
        ifOperStatus-content
      }? >> yang:config [ "false" ] # I don't know if initial or
                                    # following annotations are
                                    # better (or even equal). 
    
    ifAdminStatus-content =
      type xsd:string
    
    ifOperStatus-content =
      type xsd:string

This is starting to become a bit difficult to grasp at first sight.
Maybe we should follow the recommendation in the book and work with
the XML notation instead.

On a higher level, what exactly is the interpretation of adding
e.g. the yang:mandatory true annotation to ifAdminStatus?  The annotation
is added to the pattern which matches the xml element <ifAdminStatus>.
But that is just the encoding of the underlying object.  What happens
with this annotation if ifAdminStatus is not present in an instance
document?  Should we modify the meaning of the RelaxNG patterns and
say that they also somehow define objects in the configuration data
tree?

This schema will validate <get> replies only, since it contains both
config and non-config data.  According to your email, we'll have to
add these to the definitions of get, get-config, edit-config, and
copy-config:

   get-reply-content &=
     aaa

   get-config-reply-content &=
     # hmm... how do I do this w/o copy&paste?  I just want
     # to add aaa/bbb/ifAdminstatus.

   edit-config-content &=
     # hmm... how do I do this w/o copy&paste?  I just want
     # to add aaa/bbb/ifAdminstatus, but also add some nc:opertaion
     # attributes.

All of this (and the other things we've discussed (and the things we
haven't yet discussed :) ) can probably be solved by writing rules to
restrict the usage of RelaxNG, add the necessary annotations (around
20), and write down extra interpretion of the RelaxNG constructs we're
using, but my conclusion is the same as Juergen's list a-d in his
latest email.  To this list I'd like to add the readibility issue.  

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 30 Nov 2007 11:29:41 -0800

David Harrington wrote:
> I'll take a whack at answering the same questions.
> 
> A1) Why does NETCONF need a DML at all?
> 
> to promote vendor-neutral interoperable management. 
> 
> It is much easier to develop standards when everybody uses the same
> basic language to communicate; this "common language for shared
> communication" is also reflected in the IETF decision to use English
> text and ASCII documents.
> 

This is a good point.
I always thought it was important that if I knew how
to read one MIB module, I knew how to read them all.

If though I know how to read XSD (and most of RNG),
vendors and WGs are all over the map wrt/ how they are used.

<plug>
IMO, there are language-independent issues, such as data
organization and data naming, that are discussed in
draft-bierman-ncx-smi-00.txt.  We should at least try
to understand the difference between the landscape
10 years from now, with and without any data organization
conventions.  These issues need to be dealt with consistently,
regardless of the DML being used.  Even if YANG is used,
the XSD translation needs to match in every way.
</plug>

> This is not just about being able to standardize **device
> management**; it is a basic step to permit the standardization of
> **network management** and possibly **services management". The DML is
> a basic building block.
> 
> A2) Why is NETCONF special?
> 
> It is and it isn't. Netconf is only one protocol used for network
> management. 
> 
> It has some unique requirements, such as using a document-based
> approach and differentiating the data for config versus state and for
> dealing with different time-defined contexts such as running and
> startup configs. This differs from other network management protocols,
> such as SNMP and syslog and ipfix, which use their own data formats,
> and usually deal only with the currently-running config. Netconf is a
> tool designed to meet the special requirements of configuration, and
> the DML needs to support special features not found in other NM-DMLs. 
> 
> Netconf is not special, in that any language used for network
> management is likely to have certain common requirements. NM data
> models are commonly used directly by humans, in their raw form, such
> as when they troubleshoot problems using network sniffers. NM data
> models are also commonly used by NMS applications that can handle the
> translations into a more human-readable format. Designers of NM tools
> (e.g., protocols and data models) thus need to pay close attention to
> who will use the information, and to assume that the data will be used
> both directly by humans and by applications. Operators have complained
> strongly that OIDs are very hard to work with in raw form, yet
> operators frequently need to deal with the raw form of the data.

Not just the OIDs, although they are horrible.
Also the limited data modeling capability,
primitive protocol operations, and the very
small granularity of data access.

NETCONF addresses many of the short-comings of SNMP,
which one would expect when given 15 years of hindsight
to start with.

> 
> A3) Why won't lots of other WGs want to define their own
>         protocol-specific DMLs?
> 
>.....
> A4) Why isn't XSD or RelaxNG good enough?
> 
> As mentioned in A2, NM data models need to be both machine- and
> human-readable. XSD is machine-readable, but it is a tough language
> for humans. RelaxNG seems better. 
> 
> As discussed further in a different email, Netconf will almost
> certainly need a DML suited to its requirements, and if RelaxNG is
> found to be human-friendly-enough, we would almost certainly still
> need to select a subset and adapt it to meet configuration
> requirements. So the benefit of using RelaxNG over a domain-specific
> DML may be lost by using an adapted-subset of RelaxNG.
> 
> Most operators already understand languages like Perl and C and
> Javascript, because they already need to write lots of scripts to
> manage their networks. Most implementers of NM support in
> internetworking devices work in C or a variant of C. It makes a lot of
> sense to use a language with a C-like syntax for these people, rather
> than forcing them to learn yet another language that was designed for
> some other purpose.

It is not an accident that YANG looks familiar to people
who know SMI and C.  YANG uses something similar to the
RNG-compact clause format, which is very readable, and very extensible.

YANG has some subtle improvements over SMI, besides the obvious ones.

In SMIv2 we write:

    InterfaceIndex ::= TEXTUAL-CONVENTION
        DISPLAY-HINT "d"
        STATUS       current
        DESCRIPTION
                "A unique value, greater than zero, for each interface
                or interface sub-layer in the managed system.  It is
                recommended that values are assigned contiguously
                starting from 1.  The value for each interface sub-
                layer must remain constant at least from one re-
                initialization of the entity's network management
                system to the next re-initialization."
        SYNTAX       Integer32 (1..2147483647)

In YANG:

    typedef InterfaceIndex {
        smiext:DISPLAY-HINT "d";
        status current;
        description
                "A unique value, greater than zero, for each interface
                or interface sub-layer in the managed system.  It is
                recommended that values are assigned contiguously
                starting from 1.  The value for each interface sub-
                layer must remain constant at least from one re-
                initialization of the entity's network management
                system to the next re-initialization.";
        type int32 {
           range "1..max";
        }
     }

Note 3 things:

   1) keywords that start a clause can have a prefix,
      meaning that they are language extensions, defined
      elsewhere with the 'extension' clause.

   2) strings are usually quoted, but if they don't contain
      whitespace, or a few special tokens, they can be unquoted,
      like 'current'.

   3) The range clause has 'min' and 'max' keywords, so you don't
      have to hunt down a previous example and paste in '2147483647'
      anymore.  The compiler will fill it in for you.

> 
> [soap]
> somebody commented that the designers of XSD and RelaxNG really
> understand how to design DMLs, implying that the OPS community does
> not. Many of the people involved in the ongoing DML discussions over
> the years, and now, are MIB Doctors and operators and protocol
> designers, and have had years of experience designing and working with
> SMI and network management. They understand the requirements of a DML
> for NM far more than the designers of XSD or RelaxNG, who were not
> designing their DMLs for NM purposes.
> [end soap]
> 
> David Harrington
> [email-masked]
> [email-masked]
> 
> 

Andy