Re: [netmod] tree diagrams - flags

worley@ariadne.com (Dale R. Worley) Tue, 21 March 2017 13:22 UTC

Return-Path: <worley@alum.mit.edu>
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 95234129493 for <netmod@ietfa.amsl.com>; Tue, 21 Mar 2017 06:22:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.933
X-Spam-Level:
X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 PLECKhMRVuJO for <netmod@ietfa.amsl.com>; Tue, 21 Mar 2017 06:22:13 -0700 (PDT)
Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (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 57EAF12989D for <netmod@ietf.org>; Tue, 21 Mar 2017 06:22:13 -0700 (PDT)
Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-05v.sys.comcast.net with SMTP id qJiNchQOaygj9qJjocvoyr; Tue, 21 Mar 2017 13:22:12 +0000
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-02v.sys.comcast.net with SMTP id qJjmca3YLgFBHqJjnc93fg; Tue, 21 Mar 2017 13:22:12 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v2LDM9xZ030580; Tue, 21 Mar 2017 09:22:09 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v2LDM8XV030576; Tue, 21 Mar 2017 09:22:08 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: rwilton@cisco.com, netmod@ietf.org
In-Reply-To: <E8B217D8-9961-49ED-B035-D16CDE957270@nic.cz> (lhotka@nic.cz)
Sender: worley@ariadne.com
Date: Tue, 21 Mar 2017 09:22:07 -0400
Message-ID: <87a88evk74.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfHGaGdee0gyxPdeqh1eksqFoLxXOA0Yxq50hKFySNo61DpwssqTerrtNLr+2L59aorIX6vrzdmOVqimQFDUzB6UlpuKEVaqqZoA6hL4FPF+jnlub17Jj u2bdMPwWAz693IE0uZsvRi4vcdEIHtasnDNJNPNtSSFKXTEx0Rfx0d7HvdfcPExW2K0CONN1RCc+7uzdVRL09m0dAGdQZPShNW8=
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/WAWqnZBFyof9-orOULNG2FlI5vo>
Subject: Re: [netmod] tree diagrams - flags
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, 21 Mar 2017 13:22:15 -0000

Ladislav Lhotka <lhotka@nic.cz> writes:
> I think the "x" and "n" is only needed next to the name of rpc/action/notification. So my version would be:
>
> <flags> is one of:
>   c  for configuration data
>   x  for rpcs and actions
>   n  for notifications
>
> module: tree-sample
>   +--c config-true-container
>   |  +--c param?   string
>   +--- config-false-container
>   |  +--- value?   string
>   +--c inline-action
>   |  +--x action
>   |     +--- input
>   |     |  +--- in?   string
>   |     +--- output
>   |        +--- out?   string
>   +--c inline-notification
>      +--n notification
>         +--- duration?   string

Naively, it seems to me that "c" for configuration and "s" for state
makes a great deal of sense.  ("cf" for state ("config=false") is
hazardous as "cf" is a natural contraction of "configuration".)
config/state is a somewhat messy distinction as the transition between
them can happen anywhere in the tree.

For RPCs, actions, and notifications, using a flag only for their top
nodes makes sense, because that makes it easy to find their top nodes,
and any node under them can only be assessed based on where it is
relative to the top node.

One thing that threw me the first time I saw it is marking lists with
"*".  That doesn't match the generic use of "*", which is to mark the
thing that is repeated.  (Compare using "?" to mark an optional thing,
which does match the generic usage.)  But in the context of Yang, you
don't want to flag the items in the list with "*", that would make the
tree harder to read.

I support having a rigid and consistent standard for indentation and
where the descending lines are placed under the parent nodes --
consistency in formatting allows one to train one's eye to parse the
diagram reflexively rather than having to pause and mentally group the
items into a structure.

Dale