RE: Incomplete XML Draft

[Margaret Wasserman <mrw@windriver.com>]

At 01:16 PM 6/25/02 , Peter Thompson wrote:
>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.

There is already a "phase 0" in the draft that is supposed to
include this type of evaluation.  Suggestions about re-wording
are welcome, if it is unclear.

Margaret


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


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