> On 15 Aug 2016, at 13:31, William Lupton <wlup...@broadband-forum.org> wrote: > > Ah! Re-reading it I think that you are correct. In this spirit I propose the > change shown below. I believe that all this does is (a) generalise, and (b) > clarify. I don’t believe that it changes the intended meaning. > > OLD: > > 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. > > NEW: > > It is acceptable to reuse the same revision statement within unpublished > versions (e.g., Internet-Drafts), but the revision date (i.e., the revision > statement’s argument) MUST be updated to a higher value each time a new > version (e.g., of the Internet-Draft) is posted.
It seems strange to talk about reusing the revision statement and, in the same sentence, require to change its argument. What about this: NEW It is not required to keep the revision history of unpublished versions (e.g., Internet-Drafts). That is, within a sequence of unpublished versions, only the most recent revision MAY be recorded in the module or submodule. However, the revision date of the most recent revision MUST be updated to a higher value each time a new version (e.g., of the Internet-Draft) is posted. Lada > > —— > > Comments? > >> On 11 Aug 2016, at 17:26, Randy Presuhn <randy_pres...@alumni.stanford.edu> >> wrote: >> >> Hi - >> >> I read the text as intended to make a distinction between the *date* portion >> and the rest >> >> of the revision statement. When a module is under development, retaining a >> history >> >> of specific incremental changes isn't terribly helpful, but changing the >> date is essential >> >> to helping tools decide among the versions floating around in the lab. >> >> >> Randy (experimenting with mail readers, please forgive formatting anomalies) >> >> >> On 8/11/2016 9:17 AM, William Lupton wrote: >>> Thanks. e.g rather than i.e sounds good, BUT my point (sorry if that wasn’t >>> clear) is that this sentence seems to be contradictory. It says: >>> >>> 1. Unpublished versions, i.e IDs, can reuse revision statements. >>> 2. IDs MUST update their revision dates each time they are re-posted. >>> >>> My suggestion of removing the parenthesised text was to remove this >>> contradiction. Right now I’m not clear that I can rely on revision dates in >>> YANG modules contained within IDs. >>> >>> William >>> >>> PS, I think that the removal of this text removes the contradiction because >>> in order to make sense of the sentence the reader will be forced to the >>> conclusion that IDs are not regarded as being “unpublished”. >>> >>>> On 11 Aug 2016, at 17:07, Randy Presuhn <randy_pres...@alumni.stanford.edu >>>> <mailto:randy_pres...@alumni.stanford.edu>> wrote: >>>> >>>> Hi - >>>> >>>> The situation with Internet-Drafts is what motivated this text in the >>>> first place, so >>>> I think it is important to retain that information. However, it seems to >>>> me that >>>> the "i.e." is too limiting, and should be replaced with an "e.g.". >>>> >>>> Randy >>>> >>>> On 8/11/2016 2:06 AM, William Lupton wrote: >>>>> All, >>>>> >>>>> The text at the bottom of RFC 6087bis (draft 07) Section 5.8 seems >>>>> unclear: >>>>> >>>>> "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” >>>>> >>>>> Assuming that the intent is that the revision statements in YANG models >>>>> contained within IDs must be updated whenever the models are updated, >>>>> wouldn’t it be clearer if the parenthesised text "(i.e., >>>>> Internet-Drafts)” was deleted? >>>>> >>>>> Thanks, >>>>> William > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
