[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Poll for consensus on edit operations
At 06:51 AM 3/31/2004, Glenn Waters wrote:
>I feel like we are trying to vote on a half solution. Without context of where XPath fits into the solution I find it hard to distinguish between options A-C.
>
>I don't want option D as it mixes the protocol into the model.
>
>As another poster on this list said, a concrete example might help direct people to the answers.
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)
- 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)
- 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?
- 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.
>Regards, /gww
Andy
>> -----Original Message-----
>> From: Andy Bierman [<mailto:abierman@cisco.com>mailto:abierman@cisco.com]
>> Sent: Tuesday, March 30, 2004 17:35
>> To: netconf@ops.ietf.org
>> Subject: Poll for consensus on edit operations
>>
>> Hi,
>>
>> I'd like people to weigh in on the attribute vs. element
>> issue, including the encoding details (see below).
>>
>> I now agree with Juergen that it is highly undesirable
>> to require protocol-specific attributes in data-model
>> elements to implement any NETCONF protocol operation.
>> It is better to keep the data models as protocol independent
>> as possible, to avoid dependencies on specialty tools
>> that will limit the deployment of NETCONF. It is better
>> to use more complex mechanisms (like XPath) that are likely
>> be supported by general-purpose XML standards-based tools.
>>
>> thanks,
>> Andy
>>
>> ----------------------------------------------------------------
>>
>> 1) Specifying the start point of the edit action
>>
>> If attributes are used, then the start-point is the
>> element containing the attribute. If attributes are
>> not used, then the start point has to be specified
>> somehow. This can be done in a simple manner with
>> the attribute (in the edit-action element) start-level="<N>"
>> or the more complex start-path="<Xpath-expr>" attribute.
>>
>> 2) Basic form of the <edit-config> operation
>>
>> A) edit-actions are contained in <config>
>>
>> <edit-config>
>> <target><running/></target>
>> <test-option>test-then-set</test-option>
>> <error-option>rollback-on-error</error-option>
>> <config>
>> <create>
>> <foo> ... </foo>
>> </create>
>> <modify>
>> <goo> ... </goo>
>> </modify>
>> </config>
>> </edit-config>
>>
>> B) edit-actions are contained in <edit-config>
>>
>> <edit-config>
>> <target><running/></target>
>> <test-option>test-then-set</test-option>
>> <error-option>rollback-on-error</error-option>
>> <create>
>> <foo> ... </foo>
>> </create>
>> <modify>
>> <goo> ... </goo>
>> </modify>
>> </edit-config>
>>
>> C) multiple <config> sections allowed, each with a verb
>> and a start-level; This avoids the need for Xpath
>> support completely, since an action could appear
>> more than once (<config> maxOccurs="unbounded")
>>
>> <edit-config>
>> <target><running/></target>
>> <test-option>test-then-set</test-option>
>> <error-option>rollback-on-error</error-option>
>> <config operation="create">
>> <foo> ... </foo>
>> </config>
>> <config operation="modify">
>> <goo> ... </goo>
>> </modify>
>> </edit-config>
>>
>> D) edit-actions as operation attributes (current approach)
>>
>> <edit-config>
>> <target><running/></target>
>> <test-option>test-then-set</test-option>
>> <error-option>rollback-on-error</error-option>
>> <config>
>> <foo operation="create"> ... </foo>
>> <goo operation="modify"> ... </goo>>
>> </config>
>> </edit-config>
>>
>>
>> --
>> 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/>http://ops.ietf.org/lists/netconf/>
--
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/>