Re: How should we deal with experimental netconf work?

[Andy Bierman <ietf@andybierman.com>]

Tom Petch wrote:

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

To this day I still don't understand why manager station SW had such
a huge problem getting this right.  And don't get me started on
module-scoped imports.  So many mgmt apps completely ignored
this, so FOO-MIB::blah and BAR-MIB::blah in the same module never worked
like it's supposed to.

I guess this is relevant to netconf because the same human nature
will bite us in similar ways.  In netconf, it is more than data that
can be extended.  Namespace processing is mandatory in netconf,
and the difference between "base" and "experimental" is just
one xmlns declaration.  Literally just 8 characters different on the wire.
(Let's see SNMP try that ;-)

It is quite likely that the version that eventually gets standardized
will not be exactly the same as the experimental version anyway,
so this may not turn out to be a practical concern.

Andy


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