Hi Authors,
Thanks for the work on this following the excellent debate a few IETF sessions
ago. Here are some review comments for the current version:
Item 1
3.1. Defining and Managing Templates
Templates can be used with any YANG module. They contain nodes of
configuration data, and are stored persistently (in their unexpanded form)
in the running datastore of the device.
Item 2
3.2. Applying Templates
<snip>
Templates can be applied at multiple points in the hierarchy (typo). The
next section states the requirements when a node applies a template
and it has an ancestor that also applies a template.
Item 3
When viewing the <running> datastore, there is a mechanism to see
which templates have been will be applied to each node, and in which order.
Item 4
3.3. Producing the Intended Datastore
The device's <intended> datastore is the result of combining all the
applications expansions [JGC: applications feels wrong because we don’t know
what the application of this is, we only know that its going to be expanded
and updated]
of templates together with non-template config. This is
called "expanding out" the templates.
Item 5
The intended configuration inside a subtree is the result of taking
the relevant contents of every template applied to the subtree's root
node and its ancestors, and combining it with the (non-template) data
nodes inside the subtree.
[JGC: Can you confirm the intention here is to disallow templates being applied
to templates?]
Item 6
* When templates are applied to multiple ancestors, the innermost
ancestor takes precedence.
[JGC: I can see a need to define “innermost”, this might be better written as
“most specific” but
that also has some language issues]
Item 7
* When multiple templates are applied to a particular node, the
order of application (as indicated by the client when applying the
templates) determines the precedence within that node.
[JGC: Last wins or first wins? I’m sure there’s going to be a section later on
this but either a reference
to that section or a quick few word definition would be useful here]
Item 8
In other words, the outcome of template expansion depends solely on
the <running> datastore and not the state of the device.
[JGC: Is this still correct when considering the system configuration draft. I
believe it is but perhaps this should be clarified?]
Item 9
(Editor's note: more work may be needed here to ensure the template
is a valid subtree of config from a schema perspective. This may
mean we need a way of saying where the root of the template is in the
schema, for example with a set of "outer" nodes with
operation="none").
[JGC: “outer” should probably be defined if we’re going to use it – same
comment I had for “inner” earlier 😊 ]
Item 10
4.2.1. The "apply-templates" Metadata
Template application is indicated using the "apply-templates"
metadata. The value of this is a list of space-separated template
identifiers. If the template is applied to a node in the data tree,
the metadata object is added to that specific node.
[JGC: The draft mentions that the value of this field is a space-separated
list. Should this be
apply-template=”foo bar” or apply-template=”[foo bar]”? The square brackets
might help both
humans and machine parsers understand that this is a list rather than having to
just know that this specific
metadata attribute is a list]
Item 11
4.2.1. The "apply-templates" Metadata
Template application is indicated using the "apply-templates"
metadata. The value of this is a list of space-separated template
identifiers. If the template is applied to a node in the data tree,
the metadata object is added to that specific node.
[JGC: What is the order of application? If I have apply-templates=”t1 t2” does
the system apply t1 then apply t2 with the
last write wins concept or do I apply t2 and then t1 with last write wins… or
something else? It looks like the draft tries to
address this later with this text “ When multiple templates are applied to a
particular node, the order of application (as
indicated by the client when applying the templates) determines the precedence
within that node.” but this still doesn’t
answer the above question.
]
Item 12
The encoding of "apply-templates" metadata object follows the way
defined in Section 5 of [RFC7952].
[JGC: This restricts us from applying a template to an entire list or an entire
leaf-list but I believe this is fine. From RFC7952:
“annotations cannot be attached to a whole list or leaf-list instance, only to
individual list or leaf-list entries.”
]
Item 13
* The apply-templates attribute is specified and the value is the
empty string. The apply-templates metadata is removed and thus no
templates are applied to the node.
[JGC: Given that the apply-templates cannot be deleted, does that mean that a
configuration over time will end up with lots of
useless annotations with empty strings or is the system expected to prune them?]
Item 14
4.5. Validity of Templates
The contents of the template alone is not always sufficient to
enforce the constraints of the data model. Some constraints may
depend on configuration outside of the templates to satisfy, e.g., a
list may contain a mandatory leaf node which is not defined in the
template but explicitly provided by the client. However, servers
SHOULD parse the template and enforce the constraints if it is
possible during the processing of template creation, e.g., servers
may validate type constraints for the leaf, including those defined
in the type's "range", "length", and "pattern" properties.
[JGC: I wonder whether we should mark some specific things as not permissible
in templates? Specifically I’m thinking
of mandatory.]
Item 15
4.5. Validity of Templates
[JGC: The general question of should a template be valid by itself needs to be
answered in this draft.]
Item 16
4.5. Validity of Templates
<snip>. However, servers
SHOULD parse the template and enforce the constraints if it is
possible during the processing of template creation, e.g., servers
may validate type constraints for the leaf, including those defined
in the type's "range", "length", and "pattern" properties.
[JGC: I’m a little unclear given the current suggestions on defining templates,
how a system would know
Of any constraint existing unless something like schema-mount or full-embed are
being used here (as the
Current suggestion is a standalone YANG model]
Item 17
6. Interaction with Non-NMDA datastores
TBC
[JGC: I think this should not consider non-NMDA servers. This would make this
NMDA only, but this is not uncommon]
James
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
