[As a contributor] This message merely provides some insight behind the latest update to the "with-system" draft. [PS: “with-system” is now a misnomer, it is a holdover from when the solution mimicked the “with-defaults” RFC.]
The latest “with-system” draft is nearly the polar-opposite of the -00 version. Whereas the -00 version was very much trying to negate the need for *referenced* system-defined nodes to be copied into <running>, the latest version says that all referenced system-defined nodes MUST be copied into <running>. For <system>-aware clients, both the existence and the definition of system-defined nodes are known by querying the <system> datastore (using the NC/RC NMDA-extensions defined in RFC 8526 and RFC 8527). For <system>-unaware clients (e.g., "legacy" clients), there are two kinds: 1) those that never configure system-defined resources and 2) those that intend to configure system-defined resources. For 1st kind of legacy client, no special access needs to be provided. The solution only needs to ensure that system-defined resources exist in <running> so these clients don’t have offline-validation errors. This is exactly what the current version of this draft ensures, as opposed to the -00 version. For the 2nd kind of legacy client, the draft says: "How clients unaware of the <system> datastore can find appropriate configurations is beyond the scope of this document.”, but one imagines servers exposing proprietary equivalents to querying the <system> datastore. But since this draft states that servers MUST support NMDA, any proprietary mechanism would be redundant to the NMDA-equivalent. Further, the effort to modify a client to use the proprietary mechanism seems nearly equivalent to the effort to modify a client to use the NMDA mechanism. Combined, it begs the question if servers would ever expose a proprietary mechanism or, instead, assume “legacy” clients would actually become <system>-aware. That’s enough of a primer for now, cheers! Kent _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
