[j-nsp] Netconf & namespaces

[Phil Mayers]

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

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