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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 09 Oct 2018 09:36:43 -0700

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Oct 2018 15:35:28 +0200 (CEST)

Hi,

> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/

The intention was that this is covered in Section 7, Interaction with
the Network Configuration Access Control Model (NACM).

But it is probably a good idea to explicitly mention this in the
Security Considerations section as well (together with your last point
below).  So maybe add a paragraph at the end of Section 11:

  It is important to take the security considerations for all nodes in
  the mounted schemas into account, and control access to these nodes
  by using the mechanism described in Section 7.
  
> (Is this related to "inline" vs. "shared-schema"?)

No, this document intentionally doesn't assume anything about the
source of the instance data (as explained in section 1).  So the
answer is that they just use the same schema.

> suppositions about complexity?

I agree with you that multiple levels of mounting probably can be
complex.  But there is nothing in the design of schema mount that
prohibits this.  In fact, it "falls out for free" from the design.

A 2-level example is a physical device with LNEs
(draft-ietf-rtgwg-lne-model) which has NIs
(draft-ietf-rtgwg-ni-model).

> """For every mount point under "shared-schema", [...]"""

We use the wording "in the 'shared-schema' case" in a couple of
places.  I don't think "mount point under 'shared-schema'" is
correct.

> Can we get a reference added for XPath?

Sure, I will add this.

> constructs an XPath expression to refer to the parent-reference
> nodes

It's rather the other way around.  If a node in the mounted schema has
an XPath expression that refers to a node that is not part of the
jailed mounted schema, that node can be brought in by the
parent-reference expressions.   An example of this is given in A.3
where an "outgoing-interface" (which is a reference to
/if:interfaces/if:interface/if:name) works thanks to the
parent-reference.

>, but

Mounted nodes are no different that normal nodes in this regard; i.e.,
if NACM is configured to provide read access by default, this read
access is applied to all nodes, mounted or not.

Maybe we should do:

OLD:

   If NACM [RFC8341] is implemented on a server, it can be used to
   control access

NEW:

   If NACM [RFC8341] is implemented on a server, it is used to
   control access 

to emphasize that no additional steps need to be taken by the
administrator if NACM is used in the first place.

> instead of thet 2119 boilerplate?

Yes, I will fix.

> the description for the 'inline' and 'shared-schema' containers (i.e., in

Section 3.3 says:

   The mounted schema is determined at run time: every instance of the
   mount point that exists in the operational state MUST contain a copy
   of YANG library data that defines the mounted schema exactly as for a
   top-level schema. 

> considerations for mounted schemas continue to apply to the nodes in the

Yes, see my proposed text above.

/martin

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 11 Oct 2018 13:48:52 -0500

>   by using the mechanism described in Section 7.

I guess this addresses my concern; thanks.

> places.  I don't think "mount point under 'shared-schema'" is

Okay.

> /if:interfaces/if:interface/if:name) works thanks to the

Sorry for being dense here.  Just to check -- the idea is that I have
an existing schema that has references to external nodes, and those
external references are represented as "absolute paths" from the root node.
When I mount that existing schema, because of the namespace jailing, it
goes looking for the external reference from that path but starting at the
mountpoint instead of the real root, and the referred-to node is only
present in the mounted hierarchy if the external module in question is also
part of the same mounted schema.  What the parent-reference is doing is
allowing this absolute-path external node reference to escape the mounted
hierarchy and find the corresponding nodes from the top-level.
So there's no new "construction" of XPath expressions; it's just allowing
existing references to continue to work.

Do we need to specify a search order when there are multiple levels of
hierarchical mounts and a referred-to external node is present at both the
top-level and an intermediate mount level?

> access is applied to all nodes, mounted or not.

I think I'm considering a somewhat different case, with read-write access
by default but certain hierarchies restricted to read-only.  If those
hierarchies are then mounted in a subtree, the read-only restriction could
be absent in some cases.

> administrator if NACM is used in the first place.

Combined with the new paragraph in the security considerations, I think
this would account for everything; thanks.

>    of YANG library data that defines the mounted schema exactly as for a

"contain a copy of YANG library data" only mostly translates to "mount
ietf-yang-library".  It might be beneficial to be more explicit and/or cite
rfc7895bis here (but this is a non-blocking comment, so do what you think
is best).

-Benjamin

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 15 Oct 2018 09:33:09 +0200 (CEST)

Hi,

> existing references to continue to work.

Yes I think this is a correct description.

> top-level and an intermediate mount level?

Regarding parent refs, section 4 says:

   For the purposes of evaluating XPath
   expressions within the mounted data tree, the union of all such
   nodesets [from parent references] is added to the accessible data tree.

For example, if we have:

  A implements ietf-schema-mount and mounts B with some parent-refs Pb
  B implements ietf-schema-mount and mounts C with some parent-refs Pc

The parent-refs Pc are XPath expressions in B.  So, applying section
4, it follows that before evaluating Pc, we need to add the result
from evaluating Pb.

And it doesn't really matter if a node is present at both the
top-level and mounted, since the nodes from the parent reference
statement are added to the accessible data tree.  The result can be a
mix of nodes from the parent refs and the mounted tree.

> rfc7895bis here (but this is a non-blocking comment, so do what you think

Ok.

/martin

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 15 Oct 2018 19:07:34 -0500

> mix of nodes from the parent refs and the mounted tree.

Ah, I think I get it now.  Sorry for being so dense.

-Benjamin