Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif

Kent Watsen <kent+ietf@watsen.net> Mon, 21 September 2020 22:13 UTC

Return-Path: <01000174b2ba9c57-cbc0d353-8d30-4885-8769-1ea869b4d0be-000000@amazonses.watsen.net>
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 A3BF93A0B5B for <netconf@ietfa.amsl.com>; Mon, 21 Sep 2020 15:13:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
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 Gn0et9Xd5TDi for <netconf@ietfa.amsl.com>; Mon, 21 Sep 2020 15:13:29 -0700 (PDT)
Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F67B3A0B55 for <netconf@ietf.org>; Mon, 21 Sep 2020 15:13:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1600726408; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=LkZhsHlXVt3JIu6PzFBrJCH1VQj56eYgT73zeRy2+gk=; b=DNXsilv8R0n5wTzFHXroznAeFnwtPH72dr35biummH1z/MSkHGd4YngVbZy7n8Q9 fbjMGGk+4CEhL6JxRAXr+FQf4QPK2EtU+mjegH68JTkLJQLKrCZzQsYJfSc2Pb/0ZQP NdOGBR6ClnYENRe8MpNdBQS1KTF8LBG/p0m45WIc=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000174b2ba9c57-cbc0d353-8d30-4885-8769-1ea869b4d0be-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_FD75646A-1C22-47B4-9FDF-ECA9666BEAEE"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 21 Sep 2020 22:13:28 +0000
In-Reply-To: <e7ccc6495dd34c4fae15a1697ccd1af5@huawei.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: Andy Bierman <andy@yumaworks.com>
References: <01000173c0b07b33-ad0b793a-7afc-4b39-95f8-2f50574d57bb-000000@us-east-1.amazonses.com> <CABCOCHTP5boMJpCvhjd=Ur9sTr-+Ea0gSzOJnY_YToHGdurhsA@mail.gmail.com> <e7ccc6495dd34c4fae15a1697ccd1af5@huawei.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.09.21-54.240.48.94
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/N2jcBHv3MLnqAT_IdHq7-a1vTjk>
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif
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, 21 Sep 2020 22:13:32 -0000

Hi Andy,

Does Tianran’s response resolve your "I do not understand why the client needs this feature” comment?   As it currently stands, your comment reads like an objection.

The comment regarding if this work should be in its own RFC or as a Bis is a process-question to chairs can ask the WG after determining support for moving the work forward.

Kent and Mahesh, as NETCONF chairs.



> On Aug 10, 2020, at 11:28 PM, Tianran Zhou <zhoutianran@huawei.com> wrote:
> 
> Hi Andy,
>  
> Thanks for your review.
> Basically your understanding is correct.
> The background is about the distributed notif, which the global subscription will be decomposed to several component subscriptions.
> And the client need to compose the data from multiple publishers. It need to know if all the pieces of one data are received.
> Current solution depends on ietf-netconf-notification-messages. I just found it’s expired!
> I would like to discuss with authors about the plan on that draft. Fortunately you are one coauthor. Could you please help on the answer?
> Otherwise, we can seek other way.
>  
> Best,
> Tianran
>  
> From: netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman
> Sent: Tuesday, August 11, 2020 3:39 AM
> To: Kent Watsen <kent+ietf@watsen.net>
> Cc: netconf@ietf.org
> Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif
>  
> Hi,
>  
> I am trying to understand what problem this draft attempts to solve.
> It appears from the solution proposal is that the problem to be solved is
> the lack of message generator identifiers associated with configured subscriptions.
> These identifiers could presumably help a client understand some implementation details
> related to a subscription.  The solution seems to rely on the message-generator-id
> field in the notification message (which does not exist in current RFCs).
>  
> I do not understand why the client needs this feature.
>  
>  
> Andy
>  
>  
> On Wed, Aug 5, 2020 at 3:14 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: Subscription to Distributed Notifications
>    Link: https://tools.ietf.org/html/draft-unyte-netconf-distributed-notif <https://tools.ietf.org/html/draft-unyte-netconf-distributed-notif>
>    Abstract:
> 
>       This documents describes extensions to the YANG notifications
>       subscription to allow metrics being published directly from
>       processors on line cards to target receivers, while subscription is
>       still maintained at the route processor in a distributed forwarding
>       system.
>  
> 
> 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 <https://www.ietf.org/mailman/listinfo/netconf>