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

[Andy Bierman <[e-mail]>]

On Mon, Sep 21, 2020 at 3:55 PM Kent Watsen <[e-mail]> 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.


Andy


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