On Mon, Dec 13, 2021 at 6:55 PM Kent Watsen <kent+i...@watsen.net> wrote:
> 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?
>
>
No. Quite the opposite. The client only gets access to the config after the
device
has created an initial configuration, especially interface configuration.
The text in RFC 7950 is clear:
The accessible tree depends on where the statement with the XPath
expression is defined:
o If the XPath expression is defined in a substatement to a data
node that represents configuration, the accessible tree is the
data in the datastore where the context node exists. The root
node has all top-level configuration data nodes in all modules as
children.
The RFC does not need to discuss offline validation because the constraints
apply to a single datastore.
The original intent (in YANG and NMDA) is that inactive nodes and active
nodes
can coexist in <running>. I see no reason to change NMDA or YANG and abandon
this approach.
IMO distinguishing so-called system config from client config
is not a very compelling operational problem to solve.
Not so sure it is easy to define a system edit vs. a non-system edit.
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.
>
>
> 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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
