Re: [netmod] Proposal to enhance the YANG tree output

Ladislav Lhotka <lhotka@nic.cz> Fri, 15 September 2017 11:48 UTC

Return-Path: <lhotka@nic.cz>
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 4BEF9133071 for <netmod@ietfa.amsl.com>; Fri, 15 Sep 2017 04:48:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 JHaYLYx05VKF for <netmod@ietfa.amsl.com>; Fri, 15 Sep 2017 04:48:45 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 46CFB13217D for <netmod@ietf.org>; Fri, 15 Sep 2017 04:48:45 -0700 (PDT)
Received: from birdie (unknown [IPv6:2001:718:1a02:1::380]) by mail.nic.cz (Postfix) with ESMTPSA id 8300461282; Fri, 15 Sep 2017 13:48:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1505476123; bh=2z95ncU5K2zZ+HwGbDx53gOTt+wDp2/bn87O2+CYE/Q=; h=From:To:Date; b=YyQGpohxI3MH+svIX80hscARdR6cJajCALKHxQtjwzmDoFZ25NyIQadISOAv7B2Ti HAaFUG/Bf+9vdudAaJFVZMlvTDPviuWc0ucc9GN5GphTFSuD6U2hFjuBmEend65nkL zGzKi3Bv9n6h6ZyQ4lX0Jaoipm5fpL25C63HWaFI=
Message-ID: <1505476160.18681.23.camel@nic.cz>
From: Ladislav Lhotka <lhotka@nic.cz>
To: Martin Bjorklund <mbj@tail-f.com>, rwilton@cisco.com
Cc: netmod@ietf.org
Date: Fri, 15 Sep 2017 13:49:20 +0200
In-Reply-To: <20170915.134007.262763963470255554.mbj@tail-f.com>
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>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.5
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/T5NXJ2Bz_KQOXc8hAz1BT1I2d8o>
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: Fri, 15 Sep 2017 11:48:48 -0000

Martin Bjorklund píše v Pá 15. 09. 2017 v 13:40 +0200:
> 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 "@".  Since a parent
> reference can be very specific, e.g. one specific interface, it isn't
> really accurate to show:

Right, it is yet another example of confusing schema nodes with instances: the
tree diagram is a visualisation of the schema whereas parent references are
about concrete instances. Oh well...

Lada

> 
>                   +--mp vrf-root
>                      +--rw rt:routing/
>                      |  ...
>                      +--ro if:interfaces@
> 
> 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.
> 
> Also, what is mounted under a mount point is not defined in the
> schema, so a tool cannot generate this from the YANG modules.
> 
> 
> So maybe we should remove "/" and "@", and just keep "mp".
> 
> > I definitely think that "x" is a bit confusing since it both means
> 
> > "RPC" and also "status deprecated" depending on where it is.
> 
> 
> Possibly.  "x" for "deprecated" comes from smidump.  "x" for "execute"
> (rwx) is of course common.  So if we should change something it is
> probably "x" for "deprecated".  But "x" looks better than "d"...
> 
> 
> /martin
> 
> 
> 
> > 
> 
> > Thanks,
> 
> > Rob
> 
> > 
> 
> > 
> 
> > >
> 
> > > Lada
> 
> > >
> 
> > >>
> 
> > >> Andy
> 
> > >>
> 
> > >>
> 
> > >> On Thu, Sep 14, 2017 at 8:33 AM, Joe Clarke <jclarke@cisco.com> wrote:
> 
> > >>> I've been hacking on pyang, and I changed tree.py to add the enum
> 
> > >>> values
> 
> > >>> for enumeration types and identiyref bases for identityref types.
> 
> > >>> Here
> 
> > >>> is an example:
> 
> > >>>
> 
> > >>> module: yang-catalog
> 
> > >>>      +--rw catalog
> 
> > >>>         +--rw modules
> 
> > >>>         |  +--rw module* [name revision organization]
> 
> > >>>         |     +--rw name                     yang:yang-identifier
> 
> > >>>         |     +--rw revision                 union
> 
> > >>>         |     +--rw organization             string
> 
> > >>>         |     +--rw ietf
> 
> > >>>         |     |  +--rw ietf-wg?   string
> 
> > >>>         |     +--rw namespace                inet:uri
> 
> > >>>         |     +--rw schema?                  inet:uri
> 
> > >>>         |     +--rw generated-from?          enumeration [mib, code,
> 
> > >>> not-applicable, native]
> 
> > >>>         |     +--rw maturity-level?          enumeration [ratified,
> 
> > >>> adopted, initial, not-applicable]
> 
> > >>> ...
> 
> > >>>                                 +--rw protocols
> 
> > >>>                                 |  +--rw protocol* [name]
> 
> > >>>                                 |     +--rw name
> 
> > >>> identityref -> protocol
> 
> > >>> ...
> 
> > >>>
> 
> > >>> My questions are:
> 
> > >>>
> 
> > >>> 1. Is this useful?
> 
> > >>>
> 
> > >>> 2. If so, can this be added to pyang (happy to submit a PR) and
> 
> > >>> draft-ietf-netmod-yang-tree-diagrams?
> 
> > >>>
> 
> > >>> 3. What changes to the output format would you recommend?
> 
> > >>>
> 
> > >>> Thanks.
> 
> > >>>
> 
> > >>> Joe
> 
> > >>>
> 
> > >>> _______________________________________________
> 
> > >>> netmod mailing list
> 
> > >>> netmod@ietf.org
> 
> > >>> https://www.ietf.org/mailman/listinfo/netmod
> 
> > >> _______________________________________________
> 
> > >> netmod mailing list
> 
> > >> netmod@ietf.org
> 
> > >> https://www.ietf.org/mailman/listinfo/netmod
> 
> > 
> 
> > _______________________________________________
> 
> > netmod mailing list
> 
> > netmod@ietf.org
> 
> > https://www.ietf.org/mailman/listinfo/netmod
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67