RE: Poll for consensus on edit operations

[Branislav Meandzija <bran@arraycomm.com>]

It would be helpful to have a bit more complex real-life example using the different candidate solutions. I am more used to command-centric protocols but have the feeling that solution d) may be good for some fancy automation.

Branislav

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Andy Bierman
> Sent: Tuesday, March 30, 2004 2:35 PM
> 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/>
>


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