Lada,
On 3/8/2017 11:40 AM, Ladislav Lhotka 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? huh? - any RFC can be updated per normal process whenever appropriate. > I agree with Juergen and Martin and don't mind having the section about tree > symbols in each document that needs it. I completely disagree - it means we constantly need to do diffs. There's a good reason to reference prior work when *not* changing something which shows up, in this case in potentially 10s if not 100s of drafts. This allows *everyone* to immediately notice when something new or unique is done. (I'll have to find it, but I really loved the RFC that used a well known term, but then redefined it for that one and only document -- why do we want to allow this???) What benefit comes from defining tree syntax by reference? BTW if you/the WG prefers for the definition to be in its own document, that would work too. Lou > Lada > >> 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
