Hi,
I have read this document and think that is almost ready for
publication. I have five discuss items and a bunch of nits.
Kent // contributor
1. From Section 4:
Routing configuration inside an NI often needs to refer to interfaces (at
least those that are assigned to the NI), which is impossible unless such
a reference can point to a node in the parent schema (interface name).
This seems overstated. Rather it is a result of an earlier design decision.
An alternate solution might have exported the global interfaces into a
config false list inside the mount jail. Was such a solution discussed?
2. Also from Section 4:
For every schema mounted using the "use-schema" method, it is possible
to specify a leaf-list named "parent-reference" that contains zero or more
XPath 1.0 expressions. Each expression is evaluated with the node in the
parent data tree where the mount point is defined as the context node.
If you can nested-mounts, can you also have nested parent-references?
3. Also from Section 4 (same paragraph):
For the purposes of
evaluating XPath expressions within the mounted data tree, the union
of all such nodesets is added to the accessible data tree.
Could this ever result in name collision?
4. Regarding Security Considerations, what about /yangmnt:schema-mounts?
Also, should how NACM interacts with mounted instance data be specified?
5. This document does not say anything about how it relates to NMDA. Clearly
all this is targeted to the conventional datastores, but how is it reflected in
e.g., <operational>? Does anything need to be said here?
What if the mounted schema has deviations in <operational>.
Nits (line-break separated):
Is "other optional choices" being vague on purpose? Should it just call out
features and deviations?
"the YANG library data" seems odd. Maybe "the instance of the YANG Library
module"?
- document, and could be possibly dealt with in a future revision of the YANG
data modeling language
+ document, as it needs to be dealt with as an update to the YANG data modeling
language
- Schema mount applies to the data model
+ Schema mount regards the data model
- This document allows mounting of complete data models only.
+ This document allows mounting of complete modules only.
- may extend this model by defining
+ may extend this solution by defining
In S3, replace "YANG 1.1" with "YANG 1.1 and its continuances"?
- A "container" or "list" node
+ A 'container' or 'list' node
- of "container" and "list" statements.
+ of the "container" and "list" statements.
- Mounted schemas for all mount points
+ The schema for all mount points
- in the "yangmnt:schema-mounts" container.
+ in the top-level "yangmnt:schema-mounts" container defined in the
"ietf-yang-schema-mount" module defined in [Section 8].
The "refers through its key" part is not clear - are you talking about the
mount-point's argument/label?
I don't understand "above those that are defined in the parent schema." -
mostly the word "above" is throwing me…
- If multiple mount points with the same name
+ If multiple mount points with the same label (wasn't it called a "label"
before?)
Regarding "Note, that in this case a mount point", beyond the missing comma, an
example would be very helpful. I don't know if I understand it right.
In the YANG itself, "State data nodes" didn't parse well, "Protocol accessible
nodes" instead?
Regarding the first paragraph in Appendix A, I took me some time to realize
that the rtgwg-device-model included
ietf-network-instance and that those modules define mount-points and where.
Please make this easier for first-time readers.
In A1, is ietf-network-instance missing? - might want to double-check all
In all the examples, but beginning with A2, it might help to show the RESTSCONF
protocol operation that illustrates the result, so that it's clear where in the
data model the particular instance is located. Anything that can be done to
provide more context would be helpful.
For the 2nd half of A2, what happens if there is an "lne-2", will it also get
"eth0"?
- which should include at least
+ which should include at least an instance of ietf-yang-library:modules-state
and ietf-interfaces:interfaces-state, as follows:
Thanks again,
Kent
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
