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

<chopps@chopps.org> Mon, 11 April 2016 15:37 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 30A1D12D5D0 for <netmod@ietfa.amsl.com>; Mon, 11 Apr 2016 08:37:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.896
X-Spam-Level:
X-Spam-Status: No, score=-2.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.996] 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 qMZ_3hNTAK0H for <netmod@ietfa.amsl.com>; Mon, 11 Apr 2016 08:37:08 -0700 (PDT)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id CA54512D5A0 for <netmod@ietf.org>; Mon, 11 Apr 2016 08:37:08 -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 5998661176; Mon, 11 Apr 2016 15:37:07 +0000 (UTC)
References: <1458566013189.55874@pantheon.tech> <m2h9fxmd0i.fsf@birdie.labs.nic.cz> <87lh4n4ol0.fsf@tops.chopps.org> <20160409.093234.138748394999396297.mbj@tail-f.com>
User-agent: mu4e 0.9.16; emacs 24.5.1
From: chopps@chopps.org
To: Martin Bjorklund <mbj@tail-f.com>
In-reply-to: <20160409.093234.138748394999396297.mbj@tail-f.com>
Date: Mon, 11 Apr 2016 11:37:03 -0400
Message-ID: <87egacjgww.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/Uynh3nlCVQnooebYnXKNBhhnesg>
Cc: 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: Mon, 11 Apr 2016 15:37:10 -0000

Martin Bjorklund <mbj@tail-f.com> writes:
> <chopps@chopps.org> wrote:
>> Ladislav Lhotka <lhotka@nic.cz> writes:
>> > 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)
>
> The current schema-mount supports recursive mounts in the schema
> (e.g., if ietf-logical-devices has a mountpoint, it might be that
> ietf-logical-devices is mounted there).  Maybe 'nested mounts' is a
> better term.  But with a solution like peer mount, you probably want
> to stay out of recursive mounts (A mounts B which mounts A).

Nested schema mounts seems like a good enough name.

Before hearing of the peer/alias mounts I had thought a "symlink" would
perhaps be useful, which I believe is basically what an alias mount is.
To that end the way unix deals with infinite recursion (loops) is to
return an error when it happens (either the loop is detected and an
error is returned specific to that condition, or some maximum depth is
violated I believe).

Thanks,
Chris.

> I also do not understand the original question regarding identifier
> conflicts.
>
>
> /martin