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

Andy Bierman <> Tue, 22 September 2020 16:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E40033A09F3 for <>; Tue, 22 Sep 2020 09:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, 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 3Ar7BpsdaeJt for <>; Tue, 22 Sep 2020 09:57:53 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6AF923A09DB for <>; Tue, 22 Sep 2020 09:57:53 -0700 (PDT)
Received: by with SMTP id 77so11501320lfj.0 for <>; Tue, 22 Sep 2020 09:57:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yMI4Gd64BionvTKGo/Z5dzPsfH1cEsykWHPIfYhGDno=; b=ZpFKDLjzCvS5qK5nb1RvwckUkBRtkwkbDScoYJo8jAYOkPngGmFqjpeH9v7ysrJxlV uPoIyRycry+DWJcsenSG5JP0uYbaQeCD5Txm6fS2y3oNDKMU8lm69SanSJobrBa6+rtH N3TLhXZw/BMiq9VXGG5S0KDwPHlo9NFmgmdy/ndaNynvS8AONU5aiQTFEaZ4L/TaBhyx UJARjaw3fBNSuIEcdirCWX9RsMA9r3UTrm6ijVKXmUmoaxGJMgZ7HIy8jhGsx06e2qh7 gnGZvaZLPn0+TfIiyn6fOCiCplZlT1cLYZC+Dg7/Z3vxtmoOTYrb4sVR3hT3fbU0bVo1 cvSQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yMI4Gd64BionvTKGo/Z5dzPsfH1cEsykWHPIfYhGDno=; b=K8veFMSD9N7Y/vgJDv3joLSFdXz9+50xE+cGOrJxcH7L5D6gvaUgMfyM62RYhim4JI NXeVdrljKniPV96sKQlt510yx0Fm/RJMuLBL8bNsoytFMtZjakfKDYACCRZal6PpRHQ5 IX6RWG67YxC05Tqve35up2/W0dkqkHIc1FrqYJNX+MCrVcUcXyWTE2vcuc9+QYRt6UIh mRBuof09qzUWyRon1clnAOrgO1toMa2dq2179KuhtuYMYPkKKT4C8LWnj2/GGj8tBDZz aYoMcVJxWFk8Sq1u9cYUh6DYkTjJlvBHcLOJwzLza48qaLojI+E3lgnp8GbnTVdjuPb3 Mmyw==
X-Gm-Message-State: AOAM530RNeROJqRrxsIWtCSO0WHuQ5g1++lR18FRWJ9zTkZJETOf/++6 a8Ju3ff+ZCM1OenH/SuJ5Dv/o/lGhR3PQuXJA3LV7RykVDEleg==
X-Google-Smtp-Source: ABdhPJzXtGg45Gp4FKWp+rm+VOz0nyHqyLsjP3y+9C9/UX89w+sNi+PyKnuQQQuJt1Zpt3srEn8r9+xdD61DEhN2zSg=
X-Received: by 2002:a19:8708:: with SMTP id j8mr2191749lfd.266.1600793871344; Tue, 22 Sep 2020 09:57:51 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Andy Bierman <>
Date: Tue, 22 Sep 2020 09:57:40 -0700
Message-ID: <>
To: Kent Watsen <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000000f7d2805afe9de57"
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 16:57:55 -0000

On Mon, Sep 21, 2020 at 3:55 PM Kent Watsen <> wrote:

> [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.

The draft does not even have a section discussing the problem that needs to
be solved.
It is useful to distinguish between adoption of a problem-to-be-solved and
adoption of a draft.

Since I have to guess what problem this draft is solving, I suspect the
proposed solution
is just wrong.  The ietf-hardware module should be augmented
with a generator-id, not the subscriptions. The assumed problem is that
data reported from multiple publishers for the same subscription needs to
be correlated somehow.
The client can use the ietf-hardware info to determine the standard and
vendor-specific details
about the hardware sending the generator-id.


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.