Re: [netmod] Notifications with state data reference

[Juergen Schoenwaelder]

On Thu, Mar 08, 2018 at 09:08:42AM +0100, Michal Vaško wrote:
> 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?
>

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

-- 
Juergen Schoenwaelder   Jacobs University Bremen gGmbH
Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] Notifications with state data reference

[Juergen Schoenwaelder]

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:
> 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
> 
> ___
> netmod mailing list
> netmod@ietf.org
> 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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod