Hi,

I am working on implementation/porting of web-sockets to RESTCONF RFC-8040 (NETCONF-623). Currently, I have a working prototype in https://git.opendaylight.org/gerrit/c/81424/ (I have to test some stuff regarding enabled TLS in RESTCONF too). While I was working on it, I have observed several issues, most of them are relevant in old RESTCONF implementation too (I don't know if we want to support web-sockets in old impl. too, we must just decide). I have also created some sequence diagrams that describe the current state in RFC-8040 implementation (with my minor modifications) and that would make our discussion easier (I hope in it).

The observed issues can be separated to three areas based on work-flow towards registration of web-socket session:

1. Creation of the stream - Creation of the stream means, that the stream definition is registered at broker with all configuration - output type, path, ... There are two cases:

• A) YANG notification streams - User has to call GET on all streams to create all streams for all YANG notifications in schema context. This procedure also automatically stores monitoring information in data-store with already filled-in access information with corresponding ws locations. I see there two issues:
  • a. Creation of YANG notification streams should be automated based on schema context updates.
  • b. Monitoring information should be filled-in only by stream definition without location information, because these targets cannot be used until user subscribes to stream (only subscription to stream creates corresponding listener)
• B) Data-change event streams - It must be created by user explicitly. Currently, creation of such stream doesn't store any information in ietf-restconf-monitoring. There is one issue:
  • c. If we look at YANG notification streams, it stores some information in data-store, but creation of data-change event stream doesn't store any information in data-store; why? So there two possible ways how to resolve it:
    a) Do not store any information in ietf-restconf-monitoring on creation of the stream - I think it is not correct, because user doesn't have a way to know which streams are available.
    b) Store only basic information about the stream in data-store; especially without any locations that are unusable at this phase - but it would also require modification of YANG schema, because "location" is a mandatory leaf in schema.

2. Creation of subscription - It is similar for both YANG notify and data-change event streams - listener for data-change event or YANG notification is created and whole monitoring information is saved in data-store. Creation of the subscription is good only for replay support. Next issues:

• d. We already stored some data for YANG notification streams in step 1; now we are doing the same procedure here. It is clearly connected with issues a., b. and c. But after this step, the stream is usable by application, so the upgrade request can be sent to returned ws location. From this reason I see reasonable to put only information about stream location to the data-store (stream definition should be saved in 1. as it is explained in bug c.)
• e. For YANG notification streams, there are two ways how to subscribe to the stream - GET on streams/stream=STREAM_NAME/access=ACCESS/location=LOCATION (I think this is also specified in RFC 8040) or the old way inherited from old impl. of RESTCONF - through separated RPC. We should clear it and choose one way.
• f. If the leader of the cluster changes, the new leader should re-create subscriptions based on data-store information. To be able to do such fix, again, we have to differentiate between just-created streams on which the subscription hasn’t been created yet and others. I think, it relates with NETCONF-307.

3. Sending of the upgrade request - It results in appending of the web-socket session in listener. There could be more web-socket sessions on one listener. I see there some issues regarding closing/removal of the web-socket session:

• g. After removal of the last web-socket session, the listener is closed, and the stream is unregistered from ListenersBroker. However, data-store in ietf-restconf-monitoring is not updated at all. There are three cross-cutting concerns that should not be weaved to each other - removal of the stream definition, removal of the subscription by closing of the listener and unregistering of the web-socket session from the listener. I think, that removal of web-socket session should not lead to invocation of other tasks from the reason that user-application cannot know if it must call create stream and/or subscription again, for example after unexpected connection issues. It is OK that application creates stream and subscription separately on start-up based on available information in ietf-restconf-monitoring, but the responsibility must end here.
• h. There isn't any way how to remove created stream other than the way described in g. We should create next RPC for it.
• i. There isn't any way how to remove stream subscription other than the way described in g. We should create next RPC for it.
  Some topics of issues f., g. and h. have already been discussed in NETCONF-351.

Next, there are also some older bugs / new features related to web-sockets that must be verified against new RESTCONF impl.:

• NETCONF-11
• NETCONF-301
• NETCONF-306
• NETCONF-354
• NETCONF-471
• NETCONF-579
• NETCONF-625

The reason why I put together all these things is that I would like to help make it work from the implementation view - so I need your ideas how to solve described issues. As you can see, some of these things are more architectural based, so we should together look at it. If some of the issues are confirmed, I will create sub-tasks for them.

Description of appended sequence diagrams:

web-socket-session-management.pdf

1. creation of the web-socket session handler
2. initialisation of the web-socket session
3. closing of the web-socket session (processing of error would be similar)

data-change-event-streams.pdf

1. creation of the stream definition
2. subscription to the created stream
3. data-tree change update - processing in respect to web-sockets (notification update would be similar)

yang-notification-streams.pdf

1. creation of the stream definition
2. subscription to the created stream - common part that is referenced from (3) and (4)
3. the first way how to subscribe to stream
4. the second way how to subscribe to stream

Thanks for help,
Jaroslav