Re: [netmod] choice/case in tree diagrams

Lou Berger <lberger@labn.net> Tue, 06 March 2018 12:32 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 D16211276AF for <netmod@ietfa.amsl.com>; Tue, 6 Mar 2018 04:32:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 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=-0.001, 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 LnpnvTYuuZmX for <netmod@ietfa.amsl.com>; Tue, 6 Mar 2018 04:32:56 -0800 (PST)
Received: from gproxy6-pub.mail.unifiedlayer.com (gproxy6-pub.mail.unifiedlayer.com [67.222.39.168]) (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 C923C127735 for <netmod@ietf.org>; Tue, 6 Mar 2018 04:32:56 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 38DCE1E25C7 for <netmod@ietf.org>; Tue, 6 Mar 2018 05:17:58 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with id JcHu1x00P2SSUrH01cHxV5; Tue, 06 Mar 2018 05:17:58 -0700
X-Authority-Analysis: v=2.2 cv=ft6sXBwf c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=v2DPQv5-lfwA:10 a=wU2YTnxGAAAA:8 a=u07AKapRAAAA:8 a=e45He0E8AAAA:8 a=48vgC7mUAAAA:8 a=PzDixvQLSvBP6Jf_4xcA:9 a=6btrnREe0FY9zYBG:21 a=CQ4RqaeoHpjwhbDs:21 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=SkebfZ6J2Mmvk2rLHZle:22 a=cj7hvcB7Pb6S7jLLiKPa:22 a=w1C3t2QeGrPiZgrLijVG: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:From:References:Cc:To: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=mkjlDTwHRbb7mCpPz8dx4lQL0CpNAlYTNLNMvLiivlM=; b=GYrA0bKY1w7iGXCdGgwxMR0QmA TZTiC9IZegfTw6Iuwz/DwTpJWJ2jGL4ida0GhCJTvm5g7G9RIQ5uGR1FKE/3wkccKLlWSaAlQp4UQ kGkU2NZGuWbq/E5Qfs3IsR66n;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:57392 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from <lberger@labn.net>) id 1etBXW-000Xsu-16; Tue, 06 Mar 2018 05:17:54 -0700
To: Martin Bjorklund <mbj@tail-f.com>
Cc: vladimir@transpacket.com, netmod@ietf.org
References: <c9a60629-a1de-0b5b-77a0-595f614bcad8@transpacket.com> <20180306.104411.829341372037212681.mbj@tail-f.com> <161fb126c00.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180306.131026.1561571560543888812.mbj@tail-f.com>
From: Lou Berger <lberger@labn.net>
Message-ID: <38ac6129-fbd4-fad7-078a-14056260ee3d@labn.net>
Date: Tue, 6 Mar 2018 07:17:46 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180306.131026.1561571560543888812.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
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.86.101
X-Exim-ID: 1etBXW-000Xsu-16
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:57392
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/q1l0tssCUKGeN3_FydGx6ILlmjc>
Subject: Re: [netmod] choice/case in tree diagrams
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, 06 Mar 2018 12:33:00 -0000


