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

Re: How should we deal with experimental netconf work?

McDonald, Ira wrote:


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


I thought I was the only one who hated namespaces. ;-)
I'm experimenting with something I hope is significantly
more human-friendly.  The myth is that machines will
properly handle all the cryptic goo and humans will
never have to look at it or understand it. 
Cheers,
- Ira


Andy


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





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