[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi,

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

This is still too simplistic.  The edit-action
elements could provide a choice of 2 attributes,
start-level (for simple cases) or start-path:

     <edit-config>
       ...
       <config>
         <create start-path="/foo/bars/bar | /goo">
           <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>
           <goo> ... </goo>
         </create>
       </config>
     </edit-config>

This example is the same as the previous one, except
<goo> must not exist as well.

I guess you meant the <filter> stuff in your previous email
wrt/ "2nd proposal". I don't think the WG should spend too 
much effort on the filtering problem since it's so closely
tied to the data models.  If one xpath expression, applied
to the entire contents of the filter, is good enough, then
it would be worth doing.

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