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

Benjamin Kaduk <> Thu, 11 October 2018 18:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EA450130ECF; Thu, 11 Oct 2018 11:49:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TqjOA0En_zJi; Thu, 11 Oct 2018 11:49:06 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ECEB212008A; Thu, 11 Oct 2018 11:49:05 -0700 (PDT)
X-AuditID: 1209190e-803ff7000000723e-dd-5bbf9b1fa781
Received: from ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 55.CE.29246.02B9FBB5; Thu, 11 Oct 2018 14:49:04 -0400 (EDT)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.13.8/8.9.2) with ESMTP id w9BImwwX024705; Thu, 11 Oct 2018 14:48:59 -0400
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id w9BImqVO013900 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 11 Oct 2018 14:48:55 -0400
Date: Thu, 11 Oct 2018 13:48:52 -0500
From: Benjamin Kaduk <>
To: Martin Bjorklund <>
Message-ID: <>
References: <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOKsWRmVeSWpSXmKPExsUixG6noqswe3+0wbJr2hYTD9hbzPgzkdli 97zL7BYH5rBbdDS/ZbHo7n7GbrG6V81i/sVGVgcOj52z7rJ7LFnyk8njetNVdo8Pm5rZPDb+ WswSwBrFZZOSmpNZllqkb5fAlXHnclDBKfeK13PmMzYwHrfoYuTkkBAwkfh4+wxjFyMXh5DA YiaJFYtbWSGcjYwSk26uZQSpEhK4yiTx8LoqiM0ioCqx9tNTJhCbTUBFoqH7MjOILQIUf7Jz LQtIM7PAOkaJ+12zWEESwgKJEpMmzGUDsXkFjCXWL1oJta6ZUeLVjW3sEAlBiZMzn7CA2MwC WhI3/r0E2sABZEtLLP/HARLmFHCQeP7kLNgyUQFlib19h9gnMArMQtI9C0n3LITuBYzMqxhl U3KrdHMTM3OKU5N1i5MT8/JSi3SN9XIzS/RSU0o3MYJCn1OSbwfjpAbvQ4wCHIxKPLw/Ju6P FmJNLCuuzD3EKMnBpCTKe8QLKMSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEV3/Gvmgh3pTEyqrU onyYlDQHi5I474SWxdFCAumJJanZqakFqUUwWRkODiUJ3spZQEMFi1LTUyvSMnNKENJMHJwg w3mAhk8CqeEtLkjMLc5Mh8ifYjTmaHt6fQYzRweIFGLJy89LlRLntQQpFQApzSjNg5sGSl8S 2ftrXjGKAz0nzHtgJlAVDzD1wc17BbSKCWjVqZA9IKtKEhFSUg2MSvO4OcsW3Pi6vWvW3Vvf HjV8LYlxXx97zetcctalPw6TJmzg+ZoRtItnwco7CRu/CavPjOnV7ufL25Q7+fBpk1B2de5m w5KXkiYFPz7Mrzr1+m5we4tgjQNTjmXU1GOR++4ktpqJbLh2d2H4l/uOtlyin/R5a/VtJY90 p85s15ttlbVyXoO+EktxRqKhFnNRcSIAr3FMjToDAAA=
Archived-At: <>
Subject: Re: [netmod] Benjamin Kaduk's No Objection on draft-ietf-netmod-schema-mount-11: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Oct 2018 18:49:09 -0000

On Wed, Oct 10, 2018 at 03:35:28PM +0200, Martin Bjorklund wrote:
> Hi,
> Benjamin Kaduk <> 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
> > for more information about IESG DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> >
> > 
> > 
> > 
> > ----------------------------------------------------------------------
> > ----------------------------------------------------------------------
> > 
> > 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.


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

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?

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


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