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

Tianran Zhou <zhoutianran@huawei.com> Mon, 09 September 2019 22:15 UTC

Return-Path: <zhoutianran@huawei.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D74CB12003F for <netconf@ietfa.amsl.com>; Mon, 9 Sep 2019 15:15:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.099
X-Spam-Level:
X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xcBeHsStFTAd for <netconf@ietfa.amsl.com>; Mon, 9 Sep 2019 15:15:23 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F97D120013 for <netconf@ietf.org>; Mon, 9 Sep 2019 15:15:23 -0700 (PDT)
Received: from lhreml703-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id CDCBFD4825F6DADC532A; Mon, 9 Sep 2019 23:15:20 +0100 (IST)
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 9 Sep 2019 23:15:20 +0100
Received: from lhreml709-chm.china.huawei.com (10.201.108.58) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Mon, 9 Sep 2019 23:15:20 +0100
Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml709-chm.china.huawei.com (10.201.108.58) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Mon, 9 Sep 2019 23:15:19 +0100
Received: from NKGEML515-MBX.china.huawei.com ([fe80::a54a:89d2:c471:ff]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0439.000; Tue, 10 Sep 2019 06:15:14 +0800
From: Tianran Zhou <zhoutianran@huawei.com>
To: Alexander Clemm <alex@futurewei.com>, "Eric Voit (evoit)" <evoit@cisco.com>, Kent Watsen <kent+ietf@watsen.net>, Mahesh Jethanandani <mjethanandani@gmail.com>
CC: netconf <netconf@ietf.org>
Thread-Topic: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00
Thread-Index: AQHVZ1wNaJDIFQ93NESUh5lnPdOP/Q==
Date: Mon, 9 Sep 2019 22:15:13 +0000
Message-ID: <BBA82579FD347748BEADC4C445EA0F21BEFAEF40@NKGEML515-MBX.china.huawei.com>
References: <0100016ccff35064-9da3c8b6-263c-47f6-a4f2-4db9495bc8b7-000000@email.amazonses.com> <SN6PR11MB2638BF4053A1308CAA4849A8A1B90@SN6PR11MB2638.namprd11.prod.outlook.com>, <BYAPR13MB2296EF1D3A2EC47AD57FAA89DBB70@BYAPR13MB2296.namprd13.prod.outlook.com>
In-Reply-To: <BYAPR13MB2296EF1D3A2EC47AD57FAA89DBB70@BYAPR13MB2296.namprd13.prod.outlook.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_BBA82579FD347748BEADC4C445EA0F21BEFAEF40NKGEML515MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/VXXm16P-P5p7I2oMfsZIEq9xUM0>
Subject: Re: [netconf] Adoption Call for draft-mahesh-netconf-https-notif-00
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Sep 2019 22:15:27 -0000

I support the adoption.

Tianran




________________________________
Sent from WeLink

发件人: Alexander Clemm<alex@futurewei.com<mailto:alex@futurewei.com>>
收件人: Eric Voit (evoit)<evoit@cisco.com<mailto:evoit@cisco.com>>;Kent Watsen<kent+ietf@watsen.net<mailto:kent+ietf@watsen.net>>;Mahesh Jethanandani<mjethanandani@gmail.com<mailto:mjethanandani@gmail.com>>
抄送: netconf<netconf@ietf.org<mailto:netconf@ietf.org>>
主题: 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 <netconf-bounces@ietf.org> On Behalf Of Eric Voit (evoit)
Sent: Tuesday, September 03, 2019 8:01 AM
To: Kent Watsen <kent+ietf@watsen.net>et>; Mahesh Jethanandani <mjethanandani@gmail.com>
Cc: netconf@ietf.org
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 <netconf-bounces@ietf.org<mailto:netconf-bounces@ietf.org>> On Behalf Of Kent Watsen
Sent: Monday, August 26, 2019 6:02 PM
To: netconf@ietf.org<mailto:netconf@ietf.org>
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