Re: [netconf] Adoption-suitability for draft-wang-netconf-bulk-subscribed-notifications

Qin Wu <bill.wu@huawei.com> Tue, 11 August 2020 02:11 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 BDDDB3A0EF9 for <netconf@ietfa.amsl.com>; Mon, 10 Aug 2020 19:11:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 Ezz7Tfntpkd7 for <netconf@ietfa.amsl.com>; Mon, 10 Aug 2020 19:11:38 -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 13D1A3A0EE6 for <netconf@ietf.org>; Mon, 10 Aug 2020 19:11:37 -0700 (PDT)
Received: from lhreml703-chm.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A755B91153718F14120A for <netconf@ietf.org>; Tue, 11 Aug 2020 03:11:35 +0100 (IST)
Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1913.5; Tue, 11 Aug 2020 03:11:35 +0100
Received: from DGGEML422-HUB.china.huawei.com (10.1.199.39) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1913.5 via Frontend Transport; Tue, 11 Aug 2020 03:11:34 +0100
Received: from DGGEML511-MBS.china.huawei.com ([169.254.4.234]) by dggeml422-hub.china.huawei.com ([10.1.199.39]) with mapi id 14.03.0487.000; Tue, 11 Aug 2020 10:11:31 +0800
From: Qin Wu <bill.wu@huawei.com>
To: Andy Bierman <andy@yumaworks.com>, Kent Watsen <kent+ietf@watsen.net>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] Adoption-suitability for draft-wang-netconf-bulk-subscribed-notifications
Thread-Index: AdZvgj7LaTzaNxwMRmWVgYQUe3VBdQ==
Date: Tue, 11 Aug 2020 02:11:31 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABAAD8FAC44@dggeml511-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.164.151.108]
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABAAD8FAC44dggeml511mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/MqI0FSXidcDGIHfpXpldV8-AX6g>
Subject: Re: [netconf] Adoption-suitability for draft-wang-netconf-bulk-subscribed-notifications
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: Tue, 11 Aug 2020 02:11:41 -0000

发件人: netconf [mailto:netconf-bounces@ietf.org] 代表 Andy Bierman
发送时间: 2020年8月11日 3:40
收件人: Kent Watsen <kent+ietf@watsen.net>
抄送: netconf@ietf.org
主题: Re: [netconf] Adoption-suitability for draft-wang-netconf-bulk-subscribed-notifications

Hi,

I am trying to understand the problem statement in this draft.
It seems to be that RFC 8639 does not provide enough configuration capability
to specify how notifications from different subscriptions should be bundled
together into a single message.

[Qin]:Correct, I think it is important to define criteria to classify subscription and indicate to the server which specific subscription associated with the notification should be bundled together
before bundling multiple notification in a single transport message. That’s why we proposed two models, i.e., bulk subscription model bulk notification model,
bulk subscription model define additional subscription configuration (e.g., bundle-latency, bundle-size)and one new RPC to indicate the sever which subscription can be bundled together and which not.
The second model is bulk notification model, which is used by the server to indicate to the client about the group id and compression mode.
There is no discussion of why bundling
notifications needs to be standardized, or what benefits it provides over
the current RFC 5277 notification message definition.
[Qin]: I think the second model on bulk notification is debatable, in our opinion, it is no harm to have this model to tell
The client about the group-id for several subscription to be bundled together, but it may be redundant with the current RFC5277. Through offline discussion, Eric also expressed the similar opinion on the second model.
If this is agreement, we can remove the second model.
This approach seems to add a lot of complexity without adding much benefit.

Andy


On Wed, Aug 5, 2020 at 3:19 PM Kent Watsen <kent+ietf@watsen.net<mailto:kent%2Bietf@watsen.net>> wrote:

NETCONF WG,

Per the previous email sent moments ago, the chairs would like to solicit input on the following draft:

   Title: Bulk Subscription to YANG Event Notification
   Link: https://tools.ietf.org/html/draft-wang-netconf-bulk-subscribed-notifications
   Abstract:
      This document defines a YANG data model and associated mechanism that
      allows subscriber applications to bulk subscribe to publishers' event
      streams based on bundle group information such as bundle size and
      bundle latency.  This allows the publishers to report multiple
      notifications in a single bundling message.


In particular, please discuss adoption-suitability as it regards to the following questions:

    1) is the problem important for the NETCONF WG to solve?
    2) is the draft a suitable basis for the work?


PS: this message is itself not an adoption poll, but rather an attempt to gauge interest/support for a potential future adoption poll.

NETCONF Chairs
_______________________________________________
netconf mailing list
netconf@ietf.org<mailto:netconf@ietf.org>
https://www.ietf.org/mailman/listinfo/netconf