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). —— 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
