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.
(ENG-19428)
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".
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.
Hi,
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>.