> On 31 Aug 2016, at 13:17, William Lupton <wlup...@broadband-forum.org> wrote: > > I like this. In particular I like the clean use of “version” and “revision”. > Editorial nit: add a comma after “i.e.” because that’s the style used for > “e.g.”. Tx, W.
+1 Lada > >> On 31 Aug 2016, at 11:56, Jonathan Hansford <jonat...@hansfords.net> wrote: >> >> How about: >> >> NEW: >> >> It is not required to keep the full revision history of draft versions >> (e.g., modules contained within Internet-Drafts). That is, within a sequence >> of draft versions, only the most recent revision need be recorded in the >> module. However, whenever a new (i.e. changed) version is made available >> (e.g., via a new version of an Internet-Draft), the revision date of that >> new version MUST be updated to a date later than that of the previous >> version. >> >> Jonathan >> >> From: William Lupton >> Sent: 29 August 2016 15:20 >> To: Andy Bierman >> Cc: netmod@ietf.org >> Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements >> indrafts >> >> Andy, >> >> This thread started with discussion of an apparent ambiguity in the current >> text: >> >> 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. >> >> —— >> >> It became clear from the subsequent discussion (thanks Randy!) that the >> above text isn’t intended to mean “reuse the identical revision statement, >> INCLUDING THE REVISION DATE” but to mean “reuse the revision statement, >> UPDATING THE REVISION DATE”. >> >> Then other people raised other points, e.g only updating the revision date >> if the YANG has changed, distinguishing between the document and the YANG >> contained therein, and distinguishing between YANG in IDs and YANG created >> by other SDOs. My proposed new text tries to address all of these: >> >> NEW: >> >> It is not required to keep the full revision history of draft versions >> (e.g., modules contained within Internet-Drafts). That is, within a sequence >> of draft versions, only the most recent revision need be recorded in the >> module. However, if the module has changed, the revision date of the most >> recent revision MUST be updated to a later date whenever a new version is >> made available (e.g., via a new version of an Internet-Draft). >> >> —— >> >> I believe that this retains the original intent in a way that resolves the >> original ambiguity and addresses the other points that were raised. It it’s >> “worse”, how is it worse (apart from being longer, on which point mea culpa)? >> >> Thanks, >> William >> >> On 19 Aug 2016, at 15:42, Andy Bierman <a...@yumaworks.com> wrote: >> >> On Fri, Aug 19, 2016 at 7:13 AM, Dale R. Worley <wor...@ariadne.com> wrote: >> Andy Bierman <a...@yumaworks.com> writes: >> > An Internet-Draft is NOT a means of "publishing" a specification; >> >> As I said, that's the theory, but practice is considerably different. >> >> Anybody that implements a work-in-progress knows they are taking a risk >> on an unstable document. The guideline already says MUST update >> the revision date. >> >> Not sure what more you want to guidelines document to do. >> >> Dale >> >> Andy > > _______________________________________________ > 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
