From yang-bounces@ietf.org Wed Nov 07 16:01:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ips1b-0005kP-AL; Wed, 07 Nov 2007 16:01:23 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Ips1Z-0005f8-LR for yang-confirm+ok@megatron.ietf.org; Wed, 07 Nov 2007 16:01:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ips1Z-0005f0-At for yang@ietf.org; Wed, 07 Nov 2007 16:01:21 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ips1V-0001Yj-U3 for yang@ietf.org; Wed, 07 Nov 2007 16:01:21 -0500 Received: from localhost (c213-100-166-201.swipnet.se [213.100.166.201]) by mail.tail-f.com (Postfix) with ESMTP id 7CF3B1B80C7 for ; Wed, 7 Nov 2007 22:01:16 +0100 (CET) Date: Wed, 07 Nov 2007 22:04:35 +0100 (CET) Message-Id: <20071107.220435.215571175.mbj@tail-f.com> To: yang@ietf.org From: Martin Bjorklund X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [YANG] YANG draft X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : YANG - A data modeling language for NETCONF Author(s) : M. Bjorklund Filename : draft-bjorklund-netconf-yang-00.txt Pages : 147 Date : 2007-11-07 YANG is a data modeling language used to model configuration and state data manipulated by the NETCONF protocol, NETCONF remote procedure calls, and NETCONF notifications. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-bjorklund-netconf-yang-00.txt /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Nov 08 04:48:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq3zb-000433-4E; Thu, 08 Nov 2007 04:48:07 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Iq3za-00040j-2o for yang-confirm+ok@megatron.ietf.org; Thu, 08 Nov 2007 04:48:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iq3zP-0003or-Np; Thu, 08 Nov 2007 04:47:55 -0500 Received: from nj300815-nj-outbound.net.avaya.com ([198.152.12.100] helo=nj300815-nj-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iq3zL-0007S0-9M; Thu, 08 Nov 2007 04:47:55 -0500 X-IronPort-AV: E=Sophos;i="4.21,388,1188792000"; d="scan'208";a="76890104" Received: from 5.6.8.135.in-addr.arpa (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by nj300815-nj-outbound.avaya.com with ESMTP; 08 Nov 2007 04:47:51 -0500 X-IronPort-AV: E=Sophos;i="4.21,388,1188792000"; d="scan'208";a="123061300" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.14]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 08 Nov 2007 04:47:49 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 8 Nov 2007 10:47:41 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for Candidates - NETCONF WG chairs Thread-Index: Acgh7GeEK+PXzx1HSYCbZXmfNI4T5A== From: "Romascanu, Dan (Dan)" To: "Netconf WG" X-Spam-Score: 1.1 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: ngo@ietf.org, yang@ietf.org, Ron Bonica , ops-area@ietf.org Subject: [YANG] Call for Candidates - NETCONF WG chairs X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org A new charter for the NETCONF Working Group is right now in review. We expect it to be approved before the Vancouver meeting.=20 As you may know Andy Bierman and Simon Linen who chaired the working group from its start express the desire to step down from their positions of co-chairs by the time the Working Group engages in the new phase of NETCONF.=20 The ADs have decided to write down a brief profile for the WG chair(s) and issue an open call for candidates.=20 We would like you to consider this profile and either nominate yourself or other people that you think that would fit well in this role by sending mail to the OPS ADs. (dromasca@avaya.com and rbonica@juniper.net) We do not intend to disclose the names of the nominees in public, but we will probably solicit for feedback with various other people. If you have a problem with your name being mentioned in this context, pls let us know. Note that this profile is written for a somewhat ideal candidate. We fully realize that such people are probably non-existent, so don't hesitate to nominate somebody who in your opinion would fit this role quite well but doesn't fit this profile 100%. And the intend is to select two co-chairs that can complement each other and work together. As for the profile: =20 - Good management and process skills, including but not limited to choosing and supervising editors, commitment and follow-through on the charter, active management of the working group discussions, and handling IETF process steps in prompt fashion. - Good basic knowledge of the NETCONF protocols - Understanding of the requirements/needs/applications of management protocols. - Operational background/experience is very desirable. - Enough available time. For example, preferable not more than one other working chair role in IETF. - There is no requirement that the candidate has been an IETF working group chair before, but it helps if there is some evidence that the candidate can fulfill such a role (e.g.. other management role in other places than IETF etc.) We would like to receive your comments & nominations by November 16, 2007 and we plan to make a decision as soon as possible thereafter. It will be helpful if you indicate in your nomination mail how you or the nominated candidate fits this profile as best as possible. =20 And last but not least, we would like to thank Andy and Simon for leading and guiding the work to develop NETCONF. Their contribution was tremendous and we hope that they will continue to contribute to the NETCONF WG and other related activities in the area.=20 Ron and Dan _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Mon Nov 19 04:55:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3Li-0004SJ-Ig; Mon, 19 Nov 2007 04:55:26 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Iu3Lh-0004PY-El for yang-confirm+ok@megatron.ietf.org; Mon, 19 Nov 2007 04:55:25 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iu3Lb-0004IP-RZ for yang@ietf.org; Mon, 19 Nov 2007 04:55:19 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iu3Lb-0004Wr-FW for yang@ietf.org; Mon, 19 Nov 2007 04:55:19 -0500 Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTP id 545451B80D9 for ; Mon, 19 Nov 2007 10:55:17 +0100 (CET) Date: Mon, 19 Nov 2007 10:56:03 +0100 (CET) Message-Id: <20071119.105603.150508481.mbj@tail-f.com> To: yang@ietf.org From: Martin Bjorklund X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [YANG] YANG tools etc X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, We have set up a site dedicated to YANG, http://www.yang-central.org There you can find some free tools, examples, a tutorial etc. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Nov 27 02:36:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwuzZ-0006wv-0W; Tue, 27 Nov 2007 02:36:25 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IwuzX-0006rg-LY for yang-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 02:36:24 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwuzR-0006Yo-Q4 for yang@ietf.org; Tue, 27 Nov 2007 02:36:17 -0500 Received: from mailgw3.ericsson.se ([193.180.251.60]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwuzQ-0008HM-Rd for yang@ietf.org; Tue, 27 Nov 2007 02:36:17 -0500 Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1216E206E7 for ; Tue, 27 Nov 2007 08:36:16 +0100 (CET) X-AuditID: c1b4fb3c-b1f9bbb0000030cf-41-474bc8ef79fb Received: from esealmw127.eemea.ericsson.se (unknown [153.88.254.122]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E7D0020816 for ; Tue, 27 Nov 2007 08:36:15 +0100 (CET) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 08:36:15 +0100 Received: from selic023.lmera.ericsson.se ([150.132.89.214]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Nov 2007 08:36:15 +0100 Content-Disposition: inline From: David Partain Organization: Ericsson AB To: yang@ietf.org Date: Tue, 27 Nov 2007 08:36:14 +0100 User-Agent: KMail/1.9.8 MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200711270836.14710.david.partain@ericsson.com> X-OriginalArrivalTime: 27 Nov 2007 07:36:15.0445 (UTC) FILETIME=[310AE850:01C830C8] X-Brightmail-Tracker: AAAAAA== X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Subject: [YANG] Fwd: Some background on YANG X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Greetings, I forgot to cc this list. If you're interested, you might want to join the apps discuss list. See https://www1.ietf.org/mailman/listinfo/discuss Cheers, David ---------- Forwarded Message ---------- Subject: Some background on YANG Date: Tuesday 27 November 2007 From: David Partain To: discuss@apps.ietf.org 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 ------------------------------------------------------- _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Tue Nov 27 06:14:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwyOX-0006DL-5s; Tue, 27 Nov 2007 06:14:25 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IwyOU-00067e-S4 for yang-confirm+ok@megatron.ietf.org; Tue, 27 Nov 2007 06:14:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwyOO-00065y-LE for yang@ietf.org; Tue, 27 Nov 2007 06:14:16 -0500 Received: from co300216-co-outbound.net.avaya.com ([198.152.13.100] helo=co300216-co-outbound.avaya.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IwyOK-0001Es-Jq for yang@ietf.org; Tue, 27 Nov 2007 06:14:16 -0500 X-IronPort-AV: E=Sophos;i="4.23,219,1194238800"; d="scan'208,217";a="86902677" Received: from unknown (HELO nj300815-nj-erheast.avaya.com) ([198.152.6.5]) by co300216-co-outbound.avaya.com with ESMTP; 27 Nov 2007 06:14:11 -0500 X-IronPort-AV: E=Sophos;i="4.23,219,1194238800"; d="scan'208,217";a="128503837" Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.16]) by nj300815-nj-erheast-out.avaya.com with ESMTP; 27 Nov 2007 06:13:31 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 27 Nov 2007 12:13:07 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: analysis of YANG vs. RELAX NG Thread-Index: AcgwuTJaZ41AAbpyQx6O+E9cogUIfwALRZGA From: "Romascanu, Dan (Dan)" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 4cbeb0f20efb229aa93fae1468d20275 Subject: [YANG] FW: analysis of YANG vs. RELAX NG X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1092809690==" Errors-To: yang-bounces@ietf.org This is a multi-part message in MIME format. --===============1092809690== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C830E6.7D1F0AE5" This is a multi-part message in MIME format. ------_=_NextPart_001_01C830E6.7D1F0AE5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FYI, from the applications discussions list.=20 =20 As David pointed it would be good if folks involved with NETCONF and yang joined discuss@apps.ietf.org. =20 Dan =20 =20 =20 =20 ________________________________ From: Rohan Mahy [mailto:rohan.mahy@gmail.com]=20 Sent: Tuesday, November 27, 2007 7:49 AM To: discuss@apps.ietf.org Subject: analysis of YANG vs. RELAX NG Hi, I read through the YANG I-D (draft-bjorklund-netconf-yang-00) and thought immediately that all of the problems the draft is trying to address looked very suitable to use RELAX NG as a schema language. Looking at section F.2 (Why not RELAX NG) I did not see any specific examples motivating the apparently contradictory statements that Relax is not expressive enough and Relax is too expressive. Below is a comparison of YANG integral types and common idioms to integral types/idioms available in RELAX NG. I seems pretty clear to me that expressing any of the idioms in YANG should be straightforward in RELAX NG and very easy to read and write. =20 Writing a schema language is a lot of work, and I can't imagine the IETF designing one that would only be used by NETCONF. RELAX NG has existing tools and parsers, has additional integral types (ex: URI, dates, and times), and was written by a large group of folks who have tons of experience designing schema languages.=20 thanks, -rohan BUILT IN TYPES yang: relax: int8 byte int16 short int32 int int64 long uint8 unsignedByte uint16 unsignedShort uint32 unsignedInt uint64 unsignedLong=20 float32 float float64 double string string boolean boolean binary base64Binary empty anyxml union or =20 enumeration, =20 bits foo bar =20 keyref and instance-identifier are probably better served by referencing an 'id' attribute and using the 'ID' type, but doing exactly what is done in YANG could still be handled easily using an anyURI restricted to be an XPath expression.=20 Below, I also show examples of the YANG concepts of leaf node, leaf-list, container, and list expressed in YANG, how it would be expressed in NETCONF, and expressed in RELAX NG.=20 LEAF yang: leaf host-name { type string; description "Hostname for this system"; } netconf: my.example.com=20 relax: Hostname for this system LEAF-LIST=20 yang: leaf-list domain-search { type string; } netconf: example.com example.org relax: =20 CONTAINER yang: container system { container login { leaf message { type string; } } } netconf: =20 Hello Dave relax: =20 LIST yang: list user { key "name"; leaf name { type string; } leaf class { type string; } } netconf: alice human cheshire cat=20 relax: name =20 ------_=_NextPart_001_01C830E6.7D1F0AE5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
FYI, from the applications discussions list.=20
 
As David pointed it would be good if folks = involved=20 with NETCONF and yang joined discuss@apps.ietf.org.
 
Dan
 
 
 
 

From: Rohan Mahy = [mailto:rohan.mahy@gmail.com]=20
Sent: Tuesday, November 27, 2007 7:49 AM
To:=20 discuss@apps.ietf.org
Subject: analysis of YANG vs. RELAX=20 NG

Hi,

I read through the YANG I-D=20 (draft-bjorklund-netconf-yang-00) and thought immediately that all of = the=20 problems the draft is trying to address looked very suitable to use = RELAX NG as=20 a schema language.  Looking at section F.2 (Why not RELAX NG) I did = not see=20 any specific examples motivating the apparently contradictory statements = that=20 Relax is not expressive enough and Relax is too expressive.

Below = is a=20 comparison of YANG integral types and common idioms to integral = types/idioms=20 available in RELAX NG. I seems pretty clear to me that expressing any of = the=20 idioms in YANG should be straightforward in RELAX NG and very easy to = read and=20 write. 

Writing a schema language is a lot of work, and I = can't=20 imagine the IETF designing one that would only be used by NETCONF. RELAX = NG has=20 existing tools and parsers, has additional integral types (ex: URI, = dates, and=20 times), and was written by a large group of folks who have tons of = experience=20 designing schema languages.

thanks,
-rohan


BUILT = IN=20 TYPES
yang:   =20 relax:
int8    =20 byte
int16   =20 short
int32    = intint64   =20 long
uint8   =20 unsignedByte
uint16  =20 unsignedShort
uint32  =20 unsignedInt
uint64   = unsignedLong=20
float32  = floatfloat64  = doublestring   = stringboolean  = booleanbinary  =20 base64Binary
empty   =20 <empty/>
anyxml  =20 <anyName/>
union   =20 <choice>  or    <interleaved>
enumeration,=20 <text><choice> bits         =  =20 <value>foo</value>         &nbs= p;    =20 <value>bar</value>         &nbs= p;  =20 </choice></text>

keyref and = instance-identifier are=20 probably better served by referencing an 'id' attribute and using the = 'ID' type,=20 but doing exactly what is done in YANG could still be handled easily = using an=20 anyURI restricted to be an XPath expression.

Below, I also show = examples=20 of the YANG concepts of leaf node, leaf-list, container, and list = expressed in=20 YANG, how it would be expressed in NETCONF, and expressed in RELAX NG.=20


LEAF
yang:
leaf host-name {
  type = string;
 =20 description "Hostname for this=20 system";
}

netconf:
<host-name>my.example.com</host-name>=20

relax:
<element name=3D"host-name">
 =20 <other:description>Hostname for this=20 system</other:description>
  <data=20 type=3D"string"/>
</element>

LEAF-LIST =
yang:
leaf-list=20 domain-search {
  type=20 string;
}

netconf:
<domain-search>example.com</domain-search>
<= domain-search>=20 example.org</domain-search>

= relax:
<zeroOrMore>=20 <!-- could be oneOrMore instead -->
  <element=20 name=3D"domain-search">
    <text/>  = <!-- this=20 is an alias for data type=3D"string" -->
 =20 </element>
</zeroOrMore>

CONTAINER
yang:
cont= ainer=20 system {
  container login {
    leaf message=20 {
      type string;
   =20 }
  }
}

netconf:
<system>
  = <login>=20
    <message>Hello = Dave</message>
 =20 </login>
</system>

relax:
<element=20 name=3D"system">
  <element = name=3D"login">
   =20 <element name=3D"message">
     =20 <text/>
    </element>
 =20 </element>
</element>


LIST
yang:
list = user=20 {
  key "name";
  leaf name {
    type = string;
  }
  leaf class {
    type=20 string;
  }
}

netconf:
<user>
 =20 <name>alice</name>
 =20 <class>human</class>
</user>
<user>
&nbs= p;=20 <name>cheshire</name>
  = <class>cat</class>=20
</user>

relax:
<zeroOrMore>
  = <element=20 name=3D"user">
   =20 <other:key>name</other:key>
    = <element=20 name=3D"name">
     =20 <text/>
    </element> =
   =20 <element name=3D"class">
     =20 <text/>
    </element>
 =20 </element>
</zeroOrMore>


------_=_NextPart_001_01C830E6.7D1F0AE5-- --===============1092809690== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang --===============1092809690==-- From yang-bounces@ietf.org Wed Nov 28 20:02:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxXn1-0002B3-0d; Wed, 28 Nov 2007 20:02:03 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IxXmz-00027j-5d for yang-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 20:02:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxXmt-00024f-4k for yang@ietf.org; Wed, 28 Nov 2007 20:01:55 -0500 Received: from smtp117.sbc.mail.sp1.yahoo.com ([69.147.64.90]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IxXms-0000kO-D0 for yang@ietf.org; Wed, 28 Nov 2007 20:01:55 -0500 Received: (qmail 26228 invoked from network); 29 Nov 2007 01:01:53 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.121.107.88 with plain) by smtp117.sbc.mail.sp1.yahoo.com with SMTP; 29 Nov 2007 01:01:53 -0000 X-YMail-OSG: lskllUoVM1kEpRYjBQCAW6.I7esQD27gQCg_xjT2Jkz9.zHsKRKiKyatICCmIWMwAQidk0mlXo3ldbs2j7O1wCg. Message-ID: <474E0F71.2050003@andybierman.com> Date: Wed, 28 Nov 2007 17:01:37 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: discuss@apps.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: yang@ietf.org, NETCONF Goes On Subject: [YANG] Why NETCONF needs a data modeling language X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org 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 and 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 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 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Nov 29 06:35:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixhfe-0003Ta-Hc; Thu, 29 Nov 2007 06:35:06 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Ixhfd-0003Rr-MO for yang-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 06:35:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxhfX-0003Oz-R1; Thu, 29 Nov 2007 06:34:59 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxhfV-0008U4-Qv; Thu, 29 Nov 2007 06:34:59 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 122048A243; Thu, 29 Nov 2007 12:34:57 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 08286-03; Thu, 29 Nov 2007 12:34:52 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F0E88A241; Thu, 29 Nov 2007 12:34:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E527D4022B7; Thu, 29 Nov 2007 12:34:46 +0100 (CET) Date: Thu, 29 Nov 2007 12:34:46 +0100 From: Juergen Schoenwaelder To: Rohan Mahy Message-ID: <20071129113446.GB10751@elstar.local> References: <474E0F71.2050003@andybierman.com> <953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: yang@ietf.org, discuss@apps.ietf.org, NETCONF Goes On Subject: [YANG] Re: Why NETCONF needs a data modeling language X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Wed, Nov 28, 2007 at 08:17:04PM -0800, Rohan Mahy wrote: > > NETCONF needs > > its own MIB language, just like SNMP needs SMIv2. > > 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. 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. > 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. 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. > 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. 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 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Nov 29 08:18:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxjHP-0004pX-TR; Thu, 29 Nov 2007 08:18:11 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IxjHP-0004pK-8y for yang-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 08:18:11 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxjHO-0004ou-2a; Thu, 29 Nov 2007 08:18:10 -0500 Received: from exprod7og111.obsmtp.com ([64.18.2.175]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IxjHN-0000pH-Kx; Thu, 29 Nov 2007 08:18:09 -0500 Received: from source ([66.129.224.36]) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP; Thu, 29 Nov 2007 05:18:03 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 Nov 2007 05:18:02 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lATDI1E01926; Thu, 29 Nov 2007 05:18:01 -0800 (PST) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id lATDEklv047248; Thu, 29 Nov 2007 13:14:46 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200711291314.lATDEklv047248@idle.juniper.net> To: "Rohan Mahy" In-reply-to: <953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> Date: Thu, 29 Nov 2007 08:14:45 -0500 From: Phil Shafer X-OriginalArrivalTime: 29 Nov 2007 13:18:02.0739 (UTC) FILETIME=[452B2430:01C8328A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: yang@ietf.org, discuss@apps.ietf.org, NETCONF Goes On Subject: [YANG] Re: Why NETCONF needs a data modeling language X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org "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 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Thu Nov 29 09:34:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxkT6-0003qr-R6; Thu, 29 Nov 2007 09:34:20 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Ixapp-000328-4H for yang-confirm+ok@megatron.ietf.org; Wed, 28 Nov 2007 23:17:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixapo-00031y-QX for yang@ietf.org; Wed, 28 Nov 2007 23:17:08 -0500 Received: from el-out-1112.google.com ([209.85.162.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixapl-0002y8-T7 for yang@ietf.org; Wed, 28 Nov 2007 23:17:08 -0500 Received: by el-out-1112.google.com with SMTP id r23so1009316elf for ; Wed, 28 Nov 2007 20:17:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=6Ed99SuaAimYpZMgXj2FdqvVWDrdzz7mwQouGVxHDt8=; b=wwhynZm+0nloWeyVHzofFvT9ntKnUax4leP0ouHwiSSL64+vPLgcrw5+ve+QDU/37S+hNITWm7mnYJSnS2xwOagdsQ1rC9Bj65WDMah1B/rn2sba/RZmHgqcWx0LBbtr0Un1BiwSAGkTGJIa30s8WO7PUBy/6vkYKQcSSm4w3ec= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=oCJO2t8buvQ/5zP23rlcGvrUSoKU2HKPsp70/CoUycK/rHo4UiKWKUzCWBebzLxDPwaJQ99BESs8W3zd7H0RVC4QeIcQpAu5gW6xpOBeLoh69NA7onhFsXLzjtMMXiWgw0oQ/bzyo9CP1H+DOUSPk4WJ7GKmWa5ubz4rH2XlN9g= Received: by 10.142.128.6 with SMTP id a6mr1758191wfd.1196309824611; Wed, 28 Nov 2007 20:17:04 -0800 (PST) Received: by 10.142.214.15 with HTTP; Wed, 28 Nov 2007 20:17:04 -0800 (PST) Message-ID: <953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> Date: Wed, 28 Nov 2007 20:17:04 -0800 From: "Rohan Mahy" To: "Andy Bierman" In-Reply-To: <474E0F71.2050003@andybierman.com> MIME-Version: 1.0 References: <474E0F71.2050003@andybierman.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 3f3e54d3c03ed638c06aa9fa6861237e X-Mailman-Approved-At: Thu, 29 Nov 2007 09:34:19 -0500 Cc: yang@ietf.org, discuss@apps.ietf.org, NETCONF Goes On Subject: [YANG] Re: Why NETCONF needs a data modeling language X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0913269421==" Errors-To: yang-bounces@ietf.org --===============0913269421== Content-Type: multipart/alternative; boundary="----=_Part_7641_25750232.1196309824605" ------=_Part_7641_25750232.1196309824605 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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. On Nov 28, 2007 5:01 PM, Andy Bierman wrote: > 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. Agreed. A textual representation is needed, to easily integrate > semantic and syntactic information, in one file. Translation > or separation would introduce errors. Letting this one sit. > A protocol-specific data model definition is much more > than an XML instance document description. I agree. > NETCONF needs > its own MIB language, just like SNMP needs SMIv2. 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. 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. 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? > 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. 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. > 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. 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. > 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. 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. > 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. 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. > 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 and 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 responses. > > YANG describes NETCONF configuration databases. > IMO, YANG is way more readable than RelaxNG, but > 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 > a long time trying to define objective criteria > to evaluate DMLs, but in the end this was a total failure. thanks, -rohan ------=_Part_7641_25750232.1196309824605 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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.

On Nov 28, 2007 5:01 PM, Andy Bierman <ietf@andybierman.com> wrote:
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.

Agreed.

A textual representation is needed, to easily integrate
semantic and syntactic information, in one file.  Translation
or separation would introduce errors.

Letting this one sit.
 
A protocol-specific data model definition is much more
than an XML instance document description.  

I agree.
 
NETCONF needs
its own MIB language, just like SNMP needs SMIv2.

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.

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.

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

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

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

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

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

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
a long time trying to define objective criteria
to evaluate DMLs, but in the end this was a total failure.


thanks,
-rohan
------=_Part_7641_25750232.1196309824605-- --===============0913269421== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang --===============0913269421==-- From yang-bounces@ietf.org Thu Nov 29 11:12:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixlzv-0000Cx-IL; Thu, 29 Nov 2007 11:12:19 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Ixlzu-00008q-IK for yang-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:12:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixlzu-00008e-6e for yang@ietf.org; Thu, 29 Nov 2007 11:12:18 -0500 Received: from el-out-1112.google.com ([209.85.162.182]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Ixlzt-0006y9-RS for yang@ietf.org; Thu, 29 Nov 2007 11:12:18 -0500 Received: by el-out-1112.google.com with SMTP id r23so1162761elf for ; Thu, 29 Nov 2007 08:12:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=OohzOXp4fs5xlzZo+NlAzuE56Ci0ckRGKDzbAoiXIzY=; b=M4GrP6EyeKW62M2pEQq2QGqu1riDCl0Efq5M40iHk9EfCtqYMVGq9sEZ3VKvc9O93eQ25t2Jj/+cSgm5VPCNZwo04FLRXDgCnpg56GDIxDdhVJCtrmuwac5fo+mlxb/TwHrJIY80i4HVxqlbzVkDPXsgaF7+Bu24r0ZVXlGANx0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=R/kA8NpHSa51/nlEYDpqPnLB7ZVp/N7jOS0p/oSESF6xRIori31xHPvH6+ti3QBfDn/6ybrGEue1dY996BNvJZEZhY6C6kHKnZyMsYX613AVpjMPzDXE3V1yUo9mrcM5C4XQ3FLnI+euoBF8M2e+7mIfe29ZtrHNFTLrKtmjo5o= Received: by 10.142.104.9 with SMTP id b9mr1956024wfc.1196352736725; Thu, 29 Nov 2007 08:12:16 -0800 (PST) Received: by 10.142.214.15 with HTTP; Thu, 29 Nov 2007 08:12:16 -0800 (PST) Message-ID: <953beacc0711290812t68d2cc09se1f4ff0578cc5836@mail.gmail.com> Date: Thu, 29 Nov 2007 08:12:16 -0800 From: "Rohan Mahy" To: "Phil Shafer" In-Reply-To: <200711291314.lATDEklv047248@idle.juniper.net> MIME-Version: 1.0 References: <953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> <200711291314.lATDEklv047248@idle.juniper.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: yang@ietf.org, discuss@apps.ietf.org, NETCONF Goes On Subject: [YANG] Re: Why NETCONF needs a data modeling language X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1329189239==" Errors-To: yang-bounces@ietf.org --===============1329189239== Content-Type: multipart/alternative; boundary="----=_Part_1904_6233573.1196352736719" ------=_Part_1904_6233573.1196352736719 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 On Nov 29, 2007 5:14 AM, Phil Shafer wrote: > "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 > ------=_Part_1904_6233573.1196352736719 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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

On Nov 29, 2007 5:14 AM, Phil Shafer <phil@juniper.net> wrote:
"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

------=_Part_1904_6233573.1196352736719-- --===============1329189239== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang --===============1329189239==-- From yang-bounces@ietf.org Thu Nov 29 11:51:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixmby-0006sh-Gp; Thu, 29 Nov 2007 11:51:38 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IxmZp-0004JT-Ap for yang-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:49:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmZp-0004JG-0y; Thu, 29 Nov 2007 11:49:25 -0500 Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxmZo-0005t0-Jl; Thu, 29 Nov 2007 11:49:24 -0500 Received: from d01relay06.pok.ibm.com (d01relay06.pok.ibm.com [9.56.227.116]) by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id lATGn6K5032764; Thu, 29 Nov 2007 11:49:06 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay06.pok.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id lATGn6uh1077374; Thu, 29 Nov 2007 11:49:06 -0500 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id lATGn2Nr001569; Thu, 29 Nov 2007 09:49:03 -0700 Received: from d03nm119.boulder.ibm.com (d03nm119.boulder.ibm.com [9.17.195.145]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id lATGn2lp001565; Thu, 29 Nov 2007 09:49:02 -0700 In-Reply-To: <953beacc0711290812t68d2cc09se1f4ff0578cc5836@mail.gmail.com> To: "Rohan Mahy" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1P Oct 16, 2006 From: Chris Cross Message-ID: Date: Thu, 29 Nov 2007 11:49:01 -0500 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 7.0.2FP2HF300 | September 14, 2007) at 11/29/2007 09:49:02, Serialize complete at 11/29/2007 09:49:02 X-Spam-Score: -4.0 (----) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 X-Mailman-Approved-At: Thu, 29 Nov 2007 11:51:36 -0500 Cc: NETCONF Goes On , discuss@apps.ietf.org, yang@ietf.org Subject: [YANG] Re: Why NETCONF needs a data modeling language X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0092186937==" Errors-To: yang-bounces@ietf.org This is a multipart message in MIME format. --===============0092186937== Content-Type: multipart/alternative; boundary="=_alternative 005C5A30852573A2_=" This is a multipart message in MIME format. --=_alternative 005C5A30852573A2_= Content-Type: text/plain; charset="US-ASCII" 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" wrote on 11/29/2007 11:12:16 AM: > 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 > On Nov 29, 2007 5:14 AM, Phil Shafer wrote: > "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 --=_alternative 005C5A30852573A2_= Content-Type: text/html; charset="US-ASCII"

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" <rohan.mahy@gmail.com> wrote on 11/29/2007 11:12:16 AM:

> 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
> On Nov 29, 2007 5:14 AM, Phil Shafer <phil@juniper.net> wrote:
> "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 --=_alternative 005C5A30852573A2_=-- --===============0092186937== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang --===============0092186937==-- From yang-bounces@ietf.org Thu Nov 29 12:22:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixn5e-0008L6-IE; Thu, 29 Nov 2007 12:22:18 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Ixn5d-00088l-2I for yang-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 12:22:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixn5c-00082K-9I; Thu, 29 Nov 2007 12:22:16 -0500 Received: from exprod7og110.obsmtp.com ([64.18.2.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ixn5a-0002y6-Ae; Thu, 29 Nov 2007 12:22:16 -0500 Received: from source ([66.129.224.36]) by exprod7ob110.postini.com ([64.18.6.12]) with SMTP; Thu, 29 Nov 2007 09:22:06 PST Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp55.jnpr.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Nov 2007 09:21:22 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id lATHLLE50720; Thu, 29 Nov 2007 09:21:21 -0800 (PST) (envelope-from phil@idle.juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.13.8/8.13.8) with ESMTP id lATHI8tS048970; Thu, 29 Nov 2007 17:18:08 GMT (envelope-from phil@idle.juniper.net) Message-Id: <200711291718.lATHI8tS048970@idle.juniper.net> To: "Rohan Mahy" In-reply-to: <953beacc0711290812t68d2cc09se1f4ff0578cc5836@mail.gmail.com> Date: Thu, 29 Nov 2007 12:18:08 -0500 From: Phil Shafer X-OriginalArrivalTime: 29 Nov 2007 17:21:22.0486 (UTC) FILETIME=[434BBD60:01C832AC] X-Spam-Score: -4.0 (----) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: yang@ietf.org, discuss@apps.ietf.org, NETCONF Goes On Subject: [YANG] Re: Why NETCONF needs a data modeling language X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org "Rohan Mahy" writes: >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. 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 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Nov 30 09:32:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy6uS-0004l9-6v; Fri, 30 Nov 2007 09:32:04 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Iy6uQ-0004kf-L7 for yang-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 09:32:02 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy6uK-0004hu-FG for yang@ietf.org; Fri, 30 Nov 2007 09:31:56 -0500 Received: from qmta02.emeryville.ca.mail.comcast.net ([76.96.30.24]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy6uJ-0007eS-6Z for yang@ietf.org; Fri, 30 Nov 2007 09:31:56 -0500 Received: from OMTA13.emeryville.ca.mail.comcast.net ([76.96.30.52]) by QMTA02.emeryville.ca.mail.comcast.net with comcast id Jznb1Y00617UAYk0A0D300; Fri, 30 Nov 2007 14:31:58 +0000 Received: from Harrington73653 ([24.128.104.207]) by OMTA13.emeryville.ca.mail.comcast.net with comcast id K2Xs1Y00A4UVsHU0800000; Fri, 30 Nov 2007 14:31:58 +0000 X-Authority-Analysis: v=1.0 c=1 a=I0y0xKm2-w0A:10 a=j3Z76cjpAAAA:8 a=48vgC7mUAAAA:8 a=m7Gx0nXtxD0cURmhWtoA:9 a=Jbp6iasmxlNv7zYQp5EA:7 a=p7ZV2XQxOjHVSLzO9rel6YhuadgA:4 a=lZB815dzVvQA:10 a=FvgKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=50e4U0PicR4A:10 From: "David Harrington" To: , "'Rohan Mahy'" References: <474E0F71.2050003@andybierman.com><953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> <20071129113446.GB10751@elstar.local> Subject: RE: [YANG] Re: Why NETCONF needs a data modeling language Date: Fri, 30 Nov 2007 09:31:37 -0500 Message-ID: <241101c8335d$b84c1c70$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20071129113446.GB10751@elstar.local> Thread-Index: Acgye+QkPsKmhiGtRFyLmsSo6IbADwA17LEA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 03fb21b15d5177c512a4caa19876f30a Cc: yang@ietf.org, discuss@apps.ietf.org, 'NETCONF Goes On' X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi comments inline. > -----Original Message----- > From: Juergen Schoenwaelder > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, November 29, 2007 6:35 AM > To: Rohan Mahy > Cc: yang@ietf.org; discuss@apps.ietf.org; NETCONF Goes On > Subject: [YANG] Re: Why NETCONF needs a data modeling language > > On Wed, Nov 28, 2007 at 08:17:04PM -0800, Rohan Mahy wrote: > > > > NETCONF needs > > > its own MIB language, just like SNMP needs SMIv2. > > > > 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. > > 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. +1. Since this discussion goes outside the Network Management community in the IETF, I think some background is important. ASN.1 was a general-purpose modeling langugae that did not meet the requirements of network management. For network management standards, it is important to limit the required resources (code footprint, memory, CPU usage) to make implementtions feasible for resource-constrained devices like set-top boxes. That's why SMI is a subset of ASN.1, rather than all of ASN.1. There are aspects of the data models needed for network management that are not necessaily needed for all ASN.1 modeling. Some examples are given below. That's why SMI is an "adapted" subset of ASN.1 Now we are looking to move from the binary ASN.1 to the textual XML as the base language, to meet operators' requests (see RFC3535). Network management still needs an "adapted subset" of a general purpose modeling language or a domain-specific 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 the way SNMP did things is very inappropriate for configuration purposes (and so most operators apparently). While I strongly support reuse, especially reuse of existing standards, we need to choose the right tools for the job to be done. SNMP is not a viable candidate for confguration in most networks, for reasos described below. >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. > > 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. +1. Let me do a quick review for those who haven't followed those discussions, so we don't have to redo all these discussions from scratch. SNMP was not the only approach for configuration that failed, but we can start there. The 2002 IAB Workshop was toward the end of long discussions about configuration, not the beginning. COPS-PR, SNMPCONF, the Dilbert mailing list, the ops-nm mailing list, and many other discussions focused a lot on configuration requirements. The IAB Workshop achieved consesnus to explore an XML-based approach. The "SNMP standard" has three parts - the protocol, the MIB, and the SMI. The SNMP protocol was found inadequate for configuration for a number of reasons. SNMPv1 lacked security, so many vendors did not support SETs, so operators could not manipulate the configuration of many vendors' devices with SNMP. Even when SET was supported, SNMP was designed to run over unfragmented UDP, which limited message sizes so much it would be impossible to configure a large device in a reasonable amount of time. The major issue with MIBs for configuration was lack of vendor support for MIB modules for all features in their products, which left SNMP without MIB modules to configure everything in a device. And if the CLI could configure everything, and the CLI was needed to configure those things without MIB modules, then it made sense to simply use CLI for everything. A related issue was the long time it takes to get a standard MIB module for a new protocol versus developing a proprietary CLI command set for a new protocol; the delay made the MIB module irrelevant since the problem of configuring the feature would have been already resolved using the CLI. There were some discussions of the rigidity of the SMI, mostly around complex data structures such as nested tables, but there are workarounds for this. AFAIK, relational databases typically do not support nested tables either, so I never considered this a major fault; it just makes it harder to represent structures that can be expressed easily in C, which was the preferred language for agent developers. I think the biggest problem with the SMI is that everybody hates OIDs and wants something more human-readable. But that's not just about configuration. See RFC3535 for more detailed summaries of the IAB Workshop discussions. > > > 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. > > 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) +1. Tools for XSD or RNG will only be able to do partial validation and processing. Additional validation will be needed that is domain-specific. If XSD forces us to put much of the "adapted" stuff into app-notes, we will need special tools that can validate the content of the app-notes. > > b) that the effort to specify such an extended subset will be less > than the effort for defining a domain specific language like YANG +1; I think it might take longer to develop a RNG-standard-compliant extended subset than working with a domain specific language, because we will constantly be faced with finding workarounds for the constraints imposed by the RNG standard. > > 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 +1. > > d) that there will be long term (say 20 year) reliable change control > exercised by the organization that has change control over NETCONF +1. ASN.1 changed a lot after the SMI was developed as an adapted subset of ASN.1-1988. I think ASN.1 became more complex, adding new features for additional uses, and changed in ways that made the SMI no longer compatible with the ASN.1 standard. The separation of the SMI from the underlying langauge has allowed the SMI to remain stable for twenty years. That stability is critically important to motivating vendors to utilize our standards, since they are not faced with a constantly-changing base language. The SMING WG tried to update the SMI, and found that, even with strong pressures to remain backwards compatible with SMIv1 and SMIv2, there is a need to move forward to a new base language that is more human-readable than SMIv1 or SMIv2 (and ASN.1). But whether XML or something else, the solution needs to be able to address the requirements of network management, especially human-readability. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > > _______________________________________________ > YANG mailing list > YANG@ietf.org > https://www1.ietf.org/mailman/listinfo/yang > _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Nov 30 10:35:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy7tt-0006zI-SN; Fri, 30 Nov 2007 10:35:33 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Iy7ts-0006z0-N6 for yang-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 10:35:32 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy7ts-0006yf-BS for yang@ietf.org; Fri, 30 Nov 2007 10:35:32 -0500 Received: from qmta08.emeryville.ca.mail.comcast.net ([76.96.30.80]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Iy7tr-00081S-08 for yang@ietf.org; Fri, 30 Nov 2007 10:35:32 -0500 Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA08.emeryville.ca.mail.comcast.net with comcast id K1su1Y0091GXsuc0A08a00; Fri, 30 Nov 2007 15:35:34 +0000 Received: from Harrington73653 ([24.128.104.207]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id K3bU1Y00B4UVsHU0800000; Fri, 30 Nov 2007 15:35:34 +0000 X-Authority-Analysis: v=1.0 c=1 a=KSJUxJzPonUA:10 a=nKLD2Io1NIw4iaqvex4A:9 a=Tw-MUFs4hJt1eTxRKQoA:7 a=UJ77OrrZXaJLDYQLrM8z5A4y5kQA:4 a=si9q_4b84H0A:10 a=gJcimI5xSWUA:10 From: "David Harrington" To: "'Andy Bierman'" , References: <474E0F71.2050003@andybierman.com> Date: Fri, 30 Nov 2007 10:35:13 -0500 Message-ID: <241201c83366$9acf8070$6502a8c0@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <474E0F71.2050003@andybierman.com> Thread-Index: AcgyI3BWX50RoOCBS32El4WAOg2IiQBOy49g X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: yang@ietf.org, 'NETCONF Goes On' Subject: [YANG] Why NETCONF needs a data modeling language X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org > 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? 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 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. A3) Why won't lots of other WGs want to define their own protocol-specific DMLs? To paraphrase a wise man from the SNMP community, when you fill a room with protocol designers and ask for a solution to a problem, is it a surprise when they recommend designing a new protocol? The decision about whether to use an existing protocol/DML or develop a new protocol/DML should be made after a careful analysis of the requirements of the solution. SNMP was designed when CMIP was found to not quite address the needs. The SMI was designed when ASN.1 was found to not quite address the needs. XML was designed when other DMLs were found to not quite address the needs. The decision to explore an XML-based DML and to explore a C-like DML follows years and years and years of debate over the requiremnts of network management, and configuration in particular. If every WG spends as much time analyzing the requirements that the OPS area has spent considering this decision, it might be good for ensuring no new protoocls are designed that are not really needed, but the IETF would also grind to a halt, much as the OPS community has done over our many years of debate. And the delay caused by our debates has made IETF network management largely irrelevant to the operator community (our customers). As always, we need to be vigilant and determine whether enough thought has been given to reuse of existing protocols. We also need to consider the tradeoffs between new protocols and reusing existing protocols in ways they were not designed to be used. 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. [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 dbharrington@comcast.net ietfdbh@comcast.net _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Nov 30 12:10:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9Nf-0001Bv-4E; Fri, 30 Nov 2007 12:10:23 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1Iy9Ne-0001BM-3w for yang-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 12:10:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Iy9Nd-0001B9-Mf; Fri, 30 Nov 2007 12:10:21 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Iy9Nc-00057X-Vv; Fri, 30 Nov 2007 12:10:21 -0500 Received: from localhost (pool-71-120-236-45.spknwa.dsl-w.verizon.net [71.120.236.45]) by mail.tail-f.com (Postfix) with ESMTP id 311F31B80C8; Fri, 30 Nov 2007 18:10:17 +0100 (CET) Date: Fri, 30 Nov 2007 18:10:15 +0100 (CET) Message-Id: <20071130.181015.170292466.mbj@tail-f.com> To: rohan.mahy@gmail.com From: Martin Bjorklund In-Reply-To: <953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> References: <474E0F71.2050003@andybierman.com> <953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: yang@ietf.org, discuss@apps.ietf.org, ngo@ietf.org Subject: [YANG] Re: Why NETCONF needs a data modeling language X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi Rohan, "Rohan Mahy" wrote: > 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. 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 . 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 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 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Nov 30 13:10:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAKD-0003EM-5W; Fri, 30 Nov 2007 13:10:53 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IyAKB-0003Dn-Vj for yang-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 13:10:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyAKB-0003DZ-Kt for yang@ietf.org; Fri, 30 Nov 2007 13:10:51 -0500 Received: from smtp124.sbc.mail.sp1.yahoo.com ([69.147.64.97]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IyAKB-000243-3u for yang@ietf.org; Fri, 30 Nov 2007 13:10:51 -0500 Received: (qmail 73331 invoked from network); 30 Nov 2007 18:10:50 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@207.215.248.215 with plain) by smtp124.sbc.mail.sp1.yahoo.com with SMTP; 30 Nov 2007 18:10:49 -0000 X-YMail-OSG: Z2c.HKkVM1kTszA0MKK0oYihsCZY2pW_lh5cS7Vzxibo_BnN Message-ID: <475052A3.9070200@andybierman.com> Date: Fri, 30 Nov 2007 10:12:51 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: yang@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Subject: [YANG] Qs about keyref X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Hi, It is not clear what the real builtin type of a keyref object is supposed to be. leaf myIfIndex { description "Pointer to ifIndex for interface 'eth0'"; type keyref { path "/itf:interfaces/itf:interface[itf:name='eth0']/itf:ifIndex"; } } .... eth0 42 1500 ... 42 So what is the XSD type of 'myIfIndex'? Is it xs:string or itf:InterfaceIndex? Is a keyref, by definition, a read-only object? Clauses such as 'default', 'config', and 'units' do not seem relevant in a typedef for a keyref data type. What affect do they have for a keyref typedef? Is this even legal YANG? What if 'ifIndex' is a leaf as it is used within table X, but not table Y? This can happen, of course, if 'name' and 'ifIndex' are defined in a grouping, not directly in a list. Why isn't this just a 'leafref' instead of 'keyref'? The distinction between a 'pointer to a leaf used as key' and a 'pointer to leaf not used as a key' does not seem important. What if a user has access rights to view the 'myIfIndex' namespace/object, but not the 'interfaces' namespace/object? If the 'path' points to an object with QName content, does the keyref object XML (e.g., ) have to include that prefix-to-NS mapping mapping, or is the 'pointed-at' value considered more of an opaque string? (This is just a variant of my first question.) thanks, Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Nov 30 14:27:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyBWg-00029G-Ak; Fri, 30 Nov 2007 14:27:50 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IyBWe-00023N-SY for yang-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 14:27:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyBWe-000234-I5 for yang@ietf.org; Fri, 30 Nov 2007 14:27:48 -0500 Received: from smtp115.sbc.mail.sp1.yahoo.com ([69.147.64.88]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IyBWd-0007Jb-Gq for yang@ietf.org; Fri, 30 Nov 2007 14:27:48 -0500 Received: (qmail 58448 invoked from network); 30 Nov 2007 19:27:40 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@207.215.248.215 with plain) by smtp115.sbc.mail.sp1.yahoo.com with SMTP; 30 Nov 2007 19:27:40 -0000 X-YMail-OSG: p5nTzfsVM1lWvK8VEhVUyAXZIua6kmtdlOs9Ee51fb08CbPZ Message-ID: <475064A5.1060300@andybierman.com> Date: Fri, 30 Nov 2007 11:29:41 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: David Harrington References: <474E0F71.2050003@andybierman.com> <241201c83366$9acf8070$6502a8c0@china.huawei.com> In-Reply-To: <241201c83366$9acf8070$6502a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: yang@ietf.org, discuss@apps.ietf.org, 'NETCONF Goes On' Subject: [YANG] Re: Why NETCONF needs a data modeling language X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org David Harrington wrote: > >> 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? > > 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. 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. > 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 > dbharrington@comcast.net > ietfdbh@comcast.net > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Nov 30 15:17:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyCIx-0006Xm-G6; Fri, 30 Nov 2007 15:17:43 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IyCIw-0006XF-Iy for yang-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 15:17:42 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyCIw-0006VP-7E for yang@ietf.org; Fri, 30 Nov 2007 15:17:42 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IyCIv-0005vV-Gx for yang@ietf.org; Fri, 30 Nov 2007 15:17:42 -0500 Received: from localhost (pool-71-120-236-45.spknwa.dsl-w.verizon.net [71.120.236.45]) by mail.tail-f.com (Postfix) with ESMTP id 907AB1B80C5; Fri, 30 Nov 2007 21:17:39 +0100 (CET) Date: Fri, 30 Nov 2007 21:17:33 +0100 (CET) Message-Id: <20071130.211733.131202491.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] Qs about keyref From: Martin Bjorklund In-Reply-To: <475052A3.9070200@andybierman.com> References: <475052A3.9070200@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.3 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Hi, > > It is not clear what the real builtin type of a keyref object > is supposed to be. > > leaf myIfIndex { > description "Pointer to ifIndex for interface 'eth0'"; > type keyref { > path "/itf:interfaces/itf:interface[itf:name='eth0']/itf:ifIndex"; > } > } > > .... > > > > eth0 > 42 > 1500 > ... > > > > 42 > > > So what is the XSD type of 'myIfIndex'? > Is it xs:string or itf:InterfaceIndex? On the syntactical level (which is what you can define in XSD) it is the same as itf:InterfaceIndex, whatever that is. (then it is restricted to the set of values existing in the configuration). Typically you wouldn't hardcode the value of the key ('eth0') in the DM though since that is runtime data. > Is a keyref, by definition, a read-only object? No! As an typical example, I would define channelIfIndex in the RMON MIB as a keyref. > Clauses such as 'default', 'config', and 'units' do > not seem relevant in a typedef for a keyref data type. > What affect do they have for a keyref typedef? config I explained above. default and units are questionable. I'm not sure it makes sense to add special rules to forbid them though... > Is this even legal YANG? > What if 'ifIndex' is a leaf as it is used within table X, > but not table Y? This can happen, of course, if 'name' > and 'ifIndex' are defined in a grouping, not directly in > a list. The keyref will point to either table X or table Y, not to the grouping. So this is not a problem. > Why isn't this just a 'leafref' instead of 'keyref'? > The distinction between a 'pointer to a leaf used as key' > and a 'pointer to leaf not used as a key' does not seem important. We have discussed changing keyref into leafref. That would make sense in e.g. notifications (or other read-only data), but I'm not sure it will be very useful for configuration. As an example, suppose I do a leafref to ifAdminStatus: leaf myIfAdminStatus { type leafref { path "/itf:interfaces/itf:interface/itf:ifAdminStatus"; } } up What does that mean?? The thing here is that with the keyref you just get the key's value in the XML, you don't get the entire instance information. In order to understand the relationship, you have to check the data model definition. Compare with SNMP - if I include ifAdminStatus in a trap, I'll get both the instance identifier and the value in the varbind. You won't get that in XML unless you add both the instance identifier (XPath) and the value as separate elements/attributes. > What if a user has access rights to view the 'myIfIndex' > namespace/object, but not the 'interfaces' namespace/object? Then he would see that myIfIndex has the value 42. From this he can conclude some information, namely that an interface with ifIndex 42 exists. > If the 'path' points to an object with QName content, > does the keyref object XML (e.g., ) have to > include that prefix-to-NS mapping mapping, or is the 'pointed-at' > value considered more of an opaque string? Actually, YANG doesn't have a QName type. Maybe it should. If we add it, the prefix-to-ns mapping must be encoded in the reply. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Nov 30 15:42:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyCgy-0003rj-5X; Fri, 30 Nov 2007 15:42:32 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IyCgw-0003pO-Cy for yang-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 15:42:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyCgw-0003p9-3G for yang@ietf.org; Fri, 30 Nov 2007 15:42:30 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyCgu-0005bp-8T for yang@ietf.org; Fri, 30 Nov 2007 15:42:30 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 459598A293; Fri, 30 Nov 2007 21:42:25 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 29589-10; Fri, 30 Nov 2007 21:42:20 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8020C8A17E; Fri, 30 Nov 2007 21:42:20 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 1CB6B404735; Fri, 30 Nov 2007 21:42:20 +0100 (CET) Date: Fri, 30 Nov 2007 21:42:19 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Subject: Re: [YANG] Qs about keyref Message-ID: <20071130204219.GA14610@elstar.local> References: <475052A3.9070200@andybierman.com> <20071130.211733.131202491.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20071130.211733.131202491.mbj@tail-f.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.2 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Fri, Nov 30, 2007 at 09:17:33PM +0100, Martin Bjorklund wrote: > We have discussed changing keyref into leafref. That would make sense > in e.g. notifications (or other read-only data), but I'm not sure it > will be very useful for configuration. As an example, suppose I do a > leafref to ifAdminStatus: > > leaf myIfAdminStatus { > type leafref { > path "/itf:interfaces/itf:interface/itf:ifAdminStatus"; > } > } > > > up > > What does that mean?? > > The thing here is that with the keyref you just get the key's value in > the XML, you don't get the entire instance information. In order to > understand the relationship, you have to check the data model > definition. But YANG keys can be consist of several leafs so a keyref only works nicely in some cases. > Compare with SNMP - if I include ifAdminStatus in a trap, I'll get > both the instance identifier and the value in the varbind. You won't > get that in XML unless you add both the instance identifier (XPath) > and the value as separate elements/attributes. Yep. And that is why the SMI notification mapping is re-introducing all the instance identifying leafs. As I noted before, leafrefs make the SMI notification mapping less verbose (not necessarily a prime goal, I know). Whether the leafref make 'sense' in identifying an 'instance' is something that compilers may check. > > What if a user has access rights to view the 'myIfIndex' > > namespace/object, but not the 'interfaces' namespace/object? > > Then he would see that myIfIndex has the value 42. From this he can > conclude some information, namely that an interface with ifIndex 42 > exists. I agree, we have the same in SNMP land and so far nobody had an issue with this. The good news with yang is that you can identify an "object" you refer to; in SMI land we had to resort to special types to bind object types together. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Nov 30 16:52:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDmX-0006Rx-0S; Fri, 30 Nov 2007 16:52:21 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IyDmV-0006Rb-Ro for yang-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 16:52:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDmV-0006RJ-Al for yang@ietf.org; Fri, 30 Nov 2007 16:52:19 -0500 Received: from smtp106.sbc.mail.mud.yahoo.com ([68.142.198.205]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IyDmU-0005RJ-Uq for yang@ietf.org; Fri, 30 Nov 2007 16:52:19 -0500 Received: (qmail 37389 invoked from network); 30 Nov 2007 21:52:18 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.164.104 with plain) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 30 Nov 2007 21:52:18 -0000 X-YMail-OSG: z4HfQHUVM1ncQKkVQ8JDk0KbxxTV_1vGlhoU.b6WL2e9Ud8T Message-ID: <4750868B.10803@andybierman.com> Date: Fri, 30 Nov 2007 13:54:19 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: j.schoenwaelder@jacobs-university.de Subject: Re: [YANG] Qs about keyref References: <475052A3.9070200@andybierman.com> <20071130.211733.131202491.mbj@tail-f.com> <20071130204219.GA14610@elstar.local> In-Reply-To: <20071130204219.GA14610@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder wrote: > On Fri, Nov 30, 2007 at 09:17:33PM +0100, Martin Bjorklund wrote: >... >>> What if a user has access rights to view the 'myIfIndex' >>> namespace/object, but not the 'interfaces' namespace/object? >> Then he would see that myIfIndex has the value 42. From this he can >> conclude some information, namely that an interface with ifIndex 42 >> exists. > > I agree, we have the same in SNMP land and so far nobody had an issue > with this. The good news with yang is that you can identify an > "object" you refer to; in SMI land we had to resort to special types > to bind object types together. Well it matters to the Security Folks. I am concerned about the access control aspects of keyref/leafref as well, especially if it is a writable object. Your ifAdminStatus example is a good one. If an administrator decides that not everybody should get to set the interface to 'down', then access control for 'ifAdminStatus' is configured appropriately and the security problem is addressed. If there are other objects that the administrator doesn't know about, that also set the interface admin status, then a security hole exists. It is an SNMP practice (hopefully not in YANG) to put config parameters into the INDEX clause, to force uniqueness, for example. So there is no real security distinction between keyref and leafref, even though it might seem that way. One has to assume that a hacker will know what 'myIfIndex' (or whatever) really points to, and getting the value (42, or something sensitive, like a password), is just as good as getting access to the real object. > > /js > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Nov 30 16:58:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDsk-0006mJ-9u; Fri, 30 Nov 2007 16:58:46 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IyDsi-0006le-Lf for yang-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 16:58:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyDsi-0006lO-Bs for yang@ietf.org; Fri, 30 Nov 2007 16:58:44 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyDse-0006tX-5X for yang@ietf.org; Fri, 30 Nov 2007 16:58:44 -0500 Received: from localhost (pool-71-120-236-45.spknwa.dsl-w.verizon.net [71.120.236.45]) by mail.tail-f.com (Postfix) with ESMTP id 5D6391B80D6; Fri, 30 Nov 2007 22:58:38 +0100 (CET) Date: Fri, 30 Nov 2007 22:58:34 +0100 (CET) Message-Id: <20071130.225834.121728529.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] Qs about keyref From: Martin Bjorklund In-Reply-To: <4750868B.10803@andybierman.com> References: <20071130.211733.131202491.mbj@tail-f.com> <20071130204219.GA14610@elstar.local> <4750868B.10803@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Juergen Schoenwaelder wrote: > > On Fri, Nov 30, 2007 at 09:17:33PM +0100, Martin Bjorklund wrote: > >... > >>> What if a user has access rights to view the 'myIfIndex' > >>> namespace/object, but not the 'interfaces' namespace/object? > >> Then he would see that myIfIndex has the value 42. From this he can > >> conclude some information, namely that an interface with ifIndex 42 > >> exists. > > > > I agree, we have the same in SNMP land and so far nobody had an issue > > with this. The good news with yang is that you can identify an > > "object" you refer to; in SMI land we had to resort to special types > > to bind object types together. > > Well it matters to the Security Folks. > I am concerned about the access control aspects of keyref/leafref > as well, especially if it is a writable object. > > Your ifAdminStatus example is a good one. > If an administrator decides that not everybody should > get to set the interface to 'down', then access control > for 'ifAdminStatus' is configured appropriately and > the security problem is addressed. If there are other > objects that the administrator doesn't know about, that > also set the interface admin status, then a security hole exists. Note that the keyref/leafref is not some kind of symbolic link - if you modify myIfAdminStatus to down, you modified just that object. Again, compare with channelIfIndex in the RMON MIB. keyref formalizes what channelIfIndex has in its description clause. > It is an SNMP practice (hopefully not in YANG) to put config > parameters into the INDEX clause, to force uniqueness In YANG we have the 'unique' statement which is used to force uniqueness among leaf. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Nov 30 17:16:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyEAA-0003Gr-Iq; Fri, 30 Nov 2007 17:16:46 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IyEA9-0003BJ-K4 for yang-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 17:16:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyEA9-0003Am-A5 for yang@ietf.org; Fri, 30 Nov 2007 17:16:45 -0500 Received: from smtp123.sbc.mail.sp1.yahoo.com ([69.147.64.96]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IyEA7-0005uv-OS for yang@ietf.org; Fri, 30 Nov 2007 17:16:45 -0500 Received: (qmail 29654 invoked from network); 30 Nov 2007 22:16:43 -0000 Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.127.164.104 with plain) by smtp123.sbc.mail.sp1.yahoo.com with SMTP; 30 Nov 2007 22:16:42 -0000 X-YMail-OSG: S534.gcVM1krtZQypno0XlKEwN_ttsvCoFUT0ctHlMp43Cll Message-ID: <47508C44.4020303@andybierman.com> Date: Fri, 30 Nov 2007 14:18:44 -0800 From: Andy Bierman User-Agent: Thunderbird 2.0.0.9 (Windows/20071031) MIME-Version: 1.0 To: Martin Bjorklund Subject: Re: [YANG] Qs about keyref References: <20071130.211733.131202491.mbj@tail-f.com> <20071130204219.GA14610@elstar.local> <4750868B.10803@andybierman.com> <20071130.225834.121728529.mbj@tail-f.com> In-Reply-To: <20071130.225834.121728529.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Martin Bjorklund wrote: > Andy Bierman wrote: >> Juergen Schoenwaelder wrote: >>> On Fri, Nov 30, 2007 at 09:17:33PM +0100, Martin Bjorklund wrote: >>> ... >>>>> What if a user has access rights to view the 'myIfIndex' >>>>> namespace/object, but not the 'interfaces' namespace/object? >>>> Then he would see that myIfIndex has the value 42. From this he can >>>> conclude some information, namely that an interface with ifIndex 42 >>>> exists. >>> I agree, we have the same in SNMP land and so far nobody had an issue >>> with this. The good news with yang is that you can identify an >>> "object" you refer to; in SMI land we had to resort to special types >>> to bind object types together. >> Well it matters to the Security Folks. >> I am concerned about the access control aspects of keyref/leafref >> as well, especially if it is a writable object. >> >> Your ifAdminStatus example is a good one. >> If an administrator decides that not everybody should >> get to set the interface to 'down', then access control >> for 'ifAdminStatus' is configured appropriately and >> the security problem is addressed. If there are other >> objects that the administrator doesn't know about, that >> also set the interface admin status, then a security hole exists. > > Note that the keyref/leafref is not some kind of symbolic link - if > you modify myIfAdminStatus to down, you modified just that object. > Again, compare with channelIfIndex in the RMON MIB. keyref formalizes > what channelIfIndex has in its description clause. > Then what are the semantics of a keyref? Copy-by-value, not copy-by-reference? I thought it was a symbolic link. I thought each time somebody accessed (read or write) the keyref object, the underlying instrumentation is really accessing the current 'pointed-to' value, indicated by the path statement. So this is an informative clause, like reference, but machine-readable? OK. There are many times where the data type alone is not enough (ok, it's an InetAddress, but which one, on the device?) So, not a security concern for writing, but what about reading? Where does the value '42' for 'myIfIndex' come from, in this example? I thought the agent instrumentation read 'ifIndex' and got 42. > >> It is an SNMP practice (hopefully not in YANG) to put config >> parameters into the INDEX clause, to force uniqueness > > In YANG we have the 'unique' statement which is used to force > uniqueness among leaf. > > > /martin > > Andy _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Nov 30 17:35:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyESW-0005i5-WC; Fri, 30 Nov 2007 17:35:45 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IyESV-0005Ws-AR for yang-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 17:35:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyESU-0005Ul-Nr for yang@ietf.org; Fri, 30 Nov 2007 17:35:42 -0500 Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyESU-00017J-5K for yang@ietf.org; Fri, 30 Nov 2007 17:35:42 -0500 Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id A9132867DB; Fri, 30 Nov 2007 23:35:41 +0100 (CET) Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 05101-10; Fri, 30 Nov 2007 23:35:37 +0100 (CET) Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A0718A1A7; Fri, 30 Nov 2007 23:35:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F29344049BC; Fri, 30 Nov 2007 23:35:36 +0100 (CET) Date: Fri, 30 Nov 2007 23:35:36 +0100 From: Juergen Schoenwaelder To: Andy Bierman Subject: Re: [YANG] Qs about keyref Message-ID: <20071130223536.GA14951@elstar.local> References: <20071130.211733.131202491.mbj@tail-f.com> <20071130204219.GA14610@elstar.local> <4750868B.10803@andybierman.com> <20071130.225834.121728529.mbj@tail-f.com> <47508C44.4020303@andybierman.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47508C44.4020303@andybierman.com> User-Agent: Mutt/1.5.17 (2007-11-01) X-Virus-Scanned: amavisd-new 2.3.3 (20050822) at jacobs-university.de X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: j.schoenwaelder@jacobs-university.de List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org On Fri, Nov 30, 2007 at 02:18:44PM -0800, Andy Bierman wrote: > Then what are the semantics of a keyref? > Copy-by-value, not copy-by-reference? According to Martin, no copy at all. The value of a keyref is unique to the leaf and its special semantic is that it is used to identify some other container (and unlike the SMI, we have a way to spell out in which container the value selects an instance). > I thought it was a symbolic link. > I thought each time somebody accessed (read or write) > the keyref object, the underlying instrumentation > is really accessing the current 'pointed-to' value, > indicated by the path statement. This "symbolic link" is something I would need for notifications and it took me some time to see the difference and why keyref (or leafref) is not really want I needed for notifications. For notifications, I would like to really link to something in the config tree or state tree. But as long as you stay in the config tree, this is likely not really needed. The last time we ended with the observation that we need both, a keyref/leafref type plus a mechanism to link stuff from the data tree into the notification tree. Martin, did I get this right? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Nov 30 18:02:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyEsT-0004ER-MV; Fri, 30 Nov 2007 18:02:33 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IyEsS-00045g-6K for yang-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 18:02:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyEsR-00044l-SD for yang@ietf.org; Fri, 30 Nov 2007 18:02:31 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyEsQ-0007Gy-Fq for yang@ietf.org; Fri, 30 Nov 2007 18:02:31 -0500 Received: from localhost (pool-71-120-236-45.spknwa.dsl-w.verizon.net [71.120.236.45]) by mail.tail-f.com (Postfix) with ESMTP id 264E41B80C5; Sat, 1 Dec 2007 00:02:27 +0100 (CET) Date: Sat, 01 Dec 2007 00:02:23 +0100 (CET) Message-Id: <20071201.000223.58152913.mbj@tail-f.com> To: ietf@andybierman.com Subject: Re: [YANG] Qs about keyref From: Martin Bjorklund In-Reply-To: <47508C44.4020303@andybierman.com> References: <4750868B.10803@andybierman.com> <20071130.225834.121728529.mbj@tail-f.com> <47508C44.4020303@andybierman.com> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Andy Bierman wrote: > Then what are the semantics of a keyref? > Copy-by-value, not copy-by-reference? Neither. It is a reference to some key. This is how channelIfIndex would look: leaf channelIfIndex { type keyref { path "/if:interface/if:ifEntry/if:ifIndex"; } } Note: there is no instance information at all in the path. If you did a get-config with the same path as xpath filter, you'd get all ifIndexes on the box. > I thought it was a symbolic link. > I thought each time somebody accessed (read or write) > the keyref object, the underlying instrumentation > is really accessing the current 'pointed-to' value, > indicated by the path statement. > > So this is an informative clause, like reference, > but machine-readable? OK. There are many times > where the data type alone is not enough (ok, it's > an InetAddress, but which one, on the device?) > > So, not a security concern for writing, but what about reading? > Where does the value '42' for 'myIfIndex' come from, in this example? > I thought the agent instrumentation read 'ifIndex' and got 42. If the app has access to channelIfIndex, it will read it and get it's value, 42. /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang From yang-bounces@ietf.org Fri Nov 30 18:27:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyFGd-0000lY-SO; Fri, 30 Nov 2007 18:27:31 -0500 Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1IyFGc-0000ko-7x for yang-confirm+ok@megatron.ietf.org; Fri, 30 Nov 2007 18:27:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IyFGb-0000kc-UY for yang@ietf.org; Fri, 30 Nov 2007 18:27:29 -0500 Received: from [213.180.94.162] (helo=mail.tail-f.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IyFGb-0005Ne-AY for yang@ietf.org; Fri, 30 Nov 2007 18:27:29 -0500 Received: from localhost (pool-71-120-236-45.spknwa.dsl-w.verizon.net [71.120.236.45]) by mail.tail-f.com (Postfix) with ESMTP id 342BB1B80C5; Sat, 1 Dec 2007 00:27:25 +0100 (CET) Date: Sat, 01 Dec 2007 00:27:21 +0100 (CET) Message-Id: <20071201.002721.240670475.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Subject: Re: [YANG] Qs about keyref From: Martin Bjorklund In-Reply-To: <20071130223536.GA14951@elstar.local> References: <20071130.225834.121728529.mbj@tail-f.com> <47508C44.4020303@andybierman.com> <20071130223536.GA14951@elstar.local> X-Mailer: Mew version 5.1.51 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: yang@ietf.org X-BeenThere: yang@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: YANG modeling Language for NETCONF List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: yang-bounces@ietf.org Juergen Schoenwaelder wrote: > This "symbolic link" is something I would need for notifications and > it took me some time to see the difference and why keyref (or leafref) > is not really want I needed for notifications. For notifications, I > would like to really link to something in the config tree or state > tree. But as long as you stay in the config tree, this is likely not > really needed. The last time we ended with the observation that we > need both, a keyref/leafref type plus a mechanism to link stuff from > the data tree into the notification tree. > > Martin, did I get this right? Yes, except if we can come up with some other way of doing "symbolic links", we don't need leafrefs. When we (you and me :) discussed this, the best thing we came up with was to extend keyref into leafref. But it is still not a perfect solution... OTOH, this problem came up when translating SNMP traps. One problem there is the trap may look like this: OBJECTS { ifIndex, ifAdminStatus, ifOperStatus } In this case, all three objects will be from the same ifEntry instance. So the instance information is repeated 3 times (some may say 4). But if we did this trap in YANG + leafref, we would explicitly specify that they come from the same ifEntry: leaf ifIndex { type leafref { path "/if:interface/if:ifEntry/if:ifIndex"; } } leaf ifAdminStatus { type leafref { path "/if:interface/if:ifEntry" + "[ifIndex = $this/../ifIndex]/if:ifAdminStatus": } } leaf ifOperStatus { type leafref { path "/if:interface/if:ifEntry" + "[ifIndex = $this/../ifIndex]/if:ifOperStatus": } } And an instance doc: 2 up down The YANG spec obviously isn't perfect... but it is better than the auto-generated one. As an alternative, I was thinking that maybe we somehow could point out a list entry or container, and then just list the children we want to include in the notification. This would be useful in notifications and rpc-replies. Something like this (warning: just an idea) notification linkDown { add-objects-from { path "/if:interface/if:ifEntry"; include ifIndex; // maybe the key is auto-added? No... include ifAdminStatus; include ifOperStatus; include ifExtra/ifFooBar; // add from a container } } One problem is that the add-objects-from doesn't really work like the rest of the data definition statements in YANG... And if you have nested lists it's a bit trickier... /martin _______________________________________________ YANG mailing list YANG@ietf.org https://www1.ietf.org/mailman/listinfo/yang