On 3/6/2018 7:10 AM, Martin Bjorklund wrote:
> Lou Berger <lberger@labn.net> wrote:
>> Martin,
>>
>>
>> On March 6, 2018 4:44:47 AM Martin Bjorklund <mbj@tail-f.com> wrote:
>>
>>> Hi,
>>>
>>> After thinking some more about this, realizing that this document is
>>> in AUTH48, and looking at the first sentence in the Abstract:
>>>
>>>     This document captures the current syntax used in YANG module tree
>>>     diagrams.
>>>
>>> I have reached the conclusion that we probably shouldn't make any
>>> drastic changes.
>>>
>> I agree.
>>
>>> The current syntax, with flags for choice but not for case, may look a
>>> bit odd, but it does follow RFC 7950 where a choice node can have a
>>> config property, but case cannot.  Also, this syntax has now been used
>>> for several years w/o causing much confusion.
>>>
>>> I suggest the following changes to this document:
>>>
>>> OLD:
>>>
>>>         <flags> is one of:
>>>           rw  for configuration data
>>>           ro  for non-configuration data, output parameters to rpcs
>>>               and actions, and notification parameters
>>>           -w  for input parameters to rpcs and actions
>>>           -u  for uses of a grouping
>>>           -x  for rpcs and actions
>>>           -n  for notifications
>>>           mp  for nodes containing a "mount-point" extension statement
>>>
>>> NEW:
>>>
>>>         <flags> is one of:
>>>           rw  for configuration data
>>>           ro  for non-configuration data, output parameters to rpcs
>>>               and actions, and notification parameters
>>>           -w  for input parameters to rpcs and actions
>>>           -u  for uses of a grouping
>>>           -x  for rpcs and actions
>>>           -n  for notifications
>>>           mp  for nodes containing a "mount-point" extension statement
>>>
>>>           case nodes do not have any <flags>.
>>>
>>
>>> Then, since the syntax requires whitespace before <name>:
>>>
>> I think we should match current tooling/practice here as well. Can you
>> confirm how pyang works today?
>>
>> My memory is no such space is added.
> This is correct.
>
>> If my memory is correct, my
>> preference is to change the text rather then the tooling.
> Maybe we can simply do:
>
> OLD:
>
>      <name> is the name of the node
>        (<name>) means that the node is a choice node
>       :(<name>) means that the node is a case node
>
>        If the node is augmented into the tree from another module,
>        its name is printed as <prefix>:<name>, where <prefix> is the
>        prefix defined in the module where the node is defined.
>
> NEW:
>
>      <name> is the name of the node
>        (<name>) means that the node is a choice node
>       :(<name>) means that the node is a case node
>
>        If the node is augmented into the tree from another module,
>        its name is printed as <prefix>:<name>, where <prefix> is the
>        prefix defined in the module where the node is defined.
>
>        If the node is a case node, there is no space before the
>        <name>.
Looks good to me.

Thanks,
Lou

