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

[Sandeep Adwankar <sandeep.adwankar@motorola.com>]

If the "operation" attribute is associated with edit-config element then
it could be added to NetConf protocol schema without dependency on data
model. See below for details.

1. The edit-config is added attribute "operation" with default as
"merge" as shown in schema below.
<xsd:complexType name="edit-configType">
      <xsd:complexContent>
         <xsd:extension base="xc:rpcOperationType">
            <xsd:sequence>
               <xsd:element ref="xc:source" minOccurs="0" />
               <xsd:element ref="xc:target" />
               <xsd:element ref="xc:test-option" minOccurs="0" />
               <xsd:element ref="xc:write-option" minOccurs="0" />
               <xsd:element ref="xc:error-option" minOccurs="0" />
               <xsd:element ref="xc:config" minOccurs="0" />
            </xsd:sequence>
        <xsd:attribute name="operation" type="xsd:string"
default="merge" />
         </xsd:extension>
      </xsd:complexContent>
   </xsd:complexType>
   <xsd:element name="edit-config" type="xc:edit-configType"
substitutionGroup="xc:rpcOperation" />

2. The delete management operation looks like
<edit-config operation="delete">
   <target>
      <url>/var/www/users</url>
   </target>
</edit-config>

3. The replace operation looks like
<edit-config operation="replace">
   <target>
      <url>/var/www/users</url>
   </target>

   <config>
      <users>
         <user>
            <name>root</name>
            <type>superuser</type>
            <full-name>Charlie Root</full-name>
         </user>
         <user>
            <name>fred</name>
            <type>admin</type>
            <full-name>Fred Flintstone</full-name>
         </user>
         <user>
            <name>barney</name>
            <type>admin</type>
            <full-name>Barney Rubble</full-name>
         </user>
      </users>
   </config>
</edit-config>

4. The merge operation is the default
<edit-config>
   <target>
      <url>/var/www/users</url>
   </target>

   <config>
      <users>
         <user>
            <name>root</name>
            <type>superuser</type>
            <full-name>Charlie Root</full-name>
         </user>
         <user>
            <name>fred</name>
            <type>admin</type>
            <full-name>Fred Flintstone</full-name>
         </user>
         <user>
            <name>BoB</name>
            <type>admin</type>
            <full-name>BOB Rubble</full-name>
         </user>
      </users>
   </config>
</edit-config>

5. No change in get-config
<get-config>
   <source>
      <url>/var/www/users</url>
   </source>
   <format>xml</format>
</get-config>

Thanks
Sandeep


Andy Bierman wrote:

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


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