Some background on YANG

[David Partain <[e-mail]>]

Hi all,

As some of you may know, a group of people proposed a BOF for the
upcoming IETF on a new modeling language that we call YANG. The
BOF proposal can be found at
http://www1.ietf.org/mail-archive/web/yang/current/msg00002.html
YANG is explicitly designed to be used for configuration of
network devices using NETCONF.

The BOF proposal was rejected by the IESG/IAB but we were asked
to take the discussion of YANG to the APPS area and will be doing
a brief presentation at the meeting on Monday next week in the
Applications Area Open Meeting at 9:00 in Salon 3.  This mail is
to give some background on where YANG comes from in order to get
the discussion going _before_ the meeting.

NETCONF lacks an interoperable, standardized way to create models
for configuration data.  In SNMP terms (if you're familiar with
those), we have no SMI to use to create MIBs.  This means that
today all NETCONF tools have to invent their own language to
define configuration models and a third-party "manager" has no
prayer of handling with all of the different languages used for
models.  In SNMP, _any_ manager can _at least_ parse a model and
do rudimentary management tasks simply given access to the MIB
document itself.  We're a long way from that with NETCONF and
YANG is intended to take us closer to that goal for NETCONF.

A few IETFs ago, I initiated a dialog with one NETCONF vendor
(Tail-F Systems) and asked them if they'd be interested in
working together on a common language.  That dialog soon included
a group of interested people who share the belief that this is a
serious problem that threatens to slow uptake of NETCONF, perhaps
make it irrelevant.  Since we all think that NETCONF has great
potential to improve a rather ugly O&M picture (where
configuration management is largely the domain of proprietary
solutions), we wanted to do something about that.  The list of
people involved, all of whom have been working with NETCONF a
long time, can be found in the draft, which is at
http://www.ietf.org/internet-drafts/draft-bjorklund-netconf-yang-00.txt

The IESG/IAB decision to reject the BOF was largely based on a
"not-invented -here" argument, meaning that there was a
perception that we were inventing something just because we
could, that the new language was not really necessary, and that
we should use XSD or RelaxNG instead.  We clearly believe that
there are good reasons _not_ to use existing languages for
configuration modeling in NETCONF and I hope a dialog during this
week and during the IETF will help understand why we believe
that.

In initial discussions among NETCONF implementors, an interesting
pattern emerged.  It turned out that in at least three cases, the
implmentor had first started by trying to use XSD for modeling
and had soon discovered that users were having great trouble
using it.  Then there was a brief walk into RelaxNG, before all
the companies in question decided that they needed to have
something else, so they invented their own language.  This wasn't
something that happened overnight or without serious
consideration.

Our first priority when designing YANG has been the reader of the
model.  We believe it is critical that a human (who today uses a
CLI) MUST be able to grok a model by reading it, without tools or
having to read a book first.  XSD, in our opinion, is not
readable by (almost any) humans.  Furthermore, history in the
NETCONF working group clearly demonstrates that humans are _very_
resistant to learning XSD and are not very good at debugging it.
Bugs have been found in the XSD used in the NETCONF protocol
specification after RFC publication after years of work in the
working group....

There are a number of reasons why we think YANG is the right way
to go _for modeling configuration data for NETCONF_.  It was not,
and still is not, our intention that YANG should be used as a
general modeling language by the IETF.  YANG is intended to be
specific to NETCONF needs, by design does not support arbitrary
XML instance documents, and has many features specific to NETCONF
and derived from 15 years of experience with the SMI data
modeling language for SNMP.

Network configuration is almost completely proprietary today.
The only possible way to change that is for vendors to agree on
the common knobs and how vendor knobs 'play nice' with standard
knobs.  Discussion of data models within a WG context is even
more critical than usual in this case.  We don't think this is
going to happen without a language that people understand, which
supports all the real needs of standards and vendor-based
configuration.

While we couldn't get it in advance of the -00 deadline, we'll
publish a "draft" on http://www.yang-central.org which makes a
case for using YANG rather than an existing language.  We'll send
a pointer to that document as soon as it's available (hopefully
today or tomorrow). 

Clearly, we don't believe XSD's place is in defining the
configuration models.  That doesn't mean that we think XSD has no
place in the NETCONF picture.  We believe that XSD has a very
important place, particularly in applications development.  For
this very reason, YANG models can be translated into both an XML
representation and XSD.  Tools already exist to do this.

Cheers,

David Partain