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