Hi, So this is the test that is supposed to replace 5.8, para 7:
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. IMO the new text is worse. I like the suggestion to define "published" and "unpublished" to have the semantics defined in RFC 2026. Andy On Thu, Aug 18, 2016 at 10:08 AM, William Lupton < [email protected]> wrote: > 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 >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
