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

Benjamin Kaduk <kaduk@mit.edu> Tue, 16 October 2018 00:07 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAE18126CC7; Mon, 15 Oct 2018 17:07:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0zNCtULpxwJ8; Mon, 15 Oct 2018 17:07:45 -0700 (PDT)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8721124C04; Mon, 15 Oct 2018 17:07:44 -0700 (PDT)
X-AuditID: 12074424-4d5ff70000005ce9-4d-5bc52bcdf586
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 88.E5.23785.ECB25CB5; Mon, 15 Oct 2018 20:07:42 -0400 (EDT)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id w9G07dGh030722; Mon, 15 Oct 2018 20:07:40 -0400
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w9G07Yfj027310 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Oct 2018 20:07:36 -0400
Date: Mon, 15 Oct 2018 19:07:34 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: iesg@ietf.org, draft-ietf-netmod-schema-mount@ietf.org, joelja@gmail.com, lberger@labn.net, kwatsen@juniper.net, netmod-chairs@ietf.org, netmod@ietf.org
Message-ID: <20181016000733.GK19309@kduck.kaduk.org>
References: <153910300384.12306.5207245502751636551.idtracker@ietfa.amsl.com> <20181010.153528.100217893480849067.mbj@tail-f.com> <20181011184852.GU3293@kduck.kaduk.org> <20181015.093309.2040803844255950012.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181015.093309.2040803844255950012.mbj@tail-f.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsUixCmqrHtO+2i0wZkeS4uJB+wtZvyZyGyx e95ldosDc9gtOprfslh0dz9jt1jdq2Yx/2IjqwOHx85Zd9k9liz5yeRxvekqu8eHTc1sHht/ LWYJYI3isklJzcksSy3St0vgymg7OYelYLJ9xeGXzewNjJ8Muhg5OSQETCQmvHjH1MXIxSEk sJhJ4mvrDBYIZyOjxMkZa9ggnKtMEktOv2cFaWERUJU4tWIhC4jNJqAi0dB9mRnEFgGKP9m5 FqybWWAdo8T9rllgDcICiRKTJsxlA7F5gfZ9nt4Pte8Jo8SrvmZmiISgxMmZT8CmMgtoSdz4 9xKoiAPIlpZY/o8DJMwp4Chx4/U+sJmiAsoSe/sOsU9gFJiFpHsWku5ZCN0LGJlXMcqm5Fbp 5iZm5hSnJusWJyfm5aUW6Zrr5WaW6KWmlG5iBIU/u4vKDsbuHu9DjAIcjEo8vD+uH4kWYk0s K67MPcQoycGkJMqrugcoxJeUn1KZkVicEV9UmpNafIhRgoNZSYQ34TZQjjclsbIqtSgfJiXN waIkzjuxZXG0kEB6YklqdmpqQWoRTFaGg0NJgnee1tFoIcGi1PTUirTMnBKENBMHJ8hwHqDh t0FqeIsLEnOLM9Mh8qcYjTnanl6fwczRASKFWPLy81KlxHkfgZQKgJRmlObBTQOlMIns/TWv GMWBnhPmPQJSxQNMf3DzXgGtYgJa5W4L8kdxSSJCSqqB0Vhm9pmqBRrh140fplT8N595qvmf sYdOc43g/+b7f6NfmN+9tvhSVNDn/txTTW+TU7QYCldYJFXW/37N97Gt8+x8UaXrq/TPeMcv tlddvcggYa1LiYBke71wW7bRAtGN9Y/SlV6a7pzF+N5uQwXbrId7dr1OKvFfk1F+d6q83vT+ tx5H7/CmK7EUZyQaajEXFScCAE70AwQ8AwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/LMI91jOqbYtcoY5AxU5yWp9hgXg>
Subject: Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Oct 2018 00:07:48 -0000

On Mon, Oct 15, 2018 at 09:33:09AM +0200, Martin Bjorklund wrote:
> Hi,
> 
> Benjamin Kaduk <kaduk@mit.edu> wrote:
> > On Wed, Oct 10, 2018 at 03:35:28PM +0200, Martin Bjorklund wrote:
> > > Hi,
> > > 
> > > Benjamin Kaduk <kaduk@mit.edu> 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