Hi Andy,
> I do not have any problem with <running> containing active and inactive nodes.
> That's what has been in place for over 10 years. That's what is written in
> NMDA.
For posterity, it’s been “in place” only in proprietary implementations. It
would be nice to resurrect the “conditional-enablement” draft to have an RFC
for it.
> I cannot find any RFC text that says <running> has only nodes created by a
> client.
Really? Interesting. Still, I know it’s a mantra we’ve held closely for many
year, right?
> 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.
> Rewriting NMDA and YANG validation to add a new <system> datastore is
> a major change that will impede deployment. The IETF already had 1 "do-over"
> because of NMDA. Not so sure a 2nd do-over is going to go over well.
I don’t think a “major” change is being discussed: I think it is, effectively:
validate <intended> (not <running>).
And note that Section 5.1.4 says:
For simple implementations, <running> and <intended> are identical.
I’d guess that *all* implementations are “simple” currently. When a server
introduces a feature (inactive, template, etc.) that demands <intended>, at
that time internal logic is switched to "validating <running>" vis-a-vis
validating <intended>. Clients would also have to make that same switch, to
the extent they care about offline validation at all.
<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.
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
