Re: [netmod] mount-point in anydata,Re: mount-point in anydata

Martin Bjorklund <mbj@tail-f.com> Fri, 20 January 2017 07:35 UTC

Date: Fri, 20 Jan 2017 08:35:51 +0100
Message-Id: <20170120.083551.970804629897913074.mbj@tail-f.com>
To: nite@hq.sk
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <0aef5ef5-1ff2-f23e-d2aa-6a6dbab356fe@hq.sk>
References: <20170117.132913.781493366440105564.mbj@tail-f.com> <20170117.132913.781493366440105564.mbj@tail-f.com> <0aef5ef5-1ff2-f23e-d2aa-6a6dbab356fe@hq.sk>
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/hvQWNGmWChsggMl6yjiIiRCKd-U>
Cc: netmod@ietf.org
Subject: Re: [netmod] mount-point in anydata,Re: mount-point in anydata
Precedence: list

Robert Varga <nite@hq.sk> wrote:
> On 01/17/2017 01:29 PM, Martin Bjorklund wrote:
> > For this reason, I propose that we go back to the previous model where
> > "mount-point" would be allowed in "container" and "list".  Note that a
> > client that doesn't know anything about these mounts would see some
> > nodes in some unknown namespace; just like in the case that there is
> > an augment that the client doesn't know about.
> 
> +1, although I think the situation is not quite equal to an unknown
> augmentation: the mount point itself would be in an unknown namespace,
> but the nodes beneath it could actually match a namespace known to the
> client, right?

Yes, the namespace might be known to the client, but in a different
place.


/martin

[netmod] mount-point in anydata Martin Bjorklund
Re: [netmod] mount-point in anydata Lou Berger
Re: [netmod] mount-point in anydata Martin Bjorklund
Re: [netmod] mount-point in anydata Robert Varga
Re: [netmod] mount-point in anydata,Re: mount-poi… Martin Bjorklund