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

[Benjamin Kaduk <[e-mail]>]

On Mon, Oct 15, 2018 at 09:33:09AM +0200, Martin Bjorklund wrote:
> 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.

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

-Benjamin