there are issues:

• osgi package artifacts cannot be extracted from netconf-impl module because these artifacts are not isolated
  and having same module dependencies; maven artifacts cannot have cross-dependencies
• osgi package is not the only containing server related artifacts - majority of module top level
  artifacts are named like NetconfServer* and listed as osgi services in the blueprint

due there is almost everything to extract, suggested

• renaming modules netconf-impl -> netconf-server,  mdsal-netconf-impl -> mdsal-netconf-server
• packages renaming impl -> server, osgi -> services (or move artifacts to upper level)

Okay, fair enough. Let's punt this for 6.0.x, as renaming things will break users.

So going through the motions of migration, there is a metric ton of clean ups here. The problem is that client-side and server-side APIs are not separated and tucked in netconf-api (which hosts NetconfMessage), netconf-notifications-api and netconf-mapping-api (which both are server-side things).

We really want to separate the generic, client-side and server-sides, as otherwise we won't be able to make out what is required where. This essentially means that all the server-side APIs need to be rehosted to org.opendaylight.netconf.server.api sub-packages, to make the dependencies obvious.

There is additional wrinkle I came across, which is that we do not have proper NetconfMessage specializations for anything except <hello/> and <notification/>. This muddles which layer netconf-api is really is about:

• NetconfSession is quite obviously Transport layer
• NetconfMessage is obviously (with HelloMessage and NotificationMessage) at Messages layer

But then we lack RpcMessage and RpcReplyMessage – and this ends up being checked all over the place. One notable problem netconf.utll.messages.SubtreeFilter, which operates on plain documents, but performs checks for <get> and <get-config> operations – which indicates it operates on Operations layer, without every employing the underlying safety of the Messages layer.

As a further wrinkle we have netconf.api.monitoriing, which is obviously tied to a specific YANG module, which in turn is a Content layer thing – and there for that we have the netconf-mapping-api, which deals with RPC mapping and netconf-notifications-api, which deals with Notification mapping – both of which are server-side things.

Since the client-side of things only cares about Transport and Messages layer, netconf-api needs to only capture those layers – for now that is. The transport part of things is already being split into transport-api, hence once the dust settles, netconf-api is only about Messages layer and higher-layer concerns a purely a netconf-server thing.