https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/NETCONF-590 netconf <p>As a legacy of pre-callhome and protocol-framework world, we have no separation between network-level roles (i.e. session initiation client/server) and NETCONF-level roles (i.e. NETCONF client/server).</p> <p>This leads to quite a bit of duplication between netconf-netty-util, callhome-protocol and netconf-{tcp,ssh}, where we have separate netty dispatchers and client/server handling - even though the only difference is who is initiating the network channel – this is detailed in <a href="https://tools.ietf.org/html/rfc8071#section-2" class="external-link" target="_blank" rel="nofollow noopener">https://tools.ietf.org/html/rfc8071#section-2</a> . In the context of  Figure 1 there, our technology stack has further complication, because we rely on Apache SSH to handle SSH protocol details and we only attach to the NETCONF channel – which is subject of <a href="https://jira.opendaylight.org/browse/NETCONF-571" title="Rework SSHD integration" class="issue-link" data-issue-key="NETCONF-571">NETCONF-571</a>.</p> <p>Refactor the four components to cleanly separate the connection initiation from other session establishment concerns (authentication and NETCONF negotiation).</p> NETCONF-590

Refactor NETCONF transport layer

Improvement High Resolved Done Ruslan Kashapov Robert Varga pt Fri, 4 Jan 2019 16:50:06 +0000 Sun, 28 Jan 2024 19:03:32 +0000 Sun, 28 Jan 2024 19:03:32 +0000 7.0.0 netconf 0 2 <p><a href="https://jira.opendaylight.org/secure/ViewProfile.jspa?name=rovarga" class="user-hover" rel="rovarga">rovarga</a> is this related to the mina-sshd patches I saw coming in? <a href="https://git.opendaylight.org/gerrit/c/netconf/+/89455" class="external-link" target="_blank" rel="nofollow noopener">example </a></p> <p>Those two referenced are actually related to the email report I saw a few weeks back around ssh console being terminated during feature:install – I don't have the pointer, though. There was some follow-up work to NETCOFN-674, which is related to this, but in general, nope this issue specifically is not moving (yet).</p> <p>Okay, so we have the basic transports in, now we need to deal with switching over to it (i.e. eliminate netconf-netty-util and use these transports in netconf-client/netconf-impl)</p> Blocks NETCONF-364 NETCONF-1190 NETCONF-571 NETCONF-1191 MDSAL-829 YANGTOOLS-1514 MDSAL-768 MDSAL-824 Relates NETCONF-554 NETCONF-1030 NETCONF-1106 NETCONF-1108 NETCONF-1183 NETCONF-1237 NETCONF-1238 Development Rank 0|i03lu7: