>> I agree that if system configuration changes, any reference to it might >> cause <intended> to become invalid. As Kent suggested, how about we add some >> following text in section 6.1 to clarify: >> >> Server MUST ensure that any updates of <system> do not render <intended> >> invalid. However, any mechanism for handling these circumstances is outside >> the scope of this document. >> > > For me, this translates into "we designed something that has a problem > for which we have no solution".
I don’t see it this way. At least, when discussing <running> having a leafref to an object that exists in <system>, there is possibility that an update to the device’s software may cause the referenced object to disappear. This reality must not become a problem. How the server handles this is implementation specific, but options might include: - blocking the software-upgrade until the leafref is updated - auto-migrating the leafref to a new/preferred object in <system> - auto-copying the removed <system> object into <running> - etc. But the MUST regards *if* the server ensures validity, not *how* it does it. Are there other use-cases, e.g., a line-card being removed, that causes problems? In the line-card case, I think the <system> config (for the line card) would’ve been copied into <running>, e.g., in other to override a “MTU” value. When the line-card is removed, it is okay, per https://datatracker.ietf.org/doc/html/rfc8342#appendix-C.3.1. Is there another case we need to discuss? Kent // contributor
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
