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

[Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>]

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

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