IETF Logo Mail Archive

Re: [netmod] Y34 - root node

"Alexander Clemm (alex)" <alex@cisco.com> Thu, 27 August 2015 22:22 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 E26E81A9248 for <netmod@ietfa.amsl.com>; Thu, 27 Aug 2015 15:22:24 -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 rNx6a8E-JcTY for <netmod@ietfa.amsl.com>; Thu, 27 Aug 2015 15:22:23 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 805C21A9063 for <netmod@ietf.org>; Thu, 27 Aug 2015 15:22:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1795; q=dns/txt; s=iport; t=1440714143; x=1441923743; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=GM+KSwxNqVnPv9uToG6U0L7fJc5sYemLMz+mzbvpDS4=; b=cle0xLc9A9Uur1zFeOqjh1BqssVv47lkEAS0feLRJpdRE1CmeWSfCFBP gcoJBFy6Ki+CDvWwP1Od3G1Ac1gVmNT5VfX5yTqCiGvp6OtEM5xlRkbe5 tNH4K2R9UnB96PEzWe5WQlNm5JpCRhprMeKBRpAHBhUCceQ63fS1A7/OW E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AMBQAYjd9V/5NdJa1egxuBPQbFcgKBPTwQAQEBAQEBAYEKhCMBAQEEOj8MBAIBCA4DBAEBAQoUCQcyFAkIAgQOBQiIJsZFAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4thhEAaMQcGgxKBFAEEjGyIUQGnUyaDf3GBByUcgQUBAQE
X-IronPort-AV: E=Sophos;i="5.17,423,1437436800"; d="scan'208";a="27930665"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 27 Aug 2015 22:22:22 +0000
Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t7RMMMJw011337 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 27 Aug 2015 22:22:22 GMT
Received: from xch-aln-019.cisco.com (173.36.7.29) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 27 Aug 2015 17:22:21 -0500
Received: from xhc-aln-x10.cisco.com (173.36.12.84) by xch-aln-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1104.5 via Frontend Transport; Thu, 27 Aug 2015 17:22:21 -0500
Received: from xmb-rcd-x05.cisco.com ([169.254.15.111]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0248.002; Thu, 27 Aug 2015 17:22:21 -0500
From: "Alexander Clemm (alex)" <alex@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
Thread-Topic: [netmod] Y34 - root node
Thread-Index: AQHQzfwQhTp8SpZgRU2/JK7T0ppEc536tNgA//+74lSAAFbtgIAAz1DkgADCswCABfPJgIAC/IuAgAAMEQCAAKj6AIAAC1YAgAC+7gCAC50MgIAABoyAgAEhX4CAAA01gIABIKqAgAA8e4CAAdMvAIAADywAgAAMDoCACAd/8IAA7B0AgAC1GUA=
Date: Thu, 27 Aug 2015 22:22:21 +0000
Message-ID: <DBC595ED2346914F9F81D17DD5C32B571DC8D852@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> <20150827.082706.86671891927608851.mbj@tail-f.com>
In-Reply-To: <20150827.082706.86671891927608851.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.154.204.27]
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/xW-GXic8ACz0d_4CrmLGAsjer9Q>
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: Thu, 27 Aug 2015 22:22:25 -0000

Yes.  The one thing I would add is that validation of the mounted data can occur in its original path (the authoritative owner (in the distributed case)).  It should not be required to do this validation with the chrooted path, although that path can be used by other data nodes that refer to / have dependencies on the mounted data.  

Regarding naming, do you have an alternative suggestion?

Cheers
--- Alex

-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com] 
Sent: Wednesday, August 26, 2015 11:27 PM
To: Alexander Clemm (alex) <alex@cisco.com>
Cc: lhotka@nic.cz; netmod@ietf.org
Subject: Re: [netmod] Y34 - root node

"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

v2.23.0 | Report a Bug | By Email