Operating System: All
Platform: All

RFC 6241 section 6.3 says:
The filter output (the set of selected nodes) is initially empty.

Each subtree filter can contain one or more data model fragments,
which represent portions of the data model that will be selected
(with all child nodes) in the filter output.

Each subtree data fragment is compared by the server to the internal
data models supported by the server. If the entire subtree data-
fragment filter (starting from the root to the innermost element
specified in the filter) exactly matches a corresponding portion of
the supported data model, then that node and all its children are
included in the result data.

Since the filter output is empty initially, I think you should indeed get an empty
response if the filter does not match any data.

Also if you check the ietf-netconf yang model the rpc output for get and get-config reinforces this with:
output {
anyxml data

}

Thanks Tomas for you comment. Seems I have not read rfc6241 carefully enough.

Still my question would be, how ODL should deal with such networking equipment. So there is a potential to relax the current behavior to interwork.

The other option would be to implement a reasonable fault handling. Saying this, in the current implementation basically ODL is not mapping back the message-id of the <rpc-error> to the original request, so it waits for the response according the rpc timeout (2min by default) and after this it raises a NullPointer Exception. This should never be happen - and it is somewhat frustrating to the operator as there is no indication given about the actual root-cause.

The problem I have in principle with returning an empty <data/> node is, that there might be various reasons for this. For example it might be, that the actual subtree is not supported by the device or the netconf user has no access-read permission for that subtree. In scenarios like this I would still prefer to have an appropriate error message aka <rpc-error> to be generated by the device - and ODL should be able to deal with this. So it might be good idea to have a discuss this in IETF - and about proper ways to check if objects already exist.

(In reply to Sven Wisotzky from comment #2)

> The other option would be to implement a reasonable fault handling. Saying
> this, in the current implementation basically ODL is not mapping back the
> message-id of the <rpc-error> to the original request, so it waits for the
> response according the rpc timeout (2min by default) and after this it
> raises a NullPointer Exception. This should never be happen - and it is
> somewhat frustrating to the operator as there is no indication given about
> the actual root-cause.

This is indeed a bug and should be handled.

> The problem I have in principle with returning an empty <data/> node is,
> that there might be various reasons for this. For example it might be, that
> the actual subtree is not supported by the device or the netconf user has no
> access-read permission for that subtree. In scenarios like this I would
> still prefer to have an appropriate error message aka <rpc-error> to be
> generated by the device - and ODL should be able to deal with this. So it
> might be good idea to have a discuss this in IETF - and about proper ways to
> check if objects already exist.

This discussion is more appropriate for the ietf mailing list since the netconf projects aim is to provide a server/client implementation that conforms to the rfc. We cannot realistically add any quirk for a specific device that deviates from the rfc, if we did that we would essentially have to keep our own rfc for netconf with all the stuff that's changed from the original.

If you actually start the discussion on the ietf mailing list can you add the link to the thread here?

Can you provide a stacktrace, or some logs, for the NPE?

Discussion from ietf mailing list is here:
https://mailarchive.ietf.org/arch/search/?email_list=netconf&gbt=1&index=67SPjHZfd75jvmTiQyFrVAnGxX4

From that discussion, it turns out that empty response is the correct one.

For that NPE problem can you please provide us logs or stack trace, so we can investigate that issue further?

I think the empty <data> to an unsatisfied filter discussion was exhausted, to look into the NPE please open another bug and attach logs with the stacktrace.