> On 15 Jan 2016, at 15:10, Andy Bierman <a...@yumaworks.com> wrote: > > > > On Fri, Jan 15, 2016 at 3:55 AM, Ladislav Lhotka <lho...@nic.cz> wrote: > > > On 15 Jan 2016, at 12:49, Juergen Schoenwaelder > > <j.schoenwael...@jacobs-university.de> wrote: > > > > On Fri, Jan 15, 2016 at 12:39:16PM +0100, Ladislav Lhotka wrote: > >> > >> Does this solve any practical problem? Modules are imported based on > >> the module name and revision. On the other hand, it does create new > >> problems: > >> namespace URIs and their mappings to prefixes may be spread in many > >> places in the code, and these would have to be manually edited after an > >> I-D -> RFC transition. > >> > >> It would IMO be much better to use revision numbers rather than dates, > >> and adopt a convention, e.g., that modules in the I-D stage have > >> revisions 0.x that get bumped with each new revision of the I-D. > >> > > > > Lada, this is not how our current YANG 1.0 versioning and revision > > rules work and we are not going to change them in YANG 1.1 either. > > The rules we have do make a distinction between published modules and > > modules that are unpublished. > > I am not proposing it. The problem I'd like to get solved is proper module > revisioning already at the I-D stage so that implementations be able to > distinguish one revision from another. Appending DRAFT to the namespace URI > doesn't help anything. > > > > Changing the module name constantly does not help. > It would be better to just keep using revision dates.
Some I-Ds don't do even that, for example acl-model uses the same revision date in subsequent I-D revisions. I checked that this actually violates a MUST in RFC 6087. Lada > > > Lada > > > > Andy > > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 <http://www.jacobs-university.de/> > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
