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         <https://www.jacobs-university.de/>

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

Reply via email to