Subject: [netmod] RFC 6087bis guidance re use of revision statements in drafts

From: William Lupton <[email-masked]>
Date: Thu, 11 Aug 2016 10:06:41 +0100

All,

The text at the bottom of RFC 6087bis (draft 07) Section 5.8 seems unclear:

"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”

Assuming that the intent is that the revision statements in YANG models contained within IDs must be updated whenever the models are updated,  wouldn’t it be clearer if the parenthesised text "(i.e., Internet-Drafts)” was deleted?

Thanks,
William

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 11 Aug 2016 09:07:09 -0700

Hi -

The situation with Internet-Drafts is what motivated this text in the 
first place, so
I think it is important to retain that information.  However, it seems 
to me that
the "i.e." is too limiting, and should be replaced with an "e.g.".

Randy

On 8/11/2016 2:06 AM, William Lupton wrote:
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: William Lupton <[email-masked]>
Date: Thu, 11 Aug 2016 17:17:31 +0100

Thanks. e.g rather than i.e sounds good, BUT my point (sorry if that wasn’t clear) is that this sentence seems to be contradictory. It says:
Unpublished versions, i.e IDs, can reuse revision statements.
IDs MUST update their revision dates each time they are re-posted.

My suggestion of removing the parenthesised text was to remove this contradiction. Right now I’m not clear that I can rely on revision dates in YANG modules contained within IDs.

William

PS, I think that the removal of this text removes the contradiction because in order to make sense of the sentence the reader will be forced to the conclusion that IDs are not regarded as being “unpublished”.

> On 11 Aug 2016, at 17:07, Randy Presuhn <[email-masked]> wrote:
> 
> Hi -
> 
> The situation with Internet-Drafts is what motivated this text in the first place, so
> I think it is important to retain that information.  However, it seems to me that

---

From: Kent Watsen <[email-masked]>
Date: Thu, 11 Aug 2016 16:18:45 +0000

I think the issue is at the end of the sentence, my proposal:

    - the Internet-Draft is re-posted.
    + the work is published (e.g., it becomes an RFC).

That said, for IETF drafts (not other SDOs), my understanding is that the revision statement’s date value SHOULD be the date that the I-D is uploaded to IETF datatracker.  All my drafts are built using a Makefile that includes `sed` processing instructions to set the YANG module dates to the current date - and they include RFC-Editor instructions to reset the value again to the date the RFC is published.

Kent   // as a contributor

On 8/11/16, 5:06 AM, "netmod on behalf of William Lupton" <[email-masked] on behalf of [email-masked]> wrote:

    All,

    
    
    Thanks,
    William

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 11 Aug 2016 09:26:23 -0700

Hi -

I read the text as intended to make a distinction between the *date* 
portion and the rest

of the revision statement.  When a module is under development, 
retaining a history

of specific incremental changes isn't terribly helpful, but changing the 
date is essential

to helping tools decide among the versions floating around in the lab.

Randy (experimenting with mail readers, please forgive formatting anomalies)

On 8/11/2016 9:17 AM, William Lupton wrote:
> Thanks. e.g rather than i.e sounds good, BUT my point (sorry if that 
> wasn’t clear) is that this sentence seems to be contradictory. It says:
>
>  1. Unpublished versions, i.e IDs, can reuse revision statements.
>  2. IDs MUST update their revision dates each time they are re-posted.
>
>
> My suggestion of removing the parenthesised text was to remove this 
> contradiction. Right now I’m not clear that I can rely on revision 
> dates in YANG modules contained within IDs.
>
> William
>
> PS, I think that the removal of this text removes the contradiction 
> because in order to make sense of the sentence the reader will be 
> forced to the conclusion that IDs are not regarded as being “unpublished”.
>
>> On 11 Aug 2016, at 17:07, Randy Presuhn 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi -
>>
>>> "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”
>>>
>>> Assuming that the intent is that the revision statements in YANG 
>>> models contained within IDs must be updated whenever the models are 
>>> updated,  wouldn’t it be clearer if the parenthesised text "(i.e., 
>>> Internet-Drafts)” was deleted?
>>>
>>> Thanks,
>>> William
>>> [email-masked] <mailto:[email-masked]>

---

---

From: William Lupton <[email-masked]>
Date: Thu, 11 Aug 2016 18:14:59 +0100

Ideally I’d like a stronger guarantee than that, e.g that all YANG modules in WG-adopted IDs MUST have revision dates that reflect the most recent change to that YANG (*). The key point is that other SDOs (such as BBF!) will often develop YANG modules that (during the development phase) depend on YANG modules from IDs, so it’s important to be able to rely on their revision dates.

(*) Or the ID publication date if you prefer, but 6087bis already says “The revision date does not need to be updated if the module contents do not change in the new document revision”. Is this intended to apply to IDs?

