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

[Rob Enns <rpe@juniper.net>]

On Sat, Mar 06, 2004 at 11:28:56PM +0100, Juergen Schoenwaelder wrote:
> I was just reading through the ID and found some places where there is
> still text about different formats. I think we decided to only have one
> format - XML. The details:
> 
> a) copy-config still has a format parameter? This parameter seems to
>    have gone everywhere else.

I left the format parameter in copy-config because there's no alternative 
mechanism (ie. namespace) available to indicate if the result is desired in
text or XML. If we want to disallow format conversion via copy-config we
can whack the format parameter.
 
> b) The description/examples of <get-config>, <get-all> still refer to/use
>    the format parameter.

Thanks for catching these.
 
> What worries me a bit more:
> 
> c) get-config(source, filter) and get(filter) both take a filter to
>    select what should be retrieved. As was noted before, this really
>    interacts with the data model and what is currently written down
>    (simple subtree filtering) look to me a bit too simplistic. Has
>    this filter issue in the meantime been resolved? How does the 
>    fact that this interacts with the data model been addressed?
> 
>    [My preference is still XPATH since it will be powerful enough
>     to handle almost any reasonable XML data model and it is quite
>     natural from an XML perspective. I can live with subsetting
>     XPATH with a full XPATH capability if that really makes 
>     implementations more cost effective. In fact, defining a
>     subtree XPATH subset should be rather straightforward.]

The resolution of the issue to date is that improved text will be
written to define exactly how the simple subtree filtering works.
You're probably right, once somebody (ie. me) sits down and works
on that text, it'll turn out to be rather data-model specific 
(the filtering has to address indexing somehow, and that relates
to the data model), and folks will poke lots of holes in it that 
will eventually make me with we'd just stuck with XPATH.
 
> d) The edit-config(target, options, config) with the merge / replace 
>    / delete attribute operations looks a bit strange (like others have 
>    noted before). This really smells like a compound operation which 
>    combines merge/replace/delete operations into a single rpc call. I 
>    recently looked closer at NFSv4 protocol (RFC 3530) which has such 
>    a compound operation and NETCONF might be actually simpler by 
>    adopting a model which makes compound operations first class 
>    citizens.

This was discussed a little in Seoul, the current restriction on
edit-config is that all values of the operation attribute in a single
edit-config operation must have the same value. Is removing that 
restriction what you have in mind?

thanks,
 Rob
 
> I do not know precisely what happened in Seoul - so if these issues have
> been closed and I am just too late, let me know and I will shut up.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany
> 
> --
> 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/>

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