Subject: [netmod] Notifications with state data reference

From: Michal Vaško <[email-masked]>
Date: Wed, 07 Mar 2018 14:58:58 +0100

Hi,
in ietf-hardware [1] there are notifications defined that include leafrefs pointing to state data leaves. When the notification is generated, it is validated with regard to the current state data and if successful, the notification is then stored for possible future replay. Now, what happens when a client actually asks for notification replay including this notification? A server is no longer capable of validating it before sending because the state data changed. The same goes for the client, it is unable to validate notifications received from replay. Was this intentional, should the validation be simply skipped in this case?

Thanks,
Michal

[1] https://tools.ietf.org/html/draft-ietf-netmod-entity-08#page-29

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Mar 2018 15:21:11 +0100

Dear Michal,

I think the short answer is that the server replays notifications as
they were was recorded.

Operational state is about "in use" values and on many systems it is
impossible to take a consistent snapshot of operational state and
hence clients will have little chances to obtain consistent snapshots
and to do meaningful validation of received notifications. (Clients
would not only need a consistent snapshot to validate a received
notification but they would also need a snapshot taken at the time the
notification was generated.)

/js

On Wed, Mar 07, 2018 at 02:58:58PM +0100, Michal Vaško wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Michal Vaško <[email-masked]>
Date: Thu, 08 Mar 2018 09:08:42 +0100

Hi Juergen,
thanks for an answer. I realized that validation of such notifications could be difficult because of the reasons you mentioned so I was rather questioning the fact that it is allowed to have references to state data in notifications in the first place. Also, I am not sure it is as harmless as it seems.

What if there is a union in the notification that includes instance-identifier, for example. The client receives the notification from a replay and is unable to validate (resolve) this union leaf. In effect, I dare say the leaf (and likely the whole notification) becomes useless for the client as it simply cannot learn what value is actually stored there. Is all this really okay?

Kind regards,
Michal

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 8 Mar 2018 10:00:49 +0100

> What if there is a union in the notification that includes instance-identifier, for example. The client receives the notification from a replay and is unable to validate (resolve) this union leaf.…

Yes, it is possible to design notifications that are mostly useless
when being replayed - and sometimes even when they are sent live. The
same is true for log messages, if they do not include enough context,
they are useless. Operational state must be understood as being under
constant change. Hence, any references to operational state data that
has a high churn rate is likely of limited value.

We have to trust that authors of YANG models understand the dynamics
of the technology they are modeling. Implementation experience with
the technology usually helps a lot.

/js