<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:14:41 UTC 2024

It is possible to restrict the fields that are returned in this document by specifying the 'field' parameter in your request.
For example, to request only the issue key and summary append 'field=key&field=summary' to the URL of your request.
-->
<rss version="0.92" >
<channel>
    <title>OpenDaylight JIRA</title>
    <link>https://jira.opendaylight.org</link>
    <description>This file is an XML representation of an issue</description>
    <language>en-us</language>    <build-info>
        <version>8.20.10</version>
        <build-number>820010</build-number>
        <build-date>22-06-2022</build-date>
    </build-info>


<item>
            <title>[NETCONF-311] BrokerFacade.checkItemDoesNotExists check does fail with some vendors</title>
                <link>https://jira.opendaylight.org/browse/NETCONF-311</link>
                <project id="10142" key="NETCONF">netconf</project>
                    <description>&lt;p&gt;Before doing any NETCONF change seems like the current implementation of &quot;BrokerFacade.checkItemDoesNotExists()&quot; is always called to verify, if the corresponding object does or does not exist.&lt;/p&gt;

&lt;p&gt;Seems like in the current implementation, OpenDaylight expect the router to return an empty &amp;lt;data/&amp;gt; element. For example:&lt;/p&gt;

&lt;p&gt;&amp;lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?&amp;gt;&lt;br/&gt;
&amp;lt;rpc-reply message-id=&quot;m-83&quot;  xmlns=&quot;urn:ietf:params:xml:ns:netconf:base:1.0&quot;&amp;gt;&lt;br/&gt;
  &amp;lt;data/&amp;gt;&lt;br/&gt;
&amp;lt;/rpc-reply&amp;gt;&lt;/p&gt;

&lt;p&gt;Some vendors do not return this empty &amp;lt;data/&amp;gt; node, but will return with &amp;lt;rpc-error/&amp;gt;.&lt;/p&gt;

&lt;p&gt;According to the IETF RFC 6241 it is NOT defined, what should be returned when xpath/subtree filtering does no find any matching element. Therefore we must assume, that all of these approaches are okay: sending empty &amp;lt;data/&amp;gt; node or returning &amp;lt;rpc-error&amp;gt;.&lt;/p&gt;

&lt;p&gt;The current implementation is quite bad, as in ODL Boron this is causing a timeout because OpenDaylight is not evaluating the &amp;lt;rpc-error&amp;gt; properly and matching it back to the original request (using message-id). So it basically waits for the configured rpc timeout. After this, the method runs into a NullPointerException.&lt;/p&gt;


&lt;p&gt;Beside of fixing the behavior in ODL, it might be considered to approach IETF with this limitation, and to ask that the next updated version of RFC6241 is more specific on how to check if or not an object exists. Surely the more preferred variant would be, to have a new dedicated rpc like &quot;check_config_exists&quot; for this.&lt;/p&gt;</description>
                <environment>&lt;p&gt;Operating System: All&lt;br/&gt;
Platform: All&lt;/p&gt;</environment>
        <key id="21324">NETCONF-311</key>
            <summary>BrokerFacade.checkItemDoesNotExists check does fail with some vendors</summary>
                <type id="10104" iconUrl="https://jira.opendaylight.org/secure/viewavatar?size=xsmall&amp;avatarId=10303&amp;avatarType=issuetype">Bug</type>
                                                <status id="5" iconUrl="https://jira.opendaylight.org/images/icons/statuses/resolved.png" description="A resolution has been taken, and it is awaiting verification by reporter. From here issues are either reopened, or are closed.">Resolved</status>
                    <statusCategory id="3" key="done" colorName="green"/>
                                    <resolution id="10003">Cannot Reproduce</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="sven.wisotzky@nokia.com">Sven Wisotzky</reporter>
                        <labels>
                    </labels>
                <created>Mon, 31 Oct 2016 13:46:57 +0000</created>
                <updated>Fri, 15 Mar 2019 22:22:32 +0000</updated>
                            <resolved>Fri, 13 Oct 2017 10:50:54 +0000</resolved>
                                                                    <component>netconf</component>
                        <due></due>
                            <votes>0</votes>
                                    <watches>3</watches>
                                                                                                                <comments>
                            <comment id="39690" author="tcere" created="Thu, 3 Nov 2016 09:44:50 +0000"  >&lt;p&gt;RFC 6241 section 6.3 says:&lt;br/&gt;
   The filter output (the set of selected nodes) is initially empty.&lt;/p&gt;

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

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

&lt;p&gt;Since the filter output is empty initially, I think you should indeed get an empty&lt;br/&gt;
response if the filter does not match any data.&lt;/p&gt;

