IETF Logo Mail Archive

Re: [netconf] https-receiver in draft-ietf-netconf-https-notif-02

Qin Wu <bill.wu@huawei.com> Mon, 06 April 2020 16:49 UTC

Return-Path: <bill.wu@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 E28733A0A78 for <netconf@ietfa.amsl.com>; Mon, 6 Apr 2020 09:49:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 HYVtRkb_wlsB for <netconf@ietfa.amsl.com>; Mon, 6 Apr 2020 09:49:15 -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 607033A0AB6 for <netconf@ietf.org>; Mon, 6 Apr 2020 09:49:15 -0700 (PDT)
Received: from lhreml742-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 5DE92384990CE889AA12 for <netconf@ietf.org>; Mon, 6 Apr 2020 17:49:13 +0100 (IST)
Received: from lhreml742-chm.china.huawei.com (10.201.108.192) by lhreml742-chm.china.huawei.com (10.201.108.192) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1913.5; Mon, 6 Apr 2020 17:49:13 +0100
Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml742-chm.china.huawei.com (10.201.108.192) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1913.5 via Frontend Transport; Mon, 6 Apr 2020 17:49:12 +0100
Received: from DGGEML511-MBX.china.huawei.com ([169.254.1.195]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0487.000; Tue, 7 Apr 2020 00:49:09 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "Reshad Rahman (rrahman)" <rrahman=40cisco.com@dmarc.ietf.org>, netconf <netconf@ietf.org>
Thread-Topic: [netconf] https-receiver in draft-ietf-netconf-https-notif-02
Thread-Index: AQHWDDNKxc1J0UfnKE6t4FWYWLEhmA==
Date: Mon, 06 Apr 2020 16:49:08 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAAD5C8DE5@dggeml511-mbx.china.huawei.com>
References: <DAF9E3B9-B1F1-41CA-AA23-69A7E117D0C8@cisco.com>
In-Reply-To: <DAF9E3B9-B1F1-41CA-AA23-69A7E117D0C8@cisco.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/mixed; boundary="_004_B8F9A780D330094D99AF023C5877DABAAD5C8DE5dggeml511mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/uZygEXCjo-Hnk1QRnqLrz4gAK6c>
Subject: Re: [netconf] https-receiver in draft-ietf-netconf-https-notif-02
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, 06 Apr 2020 16:49:19 -0000

In telemetry data transport capability draft, we allow server to advertise multiple transport protocol, encoding, the client can specified transport and encoding in the yang push subscription model and select appropriate transport from
Sever supported transport protocols.



发件人： Reshad Rahman (rrahman)<rrahman=40cisco.com@dmarc.ietf.org<mailto:rrahman=40cisco.com@dmarc.ietf.org>>
收件人： netconf<netconf@ietf.org<mailto:netconf@ietf.org>>
主题： [netconf] https-receiver in draft-ietf-netconf-https-notif-02
时间： 2020-04-07 00:24:53

Hi,

I understand why nodes receiver(s) were renamed to https-receiver(s) and moved to SN.

So is the plan to have different receiver lists for each transport (assuming we’ll have multiple transports)? Why not have 1 receiver list (keyed on name) and add protocol specifics as needed? If this was already discussed, apologies for beating a dead-horse.

Regards,
Reshad.

v2.23.0 | Report a Bug | By Email