RE: Incomplete XML Draft

["Peter Thompson" <peter.thompson@starfish.com>]

Hi Margaret,

No, it just appears to have been left out of the discussion,
and leapfrogged to later work.  :)

Cheers,
	peter

> -----Original Message-----
> From: Margaret Wasserman [mailto:mrw@windriver.com]
> Sent: Tuesday, June 25, 2002 12:53 PM
> To: Peter Thompson
> Cc: xmlconf@ops.ietf.org
> Subject: RE: Incomplete XML Draft
> 
> 
> 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/>