On Tue, Dec 14, 2021 at 2:29 PM Jürgen Schönwälder < [email protected]> wrote:
> On Tue, Dec 14, 2021 at 07:43:47PM +0000, Kent Watsen wrote: > > > > > > >> Right, and in both cases, the idea was that <running> contains all > > >> data needed for the transformation into <intended>. So a client that > > >> wants to do "offline" validation would need the data + the > > >> transformation algorithms. But no additional data. > > >> > > > > > > Having to know proprietary transformation algorithms really kills the > > > idea of interoperable offline validation. It does not really get any > > > worse if transformation algorithms merge in additional definitions. > > > > > > Of the three transform algs under discussion (pruning inactive, merging > system, and expanding templates), only the last may be proprietary and, > even then, nothing is stopping IETF from standardizing one or a few well > known templating mechanisms. > > > > I doubt that existing implementations will converge to a standard > solution (which will take years to define); it seems the window of > opportunity for standards in this space is closed. > > I am still looking for a meaningful problem statement that addresses operational problems. Working on architecture for the sake of elegance is not interesting to me. The problem seems to be that the WG incorrectly assumed that all these unspecified proprietary mechanisms could be represented as YANG data, conforming to specific YANG modules. This data MUST always be valid in both <running> and <intended>. Clearly it was a mistake to assume that these proprietary mechanisms could be ignored for the purpose of YANG validation. It should be obvious that if this data cannot be properly represented in <running> then moving the data to <system> does not help at all. In fact, it makes the problem even worse, because the protocol operations are designed to work on 1 datastore at a time. Offline validation based on multiple retrievals will require long-lived locks, or just be wrong due to time skew. I do not understand the use-case for a leafref that points at instances that do not exist in <running>. It seems like a simple "enabled" leaf allows the unused instance to exist in <running> but be disabled. YANG validation is constrained to a single datastore. It would be very disruptive to change this now. > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 <https://www.jacobs-university.de/> > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
