RE: How should we deal with experimental netconf work?

["McDonald, Ira" <imcdonald@sharplabs.com>]

Hi,

Yes, the same problem - the different base OID or XML namespace
makes them mutually unintelligible to standard applications.

XML namespaces (which are sloppily managed, in my experience)
are actually _worse_ than OID-based MIBs for interoperability.

And so we advance into the shining web-based sunset...

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald@sharplabs.com

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Sharon Chisholm
> Sent: Thursday, January 26, 2006 1:47 PM
> To: Netconf (E-mail)
> Subject: RE: How should we deal with experimental netconf work?
> 
> 
> hi
> 
> I think you would just have to switch the namespace when it moved. I
> think that makes it a bit cleaner than with SNMP, but still 
> potentially
> a problem.
> 
> Sharon
> 
> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On
> Behalf Of Tom Petch
> Sent: Thursday, January 26, 2006 12:24 PM
> To: Andy Bierman; Netconf (E-mail)
> Subject: Re: How should we deal with experimental netconf work?
> 
> 
> The trick that SNMP failed to solve was how to amend all the 
> OIDs in the
> debugged working code from .1.3.6.1.3 to .1.3.6.1.2.1 without
> introducing any errors.  I see this as the reason for the 
> lack of use of
> SNMP experimental.
> 
> So the question is, can this problem be avoided in XML?
> 
> Tom Petch
> 
> ----- Original Message -----
> From: "Andy Bierman" <ietf@andybierman.com>
> To: "Netconf (E-mail)" <netconf@ops.ietf.org>
> Sent: Wednesday, January 25, 2006 9:15 PM
> Subject: How should we deal with experimental netconf work?
> 
> 
> > Hi,
> >
> > I have an idea that may help those in the WG that believe standards 
> > based on real-world solutions are not that important. I 
> have to clear 
> > it with Simon and the ADs first, but here goes...
> >
> > People with ideas for extensions should (hopefully) implement them, 
> > write them up in an Internet Draft, and propose them to the WG.
> >
> > We have a "netconf base" URI.
> > We can also have a "netconf experimental" URI.
> > (Yes, I know SMI has this already.  We need it for the same reason.)
> >
> > The WG can then decide on new proposals:
> >   1)  no thanks
> >   2) come back later with more details
> >   3) develop it as Experimental first (decide on standard later)
> >   4) charter it and develop it as a Proposed Standard
> >
> > This experimental branch (like in MIBs) would not be stable like a 
> > standard, but it is better than a vendor extension. 
> Competitors in the
> 
> > same market will be reluctant to implement each other's proprietary 
> > extensions, but they will be able to agree in a WG to implement 
> > something as a "netconf experimental" extension.
> >
> > The bar for Experimental should be much lower than for Proposed 
> > Standard, in terms of initial proposal deployment, WG 
> involvement and 
> > IESG review.
> >
> > Comments?
> >
> > Andy
> >
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with the
> word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>
> 

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>