Subject: [netconf] subtree filter any namespace

From: Christian Hopps <[email-masked]>
Date: Mon, 10 Feb 2020 15:36:09 -0500

I've been adding subtree to xpath conversion to my netconf python client/server code (with some help from others), and in trying to get the "any" namespace stuff working I ran into an issue.

The client code was setting the default namespace to 'xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"' on the top XML rpc message element. This had an unwanted side-effect of placing everything in a sub-tree filter then into the netconf namespace (if none were given). As a work-around I created the filter element with a blank default namespace; however, I'm not sure this is correct, i.e.,

<get>
 <filter xmlns=''>
 ... users specified filter ...
 </filter>
</get>

The correct thing is probably to not set the default namespace in the client code; however, I'm not sure I can do this now for backward compatible reasons. I could do it perhaps if the user specified a filter, but I'm curious if it's valid to just set it to blank. Googling produced conflicting answers for me.

Thanks,
Chris.

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 11 Feb 2020 08:59:17 +0100 (CET)

Hi,

Christian Hopps <[email-masked]> wrote:
> I've been adding subtree to xpath conversion to my netconf python
> client/server code (with some help from others), and in trying to get
> the "any" namespace stuff working I ran into an issue.
> 
> The client code was setting the default namespace to
> 'xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"' on the top XML rpc
> message element. This had an unwanted side-effect of placing
> everything in a sub-tree filter then into the netconf namespace (if
> none were given). As a work-around I created the filter element with a
> blank default namespace; however, I'm not sure this is correct, i.e.,
> 
> <get>
>  <filter xmlns=''>

This is not correct since it says that "filter" is in the ""
namespace.

> The correct thing is probably to not set the default namespace in the
> client code; however, I'm not sure I can do this now for backward
> compatible reasons. I could do it perhaps if the user specified a
> filter, but I'm curious if it's valid to just set it to
> blank. Googling produced conflicting answers for me.

I don't know how your code works but you need to end up with somthing
like:

  <rpc xmls="urn:ietf:params:xml:ns:netconf:base:1.0">
    <get>
      <filter>
        <top-node-1 xmlns="">
          ...
        </top-node-1>
        <top-node-2 xmlns="">
          ...
        </top-node-2>
      </filter>
    </get>
  </rpc>

OR

  <nc:rpc xmls:nc="urn:ietf:params:xml:ns:netconf:base:1.0">
    <nc:get>
      <nc:filter>
        <top-node-1>
          ...
        </top-node-1>
        <top-node-2>
          ...
        </top-node-2>
      </nc:filter>
    </nc:get>
  </nc:rpc>

/martin

> 
> Thanks,
> Chris.
> _______________________________________________
> netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf
>

---

From: Christian Hopps <[email-masked]>
Date: Tue, 11 Feb 2020 06:47:18 -0500

> On Feb 11, 2020, at 2:59 AM, Martin Bjorklund <[email-masked]> wrote:
> 
> Hi,
> 

Ok so my main question was is it valid to have ``xmlns=""'', which your saying works. I missed the fact that I was not putting "filter" in the netconf namespace, but I could do that with this:

 <rpc xmls="urn:ietf:params:xml:ns:netconf:base:1.0">
   <get>
     <nc:filter xmls:nc="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns="">
       <top-node-1>
         ...
       </top-node-1>
       <top-node-2>
         ...
       </top-node-2>
     </nc:filter>
   </get>
 </rpc>

and leave the current API (where users may have assumed netconf namespace was the default) unchanged.

I'm not sure how many users may have relied on the netconf namespace being the default, and it seems odd the more I think about it; part of me wants to ditch it. :)

Thanks,
Chris.