Ballot for draft-ietf-netmod-schema-mount
Yes
No Objection
Note: This ballot was opened for revision 11 and is now closed.
I really like that you've provided this capability. It might be that I've spent too much time doing Unix, but I wonder if "Yang Schema Mount Point" would be a clearer title?
Thanks to all contributors to this document for the work they invested. I have a handful of relatively minor comments. --------------------------------------------------------------------------- ID Nits reports: ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) --------------------------------------------------------------------------- §1: > Server implementors are only required to specify > all YANG modules comprising the data model... Although sources differ on the use of "comprising" in this fashion, RFC 7322 §1 defers matters of style to the Chicago Manual of Style, which specifies the following: comprise; compose. Use these with care. To comprise is “to be made up of, to include” {the whole comprises the parts}. To compose is “to make up, to form the substance of something” {the parts compose the whole}. The phrase “comprised of,” though increasingly common, is poor usage. Instead, use “composed of” or “consisting of.” By my understanding, and using the definitions above, the data model comprises the YANG modules, and the YANG modules compose the data model. I would suggest the following revision: Server implementors are only required to specify all YANG modules included in the data model... --------------------------------------------------------------------------- §2.1: > Tree diagrams used in this document follow the notation defined in > [RFC8340] I think this means that RFC 8340 needs to be normative rather than informative. --------------------------------------------------------------------------- §2.2: > | yanglib | ietf-yang-library | [RFC7895], | > | | | [I-D.ietf-netconf-rfc7895bis] | I think you want to remove RFC 7985 from this list of references. According to draft-ietf-netconf-rfc7895bis: This document takes over this registration entry made by RFC 7895. This seems to indicate that, upon publication of draft-ietf-netconf-rfc7895bis, the YANG module name "ietf-yang-library" would no longer be associated with RFC 7895 at all. I don't have a strong opinion about how this discrepancy is resolved, but I do strongly believe that this document and draft-ietf-netconf-rfc7895bis need to be consistent with each other. --------------------------------------------------------------------------- Page 13: > The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL > NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and > 'OPTIONAL' in the module text are to be interpreted as described > in RFC 2119 (https://tools.ietf.org/html/rfc2119). It seems that this language could benefit from RFC 8174's clarified boilerplate.
Substantive: §3.3, 4th paragraph: The MUST NOT seems like a statement of fact -- if no schema is mounted, it doesn't seem possible for it to include anything. §5, last paragraph: Why is the SHOULD NOT not a MUST NOT? Would it ever make sense to violate this? §9: The model includes RFC 2119 boilerplate, but the document itself uses the newer RFC 8174 boilerplate. Is it normal to include the normative keyword boilerplate in the model? If so, it should probably match that of the containing document. Editorial: §1, list item 2: "... and is stable as YANG library information of the server." Assuming you mean specific YANG library information rather than the general concept, there is a missing article before "YANG". (This pattern repeats a few time throughout the document.)
Whenever we introduce a new namespace "sub-hierarchy" there is some level of risk about surpirses with respect to the security properties of the combined system. I appreciate that the mounted schemas are "jailed" into their own subtree except for the specific exceptions for XPath access, which helps a lot. But there may still be potential for surprise with respect to, e.g., access control on mounted schemas, if an administrator previously assumed that such controls would only be needed at the top-level. The document itself doesn't give me a great picture of to what extent these risks and the possible consequences of the new nested structure have been considered; I'd be happy to hear if they've been thought about a lot already and the conclusion was that the situation is so boring that nothing needs to be mentioned in the document. Section 3.3 If multiple mount points with the same name are defined in the same module - either directly or because the mount point is defined in a grouping and the grouping is used multiple times - then the corresponding "mount-point" entry applies equally to all such mount points. Does this mean that the multiple mount points must serve the same data/contents, or just that they must use the same schema? (Is this related to "inline" vs. "shared-schema"?) Section 3.4 So this means that there can be multiple ietf-yang-schema-mount:schema-mounts:mount-point nodes at different locations in the hierarchy? When I was first reading the document, the design seemed fairly clean with just a single list of mount-points at the "top-level" that tracks everything, but this kind of recursion seems like it would make implementation potentially quite complex. What kind of implementation experience do we have that can replace my half-informed suppositions about complexity? Section 4 Therefore, schema mount also allows for such references. For every mount point in the "shared-schema" case, it is possible to specify a leaf-list named "parent-reference" that contains zero or more XPath 1.0 expressions. [...] editorial: """the "shared-schema" case""" reads oddly to me; it might be clearer to refer to schemas mounted using "shared-schema" instead. As in, """For every mount point under "shared-schema", [...]""" Can we get a reference added for XPath? It's still a little unclear to me exactly how a node in the mounted tree constructs an XPath expression to refer to the parent-reference nodes, but I did not read very far down the reference chain and maybe this is going to be clear to a practitioner without any more text in the document. Basically, do I need to know where I am mounted in order to construct references to nodes in the parent? Section 7 NACM "can be used" to control access to mounted nodes. Is there a risk that administrators will be "unpleasantly surprised" by mounted nodes by default not receiving access control, in cases when access control is already configured at the top level? Section 9 Should the top-level module description be using the RFC 8174 boilerplate instead of thet 2119 boilerplate? Should the requirement for servers that mount any schema to also mount ietf-yang-library under the mountpoint be mentioned somewhere other than the description for the 'inline' and 'shared-schema' containers (i.e., in the discussion text)? Section 11 We should probably also have some bland statement about how "the security considerations for mounted schemas continue to apply to the nodes in the mounted tree".
Thank you for addressing my DISCUSS
Section 3.3. I think it would be nice to have some examples to illustrate the differences between inline and shared-schema and some guidance to pick between the two.