Re: comments on draft-ietf-netconf-prot-02.txt

[Andy Bierman <abierman@cisco.com>]

At 07:18 AM 3/23/2004, Juergen Schoenwaelder wrote:
>On Mon, Mar 22, 2004 at 06:26:28PM -0800, Rob Enns wrote:
>
>> It's better because the edit-config operation 
>> allows the creation of a single "patch" to the device 
>> configuration which can encompass more than one 
>> operation type.
>> 
>> This is handy when scripting, and avoids carving a
>> given configuration change up into several pieces,
>> one for each operation type. 
>
>I guess this really depends on how your code is organized. (Even though
>I use emacs most of time, I write this email with vi and this editor
>requires me to say upfront what I am doing - perhaps we will never
>really resolve this issue what is more handy.)
> 
>> Also it's natural for an XML-aware application to go 
>> from an internal DOM tree representing desired changes
>> to the configuration snippet that would be passed
>> to edit-config.
>
>Why? For an application, I think the hard thing is to identify the 
>deltas that must be pushed to the device, not really the format
>of one big XML document with magic merge/replace/delete operation
>attributes sprinkled over it or a sequence of merge/replace/delete 
>operations.
>
>I can also imagine situations where you have many micro configuration 
>templates (conflet ;-) which are then combined into something you want 
>to apply to a bunch of devices. With the current netconf, you would
>have to join the XML fragments into a single XML fragment with
>appropriate attributes so that you can ship everything in a single
>edit-config operation.

The application is NOT forced to put all configlets
into 1 edit-config.  I don't want to force the
application writer to use 1 or N PDUs.  I want the
application writer to decide how many PDUs to use.
If they want to put a "create(foo)" and "delete(bar)"
in the same PDU, then why should the protocol (which
is supposed to be data model independent) place all kinds
of restrictions on data models, and prevent this?


>And most humans probably simply edit the retrieved configuration (with 
>emacs or vi ;-) and push the thing back to the device (if the device is
>smart enough to figure out the least disruptive way to move to the
>new configuration from the current one).
>
>/js

Andy


--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>