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

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Sun, 29 October 2017 18:52 UTC

Return-Path: <j.schoenwaelder@jacobs-university.de>
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 A856A13FB0D for <netmod@ietfa.amsl.com>; Sun, 29 Oct 2017 11:52:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 jQODhAq4sRUz for <netmod@ietfa.amsl.com>; Sun, 29 Oct 2017 11:52:26 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A65813FB0A for <netmod@ietf.org>; Sun, 29 Oct 2017 11:52:26 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 50648E90 for <netmod@ietf.org>; Sun, 29 Oct 2017 19:52:24 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id FsUk95OafrkB for <netmod@ietf.org>; Sun, 29 Oct 2017 19:52:21 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS for <netmod@ietf.org>; Sun, 29 Oct 2017 19:52:23 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DF13B2010F for <netmod@ietf.org>; Sun, 29 Oct 2017 19:52:23 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id UV3mlyHfJ9-K; Sun, 29 Oct 2017 19:52:23 +0100 (CET)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 639ED2010E; Sun, 29 Oct 2017 19:52:23 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 7648F414231B; Sun, 29 Oct 2017 19:50:57 +0100 (CET)
Date: Sun, 29 Oct 2017 19:50:57 +0100
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: netmod@ietf.org
Message-ID: <20171029185057.hecz7vgul343tjki@elstar.local>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: netmod@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: NeoMutt/20170714 (1.8.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/YSp73XKdJlzFEUW8ES2CxZQSgHk>
Subject: [netmod] review of draft-ietf-netmod-yang-tree-diagrams-02
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: Sun, 29 Oct 2017 18:52:29 -0000

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.

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

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

- 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').

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

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

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

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>