[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Poll for consensus on edit operations
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.
> 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.)
> 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.
> >
> >> - 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.
> 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.
> >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).
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.
<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?
/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/>