Re: [netmod] Y34 - root node

"Eric Voit (evoit)" <evoit@cisco.com> Tue, 25 August 2015 22:51 UTC

Return-Path: <evoit@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 A53431B30EC for <netmod@ietfa.amsl.com>; Tue, 25 Aug 2015 15:51:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level:
X-Spam-Status: No, score=-14.511 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, 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 zrGGf6Xibjv2 for <netmod@ietfa.amsl.com>; Tue, 25 Aug 2015 15:51:12 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468481B30ED for <netmod@ietf.org>; Tue, 25 Aug 2015 15:51:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2866; q=dns/txt; s=iport; t=1440543072; x=1441752672; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=1zVdJzJMn+UsbANk2dMYuEWHyKmRH2d1yV2QsmY9R0E=; b=j1jgIvyqAb51Glz1Ucneltvjlkt1CaolKyX9ib6meZuLN64vCZi4XcBA ZfoiI1mt2md7Gp45LXrqj5+p3nfU8oRh8sZ9Nji+buZb9DzP7kuc8Prgg B/nrdeclZIpbyDPCTAwb+D1tgUVEtmdDA4wZ2YeHO0p9anISzd94tNe9A M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CBAgAL8NxV/5FdJa1dgxuBQ74LAQmFG4JYAhyBHTgUAQEBAQEBAYEKhCMBAQEEIxFFEAIBCBUFAgYgAgICMBUQAgQBDQ2IJrM1lQkBAQEBAQEBAQEBAQEBAQEBAQEBAQEXgSKKNYQ/GhYbB4JpL4EUBZU3AYxymlMmg36BeCUcgQQBAQE
X-IronPort-AV: E=Sophos;i="5.17,412,1437436800"; d="scan'208";a="181716834"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Aug 2015 22:51:09 +0000
Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id t7PMp90b005168 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Aug 2015 22:51:09 GMT
Received: from xch-rcd-009.cisco.com (173.37.102.19) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 25 Aug 2015 17:51:08 -0500
Received: from xhc-rcd-x01.cisco.com (173.37.183.75) by xch-rcd-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Tue, 25 Aug 2015 17:51:08 -0500
Received: from xmb-aln-x11.cisco.com ([169.254.6.68]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.03.0248.002; Tue, 25 Aug 2015 17:51:08 -0500
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Andy Bierman <andy@yumaworks.com>, Martin Bjorklund <mbj@tail-f.com>, "Alexander Clemm (alex)" <alex@cisco.com>
Thread-Topic: [netmod] Y34 - root node
Thread-Index: AQHQ2ddUzvwy2SNHuku5toYbWmieK54SVS+AgAEhX4CAAA01gIABIKmAgAA8e4CAAdMvAIAADywAgAAX8YCABlKuwA==
Date: Tue, 25 Aug 2015 22:51:07 +0000
Message-ID: <EF64FF31F4C4384DBCE5D513A791C2B121B2528F@xmb-aln-x11.cisco.com>
References: <CABCOCHRgAHah6_f1qZkPs0_v8Cj6NA5TKokb_RtUv+XWNOocFA@mail.gmail.com> <20150820.101533.1535137181522006328.mbj@tail-f.com> <55D7148C.6090508@cisco.com> <20150821.150158.491063432174006492.mbj@tail-f.com> <CABCOCHQhNp99RNvfTJqgDn48+waTjOgjbwS=TcFe4HMXct8J1Q@mail.gmail.com>
In-Reply-To: <CABCOCHQhNp99RNvfTJqgDn48+waTjOgjbwS=TcFe4HMXct8J1Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.118.56.228]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/dS7FMqwVF5AZYp8yPHN3z7gbUSs>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Y34 - root node
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: Tue, 25 Aug 2015 22:51:13 -0000

From: Andy Bierman,  Friday, August 21, 2015 10:28 AM

<snip>
> >>> Currently we have a proprietary way of "relocating" YANG modules, and
> >>> ODL has its "mount", and I think Andy has some other mechanism.  Maybe
> >>> the time has come to standardize how mount works, and maybe then also
> >>> standardize the list of devices in a controller model.

It seems there are many places where mount is being used effectively.  I am all for some standard syntax.

> >> +1
> >>
> >> We just need to standardize a "docroot within a docroot".
> >> This is not relocation of subtrees within the datastore, this is just
> >> mounting
> >> a datastore somewhere within a parent datastore.
> >>
> >> In YANG validation terms, you simply adjust the docroot to the nested
> >> mount
> >> point,
> >> and the replicated datastore can be used as if it were stand-alone.
> >> This would allow any sort of encapsulation of datastores and not add
> >> any
> >> data model complexity to devices which do not have virtual servers
> >> (most of them).
> > Compared to the mount draft, I would like to decouple the schema
> > information from the instance population mechanism.  I.e., I'd like a
> > mechanism that simply defines the schema, not necessarily how the data
> > is populated (in the mount draft data was fetched from a remote
> > server, but IMO that is just one of several use cases).
> Yes, I agree that these could/should be decoupled.  Although I note
> that the mount draft does also allow for local mounts, although this
> does not seem to be intended to be the mainline case.

The mount draft was indeed driven by OpenDaylight's use cases.  In ODL, mount is used for local YANG representation of remote device information. 

Based on this I believe a generalized mount syntax should not mandate that the target must be local and cannot be remote.  Nor should a generalized mount syntax itself restrict whether the target node contain schema or instance info.   There are many ways beyond the syntax if an implementation has no desire for this.

Eric