I would indeed expect to use the same mechanisms for delivering the
error notifications as for all other notificaitons.
And I suppose one could allow a client to unsubscribe from such
notifications. But it actually seems to encourage dangerous behavior to
do so. And adds extra complexity.
Yours,
Joel
On 11/2/15 8:27 PM, Russ White wrote:
In order to apply the priority mechanism, we effectively have to retain
the
information for ephemeral state about who installed it. This is
particularly
true given the agreement that all clients will have unique priorities.
If all clients must have unique priorities, why do we need to use this
information in the priority mechanism?
Given that, it seems simple and useful to always include that installer in
the
list of people who receive a notification that the modification has been
over-
written. For one thing, that avoids any kind of race condition where the
over-ride could occur before the creator has a chance to add his
notification
request.
It is useful -- I'm not arguing that we shouldn't do this _by default_, only
that we shouldn't make this mechanism separate from any other pub/sub. It
would seem to be easier to have one mechanism that's common, rather than
multiples... I would say -- mandate it by default, but allow the client to
turn it off if it wants after the state has been installed. This keeps the
mechanism the same across all clients.
:-)
Russ
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
