ietf
[Top] [All Lists]

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

2008-04-23 09:53:03
David Harrington wrote:


Here are my reasons why I support the charter, which align with yours:

There are multiple types of users for data models.
The operators and reviewers care about the semantic model
much more than the syntactic mapping.  Ease of use and stability
have proven to be the most important factors for NM data models.

YANG provides enough semantic modeling to be useful for the
NM problem at hand, and since it will be owned by the IETF,
the complexity and stability will also be controllable by the IETF.

By decoupling the syntactic mapping from the semantic model,
the specific mapping rules can change over time as W3C standards
continue to evolve, without impacting any installed base of
data models.  Last year XSD was the only thing.  Now we seem to be
dropping XSD and adopting DSDL instead.  I am not convinced XSD is dead,
or the DSDL will be the final answer either.  But if the YANG
language stays stable, I don't care.


Andy


-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org 
[mailto:ietf-bounces(_at_)ietf(_dot_)org] 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
and
better suited for this particular purpose, but I didn't see any
really
convincing arguments of that (I certainly don't find the arguments
in
F.2 of draft-bjorklund-netconf-yang dispositive). Given what I know
of
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
modeling.

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
the
   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
dbharrington(_at_)comcast(_dot_)net
ietfdbh(_at_)comcast(_dot_)net
dharrington(_at_)huawei(_dot_)com


_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf





_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

<Prev in Thread] Current Thread [Next in Thread>