Re: [netmod] tree diagram guidelines

"Joel M. Halpern" <> Fri, 08 December 2017 01:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2BE71129501 for <>; Thu, 7 Dec 2017 17:05:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XwDrlde42Qpa for <>; Thu, 7 Dec 2017 17:04:53 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DEB5A12762F for <>; Thu, 7 Dec 2017 17:04:53 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id C6EA734008E for <>; Thu, 7 Dec 2017 17:04:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=1.tigertech; t=1512695093; bh=WBVu1oDegizaIu2xkT1BFcPF9d7wSIjO0WJGhifOIuQ=; h=Subject:To:References:From:Date:In-Reply-To:From; b=Z8bLn4fIK7Kt5fQPD/fP0M94YtaadN3WOVTMNo4XCAMrGm5iw85Lo4MfKjZ0p0s6J 6MrU364qNgW9opwjLWSo/7jcylpwXDGR0LJL9/E1vziJg7EbeIjz2vjiogx0YjgSh2 Ut3JyjTlrU65n7Q1oGUN+gclF1XLLmsGiBlVPehk=
X-Virus-Scanned: Debian amavisd-new at
Received: from Joels-MacBook-Pro.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1C986240C7A for <>; Thu, 7 Dec 2017 17:04:52 -0800 (PST)
References: <> <> <> <014a01d35e87$98797950$c96c6bf0$> <> <20171117070043.pm7rn25yj3hxum3q@elstar.local> <>
From: "Joel M. Halpern" <>
Message-ID: <>
Date: Thu, 7 Dec 2017 20:04:52 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [netmod] tree diagram guidelines
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: Fri, 08 Dec 2017 01:05:01 -0000

     I have been watching this discussion of referencing the wiki page 
from the RFC-to-be about tree diagrams.  I must admit that I am confused 
as to why we would want to do so.

     For anyone writing a document with a YANG tree, what they are 
required to do is what is in this RFC.  While the wiki page may be 
interesting, it is not normative.
     For anyone reading an RFC that uses a Tree diagram (a significantly 
larger number of people), what they need to know is in the RFC.  Reading 
the wiki not only is not normative, it may well have content that was 
not even present when the RFC that they are reading was written.  In 
fact, the content of the wiki may contradict what is in the RFC they are 
reading, without indicating any errors having been made.  Which I fear 
may be confusing to the reader.

     I understand and support wanting to make it easy for readers to 
find the wiki of ongoing discussions of YANG tree diagrams (and other 
issues.)  But it seems like this is the wrong way to achieve the goal.