> On 11 Aug 2016, at 17:18, Kent Watsen <[email-masked]> wrote:
>

---

From: William Lupton <[email-masked]>
Date: Mon, 15 Aug 2016 12:31:23 +0100

Ah! Re-reading it I think that you are correct. In this spirit I propose the change shown below. I believe that all this does is (a) generalise, and (b) clarify. I don’t believe that it changes the intended meaning.

OLD:

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.

NEW:

It is acceptable to reuse the same revision statement within unpublished versions (e.g., Internet-Drafts), but the revision date (i.e., the revision statement’s argument) MUST be updated to a higher value each time a new version (e.g., of the Internet-Draft) is posted.

——

Comments?

> On 11 Aug 2016, at 17:26, Randy Presuhn <[email-masked]> wrote:
> 
> Hi -
> 
> I read the text as intended to make a distinction between the *date* portion and the rest
> 
> of the revision statement.  When a module is under development, retaining a history
> 
> of specific incremental changes isn't terribly helpful, but changing the date is essential
> 
>>> On 11 Aug 2016, at 17:07, Randy Presuhn <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi -
>>>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 15 Aug 2016 13:44:54 +0200

> On 15 Aug 2016, at 13:31, William Lupton <[email-masked]> wrote:
> 

It seems strange to talk about reusing the revision statement and, in the same sentence, require to change its argument. What about this:

NEW

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.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Jonathan Hansford <[email-masked]>
Date: Mon, 15 Aug 2016 13:23:52 +0100

Should it be a MAY or a MUST? And why is it “e.g. of the Internet-Draft”? Isn’t it more “each time a new version is posted (e.g. in a new version of the Internet-Draft)”? Shouldn’t the revision statement reflect changes to the module or submodule rather than to the Internet-Draft in which they are published?

Jonathan

From: Ladislav Lhotka

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 15 Aug 2016 14:35:56 +0200

> On 15 Aug 2016, at 14:23, Jonathan Hansford <[email-masked]> wrote:
> 

It would indeed be useful if the revision date is bumped only after the module itself has been changed - except when the module is published in an RFC.

Lada

> 
> Jonathan
>  
> From: Ladislav Lhotka
> Sent: 15 August 2016 12:44
> To: William Lupton
> Cc: [email-masked]
> Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements indrafts
>  
>

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 15 Aug 2016 12:14:18 -0700

Hi -

The new text works for me.

Randy

---

---

From: Randy Presuhn <[email-masked]>
Date: Mon, 15 Aug 2016 12:17:44 -0700

Hi -

This also works for me, but I'd replace the odd "MAY" with the word "need".

(The semantics of "only" and of "MAY" don't quite mesh.)

Randy

---

---

From: Kent Watsen <[email-masked]>
Date: Mon, 15 Aug 2016 19:40:02 +0000

Nits:

1. First it says “unpublished” then it says “posted”, I think it better to replace the latter with “published” so the terms are consistent.

2. “unpublished” is unclear.  At least I consider submitting an I-D to datatracker as a form of publishing.  I think it might be better here to refer to something like “works in progress”.

3. Instead of saying “when a new version (of the I-D) is posted”, it would be clearer to say “when a new version is posted (e.g., it becomes an RFC)”.

Kent  // as a contributor

On 8/15/16, 3:17 PM, "netmod on behalf of Randy Presuhn" <[email-masked] on behalf of [email-masked]> wrote:

    Hi -

    
    Randy

    ---

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Aug 2016 22:30:30 +0200

> 2. “unpublished” is unclear.  At least I consider submitting an I-D to datatracker as a form of publishing.  I think it might be better here to refer to something like “works in progress”.

Perhaps this is what authors think these days but RFC 2026 makes a
clear distinction between 'publish' and 'made available'. See section
2.2 for more details. Uploading a document to a server really is not
the same as publishing in the traditional sense (and clearly not for
people with an academic background).

Yes, uploading some text to a server makes the text publicly
accessible (make avaliable in RFC 2016 terms) but there is a big
difference between a formally published document in a certain series
that exercises some sort of quality control according to the rules of
the series and simply making something public.

Perhaps we should make it clear that 'publish' is meant in the
traditional RFC 2026 sense.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Kent Watsen <[email-masked]>
Date: Mon, 15 Aug 2016 20:47:46 +0000

>    traditional RFC 2026 sense.

We could add a reference to RFC 2026, but I think that it’s easy enough to make the text understandable to any reader, regardless their familiarity with IETF process.   I like that we’ve moved IETF-specific text into parentheses, and hence hoping to avoid any IETF-loaded words outside parentheses where possible.

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 15 Aug 2016 22:54:41 +0200

> We could add a reference to RFC 2026, but I think that it’s easy enough to make the text understandable to any reader, regardless their familiarity with IETF process.   I like that we’ve moved IETF…

Whatever the wording is, I believe there is a fundamental difference
between someone simply making something available and something that
becomes accessible (persistently) after having gone through a review
and quality ensurance process.

/js

---

From: William Lupton <[email-masked]>
Date: Tue, 16 Aug 2016 12:57:45 +0100

Kent,

A couple of your comments have suggested that you feel that the “new version is posted” language should be clarified in the direction (for IETF YANG) of “ID becomes RFC”. That’s not how I read the original or how I read most of the discussion, and it’s also not the clarification that I was hoping for!

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)!

