Re: Poll for consensus on edit operations

[Andy Bierman <abierman@cisco.com>]

At 11:12 AM 4/1/2004, Juergen Schoenwaelder wrote:
>On Wed, Mar 31, 2004 at 09:05:03AM -0800, Andy Bierman wrote:
>
>> I'll work on that, but I probably won't get to it for a few days.
>> 
>> The decision tree isn't that complex:
>> 
>> 1) Should netconf protocol details (currently only applies to
>>    the 'operation' attribute used for <edit-config>) be encoded
>>    as attributes within user data models?
>>    (I think WG consensus is leaning to no, but still undecided.)
>> 
>>    If yes) we're done
>>    If no) continue
>> 
>> 2) Now a new mechanism to identify the start node of an edit-config
>>    action is needed.  Here there are some issues which might impact
>>    each other:
>> 
>>    - Should implementation of Xpath be mandatory for this purpose?
>>      (I think the WG consensus is no.  We already decided not
>>       to add the #xpath capability in v1.0)
>
>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.

The operation attribute seems way easier to implement 
in comparison.  This is important if we want vendors
to deploy NETCONF.

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.

> 
>>      - 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.  We might as well have our own proprietary
syntax like:

  /chassis/slots/slot.3/ports/port.7/filters/ip-filters/ip-filter.1

But this would be niche-specific and not generally supported
by XML tools.  The 'operation' attribute is very much in the
design of XML (separation of data and meta-data) and will
be supported by all XML tools.


>>        - Do instance identifiers need to be part of the Xpath expression
>>          for this purpose?  The agent instrumentation will know
>>          if it's okay to create "bar.7", so isn't the path /foo/bars/bar
>>          good enough?
>
>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.

> 
>>    - Should edit-config be limited to one edit action per RPC?
>>      (I think the WG consensus is no)
>>      - If no, and no Xpath, then decide to find another way to 
>>        specify the start-point.
>> 
>>   - Does the start-point even need to be specified by the application?
>>     - The start point is always the data model root for merge and replace.
>>     - Modify is not really a problem because the agent can tell 
>>       that if elements like <foo> and <bars> are being used just
>>       to specify the path to <bar>, or if actual parameters are
>>       being modified.  The "must exist" test still applies to
>>       the whole path.
>>     - The start point is only important for create and delete actions
>>       because a data model can have nested dynamic objects, which
>>       creates ambiguity as to the intended node(s) for the edit action.
>
>There are cases where you have to identify the object you want to
>delete and it depends on the naming system how this is done. With
>xpath, you can probably do this for whatever naming system we will
>end up with. If netconf only supports simple path, then the choices
>for the naming system are rather fixed.
>
>Note, for create it might be important to specify that something is
>created "before" or "behind" an existing object and so either the
>manager is able to generate URIs or the manager has a way to express
>such a constraint and the agents generates a suitable object and URI
>^W name (what I would prefer).
>
>/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/>