On 12/7/17 6:38 PM, Lou Berger wrote:
> Hi,
> Following up on this discussion (and hoping to wrap it up):
> I have created two  wikis off of
>, one for 6087bis
> content and the other for section 3 of tree diagrams.  I also propose
> the following changes to the tree-diagrams draft:
> To section 3 intro, add:
>      For the most current quidelines being developed, please see the IETF
> NetMod Working
>     Group Wiki, see:
> Add :
>    3.2.  Groupings
>     If the YANG module is comprised of groupings only, then the tree
>     diagram should contain the groupings.  The 'pyang' compiler can be
>     used to produce a tree diagram with groupings using the "-f tree --
>     tree-print-groupings" command line parameters.
> And to section 3.3, start with:
>     Tree diagrams can be split into sections to correspond to document
>     structure.
> For 6087 bis, I think section 3.4 gets replaced with something like.
>      YANG tree diagrams provide a concise representation of a YANG module,
>     and SHOULD be included to help readers understand YANG module
>      structure.  Guidelines on tree diagrams can be found in Section 3 of
>      [I-D.ietf-netmod-yang-tree-diagrams].
> These changes can be found at:
> This leaves the intended status as the key open issue on the draft.
> Lou
> On 11/17/2017 2:00 AM, Juergen Schoenwaelder wrote:
>> I am confused. I think there was some consensus to
>> - include all tree related guidelines in the tree document, remove all tree
>>    related guidelines from 6087bis and have 6087bis point to the tree document
>>    (which it already does)
>> The rest is pointless since AFAIK there is no wiki guidelines pages to
>> point to and there is AFAIK nobody in place to actually maintain such
>> a wiki page. Perhaps a wiki is the future but until future has
>> arrived, we should not point to it.
>> The other proposal I heard was to have a landing page that points to
>> the current guideline work which points to the relevant documents. A
>> wiki pointing to RFCs and ID, not RFC pointing to wikis. So this does not
>> affect the documents.
>> /js
>> PS: I am happy to add pointers to guidelines as a section to the
>>      wikipedia page.
>> On Fri, Nov 17, 2017 at 07:42:33AM +0800, Lou Berger wrote:
>>> To circle back to this.  My sense of this discussion (as contributor) is
>>> (a) the tree diagrams draft should be updated to point to a "guidelines"
>>> wiki page for "the most current guidelines"
>>> (b) the tree diagrams draft should be updated to include a full set of the
>>> current tree related guidelines
>>> (c) 6087bis should be updated to point to a "guidelines" wiki page for "the
>>> most current guidelines"
>>> (d) 6087bis should have it's tree guidelines point to the tree diagrams
>>> document -- in addition to pointing to the wiki
>>> Does this sound right?
>>> Lou
>>> (as tree co-author)
>>> On 11/16/2017 11:04 AM, Mehmet Ersue wrote:
>>>> The Wiki is useful as a starting point providing a collection of pointers to guideline RFCs and the bis-revisions in development.
>>>> Cheers,
>>>> Mehmet
>>>>> -----Original Message-----
>>>>> From: netmod [] On Behalf Of Mahesh
>>>>> Jethanandani
>>>>> Sent: Thursday, November 16, 2017 7:39 AM
>>>>> To: Robert Wilton <>
>>>>> Cc:
>>>>> Subject: Re: [netmod] tree diagram guidelines
>>>>> Other SDOs can and follow the work in IETF through the RFCs we publish.
>>>>> They do not follow wiki’s, unless the document itself says, “here are the
>>>>> guidelines, but if you are looking for the latest, go to this wiki”. I therefore
>>>>> would support the proposal outlined below. It gives the SDO a stable point of
>>>>> reference with a document, which gets updated occasionally, but also allows
>>>>> them to peak at what is coming down the pipeline.
>>>>> Thanks.
>>>>>> On Nov 15, 2017, at 6:53 PM, Robert Wilton <> wrote:
>>>>>> I liked the suggestion from Chris Hopps:
>>>>>> I think that it was along the lines of ...
>>>>>> The RFC contains a reference at the top that states that updates to the
>>>>> guidelines is available on a wiki at ....
>>>>>> Every few years the guidelines on the wiki can be folded into a latest
>>>>> version of the guidelines draft.
>>>>>> 6087bis looks to be 3.5 years old.  Should folks, e.g. at BBF,, IEEE, or MEF be
>>>>> using the latest draft guidelines, or should then use the published RFC until
>>>>> 6087bis is actually republshed?
>>>>>> Thanks,
>>>>>> Rob
>>>>>> On 15/11/2017 10:14, Martin Bjorklund wrote:
>>>>>>> Hi,
>>>>>>> There was a proposal in the meeting today to have the guidelines for
>>>>>>> tree diagrams in a wiki, instead of having them in 6087bis or in the
>>>>>>> tree diagram document.
>>>>>>> Was the proposal really to have a wiki for just the tree guidelines,
>>>>>>> or was the proposal to withdraw 6087bis from the process and instead
>>>>>>> publish all guidelines as a wiki?
>>>>>>> If it is the former, is it really worth it?
>>>>>>> Advantages with a wiki:
>>>>>>>     +  It can be updated more easily
>>>>>>> Some drawbacks:
>>>>>>>     -  It can be updated more easily
>>>>>>>        (meaning they are less stable)
>>>>>>>     -  Wikis tend to not be alive after some time, and are not that
>>>>>>>        easy to find.  Just try to find the various YANG-related wikis
>>>>>>>        we've tried to maintain over the years.
>>>>>>>     -  Links in RFCs also have problems.  Sites are re-orginized etc.
>>>>>>>        As an example, the link to the security guidelines template in
>>>>>>>        RFC 6087 doesn't work anymore.
>>>>>>>     -  People that are looking for a stable reference will have problems
>>>>>>>        (I think Rob mentioned that IEEE still refer to RFC 6087 (which
>>>>>>>        is understandable; that's the published version).
>>>>>>>     -  Who maintains the Wiki, and what are the rules for updating it?
>>>>>>> I suggest we have the tree-related guidelines (actually just a few
>>>>>>> sentences) in the tree draft, and since 6087bis already refers to
>>>>>>> this document it is not a big problem that guidelines are spread out
>>>>>>> over several documents that are difficult to find.
>>>>>>> /martin
>>>>>>> _______________________________________________
>>>>>>> netmod mailing list
>>>>>>> .
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>> Mahesh Jethanandani
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>> _______________________________________________
>>>> netmod mailing list
>>> _______________________________________________
>>> netmod mailing list
> _______________________________________________
> netmod mailing list