RE: WG Review: NETCONF Data Modeling Language (netmod)

"David Harrington" <> Wed, 23 April 2008 15:49 UTC

Return-Path: <>
Received: from (localhost []) by (Postfix) with ESMTP id 67B123A6E66; Wed, 23 Apr 2008 08:49:13 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 457613A6B9A for <>; Wed, 23 Apr 2008 08:49:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sPHUR++qW0gB for <>; Wed, 23 Apr 2008 08:49:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id ECFFB28C2F2 for <>; Wed, 23 Apr 2008 08:49:07 -0700 (PDT)
Received: from ([]) by with comcast id H2V61Z00b0QkzPwAA09d00; Wed, 23 Apr 2008 15:48:25 +0000
Received: from Harrington73653 ([]) by with comcast id H3p71Z0044HwxpC8N00000; Wed, 23 Apr 2008 15:49:13 +0000
X-Authority-Analysis: v=1.0 c=1 a=0gPrmgJd8jIA:10 a=v9OEfKO0-nUA:10 a=b5fn09ijqi0BEEJpLGAA:9 a=pTfPcPTvOirmJzAWbqcA:7 a=ryKvLgZ8qmMH6goMNMJ4MU_uISQA:4 a=lZB815dzVvQA:10 a=si9q_4b84H0A:10 a=hPjdaMEvmhQA:10 a=gJcimI5xSWUA:10
From: "David Harrington" <>
To: "'Eric Rescorla'" <>, "'Bert Wijnen - IETF'" <>
References: <><> <>
Subject: RE: WG Review: NETCONF Data Modeling Language (netmod)
Date: Wed, 23 Apr 2008 11:49:06 -0400
Message-ID: <013b01c8a559$91a23be0$>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
thread-index: Acikw0X/vRfR9NmGQGqlwEUBcIHzzQAij6Rg
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <>
List-Unsubscribe: <>, <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit


> -----Original Message-----
> From: [] On 
> Behalf Of Eric Rescorla

> > I propose that you list (again) your (technical) objections
> > to the the current proposal.
> Sure. Based on my knowledge of modelling/protocol description
> languages, the techniques that Rohan described based on RNG and
> Schematron seemed to me quite adequate to get the job done and the
> relatively large baggage introduced by defining another language
> (YANG) which is then translated into them seems wholly unnecessary.
> I appreciate that some people believe that YANG is more expressive
> better suited for this particular purpose, but I didn't see any
> convincing arguments of that (I certainly don't find the arguments
> F.2 of draft-bjorklund-netconf-yang dispositive). Given what I know
> the complexity of designing such languages, and of their ultimate
> limitations and pitfalls, this seems like a bad technical tradeoff.

The people who believe that YANG is more expressive and better suited
for this poarticular purpose include contributors to the design of
SMIv2, MIB Doctors, members of the NMRG who helped develop the SMING
information and data modeling language,  contributors to the SMIng WG
which worked on developing a proposed SMIv3 to converge the SMIv2
standard and the SPPI data modeling language standard and the NMRG
SMING approach, and engineers who have multiple independent
implementations of running code for Netconf data modeling. I respect
their experience and combined knowledge of the complexity of designing
such languages. 

I also respect operators' knowledge of the complexity of using such
languages to actually manage networks. The NM community has been
working to resolve the problem of the unsuitability of the IETF's
SNMP-only approach to configuration for many years, and the NM
comunity has deliberately sought out operators for feedback about what
does and what doesn't work well for them in configuration data

One of the major problems of designing a language for data modeling is
that there are many different constituencies with very different
requirements for a configuration language, which change over time, as
can be seen in RFC3139 and RFC3216 and RFC3535. There are a tremendous
number of potential tradeoffs to make a general-purpose language meet
"everybody's" needs. 

In RFC4101 "Writing Protocol Models", you argue that "reviewers have
only limited amounts of time" and 
  "most documents fail
   to present an architectural model for how the protocol operates,
   opting instead to simply describe the protocol and let the reviewer
   figure it out.

   This is acceptable when documenting a protocol for implementors,
   because they need to understand the protocol in any case; but it
   dramatically increases the strain on reviewers.  Reviewers need to
   get the big picture of the system and then focus on particular
   points.  They simply do not have time to give the entire document
   attention an implementor would."

The NM comunity sought out multiple operator communities, and came to
a similar conclusion. Operators need to "review" data model
specifications, and quickly understand the model, often while in the
middle of fire-fighting. To help address the need to quickly
understand the model, the MIB Doctors have developed guidelines and
templates for desecribing the data model in surrounding text. 

In practice, however, MIB modules are frequently distributed without
the surrounding document text, and operators responding to network
problems don't have time to find the right document and read it to
understand the model. As a result, the NM community concluded that
data models themselves need to be human readable. MIB modules, for
example, are read by agent implementers, application implementers,
operators, and applicatuon users (e.g., when MIB module descriptions
are presented as help files). NM data models are frequently developed
by enterprises to model their proprietary implementations, so it is
also important that the language be easy to write correctly. 

XSD can be very hard to read (and even harder to write accurately).
RelaxNG, possibly with Schematron, is better, but it can still be
difficult to understand. YANG was written with human-readability as
the highest priority.

In addition, there are some specific constructs important to managing
a network (and already available in MIB modules) that are not natively
supported in XSD or RNG, so existing XML-based tools are incapable of
writing and fully validating data models with these constructs. The NM
community thinks it would be a step backwards for the IETF to ignore
twenty years of consensus on the importance of these NM-related
constructs, and throw these away in order to use an existing standard
language that was designed for different purposes. Some major lessons
we learned from SMIv1 and SMIv2 was the difficulty of building atop
existing standards from other organizations with different goals, like
building SMI atop ASN.1, when the standards are likely to grow in
different directions than what we need for IETF NM data model
standardization purposes.

Unfortunately, you did not attend the many sessions over the past few
years as the NM community did comparisons of the suitability of SMIv2,
SPPI, SMING, XSD, RNG, YANG and others for purposes of configurastion
data modeling. But the community that has attended such discussions of
the suitability of different languages for the task at hand has
reached rough consensus and developed multiple implementations of
running code for this proposed direction forward. 

David Harrington

IETF mailing list