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

[Martin Bjorklund <[e-mail]>]

Hi,

Benjamin Kaduk <[e-mail]> wrote:
> 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.

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

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.

> 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?

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

> 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", [...]"""

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.

> 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

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
> 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?

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.

> Section 9
> 
> Should the top-level module description be using the RFC 8174 boilerplate
> instead of thet 2119 boilerplate?

Yes, I will fix.

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

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

Yes, see my proposed text above.


/martin