Thanks,
William

> On 15 Aug 2016, at 20:40, Kent Watsen <[email-masked]> wrote:
> 
> Nits:
>

---

From: Kent Watsen <[email-masked]>
Date: Tue, 16 Aug 2016 18:02:20 +0000

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

On 8/16/16, 7:57 AM, "William Lupton" <[email-masked]> wrote:

    Kent,

    
    Thanks,
    William

---

From: William Lupton <[email-masked]>
Date: Thu, 18 Aug 2016 11:08:32 +0100

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:

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-masked]> wrote:
> 
> Hi William,
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 18 Aug 2016 14:21:06 +0200

William Lupton <[email-masked]> writes:

> 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

---

From: William Lupton <[email-masked]>
Date: Thu, 18 Aug 2016 18:08:51 +0100

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-masked]> wrote:
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Aug 2016 10:21:09 -0700

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-masked]> wrote:

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

---

From: William Lupton <[email-masked]>
Date: Thu, 18 Aug 2016 18:26:12 +0100

Oh dear :(. What do you think about this, which is what I really care about?

— 
— 

William

> On 18 Aug 2016, at 18:21, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> On Thu, Aug 18, 2016 at 10:08 AM, William Lupton <[email-masked] <mailto:[email-masked]>> wrote:
> > On 18 Aug 2016, at 13:21, Ladislav Lhotka <[email-masked] <mailto:[email-masked]>> wrote:
> >
> > William Lupton <[email-masked] <mailto:[email-masked]>> writes:
> >
> >> Kent, all,
> >>
> >>> On 16 Aug 2016, at 19:02, Kent Watsen <[email-masked] <mailto:[email-masked]>> wrote:
> >>>
> >>> Hi William,
> >>>
> >> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
> >
> > --
> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Aug 2016 10:56:49 -0700

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-masked]> wrote:

> 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
>
>> >> It is not required to keep the revision history of unpublished
>> versions (e.g., Internet-Drafts). That is, within a sequence of unpublished
>> >> 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).
>> >> I hope that I avoided IETF-emotive terms outside the parentheses, e.g
>> I used the terms “draft” and “made available”.

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 18 Aug 2016 22:15:26 -0400

William Lupton <[email-masked]> writes:
> 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)!

Unfortunately, this sort of problem has to be considered.  I remember
when the "SIP multiple line appearances" draft was being worked on.
Ultimately, there were products on the market that supported the -03
version, the -04 version, and the final (RFC) version.

My suggestion is that any time a version of a module is "published", it
must either be identical to the previous "published" version, or have a
newer revision date.  As far as I can see, the *practical* meaning of
"published" is a document that has a permanent URL, because you can't
convince a customer that a document is a "specification" if it doesn't
have a stable URL.  For Internet Drafts, that seems to mean each
numbered version entered into the Data Tracker.

But there is a further problem:  A sequence of versions of a module with
different revision dates are required to be related by the rules of
section 11 of RFC 6020 (or draft-ietf-netmod-rfc6020bis), i.e., each
newer version is a proper extension of the older version(s).  Clearly,
we *don't* want to have that constraint between versions of modules in a
sequence of I-Ds, we want to be able to delete elements.

Dale

---

From: Andy Bierman <[email-masked]>
Date: Thu, 18 Aug 2016 19:43:53 -0700

> numbered version entered into the Data Tracker.

The current text says the revision date MUST be updated
if the YANG module changed at all.  Seems clear to me.

I think I will add a reference to RFC 2026, sec. 2.2
to use the term  "published" specification

An Internet-Draft is NOT a means of "publishing" a specification;

Andy

> ___________

Andy

> ____________________________________
> netmod mailing list
> [email-masked]

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 19 Aug 2016 10:13:57 -0400

> An Internet-Draft is NOT a means of "publishing" a specification;

As I said, that's the theory, but practice is considerably different.

Dale

---

From: Andy Bierman <[email-masked]>
Date: Fri, 19 Aug 2016 07:42:12 -0700

> As I said, that's the theory, but practice is considerably different.
Anybody that implements a work-in-progress knows they are taking a risk
on an unstable document.  The guideline already says MUST update
the revision date.

