Re: [netmod] explicit mount

"Alexander Clemm (alex)" <alex@cisco.com> Wed, 24 February 2016 21:04 UTC

Return-Path: <alex@cisco.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4081B3ED9 for <netmod@ietfa.amsl.com>; Wed, 24 Feb 2016 13:04:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.507
X-Spam-Level:
X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 FnjTTJJjdFBj for <netmod@ietfa.amsl.com>; Wed, 24 Feb 2016 13:04:02 -0800 (PST)
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 726CF1B3E58 for <netmod@ietf.org>; Wed, 24 Feb 2016 13:04:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2890; q=dns/txt; s=iport; t=1456347842; x=1457557442; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=LSKwaKnioWJyaGe03g5IHAmv5yygcirhhSMJtaAWUTc=; b=NFzbkarLwfxK9icNvg2Z5n7gd9jEjOYSMKFessUnapsUyRUE0e60iBqn DHU5Yt7WNSZJJ1DfZTEajWJ6lJ6xeS6QqkjOFjYd135NWWCMC5D+FiRIM ajAXF9Nu1amw9TiZ2DMcmiMDTZld2s0l5DOUyN4jWQhNFinoWXNkUGA+g 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ARAgANGs5W/5tdJa1bA4M6Um0GumcBDYFmFwqFI0oCgUk4FAEBAQEBAQFkJ4RBAQEBBAEBATc0CwwCAgIBCA4CAQQBAQEeCQcbDAsUCQgCBAENBQiIFw69VgEBAQEBAQEBAQEBAQEBAQEBAQEBARUEikiEViaDcwWXBwGIRYUSgWWHaYUtjkgBHgEBQoNkaoZjfQEBAQ
X-IronPort-AV: E=Sophos;i="5.22,494,1449532800"; d="scan'208";a="74407649"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Feb 2016 21:04:01 +0000
Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1OL41uG000985 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Feb 2016 21:04:01 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 24 Feb 2016 15:04:00 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Wed, 24 Feb 2016 15:04:00 -0600
From: "Alexander Clemm (alex)" <alex@cisco.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, Martin Bjorklund <mbj@tail-f.com>
Thread-Topic: [netmod] explicit mount
Thread-Index: AQHRbkwiGi5XXHW8ekmYwsZI6JLn0p87w3yA///smqA=
Date: Wed, 24 Feb 2016 21:04:00 +0000
Message-ID: <1da16bd668354ca6b874ef76012c812a@XCH-RCD-001.cisco.com>
References: <20160223.160806.696185201696745163.mbj@tail-f.com> <20160224160933.GA17873@elstar.local>
In-Reply-To: <20160224160933.GA17873@elstar.local>
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: [10.154.163.28]
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/PIu86QbpU8YsdUOcRMQ1uX0PzwI>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] explicit mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.15
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, 24 Feb 2016 21:04:04 -0000

Juergen, I think you are correct.  Also alias-mount and peer-mount (not just schema-mount) specify mountpoints in the schema.  They are not about mounting arbitrary data in arbitrary places, but defining a model with mountpoints declared.  
--- Alex

-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, February 24, 2016 8:10 AM
To: Martin Bjorklund <mbj@tail-f.com>
Cc: netmod@ietf.org
Subject: Re: [netmod] explicit mount

On Tue, Feb 23, 2016 at 04:08:06PM +0100, Martin Bjorklund wrote:
> Hi,
> 
> In yesterday's meeting, Lou (I think?) mentioned a use case for mount 
> that is not documented in draft-rtgyangdt-rtgwg-device-model; the need 
> for being able to specify modules to mount directly in the schema.
> Something like this:
> 
>   container root {
>     ymnt:mount-point "lne" {
>       ymnt:mount-module "ietf-interfaces";
>     }
>   }
> 
> It would be useful if the use case for this could be described in more 
> details.  Is it a requirement to be able to specify this in the 
> schema, or could it be done (as Chris mentioned) in the RFC text?
> 
> The reason I ask is that it is probably not as simple as the example 
> above.  First, you probably need to specify a revision of the module 
> to be mounted.  Or a min-revision.  Then probably a set of features 
> that must be enabled.  And so on.  It turns out that there is already 
> a proposal for specifying such a "conformance profile" - YANG Packages 
> (see draft-bierman-netmod-yang-package).  Maybe it would be better to 
> re-use packages?

We are talking schema mount, right? So why would features matter? Yes, there might be interesting versioning issues but how are they different from an augmentation putting data under root? I naively considered such a 'static schema defined mount' the simplest case, then the 'augmented schema defined mount' naturally following from the way augmentations work:

  augment /some:root {
    ymnt:mount-point "lne" {
      ymnt:mount-module "ietf-interfaces";
    }
  }

The 'dynamic runtime defined mounts' may be most flexible but then they require me to read runtime data in order to adapt to the schema structure, which has its own set of complexities. Yes, the versioning issues go away since I have to adapt to each implementation dynamically but there is surely a cost involved with that as well.

Am I missing something?

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

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod