Re: [netmod] js review of draft-ietf-netmod-schema-mount-09

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Tue, 10 April 2018 14:34 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 D4ADC12D7EA for <netmod@ietfa.amsl.com>; Tue, 10 Apr 2018 07:34:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KLtE_4988Mn9 for <netmod@ietfa.amsl.com>; Tue, 10 Apr 2018 07:34:19 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DD6E129C5D for <netmod@ietf.org>; Tue, 10 Apr 2018 07:34:19 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 0CE26E78; Tue, 10 Apr 2018 16:34:18 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id wSQlRuK6m1gu; Tue, 10 Apr 2018 16:34:16 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 10 Apr 2018 16:34:17 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id A818520035; Tue, 10 Apr 2018 16:34:17 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WDVf1gE69yzB; Tue, 10 Apr 2018 16:34:17 +0200 (CEST)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15FC120031; Tue, 10 Apr 2018 16:34:17 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C724E42AE9D0; Tue, 10 Apr 2018 16:34:16 +0200 (CEST)
Date: Tue, 10 Apr 2018 16:34:16 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Martin Bjorklund <mbj@tail-f.com>
Cc: netmod@ietf.org
Message-ID: <20180410143416.4y5wofkhr67wxxo4@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Martin Bjorklund <mbj@tail-f.com>, netmod@ietf.org
References: <20180406122406.wdba43mr3bxsnyce@elstar.local> <20180406.152710.818971844955208858.mbj@tail-f.com> <20180410124643.mnywxuxrnyaahttv@elstar.local> <20180410.161546.1818555188781690245.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180410.161546.1818555188781690245.mbj@tail-f.com>
User-Agent: NeoMutt/20171215
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/zE4NN_aN8R-x6368BE94Sd3ijqg>
Subject: Re: [netmod] js review of draft-ietf-netmod-schema-mount-09
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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, 10 Apr 2018 14:34:22 -0000

On Tue, Apr 10, 2018 at 04:15:46PM +0200, Martin Bjorklund wrote:
> > 
> > Yes, the checksum (which I think is actually a version identifier).
> > Anyway, the question is whether a client can draw any conclusions from
> > seeing YANG library instances with the same checksum and whether a
> > client must simpy treat this as a clash. If multiple mounted schemas
> > have the same YANG library, then reading one of them would be
> > sufficient. The question is whether the checksum is a tool for
> > deciding whether a YANG library is similar to an already known one or
> > whether a client must not make this assumption, i.e., a checksum is
> > always scoped to the YANG library instance and you have to read them
> > all.
> 
> Options:
> 
> 1.  Be silent about the YL checksum in this document.
> 
> 2.  State that the server MUST ensure that if two mounted YL
>     instances have the same checksum, then the YL contents MUST be
>     the same.
> 
> 3.  State that just b/c the YL checksum is the same in two mounted
>     instances, it does not mean that the YL contents is the same.
> 
> 4.  State that for use-schema, the YL contents and YL checksum MUST be
>     the samem but for inline, equal YL checksum is no guarantee for
>     equal YL contents.
> 
> From a client perspective, 2 is preferrable.  It is probably not
> difficult to implement on a server either; except in the peer mount
> case where the data is just read from some device.

The more I think about it, it seems option 4. is the right thing to
do.
 
> > > Yes you can mount NACM.  To keep things simple, I think the inner NACM
> > > should not affect the access control done in the parent.  Consider the
> > > use cases for this.  In a NI situation, it doesn't make much sense to
> > > mount NACM.  In an LNE (or in a "peer mount") situation, it may make
> > > sense to mount NACM if the LNE (or device) supports it.  In this case,
> > > if I try to access any mounted data in the parent, access is
> > > controlled by the parent.  If I have access, the parent may send a
> > > request over to the mounted device to read/write the data.  That
> > > device will use its local copy of NACM to control access, or some
> > > other mechanism.
> > 
> > In this scenarios, if the parent NACM grants access but the inner NACM
> > does not grant access, I assume I will not have access, right? So how
> > does this line up with "the inner NACM should not affect the access
> > control done in the parent"? Frankly, this is all a bit hypothetical
> > since we have no standards for doing peer mounts - and clearly not for
> > writable peer mounts. So probably the truth is that it is undefined
> > whether the inner NACM applies or not. Hm.
> 
> But maybe this is something that needs to be handled when we define
> peer mount?  The question is if we need to add any text to this
> document?
>

I think it is sufficient to say that the server's NACM rules apply to
mounted data. (In the peer mount case, it should not matter whether
the peer's NACM is mounted or not, the peer's NACM applies anyway when
the peer is accessed - but it may be accessed a username identity that
is different from the username identity used to access the mounted
data.)

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>