Hi,
IMO it is not useful to have lots of copies of a module that just differ by revision date. It is acceptable to reuse the same revision statement within unpublished versions (e.g., Internet-Drafts), but the revision date MUST be updated to a higher value each time the YANG module is changed. The revision date MAY be updated if nothing in the module has changed. Andy On Thu, Aug 18, 2016 at 10:26 AM, William Lupton < [email protected]> wrote: > Oh dear :(. What do you think about this, which is what I really care > about? > > — > Regardless of the discussion about “published”, other organisations may be > planning to use YANG modules that are currently within IDs. Obviously it’s > vastly preferable if such IDs become RFCs before these other organisations > publish any specifications or data models that use such draft IETF YANG, > but it might occasionally be necessary to reference a draft model > (hopefully one that has already been sent for AD review) in a published > standard. This is why I would like the clarification to cover IDs (at least > WG-adopted ones)! > — > > William > > On 18 Aug 2016, at 18:21, Andy Bierman <[email protected]> wrote: > > 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
