Re: Incomplete XML Draft

[Andy Bierman <abierman@cisco.com>]

At 09:30 AM 6/25/2002, Ted Goddard wrote:
>On Tuesday, June 25, 2002, at 09:08 AM, Margaret Wasserman wrote:
>
>>Do you have other ideas?  Perhaps starting with the XML <--> MIB
>>translation work?  What would be the steps in that plan that eventually
>>lead to a protocol?
>
>Here's a possible interpretation of the phased approach:

looks good -- I would even include XML encoding of proprietary CLI
configuration so complete coverage would be achievable.
Standard and proprietary MIBs do not provide the functionality
now available with CLI, and I think it would be a mistake to
limit a configuration mechanism to MIB based data. Hopefully,
over time, standard data definitions will replace proprietary ones,
but that is (almost) a separate problem.  I don't know what the
format of standard NM data will be in the future (e.g., XML schema or MIBs)
but for now, almost all of it is defined in MIBs.

Andy



>1. SOAP/WSDL definitions supporting SNMP semantics
>   (perhaps leaning more towards GetBulkRequest than GetNextRequest)
>2. XML encoding of MIB modeled data to be used in 1. and other
>   protocols.
>3. Extend the "SOAP API" from 1. to support desired semantics and
>   a richer (than 2.) XML encoding; define this encoding.
>4. Proceed with modeling work (XML schema definition?) that
>   takes advantage of 3.
>
>(1. and 2. are actually needed at the same time, but maybe 1.
>is easier to agree on quickly?)
>
>I agree this is the risk:
>
>>[Chen, Weijing] We wouldn't be interested, and may even oppose such
>>approach. We already got N^2 interfaces problem, and don't need just another
>>"standard" interface for the same old task.
>
>Have we gained anything by step 2 above?  A little bit: it should be
>easier to implement a reliably manageable device, and it should be
>possible for step 3 to be made up of many small "extension" steps
>that add capability (for instance, if the device supports transactions,
>and it sees one in the SOAP header, it should obey).
>
>Is it even possible for us to avoid creating yet another interface to the
>same old model as the first step?  Isn't it necessary because
>that's the smoothest way to get people to adopt the new standard?
>(It's also the easiest way to be initially productive on the
>new standard.)
>
>Regards,
>Ted.
>
>
>--
>to unsubscribe send a message to xmlconf-request@ops.ietf.org with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://ops.ietf.org/lists/xmlconf/>


--
to unsubscribe send a message to xmlconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/xmlconf/>