On Fri, Jan 15, 2016 at 7:38 AM, Robert Wilton <rwil...@cisco.com> wrote:
> > > On 15/01/2016 15:20, Ladislav Lhotka wrote: > >> On 15 Jan 2016, at 15:49, Andy Bierman <a...@yumaworks.com> wrote: >>> >>> >>> >>> On Fri, Jan 15, 2016 at 6:19 AM, Ladislav Lhotka <lho...@nic.cz> wrote: >>> >>> 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. >>> >>> >>> >>> If the YANG module does not change from one I-D to the next, >>> then the revision date does not need to change. >>> >> 6087(bis) says: >> >> It is acceptable to reuse the same revision statement within >> unpublished versions (i.e., Internet-Drafts), but the revision date >> MUST be updated to a higher value each time the Internet-Draft is re- >> posted. >> >> I think it is a good idea. >> > It also think that it is a good idea. > > Since an ID is effectively superseded by any new versions, I think that it > is useful if a module defined in an ID has a revision date that matches the > published ID, and also a reference back to the ID version that defines it. > At least if someone ends up implementing that module they can check its > provenance. Both of these properties would also be verifiable by idnits. > > this seems like a good idea. Rob > > Andy
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
