RE: WG Review: NETCONF Data Modeling Language (netmod)
"David Harrington" <ietfdbh@comcast.net> Wed, 23 April 2008 15:49 UTC
Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B123A6E66; Wed, 23 Apr 2008 08:49:13 -0700 (PDT)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 457613A6B9A for <ietf@core3.amsl.com>; Wed, 23 Apr 2008 08:49:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.413
X-Spam-Level:
X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sPHUR++qW0gB for <ietf@core3.amsl.com>; Wed, 23 Apr 2008 08:49:08 -0700 (PDT)
Received: from QMTA10.emeryville.ca.mail.comcast.net (qmta10.emeryville.ca.mail.comcast.net [76.96.30.17]) by core3.amsl.com (Postfix) with ESMTP id ECFFB28C2F2 for <ietf@ietf.org>; Wed, 23 Apr 2008 08:49:07 -0700 (PDT)
Received: from OMTA02.emeryville.ca.mail.comcast.net ([76.96.30.19]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id H2V61Z00b0QkzPwAA09d00; Wed, 23 Apr 2008 15:48:25 +0000
Received: from Harrington73653 ([24.128.66.199]) by OMTA02.emeryville.ca.mail.comcast.net 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 <ietfdbh@comcast.net>
To: 'Eric Rescorla' <ekr@networkresonance.com>, 'Bert Wijnen - IETF' <bertietf@bwijnen.net>
References: <20080422211401.303175081A@romeo.rtfm.com><NIEJLKBACMDODCGLGOCNCEGOEMAA.bertietf@bwijnen.net> <20080422215641.09FD05081A@romeo.rtfm.com>
Subject: RE: WG Review: NETCONF Data Modeling Language (netmod)
Date: Wed, 23 Apr 2008 11:49:06 -0400
Message-ID: <013b01c8a559$91a23be0$0600a8c0@china.huawei.com>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
In-Reply-To: <20080422215641.09FD05081A@romeo.rtfm.com>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
thread-index: Acikw0X/vRfR9NmGQGqlwEUBcIHzzQAij6Rg
Cc: ietf@ietf.org, iesg@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org
> -----Original Message----- > From: ietf-bounces@ietf.org [mailto:ietf-bounces@ietf.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@comcast.net ietfdbh@comcast.net dharrington@huawei.com _______________________________________________ IETF mailing list IETF@ietf.org https://www.ietf.org/mailman/listinfo/ietf
- Re: WG Review: NETCONF Data Modeling Language (ne… Chris Newman
- Re: [NGO] WG Review: NETCONF Data Modeling Langua… Phil Shafer
- Re: WG Review: NETCONF Data Modeling Language (ne… Eric Rescorla
- Re: WG Review: NETCONF Data Modeling Language (ne… Andy Bierman
- RE: WG Review: NETCONF Data Modeling Language (ne… Bert Wijnen - IETF
- Re: WG Review: NETCONF Data Modeling Language (ne… Eric Rescorla
- Re: WG Review: NETCONF Data Modeling Language (ne… Randy Presuhn
- Re: WG Review: NETCONF Data Modeling Language (ne… David Partain
- Re: WG Review: NETCONF Data Modeling Language (ne… Eric Rescorla
- Re: WG Review: NETCONF Data Modeling Language (ne… Eric Rescorla
- Re: WG Review: NETCONF Data Modeling Language (ne… David Partain
- RE: WG Review: NETCONF Data Modeling Language (ne… Bert Wijnen - IETF
- Re: WG Review: NETCONF Data Modeling Language (ne… David Partain
- Re: WG Review: NETCONF Data Modeling Language (ne… Andy Bierman
- Re: WG Review: NETCONF Data Modeling Language (ne… Eric Rescorla
- RE: WG Review: NETCONF Data Modeling Language (ne… Bert Wijnen - IETF
- RE: WG Review: NETCONF Data Modeling Language (ne… Bert Wijnen - IETF
- Re: WG Review: NETCONF Data Modeling Language (ne… David Partain
- Re: WG Review: NETCONF Data Modeling Language (ne… Eric Rescorla
- Re: WG Review: NETCONF Data Modeling Language (ne… Randy Presuhn
- Re: WG Review: NETCONF Data Modeling Language (ne… Eric Rescorla
- Re: WG Review: NETCONF Data Modeling Language (ne… Dave Crocker
- Re: WG Review: NETCONF Data Modeling Language (ne… Randy Presuhn
- RE: WG Review: NETCONF Data Modeling Language (ne… David Harrington
- Re: WG Review: NETCONF Data Modeling Language (ne… Harald Alvestrand
- Re: WG Review: NETCONF Data Modeling Language (ne… David Partain
- Re: WG Review: NETCONF Data Modeling Language (ne… Eric Rescorla
- Re: WG Review: NETCONF Data Modeling Language (ne… Andy Bierman
- Rough consensus among WHOM? Dave Crocker
- RE: WG Review: NETCONF Data Modeling Language (ne… Mehmet Ersue
- RE: WG Review: NETCONF Data Modeling Language (ne… Bert Wijnen - IETF
- Re: WG Review: NETCONF Data Modeling Language (ne… Michael Thomas
- RE: WG Review: NETCONF Data Modeling Language (ne… David Harrington
- Re: WG Review: NETCONF Data Modeling Language (ne… Andy Bierman
- RE: WG Review: NETCONF Data Modeling Language (ne… Leslie Daigle
- Re: WG Review: NETCONF Data Modeling Language (ne… Wes Hardaker
- Re: WG Review: NETCONF Data Modeling Language (ne… Tom.Petch
- Re: WG Review: NETCONF Data Modeling Language (ne… David Partain
- Re: WG Review: NETCONF Data Modeling Language (ne… Bernard Aboba
- RE: WG Review: NETCONF Data Modeling Language (ne… David Harrington
- Re: WG Review: NETCONF Data Modeling Language (ne… Bernard Aboba
- Re: WG Review: NETCONF Data Modeling Language (ne… Randy Presuhn