Re: [netmod] Y34 - root node

Martin Bjorklund <mbj@tail-f.com> Thu, 27 August 2015 06:26 UTC

Return-Path: <mbj@tail-f.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 145181B342E for <netmod@ietfa.amsl.com>; Wed, 26 Aug 2015 23:26:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EoiKwyVMuWgT for <netmod@ietfa.amsl.com>; Wed, 26 Aug 2015 23:26:50 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9E8A11B3465 for <netmod@ietf.org>; Wed, 26 Aug 2015 23:26:49 -0700 (PDT)
Received: from localhost (unknown [213.136.39.104]) by mail.tail-f.com (Postfix) with ESMTPSA id E469C1AE0973; Thu, 27 Aug 2015 08:26:47 +0200 (CEST)
Date: Thu, 27 Aug 2015 08:27:06 +0200
Message-Id: <20150827.082706.86671891927608851.mbj@tail-f.com>
To: alex@cisco.com
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <DBC595ED2346914F9F81D17DD5C32B571DC8B7A6@xmb-rcd-x05.cisco.com>
References: <20150821.150158.491063432174006492.mbj@tail-f.com> <BBD0133D-7EAE-4283-ACEF-358FF1D8600B@nic.cz> <DBC595ED2346914F9F81D17DD5C32B571DC8B7A6@xmb-rcd-x05.cisco.com>
X-Mailer: Mew version 6.5 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/y_3t_5wF3eMgpKw2ADiU7njSnSA>
Cc: 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: Thu, 27 Aug 2015 06:26:51 -0000

"Alexander Clemm (alex)" <alex@cisco.com> wrote:
> - As Martin mentioned, clearly by allowing to mount you are
> decoupling schema information and instance population.  Regarding
> the issue of validation, this can be addressed by several ways.

I think that the mount point effectively works as a 'chroot' for all
mounted data models in the mount point.  This means that if
ietf-interfaces and ietf-routing are mounted under
/devices/device/data, all XPath expressions and leafref paths and
instance-identifiers in these models are evaluated in a chrooted
environment where their '/' is set to
/device/device[name='...']/data.  This is how we implement validation
for such modules in our NCS (manager product).

In an implementation that actually does not store the data locally,
but fetches it from a remote device (like the original mount
proposal), it is fine to push also validation to the remote node.


[maybe mount is not a good name for this generalized thing; this term
might make you believe that the data has to be provided by some other
server.]


/martin