On Wed, Mar 8, 2017 at 8:40 AM, Ladislav Lhotka <[email protected]> wrote:
> > > On 8 Mar 2017, at 16:05, Lou Berger <[email protected]> wrote: > > > > Martin, Juergen, > > > > > > On March 7, 2017 8:08:26 PM Martin Bjorklund <[email protected]> wrote: > > > >> Juergen Schoenwaelder <[email protected]> wrote: > >>> On Fri, Mar 03, 2017 at 04:41:44PM +0000, Kent Watsen wrote: > >>>> > >>>> All, > >>>> > >>>> Lou and I were discussing how it seems unnecessary that every draft > >>>> has the same boilerplate text regarding how to interpret tree diagram > >>>> notations. It would be nice if drafts could instead just reference > >>>> another draft that contains this information. Does this make sense? > >>>> > >>>> Assuming we're interested in having such a reference, we could define > >>>> a mini-RFC or, perhaps, leverage Section 3 of 6087bis (YANG Tree > >>>> Diagrams). Either way, we'd want/need to ensure the information > >>>> is updated in a timely manner. > >>>> > >>>> Two reasons for why we may not want to pursue this are: > >>>> 1) we can’t update the reference fast enough > >>>> 2) drafts might add some proprietary annotations > >>>> > >>>> Is this worth pursuing at all? > >>> > >>> This has been discussed before. The tree format that tools generate > >>> has evolved a bit over time and the current setup allows to have some > >>> evolution. The question is whether we have reached a state where the > >>> evolution has come to standstill and we can nail a common tree format > >>> down. > > > > I don't see that as the question at all - the issue for me is needing to > > parse each document to see if and how it differs from the norm and then > > figuring out if the differences are (a) a bug, (b) limited to the > > specific document, (c) something that is a basic change that should > > impact tools (i.e., pyang) and other documents. > > > >> > >> I don't think so. For example, it was recently suggested that a > >> notion for "mount-points" should be defined. > >> > > > > Yes, and it is our (Martin, Lada and my) conversation in that context > > that prompted this discussion. > > > >> I don't think this is a big problem. > > > > Again, I do see this as an issue worth solving and am appreciative that > > 6087bis is available to easily provide a stable reference until such > > time as an update/replacement is needed. > > If the format itself isn't stable, how can 6087bis (after it becomes an > RFC) provide a stable reference? > > I agree with Juergen and Martin and don't mind having the section about > tree symbols in each document that needs it. > > The text in question is in section 4.3: If YANG tree diagrams are used, then a sub-section explaining the YANG tree diagram syntax MUST be present, containing the following text: A simplified graphical representation of the data model is used in this document. *The meaning of the symbols in these diagrams is defined in [RFCXXXX].* -- RFC Editor: Replace XXXX with RFC number and remove note Given that work on YANG 1.2 is likely to begin just after YANG 1.1 was published, it is hard to pretend that this is a stable language. So I agree this text should be replaced with new text that reflects the lack of a stable reference. Suggested Text: OLD: If YANG tree diagrams are used, then a sub-section explaining the YANG tree diagram syntax MUST be present, containing the following text: A simplified graphical representation of the data model is used in this document. The meaning of the symbols in these diagrams is defined in [RFCXXXX]. NEW: If YANG tree diagrams are used, then a sub-section explaining the YANG tree diagram syntax MUST be present, explaining the symbols in the diagram. The actual text will depend on the version of the YANG tree diagram syntax used in the document. Lada Andy > > > > Lou > > > >> > >> > >> /martin > >> _______________________________________________ > >> netmod mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
