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:
> On Wed, Oct 10, 2018 at 03:35:28PM +0200, Martin Bjorklund wrote:
> > 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.
> 
> I guess this addresses my concern; thanks.
> 
> > > 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.
> 
> Okay.
> 
> > > 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.
> 
> 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.

Yes I think this is a correct description.

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

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.

> > >, 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.
> 
> 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.
> 
> > 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.
> 
> Combined with the new paragraph in the security considerations, I think
> this would account for everything; thanks.
> 
> > > 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. 
> 
> "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).

Ok.



/martin



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