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

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

Return-Path: <01000174b2e0a349-52337b7b-81c3-4c56-a58b-36c95d68340f-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 E21483A0C94 for <netconf@ietfa.amsl.com>; Mon, 21 Sep 2020 15:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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] 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 nrwOQ5wvHL8l for <netconf@ietfa.amsl.com>; Mon, 21 Sep 2020 15:55:01 -0700 (PDT)
Received: from a8-31.smtp-out.amazonses.com (a8-31.smtp-out.amazonses.com [54.240.8.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D3F63A0C81 for <netconf@ietf.org>; Mon, 21 Sep 2020 15:55:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1600728900; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=ncJ8f7RGuDyU9NuhcZhGbZZFw8UY3PLLSk1ssziw1Ew=; b=hIQ7PlewOdlEjAg7QYpQ/xvcGv/gVG2Xi9qfD9AoEoj1fUVs78Sku7j0bI0iBopn QFtBO4jn3twKeKnmnkLQTr/ZXtgZ/++gxBWDgJWC54GMm7i3MiV9A611krCpDarISCg mfgajy7MIX/cZc7nowlf1+w+2ZlbH6J/1swJwung=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <01000174b2e0a349-52337b7b-81c3-4c56-a58b-36c95d68340f-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_228CBF47-D525-46DF-B917-DB5D06AE3B2D"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Mon, 21 Sep 2020 22:55:00 +0000
In-Reply-To: <CABCOCHR9hBn+vYg-Y8qfWd-Vj5qEqcAuGNrq_Xg+fRiiVALkVA@mail.gmail.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> <01000174b2ba9c57-cbc0d353-8d30-4885-8769-1ea869b4d0be-000000@email.amazonses.com> <CABCOCHR9hBn+vYg-Y8qfWd-Vj5qEqcAuGNrq_Xg+fRiiVALkVA@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.09.21-54.240.8.31
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/F5gfF_df-QBCoVp39AQOIp43q9Q>
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:55:03 -0000

[As an individual contributor]

> The overall approach to the binary push features seems a bit incoherent to me.
> I don't see much value in this draft, but no harm either so I do not have an objection
> to adoption.  Perhaps there is some debugging value here but since the architecture
> really does not define message generators as sub-components of a configured subscription,
> a client cannot expect any sort of consistent implementation of this field.

Good point. If I understand you correctly, what seems to be missing is an ability for the client to determine which generator-id is used by which publisher (e.g., line card).  The solution enables the client to partition notifications coming from different publishers, but that is it.  What value does this have to the client, I don’t know.  

Answering myself here, perhaps it enables two servers on the same IP address to send to the same receiver, as then the receiver doesn’t solely rely on source-IP address (assuming unauthenticated push) to designate the publisher?

Can the authors help resolve the value-proposition question here?

K.