Re: [netmod] Y34

Robert Varga <nite@hq.sk> Fri, 28 August 2015 15:14 UTC

Return-Path: <nite@hq.sk>
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 85B5E1A9234 for <netmod@ietfa.amsl.com>; Fri, 28 Aug 2015 08:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.805
X-Spam-Level:
X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=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 C6Ib96yZMr04 for <netmod@ietfa.amsl.com>; Fri, 28 Aug 2015 08:14:03 -0700 (PDT)
Received: from mail.hq.sk (hq.sk [81.89.59.181]) by ietfa.amsl.com (Postfix) with ESMTP id 34A6C1ACDEC for <netmod@ietf.org>; Fri, 28 Aug 2015 08:13:49 -0700 (PDT)
Received: from [10.0.2.15] (188-167-5-4.dynamic.chello.sk [188.167.5.4]) by mail.hq.sk (Postfix) with ESMTPSA id 6DE73240277; Fri, 28 Aug 2015 17:13:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hq.sk; s=mail; t=1440774827; bh=xG43LWjzttuZbbx3gA/0hjDHots3aFpSZSfeGquosfg=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=icXSzMqkAJt0GDSMe8Res8xohNYWb3Qr7JNjRE7ArIM3P8qyvgfOQFxUB+HlAfQIs lSQYt54m7GYic1AdvZ6YzDIwxRgZmZ9v7yqbj7mxehsgO8pmDJj9LXcelX0VvdoiC5 kkxESr3E0A70fEyXi7Qv18Hoi7ols47l7ttpwwkk=
To: Ladislav Lhotka <lhotka@nic.cz>
References: <m2d1zn0zhm.fsf@dhcp-hotel-wired-13-fe.meeting.ietf.org> <D0153452-D5F5-4E3C-B3D7-7003ACC405EA@nic.cz> <CABCOCHSqbZfKRqGjT1rsphRnw0tYdR3uT=mFvTvJYXMwL3N2uw@mail.gmail.com> <5497CE3E-19A7-4AAC-AE32-AFC9BC2451F1@nic.cz> <CABCOCHRoA9-BP7=OvUGdvXNuowPUty4xy6iai6Q6dVOjD5iGbQ@mail.gmail.com> <06C8EE42-B70D-40A7-8B16-053D37378043@nic.cz> <CABCOCHRS-JF8UK+9fQ=yvZy9ttcj3j6oJn0n3Co6f7kB0tpFgA@mail.gmail.com> <F990644A-4CBE-43D5-AB2B-A20E54A91A65@nic.cz> <20150720210041.GA17614@elstar.local> <4D704311-D5B7-43F3-BD23-C13D5289CF46@nic.cz> <20150721074428.GC18607@elstar.local> <55DFC6CF.7060105@hq.sk> <6FA04E5F-F0FB-45F7-B17F-BDDA1C9C1D18@nic.cz>
From: Robert Varga <nite@hq.sk>
Message-ID: <55E07AAA.20704@hq.sk>
Date: Fri, 28 Aug 2015 17:13:46 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <6FA04E5F-F0FB-45F7-B17F-BDDA1C9C1D18@nic.cz>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/4g7c7Gz0QF8BJniBsR0mkIKi5m0>
Cc: NETMOD Working Group <netmod@ietf.org>
Subject: Re: [netmod] Y34
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: Fri, 28 Aug 2015 15:14:05 -0000

On 08/28/2015 03:34 PM, Ladislav Lhotka wrote:
> Hi Robert,
>> On 28 Aug 2015, at 04:26, Robert Varga <nite@hq.sk> wrote:
>>
>> On 07/21/2015 09:44 AM, Juergen Schoenwaelder wrote:
>>> Lada, you can't simply 'mount' a data model into a different place.
>>> Think about paths in must or when expressions, or think about paths
>>> contraints in leafrefs etc
>> In ODL we already have a language extension which does this. Semantically it embeds the conceptual 'root' node into container/list item. That item becomes the logical root against which all expressions in the embedded models are evaluated against, e.g. it is its own little world, no constraints coming in or out of it. While incoming references could be done (by just crossing the embedding item), we have not found a use case for it yet.
> Yes, I think this could work. Two questions:
>
> 1. Is it possible to graft the same module multiple times in different places, perhaps in different revisions and with different features?
>
> 2. Can you identify a *set* of modules that are chrooted this way? For example, can you say you want to have a common root for ietf-interfaces, ietf-ip and ietf-system, rather than putting each module in its separate little world?

I would say the answer to both questions should be yes, otherwise it 
would not work well in a heterogeneous environment and/or presence of 
inter-module constraints.

 From implementation perspective, we do not declare these in the model 
itself -- it acts only as a marker for the client to understand that it 
talks to a 'sub-device' and should look for a chrooted RFC6020 
/netconf-state subtree to see what is going on in a particular chroot 
instance.

Bye,
Robert