Re: Poll for consensus on edit operations

[Andy Bierman <abierman@cisco.com>]

At 01:51 PM 4/1/2004, Juergen Schoenwaelder wrote:
>On Thu, Apr 01, 2004 at 12:39:16PM -0800, Andy Bierman wrote:
>
>> >I think not using xpath will be a pain in the longer term since we
>> >will have to stick with a rather restricted model to select and
>> >identify instances for ever.
>> 
>> What does this have to do with the instance identifier choice?
>> I thought the assumption was that no matter how the naming
>> is done, an Xpath expression can be constructed.  I'd like
>> an Xpath expert to redo the 'chassis' example I did but use
>> a different (child element based) naming scheme instead of
>> a simple attribute.   I'd like to see how the path to
>> "ip-filter.1" is constructed in this case.  I suspect
>> the expression is rather complex, if possible at all.
>
>Your attributes are designed to be unique on the nesting level
>so you have to specify the full path and the various parts of the
>instance name to identify an object. Why not use URI names for
>the objects which are device-globally unique? This would make
>the selection of a specific instance pretty simple.

Can you provide an example?

Wouldn't this be placing a big requirement on standard
and vendor data model designers, which is something we're
trying to avoid?

> 
>> The operation attribute seems way easier to implement 
>> in comparison.  This is important if we want vendors
>> to deploy NETCONF.
>
>I don't know how you measure "complex" and "easy" so I better
>do not comment here. (Also it strikes me that you think that
>vendors deploy NETCONF - I thought this is something your 
>customers have to do.)

I don't think specifying a subset of Xpath required for
NETCONF compliance is a viable approach for this WG.  
If you consider instance identification (which you
must in many data models) then the Xpath expressions
needed aren't very simple to implement.

The point is that it is quite difficult to implement
compared to the solution already in the document.
At first I wanted to get rid of the operation
attribute, but not if the solution is way too 
complicated to implement on every agent.

> 
>> Note that the 'operation' attribute only changes the 
>> encoding aspect of the coupling between the NETCONF
>> protocol and data models.   In any case, the application
>> and agent need to understand the NETCONF protocol
>> operations and edit "verbs".   This coupling exists
>> no matter how the semantics are encoded on the wire.
> 
>> It would be better to constrain the coupling to the
>> NETCONF-specific elements, but if a full Xpath engine
>> is required in every agent just to identify the start point
>> of an edit operation, then vendors will not implement
>> NETCONF.  This trade-off is too high for the problem
>> it's supposed to solve.
>
>I really fail to understand why parsing a simple xpath expression 
>consisting of path elements separated by slashes and attribute
>pattern is any more complex than matching XML subtrees. If you
>read my messages carefully, you will see that I never said to
>require full xpath in every agent.

Again, it's a question of relative complexity, comparing
various proposals to the solution already in the document.

There are widely deployed tools that let an agent implementation
callback functions register for elements (or start tags, etc.).
Parsing an XML instance document is not hard.  Parsing the
complete XPath language is hard.  Correlating a path string
to specific insertion points in the internal configuration
database representation can be hard. Since the agent has to parse 
the element tree anyway to execute the edit-config request,
it's very little extra work to check the attributes that
are encoded into each element.


>> > 
>> >>      - If so, it it okay to constrain the Xpath feature set to
>> >>        simple expressions? (E.g., absolute path from the start of 
>> >>        the <config> contents /foo/bars/bar)
>> >
>> >I rather prefer to use xpath and to constrain xpath if people are
>> >really worried about the xpath complexity. This at least allows a
>> >clean forward migration path (and also implementations can distinguish
>> >themself by supporting more or less xpath functionality).
>> 
>> It's a lot of work to specify a clean subset, especially
>> in this case.  Then there's the problem that our subset
>> might not be compatible with off-the-shelf tools that
>> support Xpath.  
>
>If you use an off-the-shelf tool, then just use full xpath.

Easier said than done on small embedded devices.
Applications are far more likely to have access to
off-the-shelf tools.  If NETCONF specifies a minimal
subset that these tools don't adhere to, the tools are
going to be useless to application developers.


>> We might as well have our own proprietary
>> syntax like:
>> 
>>   /chassis/slots/slot.3/ports/port.7/filters/ip-filters/ip-filter.1
>
>For me, this would be the biggest mistake we can make.

Yep. I agree. We're not making it either.
The only thing that counts here is what's in the draft now.

> 
>> >I think requiring instances identification in the path is problematic;
>> >I would prefer a URI based naming system and URIs in the middle of the
>> >path look kind of strange. In other words, I prefer a scheme where an
>> >object is named by a specific URI attribute. Of course, this implies
>> >that you can not restrict xpath expression to just simple paths.
>> 
>> Explain how you are going to specify that you mean the ip-filter.1
>> that is nested under slot 3, port 7?  I don't see how you can 
>> specify the start point if it's under a specific instance
>> of an element.
>
>If you refer to a specific existing instance, you use the URI (whatever
>it looks like) that the device generated for this specific instance. 
>If you create a new instance, you have to specify where it goes (probably 
>the URI of the container plus additional information - and this might 
>include things like start,end, or before/after some other instance).

This sounds like a big burden on applications and agents.


>I prefer a less deeply nested structure compared to what you have in
>mind. Trying to press everything into a single hierarchy will lead to 
>extremely long paths and things will become hard to agree on and to 
>maintain. For example, I prefer to have an <interface/> rather below 
>the top of the XML document representation instead of having it nested 
>in the physical entity hierarchy. The URI identifying the interface
>may have information where it is located but it does not have to.

I don't think a data model of a chassis with slots and ports
in it is a big stretch for data modeling requirements for
networking devices. 

><interface uri="urn:cisco:if:atm4/0">
>   <operational>up</operational>
>   <administrative>up</administrative>
>   <type>atm</type>
>   <speed unit="bps">0</speed>
>   <promiscuous>false</promiscuous>
>   <notifications>enabled</notifications>
>   <change>2004-02-16 16:38:53 +01:00</change>
>   <description>ATM4/0-atm layer</description>
>   <addresses>
>     <ip>1.2.3.4/30</ip>
>   </addresses>
></interface>
>
><chassis>
>  <slot uri="urn:cisco:slot:s19">
>    <module uri="urn:cisco:module:s19m20">
>      <port uri="urn:cisco:port:atm4/0">
>        <description>TI1570 ATM</description>
>        <interface ref="urn:cisco:if:atm4/0"/>
>      </port>
>    </module>
>  </slot>
></chassis>
>
>Does this make sense?

Yes, but the solution is worse than the problem its supposed
to solve.  Instead of a magic 'operation' attribute with simple,
universal values (e.g. 'create' or 'modify') we have
a magic 'uri' attribute with complex proprietary content.


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