Juergen, Thank you for helping to close this item.
Jason, Are you okay with this resolution? Qiufang, Please update the draft to define what happens in case an update to <system> schema and/or data causes <intended> to become invalid. As a participant, I wonder if it would be possible to enumerate such cases. For instance, let’s assume a software-update removes or renames a “shared object” in <system> that is being used. In this case, I would hope that the installer would check for use of the old shared object and prompt the user what to do. For instance, if the shared object was removed, the installer could auto-create the shared object in <running>. Similarly, if the shared object was renamed, the installer could auto-update the leafref in <running> to point to the new name. Likely it will be impossible to enumerate all possibilities, and so some generic catch-all text will be needed. For instance (please rephrase), “Servers MUST ensure that updates to <system> schema and/or data do not result in <intended> becoming invalid. It is out of scope of this document to define specific remediation mechanisms." Kent > while re-reading parts of the I-D, I tend to agree that using > or:system seems about right. > > Perhaps more explanation would be helpful how to resolve problems is > if client config depends on <system> confif and changes to <system> > cause <intended> to become invalid. Or is the undefined merge going to > "unmerge" stale client config in this situation? Or does the device > reboot to signal it had an internal problem? ;-) Section 6 details > that such a situation is possible, it does not detail how system > changes leading to an invalid <intended> are handled. > > /js > > -- > Jürgen Schönwälder Constructor University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
