Re: [netmod] schema mount open issue #1

Lou Berger <lberger@labn.net> Tue, 12 September 2017 16:37 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 C0176133083 for <netmod@ietfa.amsl.com>; Tue, 12 Sep 2017 09:37:30 -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 irqCb9H0sVRd for <netmod@ietfa.amsl.com>; Tue, 12 Sep 2017 09:37:29 -0700 (PDT)
Received: from outbound-ss-1812.hostmonster.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (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 140A8132D8F for <netmod@ietf.org>; Tue, 12 Sep 2017 09:37:29 -0700 (PDT)
Received: from cmgw4 (cmgw5 [10.0.90.85]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 9228A175C47 for <netmod@ietf.org>; Tue, 12 Sep 2017 10:37:28 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id 8gdQ1w01R2SSUrH01gdT2m; Tue, 12 Sep 2017 10:37:28 -0600
X-Authority-Analysis: v=2.2 cv=OZLoNlbY c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=2JCJgTwv5E4A:10 a=u07AKapRAAAA:8 a=wU2YTnxGAAAA:8 a=K52pD-1NwIsMUiPbzAMA:9 a=QEXdDO2ut3YA:10 a=SkebfZ6J2Mmvk2rLHZle:22 a=Yz9wTY_ffGCQnEDHKrcv: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:References:Cc:To:From: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=hHCh4wM2EYgUataQ5EOhwl1Z8UpPu9L1aH43iDolPvc=; b=ZHpXyS03lbBZnakNMRhyi0XiTt JJo5PUvpuVdZ2v4stlePh8gV4znXIaFudGRfj9jifdWYnfEnBvofX16R6grvaPoM/nCLEKpTwWKO0 2qMD5hwywhD+RzIpPi/JGLVWi;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:55654 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 1droBg-003E3c-EA; Tue, 12 Sep 2017 10:37:24 -0600
From: Lou Berger <lberger@labn.net>
To: Martin Bjorklund <mbj@tail-f.com>, lhotka@nic.cz
Cc: netmod@ietf.org
References: <1503929779.1715.65.camel@nic.cz> <81b138c6-9941-3313-979c-61edad7819a7@labn.net> <87shgacvrb.fsf@nic.cz> <20170830.094028.1809893324608957744.mbj@tail-f.com> <15e32791e40.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Message-ID: <f546e06b-c89f-084b-7374-b7a8cb58bc57@labn.net>
Date: Tue, 12 Sep 2017 12:37:22 -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: <15e32791e40.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
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: 1droBg-003E3c-EA
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]:55654
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/6Ab3xkK4yqDULBaK-ZHhaAFJP6M>
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: Tue, 12 Sep 2017 16:37:31 -0000

Hi,

The LNI/NI authors/RTG Area DT met yesterday and discussed the proposed
change as well as the other topics that came up in the subsequent
discussion.  The high order bit is that the proposed and current
definitions are adequate for our needs.  Read further if you care about
details, including confirming our understanding:

1) WRT xpath context change proposed by martin

Our understanding is that absolute paths continue to be allowed, for
example the following remains valid:

           "use-schema": [
             {
               "name": "ni-schema",
               "parent-reference": [
                 "/*[namespace-uri() = 'urn:ietf:...:ietf-interfaces']"
               ]
             }
           ]

Assuming yes, then we have no objection to the change (as it allows the
server implementor to choose how/if they support vrf name filtering.
Obviously, using the new syntax exposes the restriction to the client
which is probably desirable.)

2. parent-reference location is adequate for our needs. 
This said, we think parent-references are more appropriately contained
within the schema list and having them there will yield less complex
operational data. 

3. current mount point extension usage definition (must be in a list or
container).
Our use case is covered by always having a single mount point contained
in a container.  We don't see the need for mount point extensions within
lists or for there to ever be siblings of mount point extensions.

We don't see a need to discuss items 2 and 3 further at this time. 
Assuming  our understanding is correct, we will update the NI and LNE
draft as soon as schema mount is updated as proposed.

Lou
(as contributor and NI/LNE draft co-author)


On 8/30/2017 5:29 AM, Lou Berger wrote:
> FYI I've asked folks in the routing area, i.e., the ietf users of schema 
> mount, if they have an opinion on the node discussion. I will also do so on 
> the point I raised on parent reference location. (Which is independent from 
> your format change.) Clearly, if I'm the only one to be raising objections, 
> I'll be the one in the rough on these points.
>
> Thanks,
>
> Lou
> - as contributor
>
>
> On August 30, 2017 3:42:26 AM Martin Bjorklund <mbj@tail-f.com> wrote:
>
>> Ladislav Lhotka <lhotka@nic.cz> wrote:
>>> Lou Berger <lberger@labn.net> writes:
>>>
>>>> Lada,
>>>>
>>>>
>>>> On 8/28/2017 10:16 AM, Ladislav Lhotka wrote:
>>>>> Lou Berger píše v Po 28. 08. 2017 v 09:40 -0400:
>> [...]
>>
>>>>>> 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.
>> So, going back to the original issue; does anyone have any objection
>> to changing the XPath context for parent-reference as describied in my
>> original post?
>>
>>
>> /martin
>>