William Lupton <wlup...@broadband-forum.org> 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 <kwat...@juniper.net> 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 > 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
