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