Re: [netconf] subtree filter any namespace

Christian Hopps <chopps@chopps.org> Tue, 11 February 2020 11:47 UTC

Return-Path: <chopps@chopps.org>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA271200EC for <netconf@ietfa.amsl.com>; Tue, 11 Feb 2020 03:47:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqGmkMm_3_Ay for <netconf@ietfa.amsl.com>; Tue, 11 Feb 2020 03:47:20 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4B7A31200DF for <netconf@ietf.org>; Tue, 11 Feb 2020 03:47:20 -0800 (PST)
Received: from [192.168.1.206] (66-227-211-29.dhcp.trcy.mi.charter.com [66.227.211.29]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id B393160CE3; Tue, 11 Feb 2020 11:47:19 +0000 (UTC)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
From: Christian Hopps <chopps@chopps.org>
In-Reply-To: <20200211.085917.2142620937359879949.mbj@tail-f.com>
Date: Tue, 11 Feb 2020 06:47:18 -0500
Cc: Christian Hopps <chopps@chopps.org>, netconf@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <FDCB4E0B-E316-4A2E-918F-9D35B698EF08@chopps.org>
References: <6131477C-9EE3-499E-966A-A9ADB6FF8CD9@chopps.org> <20200211.085917.2142620937359879949.mbj@tail-f.com>
To: Martin Bjorklund <mbj@tail-f.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/jAG54I2huaW6xcwMeMcQ4UoFxo0>
Subject: Re: [netconf] subtree filter any namespace
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Feb 2020 11:47:22 -0000


> On Feb 11, 2020, at 2:59 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> 
> Hi,
> 
> Christian Hopps <chopps@chopps.org> 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=''>
>> ... users specified filter ...
>> </filter>
>> </get>
> 
> 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>

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.

> 
> 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
>> netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf