Re: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements

"Alexander Clemm (alex)" <alex@cisco.com> Fri, 08 April 2016 19:02 UTC

Return-Path: <alex@cisco.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 5BAFE12D0E0 for <netmod@ietfa.amsl.com>; Fri, 8 Apr 2016 12:02:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level:
X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 MA93Pd2Tz7aO for <netmod@ietfa.amsl.com>; Fri, 8 Apr 2016 12:02:30 -0700 (PDT)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A5A512D0F3 for <netmod@ietf.org>; Fri, 8 Apr 2016 12:02:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3106; q=dns/txt; s=iport; t=1460142143; x=1461351743; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vRmDSE0pvG2+v8MCsxj3rXpXQTcnwM3wymtb92CwU+E=; b=WAE/T69xdE8f0IetCx79TeTESzTsUD345xikNZRqZEexEsFj433kUkWe dBr2tTQKMSg3vbEhPtwDwEW87O0BLvZlLVUqN7s3PCrHmtK2ojTlsphmw ONAOdIoBU8qLlUS+xOm0EKct+o36d0g3sYKaTW4/fxrq/Rmzo52YL5Psd s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ABAgAG/wdX/40NJK1SBwODN1N9Bro/AQ2Bcx2FcAKBMzgUAQEBAQEBAWUnhEEBAQEDATo/BQcCAgIBCBABBAEBAR4QGxcdCAIEAQ0FCIgXCMBdAQEBAQEBAQEBAQEBAQEBAQEBAQEBFQSKaIQVSyaFDwWYBAGOBIFuh3WFMY8kAR4BAUKDZ2yIOwF9AQEB
X-IronPort-AV: E=Sophos;i="5.24,454,1454976000"; d="scan'208";a="89436316"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Apr 2016 19:02:22 +0000
Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u38J2Mxd018998 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Apr 2016 19:02:22 GMT
Received: from xch-rtp-001.cisco.com (64.101.220.141) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 8 Apr 2016 15:02:21 -0400
Received: from xch-rtp-001.cisco.com ([64.101.220.141]) by XCH-RTP-001.cisco.com ([64.101.220.141]) with mapi id 15.00.1104.009; Fri, 8 Apr 2016 15:02:21 -0400
From: "Alexander Clemm (alex)" <alex@cisco.com>
To: "Eric Voit (evoit)" <evoit@cisco.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Thread-Topic: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements
Thread-Index: AQHRjx7tOw12H05yWU25RG3JKFE7/J9/nzSAgABNhwCAAG5NgIAAFYTA
Date: Fri, 08 Apr 2016 19:02:20 +0000
Message-ID: <f9d6744dbb994d9a99025ecdb95cb02f@XCH-RTP-001.cisco.com>
References: <51F6361D-5F32-449F-80D6-26A4B3569DC1@juniper.net> <20160405.113822.1614298419822308565.mbj@tail-f.com> <a56bf1df63ef47e7a7d96ba78146703e@XCH-RTP-013.cisco.com> <20160408065748.GA66159@elstar.local> <c41c4265f9654e4984b977e1ed4fa9a2@XCH-RTP-013.cisco.com>
In-Reply-To: <c41c4265f9654e4984b977e1ed4fa9a2@XCH-RTP-013.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [128.107.147.91]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/PlJEVBjglBSCsXAfiylawpTwG6Q>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 08 Apr 2016 19:02:32 -0000

Hello Juergen

to your question: 
"> So why do we need 'local data mount' (aka 'alias mount')? Which 
> problem does it solve that 'peer mounting' localhost does not solve?"

Yes, you could apply peer mounting to a local host as a special case.  Certainly there is nothing that should prevent that.  However, the distinction is still relevant.  For one, in the peer mounting case, the remote host is considered the authoritative owner, the mounting host is _not_ the authoritative owner.  In alias mount, since it is the same owner, it has authority.  

The fact that in peer mount the local host has no authority means that the use cases primarily targeted involve cases that require visibility of data and support for a data retrieval, read-only view.  One of the concerns that had been raised earlier were the ramifications that transactional behavior and locking etc would have in a distributed scenario.  Given that alias-mount is local, things are simplified and use cases that go beyond pure providing visibility easier to support.  So, alias mounting may be an important special case of peer mounting, but also a simple case.  This is a fact that we would like to leverage.  

In practical terms, alias mount and peer mount can look very similar.  Peer mount involves an additional parameter (to identify the target system), with corresponding additional mountpoint management ramifications.  So, peer mount can in that sense build on top of, or extend, alias mount.  

--- Alex

-----Original Message-----
From: Eric Voit (evoit) 
Sent: Friday, April 08, 2016 6:33 AM
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Cc: Martin Bjorklund <mbj@tail-f.com>; kwatsen@juniper.net; Alexander Clemm (alex) <alex@cisco.com>; netmod@ietf.org
Subject: RE: [netmod] kw comments on draft-voit-netmod-yang-mount-requirements

> From: Juergen Schoenwaelder, April 08, 2016 2:58 AM
> 
> On Fri, Apr 08, 2016 at 02:20:19AM +0000, Eric Voit (evoit) wrote:
> > My thinking matches more closely to what Kent lays out above:
> >
> > schema-mount
> > data-mount
> > remote data mount   (a.k.a. peer mount)
> > local data mount        (a.k.a. alias mount)
> >
> > The value in the term "yang mount" is that it provides a conceptual 
> > umbrella to
> ensure a cohesive syntax across the four valid permutations of the 
> above.  The term itself was never intended to be implementable.
> >
> 
> So why do we need 'local data mount' (aka 'alias mount')? Which 
> problem does it solve that 'peer mounting' localhost does not solve?

To me it comes down to ease of use for the developer. If the system only allows mounting localhost, why require that parameter in the syntax?   That parameter shouldn't even be available/visible for entry. 

Eric

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