Re: [YANG] insert and key attributes

Andy Bierman <ietf@andybierman.com> Mon, 14 January 2008 17:31 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 1JET9h-0001fx-JM; Mon, 14 Jan 2008 12:31:25 -0500
Received: from yang by megatron.ietf.org with local (Exim 4.43) id 1JET9g-0001ff-09 for yang-confirm+ok@megatron.ietf.org; Mon, 14 Jan 2008 12:31:24 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JET9f-0001fX-LP for yang@ietf.org; Mon, 14 Jan 2008 12:31:23 -0500
Received: from smtp102.sbc.mail.mud.yahoo.com ([68.142.198.201]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1JET9f-0007iK-6B for yang@ietf.org; Mon, 14 Jan 2008 12:31:23 -0500
Received: (qmail 86777 invoked from network); 14 Jan 2008 17:31:22 -0000
Received: from unknown (HELO ?192.168.0.10?) (andybierman@att.net@67.126.240.103 with plain) by smtp102.sbc.mail.mud.yahoo.com with SMTP; 14 Jan 2008 17:31:21 -0000
X-YMail-OSG: lR8kfVoVM1mqx9MO4bKrfi_8GGv1goaCMBUDO1Im5y4GBhE3
Message-ID: <478B9CE3.3010903@andybierman.com>
Date: Mon, 14 Jan 2008 09:33:23 -0800
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: Phil Shafer <phil@juniper.net>
Subject: Re: [YANG] insert and key attributes
References: <200801141710.m0EHATX9058087@idle.juniper.net>
In-Reply-To: <200801141710.m0EHATX9058087@idle.juniper.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: yang@ietf.org
X-BeenThere: yang@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
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

Phil Shafer wrote:
> Andy Bierman writes:
>> This is your interpretation of RFC 4741.
> 

I think you are misunderstanding my concern.
Extending the set of standard edit-config operations is fine.

The document(s) specifying any new standard protocol operations should be
independent of the data modeling language.  This is done
simply by specifying the XML content (e.g., operation attribute)
instead of a particular DML representation of the XML.

The NETCONF WG should agree on this sort of new NETCONF protocol feature,
the same as any other.


Andy


> Yup, and it's my memory of the WG's repetition of "that's up
> to the data modeler".
> 
>> The goal of the IETF should be to
>> converge on a standard <edit-config> operation, not simply
>> codify proprietary CLI with angle brackets.
> 
> RFC 4741 did neither of these extremes.  We said explicitly:
> 
> 5.2.  Data Modeling
> 
>    Data modeling and content issues are outside the scope of the NETCONF
>    protocol.  An assumption is made that the device's data model is
>    well-known to the application and that both parties are aware of
>    issues such as the layout, containment, keying, lookup, replacement,
>    and management of the data, as well as any other constraints imposed
>    by the data model.
> 
>    NETCONF carries configuration data inside the <config> element that
>    is specific to device's data model.  The protocol treats the contents
>    of that element as opaque data.  The device uses capabilities to
>    announce the set of data models that the device implements.  The
>    capability definition details the operation and constraints imposed
>    by data model.
> 
> NETCONF gives all power to the data model.  It's an open spec that
> allows expandability and evolution.  The goal of the IETF is to
> deploy standards that people actually use, and past NM efforts that
> have taken this fascist content model have failed due to lack of
> flexibility and expressiveness.  NETCONF works hard not to repeat
> those mistakes.
> 
> The operations in 4741 were not meant to be an exhaustive list that
> limits what the DM can do, but to give a normal way to do the few
> things that the WG could agree on.  There are many operations that
> can only be defined once the data model is known.  YANG defines how
> keys are encoded, making it possible to do use "insert" to reorder
> lists.  Without lists, keys, and the semantics behind them, you
> can't define that operation in any meaningful manner. (Yes, you can
> to the "here's a blob to tell you what to move" and "here's a blob
> to tell you where to move it", but even these need the data model
> to tell you what you can move and where you can move it).
> 
> Thanks,
>  Phil
> 
> 



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