> On 8 Mar 2017, at 16:05, Lou Berger <lber...@labn.net> wrote: > > Martin, Juergen, > > > On March 7, 2017 8:08:26 PM Martin Bjorklund <m...@tail-f.com> wrote: > >> Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> 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. Lada > > Lou > >> >> >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
