Hi Kent, I'm not following your "In the meanwhile" thoughts.
Legacy clients are failing offline validation today. If running config has a leafref to system config, and <get-config> doesn't return that system config (which it doesn't in some implementations), then the instance data returned to the client doesn't validate against the YANG model. These implementations don't have an explicit <system> datastore today (but they do have these internal semi-hidden referenceable list entries). Jason From: netmod <[email protected]> On Behalf Of Kent Watsen Sent: Monday, November 29, 2021 5:09 PM To: Jan Lindblad <[email protected]> Cc: maqiufang (A) <[email protected]>; [email protected] Subject: Re: [netmod] Must offline-validation of <running> alone be valid? Hi Jan, On Nov 23, 2021, at 12:56 PM, Jan Lindblad <[email protected]<mailto:[email protected]>> wrote: Sergio, Qiufang, Hi Jan, You correctly wrote: Then the choices become: * Offline validation of <running> alone is NOT required * Servers internally validate <running> via validating <intended> * SB> but in fact this is what declared, for my understanding, in RFC 8342, for which “validation” is done on “intended” by the server , as also shown in figure 2 of the RFC. Is it needed to change also RFC? According to RFC 8342, *both* running and intended have to be valid at all times. Section 5.1.3 says: 5.1.3<https://datatracker.ietf.org/doc/html/rfc8342#section-5.1.3>. The Running Configuration Datastore (<running>) ... However, <running> MUST always be a valid configuration data tree, as defined in Section 8.1 of [RFC7950]<https://datatracker.ietf.org/doc/html/rfc7950#section-8.1>. Section 8.1 of RFC 7950 was the section I referred to in my previous comment. Section 5.1.4 says: 5.1.4<https://datatracker.ietf.org/doc/html/rfc8342#section-5.1.4>. The Intended Configuration Datastore (<intended>) ... <intended> is tightly coupled to <running>. Whenever data is written to <running>, the server MUST also immediately update and validate <intended>. In my judgement, changing the fundaments of RFC 7950 and 8342 is not going to happen any time soon (for good reason), and there are other (better) options. * Offline validation of <running> alone IS required * Options: * Clients MUST copy/paste any referenced system configuration into <running>, even though it goes against our objective of avoiding-copy when possible. * Defer work to be a YANG-next effort. In order to move forward, I would propose working out some more options in this list. I have suggested a few to the authors that I think are better than the two above, but I will leave it to the authors make the call for what they want to bring up for discussion. I don’t think the case has been made that *offline* validation of <running> by itself must be valid. Yes, *online* <running> must be valid, as must <intended>, with the intention of RFC 8342 being that both are validated in one and the same operation by the server (known to me as an author of RFC 8342). I understand that implementations may have assumed offline validation of <running> must be valid, I just can’t find the RFC reference that demands it be supported, and without such reference, it falls into an undefined area. Necessitating offline validation of <running>, if that is what the WG decides, results in solutions for which none seem nice to me, at least I haven’t seen any yet. Please share any “better options” you have in mind. In the meanwhile, can we discuss the issues around a legacy client failing an offline validation? In this case, a production deployment must have 1) deployed devices that support <system>, 2) deployed at least one client that supports <system>, and 3) decided to let clients start pushing config using <system>. While in the pre-production testing phase, it would be quickly discovered that all legacy clients need to be updated. By the time of going to production, the deployment should have all the clients updated, so it seems that only the forgotten (relatively insignificant) clients might have an offline validation of <running> failure. Is this a fair assessment? Kent // as a contributor
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
