[netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-netmod-schema-mount-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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".