Re: [netmod] Proposal to enhance the YANG tree output
Lou Berger <lberger@labn.net> Mon, 18 September 2017 15:48 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 39AF3133063 for <netmod@ietfa.amsl.com>; Mon, 18 Sep 2017 08:48:35 -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 ZGvjrfWKVKVR for <netmod@ietfa.amsl.com>; Mon, 18 Sep 2017 08:48:31 -0700 (PDT)
Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) (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 BF0841321A2 for <netmod@ietf.org>; Mon, 18 Sep 2017 08:48:31 -0700 (PDT)
Received: from cmgw4 (unknown [10.0.90.85]) by gproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 06EFA140996 for <netmod@ietf.org>; Mon, 18 Sep 2017 09:46:11 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with id B3m71w00R2SSUrH013mAqJ; Mon, 18 Sep 2017 09:46:11 -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=AUd_NHdVAAAA:8 a=402DYpBsjlkE6fcHpgkA:9 a=QEXdDO2ut3YA:10
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:Subject:From: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=wKmJY+fxRZIRLEj0e/Lu+Pb9dtm9aWu0DW5pKw3oPdE=; b=kEW08RezIBCyVmnDHcW10GDR4f 3WSjWXYdXJPBMpVz2gHEDufy0obKbT4W4jwMDt4M5+oR80aWxh/pvUNcvgeCinYkPyPSO1XKkNWwR Rn1kX1GqSPWYKQiShr0OoZqbu;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:56808 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 1dtyFL-001xR3-NZ; Mon, 18 Sep 2017 09:46:07 -0600
From: Lou Berger <lberger@labn.net>
To: Martin Bjorklund <mbj@tail-f.com>, rwilton@cisco.com
Cc: netmod@ietf.org
References: <CABCOCHQZ4zJ3p_4oB1Pu=1H60btzrccqTx7rUtsRsF0reXgrYw@mail.gmail.com> <1505470900.18681.0.camel@nic.cz> <5b512435-cebd-3534-eeb3-649154450d81@cisco.com> <20170915.134007.262763963470255554.mbj@tail-f.com>
Message-ID: <c5352dde-4026-7549-bafa-30b19d7bb789@labn.net>
Date: Mon, 18 Sep 2017 11:46:04 -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: <20170915.134007.262763963470255554.mbj@tail-f.com>
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: 1dtyFL-001xR3-NZ
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]:56808
X-Source-Auth: lberger@labn.net
X-Email-Count: 8
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/gnrXMFWGw08bjWSpOs6E_OqUKJw>
Subject: Re: [netmod] Proposal to enhance the YANG tree output
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, 18 Sep 2017 15:48:35 -0000
Martin, Speaking as a contributor: On 9/15/2017 7:40 AM, Martin Bjorklund wrote: > Robert Wilton <rwilton@cisco.com> wrote: >> On 15/09/2017 11:21, Ladislav Lhotka wrote: >>> Andy Bierman píše v Čt 14. 09. 2017 v 08:43 -0700: >>>> Hi, >>>> >>>> >>>> Actually I liked the early pyang output that was concise and easy to >>>> remember. >>>> The current format gets very cluttered and there are too many little >>>> symbols >>>> to remember them all. >>> I agree. > Me too. The current draft adds three new magic symbols: "mp" "@" and > "/". > > "mp" is for a mount point, and it can be generated directly from the > YANG modules. > > Directly under a "mp", "/" and "@" are used to indicate that a node is mounted > or available through a parent reference, respectively. > > I actually question the usability of "/" and "@". I agree that / and @ are something new, and enabled by schema mount. There have been repeated comments in the RTG WG that there needs to be some way for vendors to convey what they have implemented with Schema mount and this is one way to help convey (a) what is expected of server implementors and (b) what client implementors should expect. Hence the current draft text: In describing the intended use of a module containing a mount point, it is helpful to show how the mount point would look with mounted modules. The whole point of trees is to facilitate understanding for those who are less familiar with a model than the authors, and IMO that's the paramount perspective in this discussion. > Since a parent > reference can be very specific, e.g. one specific interface, it isn't > really accurate to show: > > +--mp vrf-root > +--rw rt:routing/ > | ... > +--ro if:interfaces@ This is just a conditional and we have precedent on how to handle conditional representation. > > And the trailing "/" on rt:routing doesn't add any information we > don't already know. Since vrf-root is a mount point, it follows that > its children are mounted. The issue is a bit more complex when considering some real use cases, particularity when parent references and augmentations are used. For example consider the following *without* the use / or @: module: ietf-network-instance +--rw network-instances +--rw network-instance* [name] | ... +--rw (root-type) +--:(vrf-root) +--mp vrf-root +--ro rt:routing-state | +--ro router-id? yang:dotted-quad | +--ro control-plane-protocols | +--ro control-plane-protocol* [type name] | +--ro ospf:ospf | +--ro instance* [af] +--rw rt:routing | +--rw router-id? yang:dotted-quad | +--rw control-plane-protocols | +--rw control-plane-protocol* [type name] | +--rw ospf:ospf | +--rw instance* [af] | +--rw areas | +--rw area* [area-id] | +--rw interfaces | +--rw interface* [name] | +--rw name if:interface-ref | +--rw cost? uint16 +--ro if:interfaces | ... +--ro if:interfaces-state | ... It's certainly not too hard to spot the top level mounts, but it is impossible to distinguish the parent references from the actual mounts. Further more, some mounts are hard to spot. For example, notice ospf. Did you notice that it's a mount? Is it a mount or parent reference? With the / and @ both cases are transparent: module: ietf-network-instance +--rw network-instances +--rw network-instance* [name] | ... +--rw (root-type) +--:(vrf-root) +--mp vrf-root +--ro rt:routing-state/ | +--ro router-id? yang:dotted-quad | +--ro control-plane-protocols | +--ro control-plane-protocol* [type name] | +--ro ospf:ospf/ | +--ro instance* [af] +--rw rt:routing/ | +--rw router-id? yang:dotted-quad | +--rw control-plane-protocols | +--rw control-plane-protocol* [type name] | +--rw ospf:ospf/ | +--rw instance* [af] | +--rw areas | +--rw area* [area-id] | +--rw interfaces | +--rw interface* [name] | +--rw name if:interface-ref | +--rw cost? uint16 +--ro if:interfaces@ | ... +--ro if:interfaces-state@ | ... > Also, what is mounted under a mount point is not defined in the > schema, so a tool cannot generate this from the YANG modules. I think this is a limitation in the current schema-mount definition that perhaps will be revisited to support design time mounts, but nonetheless still has value to model any reader and implementor. ... Lou
- Re: [netmod] Proposal to enhance the YANG tree ou… Xufeng Liu
- Re: [netmod] Proposal to enhance the YANG tree ou… Martin Bjorklund
- [netmod] Proposal to enhance the YANG tree output Joe Clarke
- Re: [netmod] Proposal to enhance the YANG tree ou… Andy Bierman
- Re: [netmod] Proposal to enhance the YANG tree ou… Joe Clarke
- Re: [netmod] Proposal to enhance the YANG tree ou… Balazs Lengyel
- Re: [netmod] Proposal to enhance the YANG tree ou… Joe Clarke
- Re: [netmod] Proposal to enhance the YANG tree ou… Martin Bjorklund
- Re: [netmod] Proposal to enhance the YANG tree ou… Joe Clarke
- Re: [netmod] Proposal to enhance the YANG tree ou… Ladislav Lhotka
- Re: [netmod] Proposal to enhance the YANG tree ou… Robert Wilton
- Re: [netmod] Proposal to enhance the YANG tree ou… Martin Bjorklund
- Re: [netmod] Proposal to enhance the YANG tree ou… Ladislav Lhotka
- Re: [netmod] Proposal to enhance the YANG tree ou… Juergen Schoenwaelder
- Re: [netmod] Proposal to enhance the YANG tree ou… Benoit Claise
- Re: [netmod] Proposal to enhance the YANG tree ou… Martin Bjorklund
- Re: [netmod] Proposal to enhance the YANG tree ou… Juergen Schoenwaelder
- Re: [netmod] Proposal to enhance the YANG tree ou… Robert Wilton
- Re: [netmod] Proposal to enhance the YANG tree ou… Juergen Schoenwaelder
- Re: [netmod] Proposal to enhance the YANG tree ou… Joe Clarke
- Re: [netmod] Proposal to enhance the YANG tree ou… Robert Wilton
- Re: [netmod] Proposal to enhance the YANG tree ou… Martin Bjorklund
- Re: [netmod] Proposal to enhance the YANG tree ou… Juergen Schoenwaelder
- Re: [netmod] Proposal to enhance the YANG tree ou… Acee Lindem (acee)
- Re: [netmod] Proposal to enhance the YANG tree ou… t.petch
- Re: [netmod] Proposal to enhance the YANG tree ou… Lou Berger
- Re: [netmod] Proposal to enhance the YANG tree ou… Martin Bjorklund
- Re: [netmod] Proposal to enhance the YANG tree ou… Lou Berger
- Re: [netmod] Proposal to enhance the YANG tree ou… Robert Wilton
- Re: [netmod] Proposal to enhance the YANG tree ou… Martin Bjorklund
- Re: [netmod] Proposal to enhance the YANG tree ou… Martin Bjorklund
- Re: [netmod] Proposal to enhance the YANG tree ou… Robert Wilton
- Re: [netmod] Proposal to enhance the YANG tree ou… Lou Berger
- Re: [netmod] Proposal to enhance the YANG tree ou… Lou Berger
- Re: [netmod] Proposal to enhance the YANG tree ou… Juergen Schoenwaelder
- Re: [netmod] Proposal to enhance the YANG tree ou… Martin Bjorklund
- Re: [netmod] Proposal to enhance the YANG tree ou… Martin Bjorklund
- Re: [netmod] Proposal to enhance the YANG tree ou… Ladislav Lhotka
- Re: [netmod] Proposal to enhance the YANG tree ou… t.petch
- Re: [netmod] Proposal to enhance the YANG tree ou… Lou Berger
- Re: [netmod] Proposal to enhance the YANG tree ou… Lou Berger
- Re: [netmod] Proposal to enhance the YANG tree ou… Yingzhen Qu
- Re: [netmod] Proposal to enhance the YANG tree ou… Acee Lindem (acee)
- Re: [netmod] Proposal to enhance the YANG tree ou… Martin Bjorklund
- Re: [netmod] Proposal to enhance the YANG tree ou… Xufeng Liu