IETF Logo Mail Archive

Re: [netmod] draft-bjorklund-netmod-structural-mount: Namespace issues

<chopps@chopps.org> Sat, 09 April 2016 00:23 UTC

Return-Path: <chopps@chopps.org>
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 DE8E112D54C for <netmod@ietfa.amsl.com>; Fri, 8 Apr 2016 17:23:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-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 Pf7NQFQk0SAE for <netmod@ietfa.amsl.com>; Fri, 8 Apr 2016 17:23:42 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id EBB7D12D623 for <netmod@ietf.org>; Fri, 8 Apr 2016 17:23:41 -0700 (PDT)
Received: from tops.chopps.org (24-247-68-31.dhcp.trcy.mi.charter.com [24.247.68.31]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id A84A66115B; Sat, 9 Apr 2016 00:23:40 +0000 (UTC)
References: <1458566013189.55874@pantheon.tech> <m2h9fxmd0i.fsf@birdie.labs.nic.cz>
User-agent: mu4e 0.9.16; emacs 24.5.1
From: chopps@chopps.org
To: Ladislav Lhotka <lhotka@nic.cz>
In-reply-to: <m2h9fxmd0i.fsf@birdie.labs.nic.cz>
Date: Fri, 08 Apr 2016 20:23:39 -0400
Message-ID: <87lh4n4ol0.fsf@tops.chopps.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <http://mailarchive.ietf.org/arch/msg/netmod/MQdxzzciI9YgT0oEOdqrnmwKvJw>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] draft-bjorklund-netmod-structural-mount: Namespace issues
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: Sat, 09 Apr 2016 00:23:44 -0000

Ladislav Lhotka <lhotka@nic.cz> writes:

> Hi Anton,
>
> Anton Tkáčik <anton.tkacik@pantheon.tech> writes:
>
>> Hi,
>>
>> if I understand correctly netmod-structural-mount inlines "mounted" data directly to container / list which is used,
>>
>> which brings up following issues:
>>
>>
>> 1. It is possible to have identifier conflict between data from model
>> defining mount and mounted data (if mounted schema
>
> I think we need to eliminate all kinds of recursive mount, so this
> should not happen.

While I think I need more help understanding the original problem (maybe
more explicit example of where the conflict is?), I wanted to point out
that when we (the RTG yang DT) originally came up with our desire for a
schema-mount, the ability to mount things recursively was seen as a
feature, and not something to be restricted or disallowed. For example
consider a physical network device that creates a logical network
element, which could then creates its own logical network element (i.e.,
a guest of the guest of the host in VM terms)

Thanks,
Chris.

v2.23.0 | Report a Bug | By Email