[NGO] Re: Why NETCONF needs a data modeling language
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 29 November 2007 11:35 UTC
Return-path: <ngo-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ixhfk-0003Wk-RG; Thu, 29 Nov 2007 06:35:12 -0500
Received: from ngo by megatron.ietf.org with local (Exim 4.43) id 1Ixhfj-0003WY-VQ for ngo-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 06:35:11 -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 <j.schoenwaelder@jacobs-university.de>
To: Rohan Mahy <rohan.mahy@gmail.com>
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 <ngo@ietf.org>
Subject: [NGO] Re: Why NETCONF needs a data modeling language
X-BeenThere: ngo@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@jacobs-university.de
List-Id: NETCONF Goes On - discussions on future work and extensions to NETCONF <ngo.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ngo>
List-Post: <mailto:ngo@ietf.org>
List-Help: <mailto:ngo-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ngo>, <mailto:ngo-request@ietf.org?subject=subscribe>
Errors-To: ngo-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 <http://www.jacobs-university.de/> _______________________________________________ NGO mailing list NGO@ietf.org https://www1.ietf.org/mailman/listinfo/ngo
- [NGO] Why NETCONF needs a data modeling language Andy Bierman
- [NGO] Re: Why NETCONF needs a data modeling langu… Juergen Schoenwaelder
- [NGO] Re: Why NETCONF needs a data modeling langu… Phil Shafer
- [NGO] Re: Why NETCONF needs a data modeling langu… Rohan Mahy
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Ladislav Lhotka
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Juergen Schoenwaelder
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Andy Bierman
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Ladislav Lhotka
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Balazs Lengyel
- RE: [NGO] Re: Why NETCONF needs a data modeling l… Romascanu, Dan (Dan)
- [NGO] Re: Why NETCONF needs a data modeling langu… Rohan Mahy
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Ladislav Lhotka
- Re: [NGO] Re: Why NETCONF needs a data modeling l… Ladislav Lhotka
- [NGO] Re: Why NETCONF needs a data modeling langu… Chris Cross
- [NGO] Re: Why NETCONF needs a data modeling langu… Phil Shafer
- [NGO] RE: [YANG] Re: Why NETCONF needs a data mod… David Harrington
- [NGO] Why NETCONF needs a data modeling language David Harrington
- [NGO] Re: Why NETCONF needs a data modeling langu… Martin Bjorklund
- [NGO] Re: Why NETCONF needs a data modeling langu… Andy Bierman
- [NGO] Re: Why NETCONF needs a data modeling langu… Balazs Lengyel
- [NGO] Re: Why NETCONF needs a data modeling langu… Jon Saperia
- [NGO] Re: Why NETCONF needs a data modeling langu… Balazs Lengyel
- [NGO] Re: Why NETCONF needs a data modeling langu… Jon Saperia