YANG Schema Mount
draft-ietf-netmod-schema-mount-12

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.