Hi Juergen, Thanks for hanging onto this.
> I thought I just learned that there is no system origin value. Well, > if the values come from intended, then that is what the origin is. I > do not think we should change that, I assume that was a reason why we > report intended and not running etc. Perhaps the decision was wrong > but if it was, we should take a general decision on this and not a per > datastore decision. Note that this also touches on whether we want to > expose template mechanisms or factory defaults or whatever comes next > in the origin values. I guess I am concerned about getting into many > uncoordinated updates of NMDA. Uncoordinated updates is my concern as well. Hence why my reaction when it was suggested for config in the <system> datastore to use an origin identity to express just that. Notably, RFC 8342 doesn’t define origin identities for any specific datastore. I agree that there is an inconsistency here. On one hand, we say that running and system are merged to create <intended>, which is subject to validation. But, on the other hand, the draft says that the config in <intended> that comes from <system> is from "or:system”. Repeating the example mentioned previously, a server not implementing <system> in one release marks, e.g., the loopback interface with “or:system”. Then, in the next release, the server implements <system> with the loopback interface configured, making no other change to internal code. In this example, nothing material changes, so it doesn’t make sense to me why the origin value used would differ. I continue to think that the draft has it right. Kent // contributor _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
