Re: analysis of YANG vs. RELAX NG

Andy Bierman <ietf@andybierman.com> Mon, 03 December 2007 18:11 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 1IzFlW-0003Jy-7o; Mon, 03 Dec 2007 13:11:34 -0500
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IzFlU-0003Hu-UV for discuss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 13:11:32 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzFlU-0003Hm-K5 for discuss@apps.ietf.org; Mon, 03 Dec 2007 13:11:32 -0500
Received: from omr4.networksolutionsemail.com ([205.178.146.54]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IzFlS-0006Pb-Fp for discuss@apps.ietf.org; Mon, 03 Dec 2007 13:11:32 -0500
Received: from mail.networksolutionsemail.com (ns-omr4.mgt.netsol.com [10.49.6.67]) by omr4.networksolutionsemail.com (8.13.6/8.13.6) with SMTP id lB3IAwd5001930 for <discuss@apps.ietf.org>; Mon, 3 Dec 2007 13:11:21 -0500
Received: (qmail 30610 invoked by uid 78); 3 Dec 2007 18:10:30 -0000
Received: from unknown (HELO ?130.129.85.76?) (andy@andybierman.com@130.129.85.76) by ns-omr4.lb.hosting.dc2.netsol.com with SMTP; 3 Dec 2007 18:10:30 -0000
Message-ID: <4754463C.2070901@andybierman.com>
Date: Mon, 03 Dec 2007 10:09:00 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 1.5.0.13 (Windows/20070809)
MIME-Version: 1.0
To: Ladislav Lhotka <lhotka@cesnet.cz>
Subject: Re: analysis of YANG vs. RELAX NG
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> <47543B30.1060409@andybierman.com> <1196704923.5569.14.camel@missotis>
In-Reply-To: <1196704923.5569.14.camel@missotis>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by omr4.networksolutionsemail.com id lB3IAwd5001930
X-Spam-Score: -1.0 (-)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
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

Ladislav Lhotka wrote:
> Andy Bierman píše v Po 03. 12. 2007 v 09:21 -0800:
>
>   
>> I strongly agree with Juergen.
>> YANG is based (in part) on 18+ years experience
>> with SNMP and SMI.
>>     
>
> And ignoring the additional flexibility XML can provide.
>
>   

flexibility is the enemy of inter-operability.
We are trying to create multi-vendor network management systems.
It is well understood in the NM world that refining existing data
definitions breaks existing manager code.


>> It s absolutely forbidden in NM to redefine the syntax and semantics
>> of a managed object in this way.
>>     
>
> Why? Even if I explicitly specify I am using another data model? The
> difference is that if the data model is easily extensible, I can just
> write
>
> import parent-model;
>
> and then 5 lines or so describing the differences, so that it is
> immediately clear what I am doing (and hopefully why). If the
> extensibility is weak, I have to take the parent model, change few lines
> and declare it as a new data model - but the differences are not that
> clear.
>   

This does not help the running code that expects the old definition of
the data object.

Deployment of NM code is part of our problem space.
It may be irrelevant to APPs work, but not NM.

> Lada
>  
>   

Andy