Re: [netmod] review of draft-ietf-netmod-yang-tree-diagrams-02

Martin Bjorklund <> Mon, 30 October 2017 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 35D4313F9E4 for <>; Mon, 30 Oct 2017 07:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uLmC7XD5PgcN for <>; Mon, 30 Oct 2017 07:38:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 1EFC213FA24 for <>; Mon, 30 Oct 2017 07:38:23 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTPSA id 48AE31AE01AA; Mon, 30 Oct 2017 15:38:21 +0100 (CET)
Date: Mon, 30 Oct 2017 15:36:56 +0100 (CET)
Message-Id: <>
From: Martin Bjorklund <>
In-Reply-To: <20171029185057.hecz7vgul343tjki@elstar.local>
References: <20171029185057.hecz7vgul343tjki@elstar.local>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [netmod] review of draft-ietf-netmod-yang-tree-diagrams-02
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 30 Oct 2017 14:38:49 -0000


Thank you for this review!  Comments inline.

Juergen Schoenwaelder <> wrote:
> Hi,
> I have reviewed draft-ietf-netmod-yang-tree-diagrams-02 and here are
> my comments (in document order).
> - I am not sure this is correct:
>   YANG Tree Diagrams were first published in [RFC7223].  Such diagrams
>   I think NACM (RFC 6536) already has a tree diagram. This makes for a
>   difference of ~2 years. Note sure this matter much however.

I'll fix this.

> - Do we have to speak more specifically about 'schema tree diagrams'?
>   Note that there can be many more 'tree' diagrams, like instance tree
>   diagrams, identity derivation diagrams, type derivation diagrams,
>   import relationship diagrams, ... and perhaps it makes sense to
>   allow for other diagrams to be defined over time.

I agree that there can be different types of tree.  I have to think
about this and discuss with my co-author.

> - Should we use 'sibling nodes' instead of 'peer nodes'? I think
>   the term 'sibling' is used in RFC 7950.


> - Are the empty lines mandatory or can empty lines added as one sees
>   fit? In particular, is there an empty line after the module: line?
>   Is there an empty line before each section of different top-level
>   symbols? Does the order of top-level symbols matter? Do we really
>   want to specify these details? Well, for indentation, things are
>   pretty specific so I wonder what the general strategy is here.

For indentation, spaces a specified b/c they matter (ok, we *could*
specify some more flexible indentation rules).  Blank line do not
matter.  Do you think we should say something about this?

> - There was already some discussion about having a way to not always
>   expand groupings by showing uses nodes. I think this makes sense in
>   certain situations (possible <flags> '-u').

Ok, I also think we should add something like this.

> - What are 'data modules'? This term does not appear in schema mount
>   I think. Perhaps you wanted YANG modules instead?


> - s/realted/related/


> - I think Section 4.1 is not about representing _instance_ data
>   trees. It is describing how a schema mounted schema looks like - and
>   I think this is OK. I think this document should not specify
>   instance tree formats. So change the title of section 4.1 or simply
>   delete the subsection title entirely.

I agree.  How about "Representation of Mounted Data Trees"?

> - If a schema mount point is used for a readonly mount, then I
>   understand that only the toplevel changes to ro. Is this useful or
>   potentially misleading? Was the alternative considered to change all
>   nodes recursively to ro? I assume they are all effectively ro in
>   this case.

Hmm, I'll check w/ my co-author.  I think it should be changed

> - If the WG wants to include tree diagram usage guidelines in this
>   document, then I think we should (if we still manage) take tree
>   diagram related text out of 6087bis before it is cast into
>   stone. Changes to 6087bis would be:
>   - Change the subsubstitle "2.5.1.  YANG Tree Diagrams" to "2.6.
>     YANG Tree Diagrams" (since the definition is in an external
>     document, I think this should not be nested in 2.5 anymore).
>   - Remove section 3.4.
>   - Remove this from section 8 (which is not quite correct anymore
>     anyway since the definition moved to a separate document).
>        o  Added YANG tree diagram definition and guideline
>   Since two are bug fixes anyway (I think), I think it makes sense to
>   get 6087bis fixed so that the tree diagram usage text is in one
>   place.

I have no strong opinion, but I think I prefer to have the guidelines
for tree diagrams in the tree diagram draft.  Maybe 6087 can point to
this document.