&lt;p&gt;Also if you check the ietf-netconf yang model the rpc output for get and get-config reinforces this with:&lt;br/&gt;
output {&lt;br/&gt;
      anyxml data &lt;/p&gt;
{
        description
          &quot;Copy of the source datastore subset that matched
           the filter criteria (if any).  An empty data container
           indicates that the request did not produce any results.&quot;;
      }
&lt;p&gt;    }&lt;/p&gt;</comment>
                            <comment id="39691" author="sven.wisotzky@nokia.com" created="Thu, 3 Nov 2016 11:12:18 +0000"  >&lt;p&gt;Thanks Tomas for you comment. Seems I have not read rfc6241 carefully enough.&lt;/p&gt;

&lt;p&gt;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.&lt;/p&gt;

&lt;p&gt;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 &amp;lt;rpc-error&amp;gt; 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.&lt;/p&gt;

&lt;p&gt;The problem I have in principle with returning an empty &amp;lt;data/&amp;gt; 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 &amp;lt;rpc-error&amp;gt; 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.&lt;/p&gt;</comment>
                            <comment id="39692" author="tcere" created="Thu, 3 Nov 2016 15:54:43 +0000"  >&lt;p&gt;(In reply to Sven Wisotzky from comment #2)&lt;/p&gt;

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

&lt;p&gt;This is indeed a bug and should be handled.&lt;/p&gt;

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

&lt;p&gt;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&apos;s changed from the original.&lt;/p&gt;</comment>
                            <comment id="39693" author="tcere" created="Fri, 4 Nov 2016 17:43:35 +0000"  >&lt;p&gt;If you actually start the discussion on the ietf mailing list can you add the link to the thread here?&lt;/p&gt;</comment>
                            <comment id="39694" author="adetalhouet" created="Thu, 17 Nov 2016 22:24:37 +0000"  >&lt;p&gt;Can you provide a stacktrace, or some logs, for the NPE?&lt;/p&gt;</comment>
                            <comment id="39695" author="jmorvay@cisco.com" created="Tue, 13 Dec 2016 09:20:30 +0000"  >&lt;p&gt;Discussion from ietf mailing list is here: &lt;br/&gt;
&lt;a href=&quot;https://mailarchive.ietf.org/arch/search/?email_list=netconf&amp;amp;gbt=1&amp;amp;index=67SPjHZfd75jvmTiQyFrVAnGxX4&quot; class=&quot;external-link&quot; target=&quot;_blank&quot; rel=&quot;nofollow noopener&quot;&gt;https://mailarchive.ietf.org/arch/search/?email_list=netconf&amp;amp;gbt=1&amp;amp;index=67SPjHZfd75jvmTiQyFrVAnGxX4&lt;/a&gt;&lt;/p&gt;

&lt;p&gt;From that discussion, it turns out that empty response is the correct one.&lt;/p&gt;

&lt;p&gt;For that NPE problem can you please provide us logs or stack trace, so we can investigate that issue further?&lt;/p&gt;</comment>
                            <comment id="39696" author="tcere" created="Fri, 13 Oct 2017 10:50:54 +0000"  >&lt;p&gt;I think the empty &amp;lt;data&amp;gt; to an unsatisfied filter discussion was exhausted, to look into the NPE please open another bug and attach logs with the stacktrace.&lt;/p&gt;</comment>
                    </comments>
                    <attachments>
                    </attachments>
                <subtasks>
                    </subtasks>
                <customfields>
                                                                            <customfield id="customfield_11400" key="com.atlassian.jira.plugins.jira-development-integration-plugin:devsummary">
                        <customfieldname>Development</customfieldname>
                        <customfieldvalues>
                            
                        </customfieldvalues>
                    </customfield>
                                                                                                                        <customfield id="customfield_10208" key="com.atlassian.jira.plugin.system.customfieldtypes:textfield">
                        <customfieldname>External issue ID</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>7067</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10201" key="com.atlassian.jira.plugin.system.customfieldtypes:url">
                        <customfieldname>External issue URL</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue><![CDATA[https://bugs.opendaylight.org/show_bug.cgi?id=7067]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                    <customfield id="customfield_10202" key="com.atlassian.jira.plugin.system.customfieldtypes:select">
                        <customfieldname>Priority</customfieldname>
                        <customfieldvalues>
                                <customfieldvalue key="10301"><![CDATA[Normal]]></customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                <customfield id="customfield_10000" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i01xrb:</customfieldvalue>

                        </customfieldvalues>
                    </customfield>
                                                                                                                                                                                </customfields>
    </item>
</channel>
</rss>