[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Incomplete XML Draft
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.
>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
>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
>to unsubscribe send a message to email@example.com with
>the word 'unsubscribe' in a single line as the message text body.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.