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

[Tianran Zhou <[e-mail]>]

I support the adoption.

Tianran




________________________________
Sent from WeLink

发件人： Alexander Clemm<[e-mail]<mailto:[e-mail]>>
收件人： Eric Voit (evoit)<[e-mail]<mailto:[e-mail]>>;Kent Watsen<[e-mail]<mailto:[e-mail]>>;Mahesh Jethanandani<[e-mail]<mailto:[e-mail]>>
抄送： netconf<[e-mail]<mailto:[e-mail]>>
主题： Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00
时间： 2019-09-10 04:40:59

I support the adoption as well.
--- Alex

From: netconf <[e-mail]> On Behalf Of Eric Voit (evoit)
Sent: Tuesday, September 03, 2019 8:01 AM
To: Kent Watsen <[e-mail]>; Mahesh Jethanandani <[e-mail]>
Cc: [e-mail]
Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00

I support the adoption.

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.

(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.

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).
(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.

Thanks,
Eric

From: netconf <[e-mail]<mailto:[e-mail]>> On Behalf Of Kent Watsen
Sent: Monday, August 26, 2019 6:02 PM
To: [e-mail]<mailto:[e-mail]>
Subject: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00

This email begins a 2-week adoption poll for:

    https://tools.ietf.org/html/draft-mahesh-netconf-https-notif-00<https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-mahesh-netconf-https-notif-00&data=02%7C01%7Calex%40futurewei.com%7C16a2dc1806b74e35ad0308d7307f8c74%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637031196689741853&sdata=zdRh4U2o57W%2F0jcTAaPt4rEia%2FFze4Dboq8MdTFvoyA%3D&reserved=0>
In-room support for this draft was noted but, as always, it is necessary to confirm WG consensus on the list.  If interested in the WG defining an HTTPS-based solution for *configured subscriptions* (for which there are none to date), please voice your support for this draft's adoption.  If objecting, please state your reasons.

PS: Authors, please additionally respond to as if there is any IPR to disclose.

Kent and Mahesh // as chairs