Re: How should we deal with experimental netconf work?

["Tom Petch" <nwnetworks@dial.pipex.com>]

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