On 05/12/2017 14:38, Martin Bjorklund wrote:
Balazs Lengyel <[email protected]> wrote:
On 2017-12-05 11:04, Robert Wilton wrote:
I see your point now.
The server has to evaluate the when-stmts in operational.
I think that this is probably down to implementation, but I don't
think that this is necessarily required. A server is meant to
conform to 'when' statements in <operational> (e.g. if the system
is in a normal steady state), but they are allowed to be violated,
and I'm not expecting that a server would evaluate them (except
perhaps to discover implementation bugs). Further, if violations
of when statements in <operational> are detected then I don't
think that there is anything that the server can reasonable do.
BALAZS: I always thought that if a when statement's argument was true
but becomes false, all instance data that is set/written according to
the schema nodes affected by the when statement shall be removed by
the server. So IMHO the server can and should do something about a
violated when statement.
Yes.
But I still don't think that requires that you have to evaluate when
constraints on <operational>.
E.g. [implementation dependent]:
- user sends config to <running>
- server calculates change to <intended> including implicit deletes
due to now false when statements.
- server sends calculated config change to daemons.
- config daemons late update operational with the updated applied
configuration. When statements can be transiently violated in
operational, but should converge to the behavior defined in the data
model, all being well.
Thanks,
Rob
Actually I would like a list of statements and constraints that MUST
be satisfied in the different data stores. Speaking about syntactic
versus semantic seems fluffy.
See RFC 7950, section 8 (esp. 8.1 and 8.2).
/martin
.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
