Hi Jan,
> On Nov 23, 2021, at 12:56 PM, Jan Lindblad <[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
