Hi, Rob, Thanks for getting back to me, please see below inline...
My concern is related to the statement in RFC 8342: <intended> MUST always be a valid configuration data tree. If a client references an interface eth0 in <running> which is afterwards physically removed and thus disappears from <system>, we end up with dangling reference in <intended>. This one is a bit more concerning. RFC 8342's answer to this problem was for the client to put the referenced interface into <running> so that regardless of whether the interface is present in the hardware or not, the configuration is valid. But I think for that solution to really be robust the client needs to also configure the interface type, or the system needs to be able to infer what the interface type is, since the when statements for other configuration is predicated on that interface type. But there seems to be four choices here: (1) Don't allow the forward reference into <system> in the first place, i.e., require the interface (and perhaps interface type) to always be in <running>. I.e., as per RFC 8342. (2) Modify the running configuration if the hardware is removed. E.g., remove the configuration that is referencing, or inject the referenced system configuration. (3) Allow the configuration to become invalid. (4) Keep interfaces in system, even for removed hardware, if that interface is referenced by any running configuration. This is arguably similar to 2,but avoids actually modifying running. My assumption is that the interface would still be removed from operational because it can no longer be instantiated. [Qiufang] I prefer your solution #2, solution #3 seems require the NMDA-bis work. Maybe declare it as out-of-scope is good enough? Setting require-instance to false may resolve this as well, and perhaps a best solution since you rely on some configuration that is dynamic with less control of clients. But I do understand we cannot expect this for all YANG designers. Similarly, If the upgrade/downgrade happens before keeping the configuration consistent, the invalidity of configuration between t1 (the upgrade/downgrade) and t2 (the first operation to make configuration consistent) seems also a violation of that statement. This one worries me less. Ultimately if the previous configuration is no longer valid with the new version of software then the configuration has to be changed, or the software change prevented (or reversed). Forcing the client to create a configuration that MUST be valid both in the old and new configuration seems like creating extra work for the client, probably for little benefit. [Qiufang] Agree this is less concerning. We used to have some similar discussion, configuration invalidity caused due to device upgrade/downgrade is non-specific to system configuration, there could be simply a mandatory-false node become mandatory-true and it fails to appear in <running> thus causes <running> invalid. I kind of agree that we should say less rather than more, especially when this is beyond the scope of the document. The examples here are used only to enlighten some possible solutions, we can remove these, but I am really unsure we should relax MUST to SHOULD here. But if you don't relax the MUST then how to handle the upgrade/downgrade case? Regardless of what the RFC states, what do implementations actually do here? For the OS that I'm familiar with, I think that we will remove parts of configuration from running after the software change, if that configuration is no longer valid. [Qiufang] Yes, I can see your point. How about the following new text: If system configuration changes, <running> SHOULD remain accurate and consistent with <system>. However, any mechanism for handling these circumstances is outside the scope of this document. And get rid of the examples in -10, note I avoid using "valid", trying to avoid an obvious violation with existing RFCs, and I think if system configuration changes, the real intent of clients would be to keep their configuration accurate and consistent. A side comment: I will propose some updates as well to incorporate your other comments in a separate email. Thanks a lot. Best Regards, Qiufang
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
