[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Incomplete XML Draft
Hi Folks,
Perhaps you should add a step 0: close evaluation of
existing standards for possible re-use/adoption. You could
do step 0 in conjunction with step 2, and move forward with
parallel efforts.
Cheers,
Peter Thompson
> -----Original Message-----
> From: owner-xmlconf@ops.ietf.org [mailto:owner-xmlconf@ops.ietf.org]On
> Behalf Of Ted Goddard
> Sent: Tuesday, June 25, 2002 9:31 AM
> To: Margaret Wasserman
> Cc: Andy Bierman; xmlconf@ops.ietf.org
> Subject: Re: Incomplete XML Draft
>
>
> 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:
>
> 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/>