Ask is moving to Stack Overflow and Serverfault.com! Please use the "opendaylight" tag on either of these sites. This site is now in Read-Only mode

Revision history [back]

Kanika,

Few things:
- ODL does not yet support draft17, but draft02. Here are the diff
- Regardless the above point, both draft share the same specification for the stream subscription, as you pointed out:
1. Client request the list of available streams
3. Server return the available streams
2. Client subscribe to one of the available stream (HTTP GET)

The RFC section you mentioned is for the "Subscribing to Receive Notifications" only.

Looking at the "Event Streams" section, this is where I believe ODL is missing something:
"A RESTCONF server that supports notifications will populate a stream resource for each notification delivery service access point."
As ODL does not populate this automatically (expect for NETCONF device), you have to create the stream yourself, e.g. the extra steps 1 and 2 you highlighted: client invokes rpc, server returns streams.

Hope this helps, Alexis

Kanika,

Few things:
- ODL does not yet support draft17, but draft02. Here are the diff
- Regardless the above point, both draft share the same specification for the stream subscription, as you pointed out:
1. Client request the list of available streams
3. 2. Server return the available streams
2. 3. Client subscribe to one of the available stream (HTTP GET)

The RFC section you mentioned is for the "Subscribing to Receive Notifications" only.

Looking at the "Event Streams" section, this is where I believe ODL is missing something:
"A RESTCONF server that supports notifications will populate a stream resource for each notification delivery service access point."
As ODL does not populate this automatically (expect for NETCONF device), you have to create the stream yourself, e.g. the extra steps 1 and 2 you highlighted: client invokes rpc, server returns streams.

Hope this helps, Alexis

Kanika,

Few things:
- ODL does not yet support draft17, but draft02. Here are the diff
- Regardless the above point, both draft share the same specification for the stream subscription, as you pointed out:
1. Client request the list of available streams
2. Server return the available streams
3. Client subscribe to one of the available stream (HTTP GET)

---------------------[EDIT]------------------------

The RFC says, regarding step 3 above:
"The server will treat the connection as an event stream, using the Server Sent Events [wd-eventsource] transport strategy." e.g. create a websocket client using SSE strategy
"The server might send the following response:"
The response being the location of the opened websocket.
But does never specify how to get/listen to this connection, hence I believe this is up to the implementation.

---------------------[/EDIT]------------------------

The RFC section you mentioned is for the "Subscribing to Receive Notifications" only.

Looking at the "Event Streams" section, this is where I believe ODL is missing something:
"A RESTCONF server that supports notifications will populate a stream resource for each notification delivery service access point."
As ODL does not populate this automatically (expect for NETCONF device), you have to create the stream yourself, e.g. the extra steps 1 and 2 you highlighted: client invokes rpc, server returns streams.

Hope this helps, Alexis

Kanika,

Few things:
- ODL does not yet support draft17, but draft02. Here are the diff
- Regardless the above point, both draft share the same specification for the stream subscription, as you pointed out:
1. Client request the list of available streams
2. Server return the available streams
3. Client subscribe to one of the available stream (HTTP GET)

---------------------[EDIT]------------------------

The RFC says, regarding step 3 above:
"The server will treat the connection as an event stream, using the Server Sent Events [wd-eventsource] transport strategy." e.g. create a websocket client using SSE strategy
"The server might send the following response:"
The response being the location of the opened websocket.
But does never specify how to get/listen to this connection, hence I believe this is up to the implementation.

---------------------[/EDIT]------------------------

The RFC section you mentioned is for the "Subscribing to Receive Notifications" only.

Looking at the "Event Streams" section, this is where I believe ODL is missing something:
"A RESTCONF server that supports notifications will populate a stream resource for each notification delivery service access point."
As ODL does not populate this automatically (expect for NETCONF device), you have to create the stream yourself, e.g. the extra steps 1 and 2 you highlighted: client invokes rpc, server returns streams.yourself.

Hope this helps, Alexis