[j-nsp] Netconf & namespaces

[Keegan Holley]

On Jun 17, 2014, at 10:01 AM, Phil Mayers <p.mayers at imperial.ac.uk> wrote:

> On 17/06/14 14:49, Keegan Holley wrote:
>>> 
>>> I've looked at the PyEZ and ncclient code, and basically they seem
>>> to take the approach of just throwing away all namespace
>>> information. This seems icky to me, and make me wonder if Netconf
>>> is going to be another SOAP - so many implementation errors that
>>> "interop" ends up being a mess of special casing and workarounds.
>> 
>> 
>> Do you really need the namespaces?  If different vendors use the same
>> tags for different things you’ll still have to write code to deal
>> with it whether you have a namespace to warn you or not.  Maybe I’m
>> missing something.
> 
> It's not really a matter of "need". They're mandatory per the Netconf spec. It's not some optional thing you can dispense with if you don't like it, or because your COBOL libraries don't do them properly or some other reason.
> 
> If vendors are generating XML without required namespace declarations, you can't validate the returned XML against the schema for the protocol, or for example against their published Yang data model.
> 
> If you can't do that, you can't be sure it's well-formed semantically. You end up embedding all kinds of "turn your head and squint" workarounds, and we're back to being only slightly better off than parsing Cisco IOS configs by looking at the indent and using regexps…

That’s my point.  Even if there are conflicts between namespaces you’ll end up having to implement workarounds.  Either you find them in the namespace (which no one reads.. Go for it http://tools.ietf.org/html/rfc6241) or you’ll find them when you’re debugging your code.  
> 
> (I exaggerate here...)
> 
> Obviously disposing of the namespace info is possible. But it might surprise you how complicated that makes certain things.
> 
> For example, one thing I've found myself doing is pulling the config as XML from JunOS, annotating and mutating the document locally according to template and database info, then sending it back in the other direction. If I've thrown away namespaced tags and attributes, I might have received this:
> 
> <junos:comment>Link to provider</junos:comment>
> <interface>
>  <name>ge-0/0/0</name>
>  ...
> </interface>
> 
> ...but I send back:
> 

> <comment>Link to provider</junos:comment>
> <interface>
>  <name>ge-0/0/0</name>
>  ...
> </interface>
> 
> ...which is invalid.

 The comments are a big caveat and are handled poorly. Most of the JunOS XML I’ve parsed I’ve used standard libraries and I haven’t run into any problems yet, but I normally don’t deal with comments either.  That being said either way you’re going to have to write code to replace the ns's until juniper fixes their kit.  Everything else is just a rant.  I’m with you in spirit, but I usually do my ranting on Nanog.