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

Mahesh Jethanandani <> Tue, 22 September 2020 15:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ED8FF3A0F9F for <>; Tue, 22 Sep 2020 08:10:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BQKvFx28X6OP for <>; Tue, 22 Sep 2020 08:10:33 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CBC8A3A0F8A for <>; Tue, 22 Sep 2020 08:10:32 -0700 (PDT)
Received: by with SMTP id v123so19308697qkd.9 for <>; Tue, 22 Sep 2020 08:10:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=piPxfaFFNZT3uE78wMyx68a5eJ+xbjJ3toR/s3zy1kc=; b=Fqvqj2cY6szPvWnKd1kiD3WmFaNajVAqlXTGxsBZXHJTFF67hMwZ/4BBHH5/a1SMUA MziwXfakIbV7vbE3BUus4VE4tJTXx72oZN+yeknDHBfup4XH4CXgJD5K8OHjGNPRMQwn 9u7nNRjmi/HaCKzh4qJb7REd63HadVUwQ+RgGkUKziVIJhckKcTZYa8xYWGlgQdWCH9x VSrL5RraN4zZcCzZSi81KcKtwLy/jAC1Ws9VgOYuJq5JD+GkQAf9TMChZA1N0O6t8913 NqXneSn81tkc6RsGPBjRTtwTE2uC2KGAnqhTw9BPgLdtOy+sDucRrH3wXhOEz6A96fl8 cScA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=piPxfaFFNZT3uE78wMyx68a5eJ+xbjJ3toR/s3zy1kc=; b=dMTi5sn8GemFEJzdtEdZFPVvqbSTPQMl+Sjhr32jGM71zQPe9atBicBEZi1GBvbRy3 pJ/gFrFCTUExjt0udgJw0ABCH9kxfrz4pe1PwaF49KDxbaqhLaSeIoMZH7m6Bp1Kmc8U Q3m1KmY/FW6uOi9WFk2O49EId4VC/CZJN8pR3pN6Pe9XGnhTr35x5dcPxVFikMAUINL0 l1ZTdloNOiOVYecPj2K68ikaXMy9FeNKq7bw9NCYzZFbGLHiNtSUD240yJu/l6ZRU54U Op4i1kGCUCERAV9USLRMI4hq5kkVwJJRzJH6pUVxF26zMmeJ+s9PsBr1bbDa4cYYZF9v e+4A==
X-Gm-Message-State: AOAM532GIjCMMyST5awiZqy6XIOrm3Hh7HziZ7botN+kdoKKtdmZHr1/ TP/Bf3YhOr1jyARzRuedk1vLB27/eM/UqA==
X-Google-Smtp-Source: ABdhPJwX/KyPbJAlzQ4nzZ6lWajA+CGxIR0xcAJsLi//+ljtLo0BhhYuhV2zk9dTGLKmCAV90XnSaw==
X-Received: by 2002:a37:9c8:: with SMTP id 191mr5218805qkj.292.1600787431740; Tue, 22 Sep 2020 08:10:31 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id g12sm11870365qke.90.2020. (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Sep 2020 08:10:30 -0700 (PDT)
From: Mahesh Jethanandani <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_05BCDF4E-9114-41D4-9DFA-E57DA824E7E2"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Date: Tue, 22 Sep 2020 08:10:28 -0700
In-Reply-To: <>
Cc: Kent Watsen <>, Andy Bierman <>, "" <>
To: Tianran Zhou <>
References: <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Sep 2020 15:10:35 -0000

[As a contributor]

Hi Tianran,

I am confused by the value statement. Maybe you can help clarify.

It would help if we can use a single terminology of publisher/subscriber instead of mixing it with client, which I understand to be the subscriber and server which I understand to be the publisher. Note, if HTTPS is used, the role of client and server would be reversed, so it is best to avoid using those terms.

See inline with [mj].

> On Sep 21, 2020, at 7:04 PM, Tianran Zhou <> wrote:
> Thanks Andy for your opinion. And thank Kent for your expansion and further question.
> The goal is to allow the client to know if it has received all the data pieces. Furthermore, the client know which publisher failed to send data. Then it depend on the client to do the action, e.g., ignore, require the data one more, …
> We just use the generator-id to indicate the publisher, as we find it in ietf-netconf-notification-messages, and it’s very convenient for this usage.

[mj] What usage would be that? The usage of generator-id to indicate who is the publisher and thereby have the subscriber request for any missing data? I would like to note that nothing prevents usage of a reliable transport, e.g. HTTPS or TCP, with this draft. Would you still need a generator-id?

> One use case is exactly as Kent mentioned “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”.
> It’s also OK for us to use another indicator if the generator-id is not feasible.

[mj] Precisely. If you use a reliable transport, you would have other means to identify the source of the notifications, in which case you would not need the generator-id.

Which goes back to the question of why we need a generator-id. If we do not want data loss, we should be using a reliable transport, in which case we do not need a generator-id. If we can tolerate data loss, e.g. with statistics, we do not care for generator-id because we are not going to ask for missing data. What use case requires us to use unreliable transport and yet need a generator-id?


> “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). ”
> If necessary, maybe we can extend this mapping in some initial exchanges. To be clear, how do you want to name the publisher?
> Thanks,
> Tianran
> From: netconf [] On Behalf Of Kent Watsen
> Sent: Tuesday, September 22, 2020 6:55 AM
> To: Andy Bierman <>
> Cc:
> Subject: Re: [netconf] Adoption-suitability for draft-unyte-netconf-distributed-notif
> [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.
> _______________________________________________
> netconf mailing list

Mahesh Jethanandani