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

[Juergen Schoenwaelder <[e-mail]>]

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?

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

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>