Re: [netmod] Differentiating the types of Mount

STUART VENTERS <stuart.venters@adtran.com> Wed, 16 March 2016 16:58 UTC

Return-Path: <stuart.venters@adtran.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 2A98C12D569 for <netmod@ietfa.amsl.com>; Wed, 16 Mar 2016 09:58:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 m2jtw9-8zg4A for <netmod@ietfa.amsl.com>; Wed, 16 Mar 2016 09:58:26 -0700 (PDT)
Received: from s12p02o143.mxlogic.net (s12p02o143.mxlogic.net [208.65.145.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960D812D518 for <netmod@ietf.org>; Wed, 16 Mar 2016 09:58:26 -0700 (PDT)
Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by s12p02o143.mxlogic.net(mxl_mta-8.5.0-8) with ESMTP id 2b099e65.7ff35a1fc700.61837.00-584.183675.s12p02o143.mxlogic.net (envelope-from <stuart.venters@adtran.com>); Wed, 16 Mar 2016 10:58:26 -0600 (MDT)
X-MXL-Hash: 56e990b235069f52-15db05b2deac6de7547a3a939e417478e35c6eea
Received: from unknown [76.164.174.83] (EHLO ex-hc2.corp.adtran.com) by s12p02o143.mxlogic.net(mxl_mta-8.5.0-8) over TLS secured channel with ESMTP id 9a099e65.0.61651.00-122.183187.s12p02o143.mxlogic.net (envelope-from <stuart.venters@adtran.com>); Wed, 16 Mar 2016 10:58:24 -0600 (MDT)
X-MXL-Hash: 56e990b0685c5067-51f74bab6b1b79352b6c4dccd97e0a39e0664ae9
Received: from ex-mb1.corp.adtran.com ([fe80::51a3:972d:5f16:9952]) by ex-hc2.corp.adtran.com ([fe80::a019:449b:3f62:28e5%10]) with mapi id 14.03.0266.001; Wed, 16 Mar 2016 11:58:12 -0500
From: STUART VENTERS <stuart.venters@adtran.com>
To: 'Juergen Schoenwaelder' <j.schoenwaelder@jacobs-university.de>, "Eric Voit (evoit)" <evoit@cisco.com>
Thread-Topic: [netmod] Differentiating the types of Mount
Thread-Index: AdF/OD2NJ3Cq4cCSQLyujReGzdHIoQAZ+8KAAACU0PA=
Date: Wed, 16 Mar 2016 16:58:11 +0000
Message-ID: <1220E2C537595D439C5D026E83751866E7B4C101@ex-mb1.corp.adtran.com>
References: <84d0c3c5331c4b5e9d0883f890a87a40@XCH-RTP-013.cisco.com> <20160316112329.GB39598@elstar.local>
In-Reply-To: <20160316112329.GB39598@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.22.118.25]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-AnalysisOut: [v=2.1 cv=POIJjKeC c=1 sm=1 tr=0 a=5zDNsY1we+1mvVcp/5+1jQ==]
X-AnalysisOut: [:117 a=5zDNsY1we+1mvVcp/5+1jQ==:17 a=0eaKXOXVzoQA:10 a=kj9]
X-AnalysisOut: [zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=7OsogOcEt9IA:10 a=48vgC7m]
X-AnalysisOut: [UAAAA:8 a=j3Z76cjpAAAA:8 a=OCM4CDYJNLJQ-D5Haa0A:9 a=5dU66M]
X-AnalysisOut: [r8LEQ73UBn:21 a=-mkwRyczlgZDIEss:21 a=CjuIK1q_8ugA:10 a=Fv]
X-AnalysisOut: [gKqOQ44qUA:10 a=JrSEOxZJtCQA:10 a=-FEs8UIgK8oA:10 a=NWVoK9]
X-AnalysisOut: [1CQyQA:10]
X-Spam: [F=0.5000000000; CM=0.500; MH=0.500(2016031611); S=0.498(2015072901)]
X-MAIL-FROM: <stuart.venters@adtran.com>
X-SOURCE-IP: [76.164.174.83]
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/cG1pupsVp_Ja9UPPkevYfEvVOpw>
Cc: "Martin Bjorklund (mbjorklu)" <mbjorklu@cisco.com>, "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Differentiating the types of Mount
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: Wed, 16 Mar 2016 16:58:29 -0000

Defining a schema-tree seems Yang's strong suite.
I'm not sure if the suite extends to defining what goes into a data-tree governed by the schema-tree.

Perhaps:

YANG Mount
 ----------------
 Definition: An abstracted term for a YANG mechanism that grafts a sibling schema-tree as a subtree of a parent schema-tree.
 Purpose: Provides flexibility by enabling the growth of YANG models via an explicit reference to other YANG models defined elsewhere.

Given the ability to specify a combined schema-tree, maybe something at the protocol level could specify what data to use to populate the grafted tree.
This could provide a place to specify details like who has ownership of the data, if it is RW, etc.

NETCONF Mount
------------------
Definition: An abstracted term for a NETCONF mechanism to construct a combined data-tree according to a schema defined with YANG mount.
Purpose: ...



-----Original Message-----
From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder
Sent: Wednesday, March 16, 2016 6:23 AM
To: Eric Voit (evoit)
Cc: netmod@ietf.org; Martin Bjorklund (mbjorklu)
Subject: Re: [netmod] Differentiating the types of Mount

On Wed, Mar 16, 2016 at 03:59:50AM +0000, Eric Voit (evoit) wrote:
> To help differentiate between concepts and drafts, below are strawman definitions for the various types of Mount which we have been discussing over the last year in Netmod.   Thoughts/suggestions?
> 
> YANG Mount
> ----------------
> Definition: An abstracted term for a mechanism that a parent YANG model can use to link in YANG information defined or located elsewhere.  
> Purpose: Provides model flexibility by enabling the growth of YANG trees via an explicit reference to other YANG information and structures.

Trying to rewrite the definition to be more consistent with existing
terminology:

  The abstract concept of incorporating a YANG-defined data tree (the
  mounted data tree) into a existing YANG-defined data tree (the
  parent data tree).

Well, this is not really correct, perhaps we have to just say 'tree'
instead of 'data tree' since a schema mount (as I understand it) seems to incorporate a schema tree into another schema tree while the other two mounts incorporate a data tree into a data tree. So perhaps the general definition is something like this:

  The abstract concept of incorporating a YANG-defined data tree or
  schema tree (the mounted data or schema tree) into a existing
  YANG-defined data tree or schema tree (the parent data tree).

The schema mount then essentially removes data tree and the other two mounts remove the schema tree from this definition.

Is your alias mount simply a special case of a peer mount where the peer is local? Or is there more to it? In other words, would it be reasonable to think of the terms in this way:

         +-> schema (tree) mount
	 |
mount -> |                        +-> local data tree (alias) mount
         +-> data (tree) mount -> |
                                  +-> remote data tree (peer) mount

/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