[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Proposal to do away with netconf attributes in data model payloads
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/>