Re: [netmod] choice/case in tree diagrams

Vladimir Vassilev <vladimir@transpacket.com> Tue, 06 March 2018 09:08 UTC

Return-Path: <vladimir@transpacket.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 BDE13124D37 for <netmod@ietfa.amsl.com>; Tue, 6 Mar 2018 01:08:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 JDR1nwrJ92Oy for <netmod@ietfa.amsl.com>; Tue, 6 Mar 2018 01:08:16 -0800 (PST)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D75B3126DFB for <netmod@ietf.org>; Tue, 6 Mar 2018 01:08:09 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 4256F1424C22; Tue, 6 Mar 2018 10:08:07 +0100 (CET)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ZrE8PGIskbiY; Tue, 6 Mar 2018 10:08:07 +0100 (CET)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 147821424C44; Tue, 6 Mar 2018 10:08:07 +0100 (CET)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id DemRmK9rNfWs; Tue, 6 Mar 2018 10:08:07 +0100 (CET)
Received: from [192.168.209.122] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id E47411424C22; Tue, 6 Mar 2018 10:08:06 +0100 (CET)
To: Per Hedeland <per@tail-f.com>, "netmod@ietf.org" <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> <6a1ed43f-398b-4538-52aa-d7f8c219047e@tail-f.com>
From: Vladimir Vassilev <vladimir@transpacket.com>
Message-ID: <c9a60629-a1de-0b5b-77a0-595f614bcad8@transpacket.com>
Date: Tue, 6 Mar 2018 10:08:06 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0
MIME-Version: 1.0
In-Reply-To: <6a1ed43f-398b-4538-52aa-d7f8c219047e@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: nb
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/IWjidFtYQPsAoAXEwUGfbWB7HMw>
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 09:08:19 -0000


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