Re: analysis of YANG vs. RELAX NG

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 03 December 2007 15:34 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 1IzDJn-00009a-Cb; Mon, 03 Dec 2007 10:34:47 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzDJm-000094-8u for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 10:34:46 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzDJl-00008s-Vg for discuss@apps.ietf.org; Mon, 03 Dec 2007 10:34:45 -0500
Received: from hermes.jacobs-university.de ([212.201.44.23]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzDJl-0005bN-8I for discuss@apps.ietf.org; Mon, 03 Dec 2007 10:34:45 -0500
Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id B39C28A2DF; Mon, 3 Dec 2007 16:34:44 +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 15352-08-10; Mon, 3 Dec 2007 16:34:39 +0100 (CET)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5037C8A2FB; Mon, 3 Dec 2007 16:34:10 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 5406540687F; Mon, 3 Dec 2007 16:34:10 +0100 (CET)
Date: Mon, 3 Dec 2007 16:34:10 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Ladislav Lhotka <lhotka@cesnet.cz>
Subject: Re: analysis of YANG vs. RELAX NG
Message-ID: <20071203153410.GA17459@elstar.local>
References: <953beacc0711271504y7aea5f21jc301ccad886d3611@mail.gmail.com> <474D9194.3060103@ericsson.com> <953beacc0711281025w4d993dd7u77d729111074496c@mail.gmail.com> <20071128.230244.254578150.mbj@tail-f.com> <63F8A418-6AF0-4205-ACC7-53A8C7BC6A73@osafoundation.org> <47512728.6040201@gmx.de> <517bf110712021242v43c462f0v86267f591e5cdfbd@mail.gmail.com> <1196690162.5874.13.camel@missotis> <20071203140846.GB17536@elstar.local> <1196692404.5874.36.camel@missotis>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1196692404.5874.36.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: e8a67952aa972b528dd04570d58ad8fe
Cc: discuss@apps.ietf.org
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@jacobs-university.de
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

On Mon, Dec 03, 2007 at 03:33:24PM +0100, Ladislav Lhotka wrote:
 
> It doesn't necessarily mean mixed content, just changing
> 
> <anel>XYZ</anel>
> 
> into
> 
> <anel>
>   <anel-qual>ABC</anel-qual>
>   <anel-value>XYZ</anel-value>
> </anel>
> 
> Or, alternatively, the qualification info can be encoded in an
> attribute, which doesn't seem to be possible in YANG at all. I know,
> attributes are also frowned upon, but sometimes such a flexibility comes
> handy - and, after all, in some situations the extra attribute can be
> understood as metadata.

Historically, network management protocols did not allow such a change
of semantics of a defined construct. 

Once you have standardized <anel>XYZ</anel>, then it is supposed to be
exactly that. If you allow changes as suggested above, the life of
management applications that have to support multiple versions becomes
fun. Note also that it is common to have references between different
parts of a larger data model and if you are allowed to make changes as
above, you might break references you are not aware of. The versioning
rules therefore have always been "once published, don't change" and
"if broken, create something new which is better".

> > > Another problem might be the default statement in leaves (or it is
> > > proper to say leafs here?:-) or typedefs. What if a standard data model
> > > defines an item, say a hello timer, with such a default, but an
> > > implementation wants to use another value for the default? Should it
> > > come up with another schema?
> > 
> > No. There can only be one standard default. If you are thinking about
> > reusable groupings, then defaults can actually be changed wherever you
> > apply a grouping as far as I know.
> 
> Protocols specifications in RFCS usually say that a particular default
> value SHOULD be something. So an impementation might have a reason for
> using something else. In such cases, the standard data model thus cannot
> use the default statement, right? 

Yes, YANG says:

   If the leaf has a default value, the server MUST use this value
   internally if no value is provided by the NETCONF client when the
   instance is created.

So yes, a YANG default is a contract between the device and the
manager I can rely on. You may argue this is bad and sure such a
discussion can be held. But we did this knowingly and not as an
accident.

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