>
> /martin
>
>
>
>> Lou
>> (As contributor)
>>
>>>       <status>--<flags> <name><opts> <type> <if-features>
>>>
>>> we need to fix the examples:
>>>
>>> OLD:
>>>
>>>               +--rw (root-type)
>>>                  +--:(vrf-root)
>>>
>>> NEW:
>>>
>>>               +--rw (root-type)
>>>                  +-- :(vrf-root)
>>>
>>> (two occurances)
>>>
>>>
>>>
>>> /martin
>>>
>>>
>>>
>>> Vladimir Vassilev <vladimir@transpacket.com> wrote:
>>>>
>>>> On 03/05/2018 06:40 PM, Per Hedeland wrote:
>>>>> On 2018-03-05 16:06, Ladislav Lhotka wrote:
>>>>>> On Mon, 2018-03-05 at 15:49 +0100, Per Hedeland wrote:
>>>>>>> On 2018-03-05 15:41, Ladislav Lhotka wrote:
>>>>>>>> On Mon, 2018-03-05 at 15:26 +0100, Martin Bjorklund wrote:
>>>>>>>>> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>>>>>>>>> On Mon, Mar 05, 2018 at 02:54:18PM +0100, Martin Bjorklund wrote:
>>>>>>>>>>>> So it seems the running code got it right. ;-)
>>>>>>>>>>> As the author of that code, I think that was purely by accident...
>>>>>>>>>>>
>>>>>>>>>>> But I'm not convinced it is the correct solution.  We have one
>>>>>>>>>>> example
>>>>>>>>>>> in the other thread where someone was confused by the "rw" flag and
>>>>>>>>>>> thought that it implied that the node would be present in the data
>>>>>>>>>>> tree.
>>>>>>>>>>>
>>>>>>>>>> So what does rw mean?
>>>>>>>>>>
>>>>>>>>>> (i)  The schema node has a rw property.
>>>>>>>>>> (ii) The schema node can be instantiated and the instantiated data
>>>>>>>>>> node
>>>>>>>>>>        has a rw property.
>>>>>>>>>>
>>>>>>>>>> I think it is difficult to have both at the same time. If the tree
>>>>>>>>>> is
>>>>>>>>>> a representation of schema nodes, then (i) seems to make more
>>>>>>>>>> sense. That said, the explanation in 2.6 is somewhat vague since it
>>>>>>>>>> says 'data' and not 'nodes' (like everywhere else):
>>>>>>>>>>
>>>>>>>>>> OLD:
>>>>>>>>>>
>>>>>>>>>>          <flags> is one of:
>>>>>>>>>>            rw  for configuration data
>>>>>>>>>>            ro  for non-configuration data, output parameters to rpcs
>>>>>>>>>>                and actions, and notification parameters
>>>>>>>>>>
>>>>>>>>>> NEW:
>>>>>>>>>>
>>>>>>>>>>          <flags> is one of:
>>>>>>>>>>            rw  for configuration data nodes
>>>>>>>>>>            ro for non-configuration data nodes, output parameters to
>>>>>>>>>>            rpcs
>>>>>>>>>>                and actions, and notification parameters
>>>>>>>>> I think this is ok.  But that means that we also have to add:
>>>>>>>>>
>>>>>>>>>              --  for a choice or case node
>>>>>>>>>
>>>>>>>>> But in order to be consistent, we should probably have:
>>>>>>>>>
>>>>>>>>>              --  for a choice, case, input or output node
>>>>>>>> But unlike the three other statements, "choice" can have the config
>>>>>>>> substatement, so "rw/ro" makes sense there.
>>>>>>> I don't think so - that config statement does not a define a property
>>>>>>> of
>>>>>>> the choice node (it can obviously neither be read nor written), only a
>>>>>>> default for descendant data nodes, as described in section 7.21.1 of
>>>>>>> RFC
>>>>>>> 7950.
>>>>>> It is not a default - if a choice has "config false", then no
>>>>>> descendant can be
>>>>>> "config true". One of the benefits of having rw/ro in the ascii tree
>>>>>> is to see
>>>>>> where a state data subtree actually starts.
>>>>> It is a default, but yes, it is also a restriction in the specific
>>>>> case
>>>>> of the argument being "false" at a point where the default would
>>>>> otherwise be "true". And in that case it is equivalent to having
>>>>> "config
>>>>> false" on all the descendant data nodes, and they will of course be
>>>>> flagged as "ro" regardless of whether the "config false" comes from
>>>>> the
>>>>> choice or the individual data nodes - and that is where the state
>>>>> *data*
>>>>> suntree(s) actually start(s).
>>>>>
>>>>> So I guess the question then is whether this specific case motivates
>>>>> always having flags on specifically choice nodes, while the other
>>>>> non-data nodes have no flags. Since the 'config' statement is ignored
>>>>> in
>>>>> rpc/action input/output and notification, choice nodes there should
>>>>> then
>>>>> presumably have "-w"/"ro"/"-n". Personally I think the diagram is
>>>>> clearer with flags only on the data nodes.
>>>> When I think about it <flags> do not have any information contents
>>>> outside of the context of a data tree and its schema. So if we are
>>>> removing clutter we should probably start there by specifying that
>>>> <flags> should be ommited under rpc,notification and action.
>>>>
>>>> Vladlimir
>>>>> --Per
>>>>>
>>>>>> Lada
>>>>>>
>>>>>>> --Per
>>>>>>>
>>>>>>>> Lada
>>>>>>>>
>>>>>>>>> This means that the correct tree syntax for choice and case will be:
>>>>>>>>>
>>>>>>>>>        +-- (subnet)?
>>>>>>>>>           +-- :(prefix-length)
>>>>>>>>>           |  +--rw prefix-length?   uint8
>>>>>>>>>           +-- :(netmask)
>>>>>>>>>              +--rw netmask?         yang:dotted-quad
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> /martin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> The document (as far as I searched for it) does not clearly say that
>>>>>>>>>> 'node' means 'schema node'. In hindsight, it might have been useful
>>>>>>>>>> to
>>>>>>>>>> explicitely import terminology from RFC 7950 and to use it carefully
>>>>>>>>>> (RFC 7950 has 'schema node' and 'data node' but here we largely talk
>>>>>>>>>> about 'nodes' - and my assumption is that this means 'schema
>>>>>>>>>> nodes'.)
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>> _______________________________________________
>>>> 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
>>>
>>