Re: [netmod] choice/case in tree diagrams

Per Hedeland <per@tail-f.com> Mon, 05 March 2018 17:40 UTC

Return-Path: <per@tail-f.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 0250912DA14 for <netmod@ietfa.amsl.com>; Mon, 5 Mar 2018 09:40:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 ehtORBFdL6Zu for <netmod@ietfa.amsl.com>; Mon, 5 Mar 2018 09:40:11 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DF8C312D96C for <netmod@ietf.org>; Mon, 5 Mar 2018 09:40:10 -0800 (PST)
Received: from mars.tail-f.com (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id 85C8D1AE02EF for <netmod@ietf.org>; Mon, 5 Mar 2018 18:40:09 +0100 (CET)
To: netmod@ietf.org
References: <20180305134934.neam7t2snb2wdvon@elstar.local> <20180305.145418.2010818875235650756.mbj@tail-f.com> <20180305141355.gi6kfej3eifdxtjq@elstar.local> <20180305.152602.113020152789243398.mbj@tail-f.com> <1520260878.7198.28.camel@nic.cz> <114ab291-27d2-2aa5-1327-23d80d35cc9f@tail-f.com> <1520262414.7198.35.camel@nic.cz>
From: Per Hedeland <per@tail-f.com>
Message-ID: <6a1ed43f-398b-4538-52aa-d7f8c219047e@tail-f.com>
Date: Mon, 5 Mar 2018 18:40:08 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <1520262414.7198.35.camel@nic.cz>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/imR2ogKnbPOmAAIe0Pu2ZpVvr8M>
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: Mon, 05 Mar 2018 17:40:13 -0000

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.

--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