On Fri, Dec 18, 2015 at 12:23 PM, Nadeau Thomas <[email protected]> wrote:
> > On Dec 18, 2015:3:00 PM, at 3:00 PM, Andy Bierman <[email protected]> > wrote: > > > > On Fri, Dec 18, 2015 at 11:49 AM, Nadeau Thomas <[email protected]> > wrote: > >> >> On Dec 18, 2015:11:06 AM, at 11:06 AM, Andy Bierman <[email protected]> >> wrote: >> >> >> >> On Fri, Dec 18, 2015 at 7:49 AM, Ladislav Lhotka <[email protected]> wrote: >> >>> Hi, >>> >>> if we want people to take YANG modules appearing in I-Ds seriously and >>> implement them, then we should apply the revisioning rules to them. That >>> is, if a module changes between two I-D revisions, then its revision-date >>> has to be bumped and a new entry added to the revision history. As it is >>> now, the I-D-based modules are esentially revisionless. >>> >>> >> >> The revision rules only apply to published modules. >> In IETF-speak, that means an RFC. An Internet Draft >> is a work-in-progress. We update the revision date every time >> the module changes, but the numerous incremental changes >> for a work-in-progress should not be recorded in the module >> revision history. They should be recorded in the Change Log appendix. >> >> I will try to make this procedure more clear in the YANG guidelines draft. >> >> >> The question is one of “published”. So at the IETF that means an RFC >> today, but Lada makes a good point in that in our new rapid development >> environment we may never get to RFCs for most of the models being worked >> on today - or not for some time. If we want those I-Ds to be used in >> production, it might make sense to define an I-D as “published”. >> >> As I pointed out earlier, for other organizations, they have different >> definitions of “published”, so we should consider a more flexible >> definition of >> “published” to encompass those. Its probably not a big deal to just say >> something like, “other organizations that define models will define their >> own definition of stable/published, and in those cases, that will >> suffice as the threshold for a version and following the updating >> rules described herein." >> > > > I think we should just try to focus on our own standards development > process. > Other organizations can adopt or reject IETF practices if they want. > We are using the same definition of published for about 25 years. > It means RFC in our process. In a vendor environment, it means modules > released to customers. > > We don't have a rapid development environment in the IETF. > If people want to implement half-baked YANG modules, that is their > business. > They should be commended if they actually provide implementation feedback > into the RFC, but a work-in-progress is not a published module. > > > That isn’t the point; the rest of the Yang universe looks to the IETF > to standardize and manage the Yang lanague and also looks here > for rules or best practices on building modules. > I don't really understand the confusion here. Modules under development change constantly. Almost all the changes are illegal for published modules. Each SDO has a concept of unfinished work and finished work. It should be easy to understand that the change rules apply to finished work. > —Tom > > > Andy > > > >> —Tom >> > > > Andy > > >> >> >> >> >> >> >>> Lada >>> >>> >> Andy >> >> >> >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>> >>> >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/netmod >>> >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
