Thanks. Of course I am fine with this suggestion. This gives: 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). > On 18 Aug 2016, at 13:21, Ladislav Lhotka <[email protected]> wrote: > > William Lupton <[email protected]> writes: > >> Kent, all, >> >> OK :). I will take Lada’s update to my Monday text as a baseline and will >> give my proposed new text without further ado, followed by rationale. >> >> BASELINE: >> >> 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. >> >> 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 higher >> value whenever a new version is made available (e.g., via a new >> version of an Internet-Draft). > > I like this text. Perhaps "a higher value" could be replaced with "a > later date"? > > Lada > >> >> —— >> >> The main comments and suggestions on the baseline text were: >> Why say MAY rather than MUST? Suggestion to say “need” to avoid difficulty >> with “only” and “MAY”. >> Should be more precise re the difference between a draft and a module >> contained within a draft. >> Should allow or encourage the module revision date to be bumped only if the >> YANG has changed (or on the containing draft becoming a standard). >> Discussion of “published” / “posted” etc., and their meanings in an IETF >> context. >> Support for the principle that the text should be both general (applying to >> all organisations) and specific (applying to IETF) and note that >> IETF-specific text should be parenthesised. >> Assertion that all publicly-available “adopted” modules (whether draft or >> standard) must bump revision dates if the YANG changes. >> >> Here are a few notes to forestall some of your possible comments: >> I didn’t mention submodules, because of the generic (Section 2.3) note that >> “module” means “module or submodule” unless specifically discussing >> submodules. >> I didn’t mention RFC publication as a special case (revision date MUST be >> unconditionally updated) because this paragraph is only about drafts. I >> assume that requirements governing modules in RFCs are already covered >> elsewhere. >> I hope that I avoided IETF-emotive terms outside the parentheses, e.g I used >> the terms “draft” and “made available”. >> I nearly added “statement” as in “revision date of the most recent revision >> statement”. I would certainly be happy with that change. >> I don’t really like “higher value” because that makes it sounds like a >> numeric value. However, no-one has commented on this and I guess it’s >> unambiguous. So let fido sleep on. >> >> Comments? >> >> Thanks, >> William >> >>> On 16 Aug 2016, at 19:02, Kent Watsen <[email protected]> wrote: >>> >>> Hi William, >>> >>> Do you want to take a stab on consolidating on the comments into new >>> proposed draft-text? - there were two proposals put out before, and a >>> number of refinements since, but I’m unsure which were picked up or not. >>> Since you raised this issue originally, if would be helpful to get your >>> current take on it. >>> >>> Thanks, >>> Kent >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
