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