Re: [YANG] insert and key attributes

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Sun, 13 January 2008 18:01 UTC

Return-path: <yang-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE79A-0001Qe-TR; Sun, 13 Jan 2008 13:01:24 -0500
Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JE799-0001QZ-6v for yang-confirm+ok@megatron.ietf.org; Sun, 13 Jan 2008 13:01:23 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JE798-0001QQ-Rz for yang@ietf.org; Sun, 13 Jan 2008 13:01:22 -0500
Received: from hermes.jacobs-university.de ([212.201.44.23]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1JE798-0003l2-90 for yang@ietf.org; Sun, 13 Jan 2008 13:01:22 -0500
Received: from localhost (demetrius.jacobs-university.de [212.201.44.32]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAD818A2DA; Sun, 13 Jan 2008 19:01:20 +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 30989-08-5; Sun, 13 Jan 2008 19:01:15 +0100 (CET)
Received: from elstar.local (elstar.iuhb02.iu-bremen.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25AEE8A350; Sun, 13 Jan 2008 19:01:15 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id D05F046661E; Sun, 13 Jan 2008 19:01:13 +0100 (CET)
Date: Sun, 13 Jan 2008 19:01:13 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Andy Bierman <ietf@andybierman.com>
Subject: Re: [YANG] insert and key attributes
Message-ID: <20080113180113.GA26178@elstar.local>
Mail-Followup-To: Andy Bierman <ietf@andybierman.com>, Martin Bjorklund <mbj@tail-f.com>, yang@ietf.org
References: <200801130549.m0D5nSFR049573@idle.juniper.net> <478A2621.2060603@andybierman.com> <20080113.173532.102915601.mbj@tail-f.com> <478A4DC7.1020705@andybierman.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <478A4DC7.1020705@andybierman.com>
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: e1e48a527f609d1be2bc8d8a70eb76cb
Cc: yang@ietf.org
X-BeenThere: yang@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: j.schoenwaelder@jacobs-university.de
List-Id: YANG modeling Language for NETCONF <yang.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/yang>, <mailto:yang-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/yang>
List-Post: <mailto:yang@ietf.org>
List-Help: <mailto:yang-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/yang>, <mailto:yang-request@ietf.org?subject=subscribe>
Errors-To: yang-bounces@ietf.org

On Sun, Jan 13, 2008 at 09:43:35AM -0800, Andy Bierman wrote:

> IMO, it is important to separate the data modeling language
> from the protocol, and to keep the NETCONF protocol as DML-neutral
> as possible.

A protocol and its data modeling language go hand in hand.

> It doesn't seem like a good idea for interoperability to
> have one flavor of NETCONF if the vendor uses YANG data models
> and another if the vendor uses XSD or RelaxNG.  Even worse,
> what if the vendor publishes some modules as YANG, others
> as XSD, and there are different flavors of NETCONF within
> the same agent.

XSD and RelaxNG without extensions and restrictions won't be terrible
useful for YANG. So if at all, we talk about XSD-+ and RelaxNG-+.

> But the key and insert attributes change the behavior of the
> <edit-config> operation.  It doesn't matter that they change it for
> the better, by adding support for user-ordered lists.  What matters
> is that a standard protocol needs to be changed by a WG, and should
> be done in a way that is not specific to one particular DML.

If there are things in YANG that really belong to the protocol, we
should turn them into proper protocol extension proposals for the
NETCONF working group to consider.

The end goal is to make NETCONF a success and if there are things
where the protocol needs improvement based on implementation
experience, then lets work out the details and get the NETCONF WG to
look at it. I think it would be good if the NETCONF WG would have a
plan to revise the NETCONF spec - if alone to fix known bugs and
ambiguities.

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


_______________________________________________
YANG mailing list
YANG@ietf.org
https://www1.ietf.org/mailman/listinfo/yang