Not sure what more you want to guidelines document to do.

Andy

---

From: William Lupton <[email-masked]>
Date: Mon, 29 Aug 2016 15:20:08 +0100

Andy,

This thread started with discussion of an apparent ambiguity in the current text:

OLD

—— 

It became clear from the subsequent discussion (thanks Randy!) that the above text isn’t intended to mean “reuse the identical revision statement, INCLUDING THE REVISION DATE” but to mean “reuse the revision statement, UPDATING THE REVISION DATE”.

Then other people raised other points, e.g only updating the revision date if the YANG has changed, distinguishing between the document and the YANG contained therein, and distinguishing between YANG in IDs and YANG created by other SDOs. My proposed new text tries to address all of these:

NEW:

——

I believe that this retains the original intent in a way that resolves the original ambiguity and addresses the other points that were raised. It it’s “worse”, how is it worse (apart from being longer, on which point mea culpa)?

Thanks,
William

> On 19 Aug 2016, at 15:42, Andy Bierman <[email-masked]> wrote:
> 
> On Fri, Aug 19, 2016 at 7:13 AM, Dale R. Worley <[email-masked] <mailto:[email-masked]>> wrote:
> Andy Bierman <[email-masked] <mailto:[email-masked]>> writes:

---

From: Jonathan Hansford <[email-masked]>
Date: Wed, 31 Aug 2016 11:56:18 +0100

How about:

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, whenever a new (i.e. changed) version is made available (e.g., via a new version of an Internet-Draft), the revision date of that new version MUST be updated to a date later than that of the previous version.

Jonathan

From: William Lupton

---

From: William Lupton <[email-masked]>
Date: Wed, 31 Aug 2016 12:17:52 +0100

I like this. In particular I like the clean use of “version” and “revision”. Editorial nit: add a comma after “i.e.” because that’s the style used for “e.g.”. Tx, W.

> On 31 Aug 2016, at 11:56, Jonathan Hansford <[email-masked]> wrote:
> 
> How about:
>  
> NEW:
>  
> From: William Lupton <mailto:[email-masked]>
> Sent: 29 August 2016 15:20
> To: Andy Bierman <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> On 19 Aug 2016, at 15:42, Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 31 Aug 2016 14:00:03 +0200

> On 31 Aug 2016, at 13:17, William Lupton <[email-masked]> wrote:
> 

+1

Lada

>> To: Andy Bierman

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 31 Aug 2016 12:14:50 +0000

On 8/31/16, 8:00 AM, "netmod on behalf of Ladislav Lhotka"
<[email-masked] on behalf of [email-masked]> wrote:

>> I like this. In particular I like the clean use of “version” and
>>“revision”. Editorial nit: add a comma after “i.e.” because that’s the
>>style used for “e.g.”. Tx, W.
>
>+1
>
>Lada

I like this text as well. Keeping a complete revision history in the model
can become unwieldy. Besides, git does a MUCH better job of this.

Thanks,
Acee

>>>recorded in the module. However, whenever a new (i.e. changed) version
>>>is made available (e.g., via a new version of an Internet-Draft), the
>>>revision date of that new version MUST be updated to a date later than
>>>that of the previous version.
>>>  
>>> Jonathan
>>>  
>>> From: William Lupton
>>>MUST be updated to a higher value each time the Internet-Draft is
>>>re-posted.
>>>  
>>> —— 
>>>  
>>> It became clear from the subsequent discussion (thanks Randy!) that
>>>the above text isn’t intended to mean “reuse the identical revision
>>>statement, INCLUDING THE REVISION DATE” but to mean “reuse the revision
>>>statement, UPDATING THE REVISION DATE”.
>>>  
>>> Then other people raised other points, e.g only updating the revision
>>>date if the YANG has changed, distinguishing between the document and
>>>the YANG contained therein, and distinguishing between YANG in IDs and
>>>YANG created by other SDOs. My proposed new text tries to address all
>>>of these:
>>>  
>>> NEW:
>>> 
>>>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).
>>>  
>>> ——
>>>  
>>> I believe that this retains the original intent in a way that resolves
>>>the original ambiguity and addresses the other points that were raised.
>>>It it’s “worse”, how is it worse (apart from being longer, on which
>>>point mea culpa)?
>>>  
>>> Thanks,
>>> William
>>>

---

From: Kent Watsen <[email-masked]>
Date: Wed, 31 Aug 2016 15:30:14 +0000

I like Jonathan’s proposed text as well.

Kent // as a contributor

On 8/31/16, 8:14 AM, "netmod on behalf of Acee Lindem (acee)" <[email-masked] on behalf of [email-masked]> wrote:

    

    Thanks,
    Acee