Unable to perform get without using subtree filter using confd7.3

The get works with following example

<rpc message-id="101” xmlns=”urn:ietf:param
<filter type="subtree"
<top xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces";

But the same get does not work if the filter type as subtree is not mentioned.

<rpc message-id="1" xmlns="urn:ietf:params:xml:ns:netconf:base:
<filter xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces"

Please let know if there is a change in the confd7.3 wrt confd6.3

There is no filter node in the “urn:ietf:params:xml:ns:yang:ietf-interfaces” namespace, it is in the “urn:ietf:params:xml:ns:netconf:base:1.0” namespace, i.e. same as <get> - thus you are requesting something that doesn’t exist, and receiving an empty reply is the expected result.

The significant difference from your working case isn’t the addition of the type="subtree" attribute, but the moving of the xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" attribute from <filter> to <top> - although there also isn’t any top node in the standard ietf-interfaces.yang module, so it’s unclear how that can work if you’re using that module. For the standard module, that xmlns atttribute should be given for <interfaces>.

The relevant CHANGES note is (from ConfD-7.1, the “Non-backwards compatible corrections” section):

  - confd: XML validation did not strictly apply the namespace declarations.
    E.g. the NETCONF server would treat <filter> as a parameter to
    <get-config> and <config> as a parameter to <edit-config> even if the
    "xmlns" attribute for the <filter> and <config> nodes specified a
    different namespace. This has been fixed.


By the way, omitting the type="subtree" attribute doesn’t mean that there is no subtree filtering, since subtree filtering is the default when <filter> is given - see https://tools.ietf.org/html/rfc6241#section-7.7 . I.e. the result is the same with or without type="subtree".

I get the following error even after checking different ways

<?xml version="1.0" encoding="UTF-8"?>

<rpc-reply xmlns=“urn:ietf:params:xml:ns:netconf:base:1.0” message-id=“1”


Is there some constraint to use filter on top node.

Fololwing xml is used

<?xml version="1.0" encoding="UTF-8"? <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" <capabilities urn:ietf:params:netconf:base:1.0</capability </capabilities ]] <?xml version="1.0" encoding="UTF-8"? <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="1" <get <filter xmlns="http://hello.com/ns/xxx/MS" <MS <tableInfo/ </MS </filter </get </rpc ]] <?xml version="1.0" encoding="UTF-8"? <rpc xmlns="urn:ietf:params:xml:ns:netconf:base:1.0" message-id="2" <close-session/ </rpc

Please use the “preformatted text” formatting option for your XML, it is completely unreadable here, and only barely in the e-mail sent by the forum (if I tell my mail program to show it as “plain text”). From the latter, I can see that you use

<filter xmlns="http://hello.com/ns/xxx/MS">

Do you have a toplevel node called filter in your data model?. Did you even read what I wrote previously? If you don’t have a toplevel node called filter, but rather intend the <filter> that is a parameter to <get>, you should move the xmlns="http://hello.com/ns/xxx/MS" from <filter> to <MS>, which apparently is a toplevel node in your data model.

Thanks a lot for your response.
Sorry for the text display !!! Would surely use pre-formatted text suggested by you.
And yes I had read whatever you had mentioned previously.

Moving the xmlns = … from the filter to MS surely works.
This I had tried even before posting to the forum.

My only concern is when the same filter xmlns = … was working in confd6.3.
It does not work for confd7.3 except when I move the xmlns = … to MS.

So wanted to know if there is a way wherein I can make filter xmlns=… work like before or this shall be a constraint for the confd7.3.


This was due to the bug described in the CHANGES note I quoted - the NETCONF server effectively took the <filter> tag as the parameter to <get>, even though a different namespace was specified (ignored by the NETCONF server).

It’s not a “constraint”, just that ConfD-7.1 and later requires that your request has valid XML, while earlier versions accepted/ignored an invalid namespace. There is no way to make current ConfD ignore the namespace specified for a node, like the old versions did - in your case it was “benign”, but in other cases it could make it impossible to reference a specific node.

If you for some reason want to give an xmlns attribute on the <filter> parameter to <get>, it must be “urn:ietf:params:xml:ns:netconf:base:1.0” - but that is redundant, since this is the default namespace due to the xmlns attribute on <rpc>.