Re: [netmod] Fwd: Re: YANG schema mount - any early implementations?

Lou Berger <lberger@labn.net> Thu, 02 August 2018 19:28 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 EA4511286E3 for <netmod@ietfa.amsl.com>; Thu, 2 Aug 2018 12:28:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.791
X-Spam-Level:
X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (768-bit key) reason="fail (body has been altered)" 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 Htp-vdc1gebs for <netmod@ietfa.amsl.com>; Thu, 2 Aug 2018 12:28:42 -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 368071277C8 for <netmod@ietf.org>; Thu, 2 Aug 2018 12:28:42 -0700 (PDT)
Received: from cmgw12.unifiedlayer.com (unknown [10.9.0.12]) by gproxy9.mail.unifiedlayer.com (Postfix) with ESMTP id 0300C1E06B8 for <netmod@ietf.org>; Thu, 2 Aug 2018 13:28:42 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id lJH7f8Oy2ak7tlJH7fMPsS; Thu, 02 Aug 2018 13:28:41 -0600
X-Authority-Reason: nr=8
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:Sender:Reply-To:Cc:Content-Transfer-Encoding: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=fbjottetmZpJhinkTBd3zZR7AisPDOXskri7vOEU3HU=; b=2jrYtmCVBbXG7RZAKvHgGz/bbW VhIssKGTUxzOxPTidL3jbsquU8ngkRRjl2rDBiz3tAChxKabJDMaByDkWoPIEsy+3npsJ6D3OG4/M ha8r6bkAOOXI4FieVVihiZgAW;
Received: from pool-100-15-106-211.washdc.fios.verizon.net ([100.15.106.211]:44470 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from <lberger@labn.net>) id 1flJH7-001IAk-IK; Thu, 02 Aug 2018 13:28:41 -0600
To: Hayden Brown <Hayden.Brown@Aviatnet.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <5df7eb40589d4631a33c704358bc8f8e@USP-EXCHPROD01.GNET.global.vpn>
From: Lou Berger <lberger@labn.net>
Message-ID: <a6ad2e01-48e6-455a-7bbc-6ac5f58b9e07@labn.net>
Date: Thu, 02 Aug 2018 15:28:40 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <5df7eb40589d4631a33c704358bc8f8e@USP-EXCHPROD01.GNET.global.vpn>
Content-Type: multipart/alternative; boundary="------------0C65124D0E3B3DF92F8F2AC6"
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.106.211
X-Source-L: No
X-Exim-ID: 1flJH7-001IAk-IK
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-106-211.washdc.fios.verizon.net ([IPv6:::1]) [100.15.106.211]:44470
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/gnbbmQS13HzY0Iocm0iv_8YXJ_g>
Subject: Re: [netmod] Fwd: Re: YANG schema mount - any early implementations?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.27
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: Thu, 02 Aug 2018 19:28:44 -0000

Hi,

     hopefully others will chime in too, but here's my view (as a user 
of schema mount, see 
https://tools.ietf.org/html/draft-ietf-rtgwg-ni-model)...


On 7/30/2018 7:27 PM, Hayden Brown wrote:
>
> Hi everyone,
>
> I just wanted to ask if it would be possible to clarify the intentions 
> around some of the wording of the draft schema mount standard 
> (Rev-10). In particular, regarding entries of the 
> /schema-mounts/mount-points list.
>
> My interpretation is that the intended use of the 
> /schema-mounts/mount-points list entries are to specify the *parent 
> modules* that contain a mount point.
>
yes
>
> Following on from this, the client should use the YANG library 
> instance to determine which schema options can be mounted at the root 
> of a mount point. This seems consistent with the examples of Appendix 
> A of the draft standard.
>
if you drop the word "options", then yes.  Other examples can be found 
in draft-ietf-rtgwg-ni-model

> In this email I wanted to highlight the following sections of the 
> draft RFC below. In my view they seem to me to be somewhat ambiguous, 
> in implying that the mount-point list entries specify the /*child* 
> /module (sub-schema):
>
>
> >From 
> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/?include_text=1
>
> *Section 3.3 – Page 7*
> > The "/schema-mounts" container has the "mount-point" list as one of its children. Every entry of this list 
> refers through its key to a mount point and specifies the mounted schema.
>
> *Section 3.3 - Page 8*
> > An entry of the "mount-point" list can specify the mounted schema in two different ways, "inline" or 
> "shared-schema".
>
>
> *Section 9 - Page *13
> > A mount point defines a place in the node hierarchy where other data models may be attached. A server that 
> implements a module with a mount point populates the 
> /schema-mounts/mount-point list with detailed information onwhich data 
> models are mounted at each mount point.
>
> *Section 9 - Page *14
> list mount-point {
>     key "module label";
>     description
>     "Each entry of this list specifies a schema for a particular mount 
> point.
>

I have reread the a few times and am having a hard time understand what 
should be changed.  Can you suggest specific changes that would address 
your concern/comment?  This might help to understand the issue you are 
seeing.

>
> The wording makes me wonder if these passages might actually just be 
> "left-over" context from earlier revisions of the draft standard 
> (Revision 8 and prior) -- effectively referring back to the 
> schema-mount '/use-schema/' list.
>
Again, I'm seeing the issue.

>
> I do of course acknowledge that it is entirely possible that I've 
> misinterpreted the wording of the passages above, however if that is 
> the case, I suspect I may not be the only one in future.
>
And I'm sure I'm suffering from having spent way too much time on this 
topic so may be seeing things in the text that aren't actually there!

Cheers,
Lou
(no hats)


> Many thanks for your time on this matter.
>
> Best regards,
> Hayden
>
> On 20/07/2018 8:09 PM, Juergen Schoenwaelder wrote:
>
> On Wed, Jul 11, 2018 at 09:43:32AM +1200, hayden wrote:
>    
> I understand that the schema mount proposal is still effectively in a
> state of flux, but are there any publicly visible implementations or
> deployments of a NETCONF or RESTCONF server that those interested could
> experiment with (e.g. to aid in client development)?
> State of flux? It is past WG last call and IETF last call.
> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/history/
> /js
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod