Hi, Kent Watsen <[email protected]> wrote: > Hi Andy,
> > I cannot find any RFC text that says system-injected config is > > special, especially since > > server implementations exist that treat these edits as just another > > client > > (although probably a 'root' user client). > > Very true (and Juergen’s point as well). I’ve seen this done before. > Unhappy results. Can you elaborate on this, or send a pointer if it has been documented somewhere? I will also add a +1 to letting the system "act as a client" and put data into running. This is what we do in our current project. A few other comments. The name "system" for this new proposed datastore is perhaps not the best, since RFC 8342 already defines this term, and associated semantics. If the new proposed datastore is supposed to add static data like "built-in profiles and policies", it is rather limited, compared to "system config" as defined in RFC 8342. The reason is that system config can be injected at various levels in the config hierarchy; specifically also under user-defined list entries. And if this is indeed the use case you (as in all proponents of the proposal) have in mind, I think the solution with adding this to <running> works. (But I am curious to hear your experience of this). > <putting on flame suit> > > As a co-author, I know this was the intention of RFC 8342, which is > supported by, for instance: > > > Section 4.1: > > o Several implementations have proprietary mechanisms that allow > clients to store inactive data in <running>. Inactive data is > conceptually removed before validation. > > o Some implementations have proprietary mechanisms that allow > clients to define configuration templates in <running>. These > templates are expanded automatically by the system, and the > resulting configuration is applied internally. 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. /martin > > Section 5: > > <intended> // subject to validation > > Section 5.1.4: > > <intended> is tightly coupled to <running>. Whenever data is written > to <running>, the server MUST also immediately update and validate > <intended>. > > > <taking off flame suit> > > > Of course, some will point to Section 5.1.3: > > 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>. > > But it has to be obvious that this is a bug. For instance, > > - YANG defines a leaf is of type union { uint8 | variable } > - <running> defines the leaf having value “MAX_FOOBAR” > with a template that defines MAX_FOOBAR=1000. > - so, <running> would be syntactically valid but > semantically invalid. > > Or a more egregious example: > > - YANG defines a "max-elements" value “MAX_FOOBAR” > - how is this possible when RFC 7950 says max-elements > Is a positive integer or the string “unbounded”? > - so now we’re into YANG-next territory as far as > templates are concerned, but hang with me a little > while longer… > - <running> has a template that defines MAX_FOOBAR=3 > - how coulda server validate if <running>’s list contained less > than max-elements? Worse, what if the result of another > template added more elements to the list? > > > I may have taken off the flame suit too early ;) > > K. > > > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
