[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: How should we deal with experimental netconf work?



hi

My assumption would be that this work would be done in private
namespace. What are the advantages and disadvantages of doing this in a
shared commons? 

I imagine if two vendors wanted to support the same experiment, then
shared space would be good. I imagine though, that the shared
experimental space would need to be managed as closely as real space
wouldn't it? Would we ask IANA to do that?

Sharon
-----Original Message-----
From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org] On
Behalf Of Andy Bierman
Sent: Wednesday, January 25, 2006 3:16 PM
To: Netconf (E-mail)
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/>