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

[Andy Bierman <abierman@cisco.com>]

At 10:43 AM 3/9/2004, Rob Enns wrote:
>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.

I think we should defer format conversion issues to the data modeling
WG (or whatever it's called).  This format parameter does not seem
interoperable or complete.  It's possible for zero or multiple
mappings to exist for a given element sub-tree (or text blob,
going the other way).  We cannot mandate a 1:1 complete mapping,
since we aren't standardizing data models yet.

I think this should be left as a proprietary RPC call for now,
instead of part of copy-config.  


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

We already have an issue (14.1) for this, and the WG agreed
in Seoul to try harder to fix this "big get" problem.
I think we may have closed 14.1.3 (subset by name) a bit early.  
The comment says:

  "Closed: data model specific, defer to a different WG effort"

While it's true that the instance information format is
data model dependent, the notion of retrieving just the
instance information (for the specified element) is not.
The protocol could have a "instance info only" retrieval
mode, and place a requirement on the data modelling 
language to support it.

This may be a new topic, but the protocol does not have
a good mechanism for instance discovery.  We have no
get-next, and we don't want lexinext ordering, so
we don't want get-next,  but we still need an efficient
way to discover the instance information without
retrieving the entire data structure.

Note that is feature is much different than XPath expressions.
A generic application should be able to retrieve instance
information, and traverse the data model instances, without 
full knowledge of the data model (as required with XPath).
Most of the details of this procedure are outside the
scope of this WG, but any protocol support for this
operational mode is in scope.

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

By all means no!!
The mailing list is the official record of WG consensus.
I know the Issue Last Call is supposed to be over, but that
doesn't mean we cut off discussion of unresolved issues.

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