Subject: RE: How should we deal with experimental netconf work?

From: "McDonald, Ira" <[email-masked]>
Date: Thu, 26 Jan 2006 10:58:15 -0800

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: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]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: [email-masked] 
> [mailto:[email-masked]] 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" <[email-masked]>
> To: "Netconf (E-mail)" <[email-masked]>
> 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 [email-masked] 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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 Jan 2006 11:39:38 -0800

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

Andy

---

From: Phil Shafer <[email-masked]>
Date: Thu, 26 Jan 2006 15:00:30 -0500

>I thought I was the only one who hated namespaces. ;-)

Namespaces are a pain.  Anyone who says otherwise is selling
something.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 Jan 2006 12:11:52 -0800

>Namespaces are a pain.  Anyone who says otherwise is selling

Speaking of which, how are you handling this special case problem:

The RPC processing mandates that all the attributes in <rpc> are
returned in <rpc-reply>.  This includes all the xmlns declarations.

Inside data models, the label for a given namespace can change (over and 
over)
with yet more xmlns declarations.  

If an error occurs, and a QName needs to be returned in <error-info>,
do you reuse the labels forced in the <rpc-reply> or create a new xmlns
declaration with the label used in the QName? And if that label is
already in use for a different namespace (in the <rpc> element)? Do you
use the label from the xmlns in the original <rpc> element?

Since the URIs are the same, all SW is expected to figure out that different
labels map to the same NS, and applications should handle it no matter what.

XML is so fun...

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 26 Jan 2006 21:46:48 +0100 (CET)

> use the label from the xmlns in the original <rpc> element?

When you write 'label', do you mean the namespace prefix?  Actually I
don't see the problem, but in this case, our implementation uses new
prefixes and new xmlns declarations.

> labels map to the same NS, and applications should handle it no matter what.

Yes, but honestly I don't think namespace handling is the biggest
problem when implementing netconf... But then I am selling something :)

> returned in <rpc-reply>.  This includes all the xmlns declarations.

Is this intentional?  Why is it important to return the xmlns
declarations?  Couldn't we just state that xmlns declarations are not
returned?

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 26 Jan 2006 13:16:59 -0800

>prefixes and new xmlns declarations.

Yes I mean prefix.

>declarations?  Couldn't we just state that xmlns declarations are not

No.  We state that all attributes in the <rpc> are returned unchanged in
the <rpc-reply>.  We can add extras after that.

Andy