RE: Proposal to do away with netconf attributes in data model pay loads

[Andy Bierman <abierman@cisco.com>]

At 06:20 AM 3/29/2004, Gilbert Gagnon wrote:

>Hello, 
>
>If you go back to my second reply, this is what I was suggesting 
>with the action-dominant encoding.  I never restricted it to one operation 
>at a time.  If you support a sequence of operations like that I also do not 
>see this having any issue on the fail-on-error model (again, I'm mainly 
>commenting on the encoding).  IHMO, however, it make the creation of the 
>PDUs more forward and it clears up the separation between what NetConf 
>wants to define (the operations and the RPC mechanisms) and what 
>it wants to defer (the data model). 
>
>I therefore agree with this (a bit more with the first than the second proposal 
>but not enough to argue about it). 

okay -- my concern was over the 1 edit-action per PDU constraint.
I don't care much about the 2nd proposal either.  <edit-config>
vs. <edit><config> isn't that important.

There is a restriction in my proposal (or is it yours? ;-)
that the action applies to the innermost nest layer specified
in each data model subtree.  
  
  1) This restriction only applies to <create>, <modify>,
     and <delete>.  The <merge> and <replace> edit-actions apply
     to all the elements in the payload. 
  2) The "innermost nest level" is too simplistic because 1 or more
     of the sibling nodes at the target nest level may themselves
     be aggregates (e.g. InetAddress)

     One approach to fix this is to make the innermost level the
     default target, but add an attribute to the edit-action elements
     to override the target nest level:

     <edit-config>
       ...
       <config>
         <create start-layer="3">
           <foo> 
             <bars>
               <bar>
                 <instance-id>7</instance-id>
                 <priority>3</priority>
                 <server-addr>
                   <addr-type>ipv4</addr-type>
                   <addr>192.168.1.1</addr>
                 </server-addr>
               </bar>
             </bars>
           </foo>
         </create>
       </config>
     </edit-config>

In this example, the start layer is /foo/bars/bar.
The path /foo/bars must already exist and "bar.7"
must not exist.


>Thanks 

Andy



>-----Original Message----- 
>From: Andy Bierman [<mailto:abierman@cisco.com>mailto:abierman@cisco.com] 
>Sent: Sunday, March 28, 2004 6:53 PM 
>To: j.schoenwaelder@iu-bremen.de 
>Cc: Gagnon, Gilbert [CAR:NM10:EXCH]; Waters, Glenn [CAR:IO47:EXCH]; netconf@ops.ietf.org 
>Subject: Proposal to do away with netconf attributes in data model payloads 
>
>Hi Juergen, 
>
>Would this idea make you like edit-config any better? 
>
>What if we formalized the edit-config verb as a node under <config> instead of putting it in the data model? 
>
>I.e., instead of 
>  
> <edit-config> 
>    ... 
>    <config> 
>       <foo operation="create"> ... </foo> 
>       <goo operation="modify"> ... </goo> 
>    </config> 
>  </edit-config> 
>
>    where <config> is the standard container 
>
>we have: 
>
>  <edit-config> 
>    ... 
>    <config> 
>      <create> 
>        <foo> ... </foo> 
>      </create> 
>      <modify> 
>         <goo> ... </goo> 
>      </modify> 
>    </config> 
>  </edit-config> 
>
> where <create>, <modify>, <merge>, <replace> and <delete> 
> are the standard containers.  The verb applies to the  innermost nest-level specified in the data model content.  Each of these containers can appear zero or one times (in any
>
> order) within a <config> element.  The agent will execute 
> them in the order they appear. 
>
>In addition, the same technique could be used to eliminate the need to have an xpath attribute in the data model: 
>
>  <get-config> 
>    ... 
>    <config> 
>      <filter value="xpath-expr-for-foo"> 
>        <foo/> 
>      </filter> 
>      <filter value="xpath-expr-for-goo"> 
>         <goo> ... </goo> 
>      </filter> 
>    </config> 
>  </get-config> 
>
><filter> can appear zero or more times.  Data like <foo> 
>can appear instead of <filter>. 
>
>---------------------------------------------------------------- 
>
>Separate proposal: 
>
>I wouldn't even mind if we put the 'config' in the 
>element path, so we had: 
>
>  <edit> 
>    <config> 
>      ... normal edit-config parmameters like <error-option> ... 
>      <config-data>  (container renamed from <config>) 
>        <create>  ... </create> 
>      </config-data> 
>    </config> 
>  </edit> 
>
> This way <config> could be a 'choice' in the XSD, and 
> we could add other 'filters' later.  For <get> the 
> choice is between <config> or <all>: 
>
>  <get> 
>    <config> 
>      ... get-config specific params 
>      <config-data> 
>         ... 
>      </config-data> 
>    </config> 
>  </get> 
>
>OR 
>
>  <get> 
>    <all> 
>      ... get-all specific params 
>      <data> 
>         ... 
>      </data> 
>    </all> 
>  </get> 
>
>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/>