Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)

Martin Bjorklund <mbj@tail-f.com> Wed, 10 October 2018 12:33 UTC

Return-Path: <mbj@tail-f.com>
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 86CC9130EF6; Wed, 10 Oct 2018 05:33:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 jVAq534HvQ8x; Wed, 10 Oct 2018 05:33:04 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF6C130EEB; Wed, 10 Oct 2018 05:33:01 -0700 (PDT)
Received: from localhost (unknown [173.38.220.61]) by mail.tail-f.com (Postfix) with ESMTPSA id 1A60B1B039FA; Wed, 10 Oct 2018 14:32:58 +0200 (CEST)
Date: Wed, 10 Oct 2018 14:32:57 +0200
Message-Id: <20181010.143257.2013021260712498361.mbj@tail-f.com>
To: ekr@rtfm.com
Cc: iesg@ietf.org, netmod-chairs@ietf.org, netmod@ietf.org, joelja@gmail.com, draft-ietf-netmod-schema-mount@ietf.org, kwatsen@juniper.net, lberger@labn.net
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <153914105176.10625.9957580509164313779.idtracker@ietfa.amsl.com>
References: <153914105176.10625.9957580509164313779.idtracker@ietfa.amsl.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/cnCOlUzfCRT9E4Ow5sAGy-mKhBU>
Subject: Re: [netmod] Eric Rescorla's Discuss on draft-ietf-netmod-schema-mount-11: (with DISCUSS)
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: Wed, 10 Oct 2018 12:33:07 -0000

Hi,

Eric Rescorla <ekr@rtfm.com> wrote:
> Eric Rescorla has entered the following ballot position for
> draft-ietf-netmod-schema-mount-11: Discuss
> 
> 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/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3506
> 
> 
> 
> DETAIL
> S 4.
> >   
> >      It is worth emphasizing that the nodes specified in
> >      "parent-reference" leaf-list are available in the mounted schema only
> >      for XPath evaluations.  In particular, they cannot be accessed there
> >      via network management protocols such as NETCONF [RFC6241] or
> >      RESTCONF [RFC8040].
> 
> What are the security implications of this XPath reference outside the
> mount jail? Specifically, how does it interact with the access control
> for the enclosing module.

There is no such interaction, since access control comes into play
when some external entity accesses the data through some management
protocol, and the nodes from the "parent-reference" expressions cannot
be accessed via management protocols.

The last sentence of the quoted paragraph was supposed to make this
clear, but it seems we might need some additional explanation?



/martin