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

Martin Bjorklund <mbj@tail-f.com> Mon, 30 October 2017 15:11 UTC

Return-Path: <mbj@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 E4C1E13FA5B for <netmod@ietfa.amsl.com>; Mon, 30 Oct 2017 08:11:37 -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, SPF_PASS=-0.001, 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 NcgfD0FGP2Kx for <netmod@ietfa.amsl.com>; Mon, 30 Oct 2017 08:11:27 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C4D8613F547 for <netmod@ietf.org>; Mon, 30 Oct 2017 08:10:55 -0700 (PDT)
Received: from localhost (unknown [173.38.220.41]) by mail.tail-f.com (Postfix) with ESMTPSA id DFC7E1AE01AA; Mon, 30 Oct 2017 16:10:53 +0100 (CET)
Date: Mon, 30 Oct 2017 16:09:29 +0100 (CET)
Message-Id: <20171030.160929.235441604951701829.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: netmod@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <20171030150556.frebbljyv26buiub@elstar.local>
References: <20171029185057.hecz7vgul343tjki@elstar.local> <20171030.153656.1325329737662426135.mbj@tail-f.com> <20171030150556.frebbljyv26buiub@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: <https://mailarchive.ietf.org/arch/msg/netmod/zaVwGYF89GIKaoG5n1pkxXXV_js>
Subject: Re: [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: Mon, 30 Oct 2017 15:11:38 -0000

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> On Mon, Oct 30, 2017 at 03:36:56PM +0100, Martin Bjorklund wrote:
> > > - 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?
> 
> I would hope that nobody ever comes up with the idea of writing
> programs to parse tree diagrams, hence I am fine with a rather liberal
> definition (and I also do not care about the exact number of spaces
> but I if it helps to describe the indentation rules then OK).
> 
> > > - 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"?
> 
> Isn't is a mounted schema tree?

Whoops, yes:   "Representation of Mounted Schema 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
> > recursively.
>  
> > > - 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.
> 
> RFC 6087bis would still point to the tree diagram if you apply the
> edits above but it would no do anything more than that.

Ok.


/martin