On Mon, Oct 15, 2018 at 09:33:09AM +0200, Martin Bjorklund wrote: > Hi, > > Benjamin Kaduk <[email protected]> wrote: > > On Wed, Oct 10, 2018 at 03:35:28PM +0200, Martin Bjorklund wrote: > > > Hi, > > > > > > Benjamin Kaduk <[email protected]> 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 _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
