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

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

To: Andy Bierman <abierman@cisco.com>
Subject: Re: Proposal to do away with netconf attributes in data model payloads
From: Sandeep Adwankar <sandeep.adwankar@motorola.com>
Date: Mon, 29 Mar 2004 16:19:09 -0600
Cc: j.schoenwaelder@iu-bremen.de, Gilbert Gagnon <gagnong@nortelnetworks.com>, Glenn Waters <gww@nortelnetworks.com>, netconf@ops.ietf.org
Organization: Motorola Labs
References: <0D7FC1D8D861D511AEA70002A52CE5E608F8BF8D@zcard0ke.ca.nortel.com> <6.0.3.0.2.20040326155900.026b2c28@fedex.cisco.com> <20040327210234.GA1036@iu-bremen.de> <6.0.3.0.2.20040328151434.0282ef98@fedex.cisco.com> <4068611E.5760EDF0@motorola.com> <6.0.3.0.2.20040329104143.02836768@fedex.cisco.com> <40687A0B.32F34FE8@motorola.com> <6.0.3.0.2.20040329121502.028017d8@fedex.cisco.com>

Since NetConf is designed to allow for only one rpc operation ( no constructs for
binding multiple operations together)  in a rpc message, I guess there will be two
separate rpc messages if a query is made to get admins and users.

<rpc message-id="1" xmlns="http://ietf.org/netconf/base/1.0";>
   <get-config>
      <source>
         <url>http://example.com/usrs/admins</url>
      </source>
      <format>xml</format>
   </get-config>
</rpc>

<rpc message-id="3" xmlns="http://ietf.org/netconf/base/1.0";>
   <get-config>
      <source>
         <url>http://example.com/usrs/users</url>
      </source>
      <format>xml</format>
   </get-config>
</rpc>

For such as design, the approach of unbounded items as below may be considered
complex.

<xsd:complexType name="edit-configType">
   <xsd:sequence>
      <xsd:element name="edit-configItem" maxOccurs="unbounded">
         <xsd:complexType>
            <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="item-id" type="xsd:string" use="required"
/>
                  <xsd:attribute name="operation" type="xsd:string"
default="merge" />
               </xsd:extension>
            </xsd:complexContent>
         </xsd:complexType>
      </xsd:element>
   </xsd:sequence>
</xsd:complexType>

Anyway whatever approach you take, it should be representable in schema's
presented in the draft.

Sandeep


Andy Bierman wrote:

> At 11:33 AM 3/29/2004, Sandeep Adwankar wrote:
> >One approach for multiple operations is to define edit-config as sequence of
> >config items as below. Again this will affect protocol schema only and not
> >data model.
>
> This is very similar to Juergen's NFS-chaining proposal.
> The problem is that all we want to support is the combination
> of different edit-actions within the same RPC transaction.
> Your approach allows every single parameter to the edit-config
> operation to be different for each "edit-configItem".  This
> is overkill and too complex to implement.
>
> Andy
>
> ><xsd:complexType name="edit-configType">
> >   <xsd:sequence>
> >      <xsd:complexType name="edit-configItem">
> >         <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="item-id" type="xsd:string" use="required"
> >/>
> >               <xsd:attribute name="operation" type="xsd:string"
> >default="merge" />
> >            </xsd:extension>
> >         </xsd:complexContent>
> >      </xsd:complexType>
> >   </xsd:sequence>
> ></xsd:complexType>
> >
> >
> >Sandeep
> >
> >Andy Bierman wrote:
> >
> >> At 09:47 AM 3/29/2004, Sandeep Adwankar wrote:
> >> >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.
> >>
> >> I understand how this would be accomplished in an XSD.
> >> My objection is that is approach is essentially the
> >> same that Juergen suggested, which is to limit the "edit"
> >> protocol operation to a single edit-action type.
> >>
> >> Andy
> >>
> >> >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/>
>
> --
> 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/>

References:
- RE: same value operation attributes restriction
  - From: "Gilbert Gagnon" <gagnong@nortelnetworks.com>
- RE: same value operation attributes restriction
  - From: Andy Bierman <abierman@cisco.com>
- Re: same value operation attributes restriction
  - From: Juergen Schoenwaelder <j.schoenwaelder@iu-bremen.de>
- Proposal to do away with netconf attributes in data model payloads
  - From: Andy Bierman <abierman@cisco.com>
- Re: Proposal to do away with netconf attributes in data model payloads
  - From: Sandeep Adwankar <sandeep.adwankar@motorola.com>
- Re: Proposal to do away with netconf attributes in data model payloads
  - From: Andy Bierman <abierman@cisco.com>
- Re: Proposal to do away with netconf attributes in data model payloads
  - From: Sandeep Adwankar <sandeep.adwankar@motorola.com>
- Re: Proposal to do away with netconf attributes in data model payloads
  - From: Andy Bierman <abierman@cisco.com>

Prev by Date: URL issues
Next by Date: Re: URL issues
Previous by thread: Re: Proposal to do away with netconf attributes in data model payloads
Next by thread: Re: Proposal to do away with netconf attributes in data model payloads
Index(es):
- Date
- Thread