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

"Xufeng Liu" <xufeng.liu.ietf@gmail.com> Wed, 27 September 2017 13:31 UTC

Return-Path: <xufeng.liu.ietf@gmail.com>
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 C1EC613301E for <netmod@ietfa.amsl.com>; Wed, 27 Sep 2017 06:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 7lhqwJIrK3z7 for <netmod@ietfa.amsl.com>; Wed, 27 Sep 2017 06:31:07 -0700 (PDT)
Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4AB513308D for <netmod@ietf.org>; Wed, 27 Sep 2017 06:31:06 -0700 (PDT)
Received: by mail-wr0-x235.google.com with SMTP id 108so16520317wra.5 for <netmod@ietf.org>; Wed, 27 Sep 2017 06:31:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=HXwzyjzttF9Gr6SOoeJCiZ7KMEwjHlK6l0dTxx466XQ=; b=V0qffVK5XW6hUu7oyEr3fFQaYMN7ktNKESjxZfT6nwLwDlzh9VZeHm6GrFsxC4ugiv Lgor4cIauXK4GhTRW7IqlOOGD8sD89btY5xnEJYZDtssKpsIN0yh0/v2FOydJWW+TdG8 7d5tLkumelLLSsdjQpfd3pBqiH0Zi1BR529J6Hz69gr+08DecJ1s/6fae2BIjhteSkC4 rI9daCHh98CaqmVWro0lDg0A9/545lRDdWd8mnXbol3f+ht5E0GSkh0JC8/QuG3xlc+m C7fwuWR0YL3hVw1VvMMwG+lxQ3VZz+9k4MuDLGGigOSnqhb9cKzXkFnpb/0OR8jrBtgB csPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=HXwzyjzttF9Gr6SOoeJCiZ7KMEwjHlK6l0dTxx466XQ=; b=TIehqC6vlP7LXW3PyygN6DeAj0vSCbpAqVu74KyGJER8eU2FbFMZUy9GozDojEgHu+ 3coOgA+54vKZHpnOpcv1OKTvVlJeZlIaoTd7ggHjTkI6yjDcjV3SvJmjNrfuiizFxEAo 4uTd/2H6YzN+ZtVby1pZftNRzIUysIl0v/RtNwgRylhKuwrSZbg0XE56a6x1MFwLpmim CK2hZNiD9II5rqF4Vh3xgMRF3SvZQ5CBCBw4aQ2YnxL3xzlP5tgNYDOy1US7UWXPljxC vcR+VwJLfyRiU1+ZdqcjK7r0UxeDpZ0frgWY/QOVR2LaELG6G/ZTczYIKQQqkyVPq1o5 fY3w==
X-Gm-Message-State: AMCzsaXwueaU1KMmrdp8uhDOHIzNstBXL7t9ZYecC0s0P2sgooYrONoP mp9fYyjlTLugp7FKx2HrL0E=
X-Google-Smtp-Source: AOwi7QDkgfP8wT3E033qw3uKl39rRSvx5L3DDEnhKyf6fInj0RBC14PW01yPZ2Mr4keAYoGlYoRTYw==
X-Received: by 10.25.78.81 with SMTP id c78mr559064lfb.133.1506519065228; Wed, 27 Sep 2017 06:31:05 -0700 (PDT)
Received: from xliuus (wsip-98-191-72-170.dc.dc.cox.net. [98.191.72.170]) by smtp.gmail.com with ESMTPSA id g12sm1678477lfd.64.2017.09.27.06.31.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Sep 2017 06:31:04 -0700 (PDT)
From: "Xufeng Liu" <xufeng.liu.ietf@gmail.com>
To: "'Martin Bjorklund'" <mbj@tail-f.com>
Cc: <acee@cisco.com>, <netmod@ietf.org>
References: <D5EEA5E2.C9623%acee@cisco.com> <20170925.193903.1777711656523405872.mbj@tail-f.com> <005601d33673$1d27c180$57774480$@gmail.com> <20170926.083642.680914684763815093.mbj@tail-f.com>
In-Reply-To: <20170926.083642.680914684763815093.mbj@tail-f.com>
Date: Wed, 27 Sep 2017 09:31:01 -0400
Message-ID: <011001d33794$ddfb0760$99f11620$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQGM5OWQIGcbPwETqqFBVCOq/XS5FwJLwRhDAXmsw7wCS2U42aMk1GkQ
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/2GJx470fekrlkoE6URnFJrOMWf0>
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: Wed, 27 Sep 2017 13:31:10 -0000


> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Tuesday, September 26, 2017 2:37 AM
> To: xufeng.liu.ietf@gmail.com
> Cc: acee@cisco.com; netmod@ietf.org
> Subject: Re: [netmod] Proposal to enhance the YANG tree output
> 
> "Xufeng Liu" <xufeng.liu.ietf@gmail.com> wrote:
> > To a user of the schema-mount, it is important to be able to visualize
> > all key elements of the mounting mechanism: mount-point, mounted
> > schema module, and parent-reference. The details can be worked out,
> > but if any of these elements were not useful in the presentation, it
> > would be questionable whether it had well-specified in the schema
> > mount draft.
> 
> We agreed that we probably don't want to list all enums in the tree.
> Does that imply that enumerations are not well-specified in YANG?
> 
> > > -----Original Message-----
> > > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Martin
> > > Bjorklund
> > > Sent: Monday, September 25, 2017 1:39 PM
> > > To: acee@cisco.com
> > > Cc: netmod@ietf.org
> > > Subject: Re: [netmod] Proposal to enhance the YANG tree output
> > >
> > > "Acee Lindem (acee)" <acee@cisco.com> wrote:
> > > > Martin, Lada, et al,
> > > >
> > > > While I don’t think we need additional annotations that Joe had
> > > > prototyped (at least not as the default), I strongly believe we
> > > > need to keep the ‘@‘ and ‘/‘ in the tree output for schema mount.
> > >
> > > Can you explain what information "/" gives the reader?  Compare
> > > these two
> > > trees:
> > >
> > >   +--mp vrf-root
> > >      +--rw rt:routing/
> > >         +--rw rt:router-id
> > >
> > > and
> > >
> > >   +--mp vrf-root
> > >      +--rw rt:routing
> > >         +--rw rt:router-id
> > >
> > > What did the "/" in the first tree tell me that I don't see in the
> > > second tree?
> >
> > [Xufeng] Because the schema mount draft allows an augmenting module
> > not to be listed in the mounted schema list. The following two
> > examples show two different configurations:
> >
> >   +--mp root
> >      +--rw rt:routing/
> >      |  +--rw router-id?                 yang:dotted-quad
> >      |  +--rw control-plane-protocols
> >      |     +--rw control-plane-protocol* [type name]
> >      |        +--rw ospf:ospf/
> >
> > where ospf augments rt, and has been listed in the mounting schema
> > list.
> >
> >   +--mp root
> >      +--rw rt:routing/
> >      |  +--rw router-id?                 yang:dotted-quad
> >      |  +--rw control-plane-protocols
> >      |     +--rw control-plane-protocol* [type name]
> >      |        +--rw ospf:ospf
> >
> > where ospf augments rt, and has not been listed in the mounting schema
> > list.
> 
> If the ospf module is NOT listed in the yang library data for the mount point,

[Xufeng] I think that draft-ietf-netmod-schema-mount has the distinction between yang library data and schema-mounts/schema list. Do you mean the latter?

> then it will not be present in the tree.  So in this case the tree will be:
> 
>    +--mp root
>       +--rw rt:routing
>       |  +--rw router-id?                 yang:dotted-quad
>       |  +--rw control-plane-protocols
>       |     +--rw control-plane-protocol* [type name]
>              // no ospf here
> 
> [Think about it the other way around; if we were to show all nodes from all
> modules that are NOT mounted, our tree would be inifinitely big...]
> 
> If the ospf module *is* listed in the yang library data for the mount point, then
> the tree can be:
> 
>    +--mp root
>       +--rw rt:routing
>       |  +--rw router-id?                 yang:dotted-quad
>       |  +--rw control-plane-protocols
>       |     +--rw control-plane-protocol* [type name]
>       |        +--rw ospf:ospf
> 
> No need for a '/'.
> 
[Xufeng] What if the user does want to see all nodes in the system, whether they are mounted or un-mounted, is it possible?

Also, there is another case: I think that draft-ietf-netmod-schema-mount does not prohibit the mount-point container from containing other sub-containers. How can we tell these sub-containers are not from mounted modules?

   +--mp root
      +--rw rt:routing
      |  +--rw router-id?                 yang:dotted-quad
      |  +--rw control-plane-protocols
      |     +--rw control-plane-protocol* [type name]
      |        +--rw ospf:ospf
      +--rw other:other-container  // augmented by module "other"
      |  +--rw other-leaf?                 int32

> 
> > > Then consider:
> > >
> > >   +--ro if:interfaces@
> > >
> > > and
> > >
> > >   +--ro if:interfaces
> > >      +-- if:interface@
> > >
> > > and
> > >
> > >   +--ro if:interfaces@
> > >      +-- if:interface@
> > >
> > >
> > > Which ones are legal, and what do they mean?
> > >
> > [Xufeng] The display shows the result of the XPath, right?
> 
> I don't know what it shows; I'm not proposing this notation.  Also note that the
> result of the XPath is a node set of *instance data*, but the tree shows the
> *schema*, and mixing the two is confusing.
> 
> Hopefully by looking at the trees above, the reader will understand what's
> behind this notation.  So I ask again, what do the notations above mean?
> 
> > Whether
> > they are legal or not should be determined by the schema-mount draft,
> > not by the displaying notation.
> 
> The schema mount draft does not specify the rules for the '@' in the tree output.
> 
> --
> 
> My points are that:
> 
>   (1)  "/" is redundant and not needed.  The same information can be
>        conveyed w/o "/".
> 
>   (2)  "@" is under specified, and it mixes schema and instance data.
[Xufeng] I agree that we should have "@" fully specified, but I'd hope that it won't get dropped so that there won't be a convenient way to tell whether a node is a parent-reference or not.

Thanks,
- Xufeng

> 
> 
> 
> /martin
> 
> 
> 
> 
> 
> 
> >
> > >
> > >
> > > /martin
> > >
> > > While the former enhancement
> > > > provided details, the schema mount tree designations are every bit
> > > > as important as knowing, for example, whether or not a schema leaf
> > > > is a presence node.
> > > >
> > > > Thanks,
> > > > Acee
> > > >
> > > >
> > > > On 9/15/17, 9:56 AM, "Acee Lindem (acee)" <acee@cisco.com> wrote:
> > > >
> > > > >+1 - Also it is hard enough to format the tree output to fit in a
> > > > >+draft
> > > > >w/o further annotations (even with —-tree-line-length).
> > > > >Thanks,
> > > > >Acee
> > > > >
> > > > >
> > > > >On 9/15/17, 6:21 AM, "netmod on behalf of Ladislav Lhotka"
> > > > ><netmod-bounces@ietf.org on behalf of lhotka@nic.cz> 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.
> > > > >>
> > > > >>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
> > > > >>--
> > > > >>Ladislav Lhotka
> > > > >>Head, CZ.NIC Labs
> > > > >>PGP Key ID: 0xB8F92B08A9F76C67
> > > > >>
> > > > >>_______________________________________________
> > > > >>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
> >