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] > <mailto:[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] > > <mailto:[email protected]>> wrote: > > > > William Lupton <[email protected] > > <mailto:[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] > >>> <mailto:[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] <mailto:[email protected]> > >> https://www.ietf.org/mailman/listinfo/netmod > >> <https://www.ietf.org/mailman/listinfo/netmod> > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > > > _______________________________________________ > netmod mailing list > [email protected] <mailto:[email protected]> > https://www.ietf.org/mailman/listinfo/netmod > <https://www.ietf.org/mailman/listinfo/netmod> >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
