Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 28 Oct 2019 13:51:35 -0700

Hi Eric,

Picking up on this thread ...

> On Sep 3, 2019, at 8:00 AM, Eric Voit (evoit) <[email-masked]> wrote:
> 
> Building upon that, there are a few elements which would be good to consider in future iterations.
>  
> (1)  Understanding the capabilities of the configured receiver is important.  One or more publishers of configured subscriptions could be used to overwhelm a receiver which doesn't even support subscriptions.    This document should include ways to ensure a configured stream won't be established with an endpoint unequipped to deal with the inbound notifications.  As a starting point for these discussions, there are mechanisms in draft-ietf-netconf-restconf-notif v5 to address this.   E.g., the  HTTP transport augmentation on the receiver must send an "HTTP OK" to a "subscription-started" notification before the publisher starts streaming any subscribed content.

You bring up some interesting points.

>  
> (2)  Multiple versions of draft-ietf-netconf-restconf-notif include topics/text which might be useful, even as an appendix.   For example Section B.2 of v5 includes example config operations and interaction models.

Our motivation with the draft is to keep the “protocol” simple. The draft does not assume HTTP2, and therefore cannot assume a state of “subscription-started” as described in draft-ietf-netconf-restconf-notif-05. 

What it can do, however, is to use the HTTP Response, much as you show in your draft, to indicate that the receiver could not process the notification for whatever reason.

>  
> Side comment:  there are advantages in subscriptions over HTTP2 transports, which I don't believe it will be covered in this draft.  GRPC has the ability to optimize based its leverage of HTTP2.    To examples from draft-ietf-netconf-restconf-notif v5 which are good to think about are:
> (a) optimizing multiple configured subscription streams to a single receiver (such as a controller). 

This has been discussed on the thread, where Martin suggested the notion of “pipelining” of notifications. As far as “subscription stream” is concerned, the idea was to use “bundled-messages” structure defined in draft-ietf-netconf-notification-messages.

> (b) it can be easier overwhelm a receiver which is unable to control or handle the volume of Event Notifications received  
> It would be good to somehow capture the implications of using different underlying HTTP capabilities as part of these discussions.

I have opened an issue titled "Supporting discovery of receiver capabilities” for this in GitHub here <https://github.com/netconf-wg/https-notif/issues/5>. I am not clear on how a receiver can document its capability in a way that is meaningful to each stream across all the streams of messages it is receiving.

Mahesh Jethanandani
[email-masked]