Re: Proposal to do away with netconf attributes in data model payloads

[Andy Bierman <abierman@cisco.com>]

At 12:57 PM 3/30/2004, Juergen Schoenwaelder wrote:
>On Sun, Mar 28, 2004 at 03:52:31PM -0800, Andy Bierman wrote:
> 
>> 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.
>
>My proposal would be something like this:
>
>  <edit-config>
>    <create>
>      <foo> ... </foo>
>    </create>
>    <modify>
>      <goo> ... </goo>
>    </modify>
>  </edit-config>
>
>Note that I do not make assumptions about the naming, which you seem
>to do.  (And I tend to believe that the assumption everything can be 
>fitted into a single naming hierarchy will not work.)

Your proposal is essentially the same as above,
except you removed the <config> container.
The only reason there aren't any assumptions
about naming is that there's no naming in your example.
The data modeling language will have to specify 
how naming is done.  

As I pointed out in my previous emails, this approach
is too simplistic because the agent needs to know the
specific element sub-tree associated with the edit-action.
That's why we're using the 'operation' attribute now.

Andy



>If we want to express where some configuration snipped goes, we
>should use xpath. And we should make sure that we can specify things
>like insert before or insert behind. 
> 
>> 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>.
>
>Not sure I understand this. Why do you want to have two filter
>expressions? It should be possible to combine both sub-expressions 
>into a single expression. Also, I do not see the value of the
><config/> element here.
> 
>> ----------------------------------------------------------------
>> 
>> 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>
>
>Well, perhaps this is syntactic encoding and style. However, what I
>would like to see is an encoding which allows to create a procedural
>programmatic interface without too much "conversion". This is why I
>prefer to view the primitives as function signatures, e.g.
>
>
>
>-- 
>Juergen Schoenwaelder               International University Bremen
><http://www.eecs.iu-bremen.de/>     P.O. Box 750 561, 28725 Bremen, Germany
>
>--
>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/>