Re: [netmod] schema mount open issue #1

Lou Berger <lberger@labn.net> Mon, 28 August 2017 19:13 UTC

Return-Path: <lberger@labn.net>
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 1E4DE132360 for <netmod@ietfa.amsl.com>; Mon, 28 Aug 2017 12:13:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
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 kehDQ-k4MUIL for <netmod@ietfa.amsl.com>; Mon, 28 Aug 2017 12:13:40 -0700 (PDT)
Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com [69.89.20.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8615A132143 for <netmod@ietf.org>; Mon, 28 Aug 2017 12:13:40 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id C004D1E07E4 for <netmod@ietf.org>; Mon, 28 Aug 2017 13:13:36 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id 2jDZ1w01N2SSUrH01jDc4W; Mon, 28 Aug 2017 13:13:36 -0600
X-Authority-Analysis: v=2.2 cv=G8xsK5s5 c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=KeKAF7QvOSUA:10 a=48vgC7mUAAAA:8 a=HYdXEmAEtF05-tEcD6wA:9 a=ERfcdGFNRYMmk1YL:21 a=7JH8CNHjtSvyIUsG:21 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Pp/aQsrEemZ4e6T/mvRy+xALh4Wdj81XsE0Sbv18ND8=; b=08BLv/eqYft4L9idPP/BkthmVb igqEur5frtzaXImjcRriy50t9QeYyZ9ZI8VeVnUzPaUnDWGEpNBwOYrRTXrs4x+ayLR2M2C+IdE/X ygf9yIYuHdEDMUOa3ood2fbxn;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:52788 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1dmPTZ-000y1k-ID; Mon, 28 Aug 2017 13:13:33 -0600
To: Ladislav Lhotka <lhotka@nic.cz>, Martin Bjorklund <mbj@tail-f.com>
Cc: netmod@ietf.org
References: <edf93508-3b14-e962-488f-a4844d7f8399@labn.net> <20170828.122845.1527315474517128533.mbj@tail-f.com> <ca476502-c8f5-ffad-a463-04f21e2411f9@labn.net> <20170828.133507.2047018591752852829.mbj@tail-f.com> <e356dcb1-6bb2-96ec-17d4-c0bf7f1868b4@labn.net> <1503927029.1715.46.camel@nic.cz> <7c99497f-d719-0fe2-01f5-a06d53c8fc68@labn.net> <1503929779.1715.65.camel@nic.cz>
From: Lou Berger <lberger@labn.net>
Message-ID: <81b138c6-9941-3313-979c-61edad7819a7@labn.net>
Date: Mon, 28 Aug 2017 15:13:25 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
In-Reply-To: <1503929779.1715.65.camel@nic.cz>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1dmPTZ-000y1k-ID
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:52788
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/3ZKrdpmB3WJKTuMO0UXm1UjqCDM>
Subject: Re: [netmod] schema mount open issue #1
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
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, 28 Aug 2017 19:13:43 -0000

Lada,


On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
> Lou Berger píše v Po 28. 08. 2017 v 09:40 -0400:
>> Lada,
>>
>> On 8/28/2017 9:30 AM, Ladislav Lhotka wrote:
>>>> Can you please take a look at it and see if we have any other disconnects?
>>> This is really scary. 
>> I agree!
>>
>>> How can we expect poor data modellers to understand the
>>> concept if we have such fundamental disconnects, after so many hours of
>>> discussing it?
>> This highlights why getting the text in (any) document is so important,
>> and why discussions shouldn't be viewed as being closed until the impact
>> on the text is agreed to!
> I think many people still don't make much distinction between schema mount
> (manipulation of the schema) and data mount. I still believe we need to clearly
> separate these two concepts, preferably using two different mechanisms.

Frankly, I'm focused on removing blocking issues on the current WG
deliverable, i.e., schema mount.
...
>> Lou
>>
>> PS is your view aligned with martin or our example?
> If you mean shifting the XPath context node to the mount point instance, then
> yes.

funny, you answered yes to a choice!  I was asking if you think the
mount point shows up as a node in the data tree, i.e., as shown in the
example in
https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model-03#appendix-B.1?

from my perspective and my co-authors in the RTG area using schema
mount, we've never heard of a (filesystem) mount point that doesn't show
in the (directory) structure and this is the mental analogue we've been
assuming. Since there never was an explicit example/discussion or text
to dissuade us of this, this disconnect was never noticed.  Certainly
this needs to be explicit in the document (either way). The following
change could be made to the schema mount draft (at a minimum):

OLD
          A mount point defines a place in the node hierarchy where
          other data models may be attached. A server that implements a
NEW
          A mount point defines a node in a data tree under which
instances of
          other data models may be attached. A server that implements a

Lou

> Lada
>
>>> Lada
>>>