Re: Proposal to do away with netconf attributes in data model pay loads

[Andy Bierman <abierman@cisco.com>]

At 02:56 PM 4/8/2004, Juergen Schoenwaelder wrote:
>On Fri, Apr 02, 2004 at 07:20:46AM -0800, Andy Bierman wrote:
> 
>> Here are the problems with (a):
>> 
>>   - specifying a NETCONF-only subset of XPath is not an
>>     option.  It's all-or-nothing for XML standards like this
>
>I fail to see the logic here. I guess your real concern is that once
>there is a subset of XPATH, devices will end up supporting full XPATH
>at the end anyway. While you believe this would be really bad, I tend
>to believe that this might be not so bad.

In order for a vendor to comply with the NETCONF Xpath subset,
the NETCONF WG would have to specify exactly which parts
of XPath need to be supported.  I don't think a subset is
a good idea in the first place, but if it was, the NETCONF WG
is probably not the right standards working group to define
such a standard.  

As others have also pointed out, my objections are entirely
related to using XPath to identify a node in the XML instance
document to apply edit-config operations.  


>>   - image footprint, memory/CPU requirements, coding and
>>     testing complexity are all negatively impacted by 
>>     the XPath implementation requirement.  The smaller
>>     the device, the more this matters
>
>Again, why is comparing subtrees any cheaper than parsing simple
>XPATH path expressions? I asked the question before and did not
>get a convincing answer.

I think others have pointed out the difference in
complexity quite well.  Constructing XPath expressions
is harder on the application than inserting an attribute.
Deconstructing XPath expressions and associating them
with specific nodes in the element tree is harder on
the agent than extracting attributes from the instance
document.


>>   - instance naming impacts the complexity and form of the
>>     Xpath expressions. What is the canonical representation?
>>     These data modeling issues won't be decided until after
>>     the protocol is finished. 
>
>This is a general observation, not an argument against XPATH. In fact,
>it is an argument in favor of XPATH since we keep the flexibility
>without over constraining the data modeling solution at this point.

We aren't even going near the instance naming issue if we
use the operation attribute.  


>>   - The Xpath expressions are not going to be interoperable,
>>     since there are no guidelines at all how to use it.
>>     Any attempt to impose order will require some netconf-specific
>>     elements or attributes be encoded in the data model
>>     (like Juergen's 'uri' attribute).  But this is the exact
>>     problem the Xpath approach is supposed to solve.
>
>I used uri's for naming, which is at this point treated as a data 
>modeling issue. Obviously, there can't be guidelines for using
>XPATH before the data model stuff has been worked out. This is a
>feature, not a bug.

IMO, it's a weakness of the XPath-for-identifying-the-start-node
approach.  The current approach uses XML attributes.  There is 
no need to define any new constructs for naming in order to
identify the start node of an edit operation.  XPath+uri attribute
is much more complex than needed for this task. The "+uri attribute"
part just trades a simple attribute (operation) for a
different one (uri) with more complicated semantics.

> 
>> IMO, option (c) is the easiest to implement (for agent and
>> manager), the most readable, and the most interoperable
>> choice we have.
>
>I obviously disagree on all points (noting that interoperability
>without at least specifying how naming works is impossible).

I agree that in order for 2 implementations of the FOO module
to interoperate, the FOO module has to be specified.  Since
there are no standard XML data models for netconf yet, it's
premature to declare defeat yet.


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