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