> After reading the RFC details, it seems that the example is intentional based
> on
> the text about NP-containers.
>
> I think an errata could be used because the sentence about a top-level origin
> must be defined
> could be interpreted to define "top-level" as the topmost level for which the
> origin property
> is applicable. It appears the intent was to exclude NP-containers from this
> requirement.
Yes, it was intentional to exclude np-containers, I view something like:
OLD:
The origin for any top-level configuration data nodes must be specified.
NEW:
The origin for any top-level configuration data nodes, except
non-presence containers, must be specified.
to be almost editorial in nature. That said, I also do not think that it’s
needed, in that I think
one could argue that an np-container isn’t actually “configuration” at all,
it’s just implicitly
there providing a skeleton to hang stuff off of.
RFC 8342 says:
o configuration: Data that is required to get a device from its
initial default state into a desired operational state.
An np-container doesn’t actually do this. RFC 7950 says:
o non-presence container: A container that has no meaning of its
own, existing only to contain child nodes.
Bingo. RFC 7950 also says:
o data node: A node in the schema tree that can be instantiated in a
data tree. One of container, leaf, leaf-list, list, anydata, and
anyxml.
Note that it says “container” without clarification. Clearly an np-container
isn’t “data”
so, if there is to be an errata, perhaps it should be against RFC 7950, for
instance:
NEW
o data node: A node in the schema tree that can be instantiated in a
data tree. One of presence container, leaf, leaf-list, list, anydata,
and anyxml.
Kent // contributor
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
