Re: [NGO] Re: Why NETCONF needs a data modeling language
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Thu, 29 November 2007 15:31 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 1IxlMd-00032k-1w; Thu, 29 Nov 2007 10:31:43 -0500
Received: from ngo by megatron.ietf.org with local (Exim 4.43) id 1IxlMc-00032D-4r for ngo-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 10:31:42 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxlMb-000322-RE for ngo@ietf.org; Thu, 29 Nov 2007 10:31:41 -0500
Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxlMa-00011X-GB for ngo@ietf.org; Thu, 29 Nov 2007 10:31:41 -0500
Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9FFBF8654F; Thu, 29 Nov 2007 16:31:39 +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 04210-07-3; Thu, 29 Nov 2007 16:31:32 +0100 (CET)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D719E8A242; Thu, 29 Nov 2007 16:30:56 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 9B6A0402C55; Thu, 29 Nov 2007 16:30:56 +0100 (CET)
Date: Thu, 29 Nov 2007 16:30:56 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@cesnet.cz>
Subject: Re: [NGO] Re: Why NETCONF needs a data modeling language
Message-ID: <20071129153056.GA11820@elstar.local>
References: <474E0F71.2050003@andybierman.com> <953beacc0711282017p3ad865abw19920b4e68e82e80@mail.gmail.com> <20071129113446.GB10751@elstar.local> <1196348560.5918.76.camel@missotis>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <1196348560.5918.76.camel@missotis>
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: 25620135586de10c627e3628c432b04a
Cc: ngo@ietf.org
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 Thu, Nov 29, 2007 at 04:02:40PM +0100, Ladislav Lhotka wrote: > > 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) > > For example, NETCONF data could be validated (as an XML document) using > the existing tools, RNG specification requires that foreign elements be > ignored. As for the subset of RNG - could it perhaps be just a > convention, like "avoid mixed content"? This is what was done with ASN.1 in the early 1990s to form the SMI. To scale and to interoperate, we then needed tools that can check such "conventions" (or "constraints") on the underlying language. > > > > b) that the effort to specify such an extended subset will be less > > than the effort for defining a domain specific language like YANG > > I'd say the former effort will be *significantly* smaller than the > latter since the main issue - defining document structure - comes for > free and has already been thoroughly tested. A problem may be though > that the hybrid language could turn out to be less readable for humans. The funny thing is that the YANG parts that define document structure were the simplest things to get done. The type system has a history ranging from SMIv2 over SMIng to YANG with some influences from XSD (since we see a need by some people to translate into the XSD world, even though none of he YANG people considers such translations terribly useful). Most of the time was spent figuring out what we need to make NETCONF data models work and simple to write. > > > > 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 > > It would make sense if one could use both the traditional XML tools and > new NETCONF-specific tools. The big advantage would be that both > categories would use exactly the same data model specification. Even if > someone writes conversion tools like YANG->RNG, it would be more > difficult to guarantee consistency. Transformations YANG->RNG (or YANG->XSD) actually guarantee consistency since such translations makes it clear that YANG is the binding specification. You get real nasty consistency problems if people start to write RNG in the hope that this might be somehow valid YANG using generic RNG tools that have no clue about the specifics of the adapted subset relevant for NETCONF. In the early SMI days, people who where used to ASN.1 did this. > > d) that there will be long term (say 20 year) reliable change control > > exercised by the organization that has change control over NETCONF > > For the extension within an IETF-controlled namespace this could be > guaranteed, but of course if the XML world turns entirely to Yet Another > Schema Language, the extension would have to be ported to it. Given the > momentum behind RNG these days, I don't think it is very likely. This is what ASN.1 people believed in the late 80s as well... I assume Google is archiving all this somewhere and so we can meet in 2027 again and revisit the situation. ;-) Anyway, I think we are at a point where I understand your position and you understand mine. I assume it is unlikely that we convince each other to change our position; so unless there are new arguments, we should probably just let this thread stand where it is. /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