RE: I-D draft-weijing-netconf-interface-01.txt

["Chen, Weijing" <Weijing_Chen@labs.sbc.com>]

> 
> Given that I've got code that generates text from the internal database
> and
> that the application wants text, why would I want to go thru the process
> of
> making sham xml that the application will have to decode and reconstruct?
> Text configuration is very useful and I don't see the need for it
> disappearing
> overnight.
>
The difference is about where the optional configuration information
resides.  See the following examples:
In WG I-D, we use:
        <get-config>
           <source>
             <running/>
           </source>
           <config xmlns="http://example.com/schema/1.2/config";>
             <users/>
           </config>
           <format>text</format>
         </get-config>
to get "text" version of configuration data.  Now what if the device does
not support the text, only XML, what is the response?  In our approach,
whether device support "text" version of configuration data is totally
depended on the schema it supports.  If the device data model schema contain
"text" element, then it supports "text", otherwise no.  It is loud and clear
to managing system by looking at the data model schema.  See the example we
propose:
        <get-config>
           <config xmlns="http://example.com/schema/1.2/config";>
             <running>
               <text>
                 <users/>
               </text>
             </running>
           </config>
         </get-config>

Now if the schema "http://example.com/schema/1.2/config"; support the "text"
version, it will give you the "text".  If not, the XML validator will reject
the request right way.

It again boils down to where the configuration information should reside:
protocol or data model?



--

Weijing Chen


> -----Original Message-----
> From: Phil Shafer [mailto:phil@juniper.net]
> Sent: Wednesday, September 03, 2003 4:30 PM
> To: Chen, Weijing
> Cc: netconf@ops.ietf.org
> Subject: Re: I-D draft-weijing-netconf-interface-01.txt
> 
> "Chen, Weijing" writes:
> >> The format element allows the application to retrieve the
> >> configuration in the device's native text-based format. This allows
> >> for archival, text-based diffing, human viewing and other applications
> >> for which xml is not suitable.
> >In the XML world, every XML content should have corresponding XML schema
> or
> >DTD, even for plain text.  One can use the following to describe the
> plain
> >text content:
> ><element name="text" type="string"/>.
> 
> Given that I've got code that generates text from the internal database
> and
> that the application wants text, why would I want to go thru the process
> of
> making sham xml that the application will have to decode and reconstruct?
> Text configuration is very useful and I don't see the need for it
> disappearing
> overnight.
> 
> >For device not
> >matching the model, it either cannot re-use the protocol operation or
> >results complex and ugly hacking.
> 
> Capabilities give a simple mechanism for extending the protocol to
> match future (and existing) models.
> 
> Thanks,
>  Phil

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