Re: analysis of YANG vs. RELAX NG

Phil Shafer <phil@juniper.net> Thu, 29 November 2007 16:53 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmdT-0007xw-PI; Thu, 29 Nov 2007 11:53:11 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IxmdS-0007xW-Kl for discuss-confirm+ok@megatron.ietf.org; Thu, 29 Nov 2007 11:53:10 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IxmdS-0007xL-BI for discuss@apps.ietf.org; Thu, 29 Nov 2007 11:53:10 -0500
Received: from exprod7og112.obsmtp.com ([64.18.2.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IxmdR-0006Yj-Rw for discuss@apps.ietf.org; Thu, 29 Nov 2007 11:53:10 -0500
Received: from source ([66.129.224.36]) by exprod7ob112.postini.com ([64.18.6.12]) with SMTP; Thu, 29 Nov 2007 08:52:54 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 08:51:48 -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 lATGplE44251; Thu, 29 Nov 2007 08:51:47 -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 lATGmYsT048635; Thu, 29 Nov 2007 16:48:34 GMT (envelope-from phil@idle.juniper.net)
Message-Id: <200711291648.lATGmYsT048635@idle.juniper.net>
To: Rohan Mahy <rohan.mahy@gmail.com>
Subject: Re: analysis of YANG vs. RELAX NG
In-reply-to: <953beacc0711290824k50d781dfm21e06f3dcc898236@mail.gmail.com>
Date: Thu, 29 Nov 2007 11:48:34 -0500
From: Phil Shafer <phil@juniper.net>
X-OriginalArrivalTime: 29 Nov 2007 16:51:48.0067 (UTC) FILETIME=[21A8E330:01C832A8]
X-Spam-Score: -4.0 (----)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: discuss@apps.ietf.org
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

"Rohan Mahy" writes:
>If you want to do strict validation of things like RPC methods on the
>receiving implementation, the implementation can contain a list of all the
>RPC methods it supports (an effective schema). If this level of validation
>is not desired, we can ignore this concept.

The issue isn't validation of the messages, but validation of the
NETCONF datastore.  We want to be modeling the data inside the NETCONF
datastore, thinking more in terms of the object instances than the
xml content being sent over the wire.  XSD and RNG model the syntax of
the xml content, not the semantics of the databases that NETCONF is
building.

If I say that a particular node is mandatory in the datastore, I'm not
saying that it must appear in every XML RPC that's manipulating the
datastore.  If <b> is a mandatory leaf under <a>, I can perform an RPC
that creates <c> under <a> without that RPC containing <b>.  The
validation tests are only meaningful to the complete data contents,
not for individual RPCs.  The constraints imposed by the YANG module
definition must be complied with to have a valid configuration
datastore, but do not apply to each <edit-config> operation.

The semantics YANG provides are also important for defining the
operations that are available over NETCONF.  For example, when the
order of entries in a list are maintained in an order defined by the
user, you use YANG's "ordered-by user" statement to indicate that the
list entries can be modified using the "insert" attribute.  And saying
that a container is operational data (rather than configuration) tells
me that this container will be in the output of a suitable <get> RPC,
within the proper hierarchy and keys defined in the YANG module.

With YANG, I don't need distinct schemas to describe the scenarios
where I traffic my YANG module's data, if I drive my validation from a
YANG-enabled parser.  But I can derive those schemas from my YANG
module as needed.

In many respects, YANG is similar to the approach of WSDL and WADL,
which puts high-level concepts in specific high-level statements, but
allows easy translation to XML schema languages.  You can think of
YANG as an IDL for NETCONF, but it does considerably more, in terms of
modeling the configuration.

Thanks,
 Phil