<!-- 
RSS generated by JIRA (8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d) at Wed Feb 07 20:15:25 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-597] Improve robustness of Netconf over TLS setup procedure, Fluorine SR1</title>
                <link>https://jira.opendaylight.org/browse/NETCONF-597</link>
                <project id="10142" key="NETCONF">netconf</project>
                    <description>&lt;p&gt;While a normal, succesful setup of a southbound Netconf over TLS connection works fine, there seems to be robustness issues in ODL at unsuccessful connection attempts.&lt;/p&gt;

&lt;p&gt;ODL is observed to go into an infinite loop of connection re-attempts when certain error conditions are met in the setup sequence. In these cases, it doesn&apos;t matter what the &amp;lt;max-connection-attempts&amp;gt; parameter is set to. It doesn&apos;t even help to delete the Netconf device from the topology data store. The device has to be deleted from the data store and then ODL restarted in order for ODL to stop attempting to connect.&lt;/p&gt;

&lt;p&gt;A specific case when this happens is for example when keys and/or certificates haven&apos;t been properly configured in ODL. If ODL can&apos;t find a private key, it will throw an exception and immediatly try to find a key again. During these attempts, ODL will also send the initial TCP packets towards the device.&lt;/p&gt;

&lt;p&gt;The same behavior has been observed at some other error conditions.&lt;/p&gt;

&lt;p&gt;Some improvements to the robustness of ODL in cases like these should probably be considered.&lt;/p&gt;

&lt;p&gt;&#160;&lt;/p&gt;</description>
                <environment></environment>
        <key id="31308">NETCONF-597</key>
            <summary>Improve robustness of Netconf over TLS setup procedure, Fluorine SR1</summary>
                <type id="10100" iconUrl="https://jira.opendaylight.org/secure/viewavatar?size=xsmall&amp;avatarId=10310&amp;avatarType=issuetype">Improvement</type>
                                            <priority id="3" iconUrl="https://jira.opendaylight.org/images/icons/priorities/major.svg">Medium</priority>
                        <status id="10003" iconUrl="https://jira.opendaylight.org/images/icons/status_generic.gif" description="">Confirmed</status>
                    <statusCategory id="2" key="new" colorName="blue-gray"/>
                                    <resolution id="-1">Unresolved</resolution>
                                        <assignee username="-1">Unassigned</assignee>
                                    <reporter username="Martin_S">Martin Sandberg</reporter>
                        <labels>
                    </labels>
                <created>Mon, 14 Jan 2019 12:06:30 +0000</created>
                <updated>Tue, 13 Aug 2019 07:38:38 +0000</updated>
                                                                            <component>netconf</component>
                        <due></due>
                            <votes>0</votes>
                                    <watches>1</watches>
                                                                                                                        <attachments>
                            <attachment id="15095" name="karaf.log.txt" size="40060" author="Martin_S" created="Fri, 18 Jan 2019 09:48:45 +0000"/>
                    </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_10000" key="com.pyxis.greenhopper.jira:gh-lexo-rank">
                        <customfieldname>Rank</customfieldname>
                        <customfieldvalues>
                            <customfieldvalue>0|i03m33:</customfieldvalue>

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