Subject: [Tools-discuss] Drafts that aren't expired but say that they are

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 May 2014 07:20:03 +0200

When presenting a draft at tools.ietf.org, datatracker.ietf.org, etc., that is beyond its original shelf life but is on life-support for some IESG or RFC editor action, a prominent note needs to be displayed that the expiry date in the document is no longer correct.

Grüße, Carsten

---

From: Dave Crocker <[email-masked]>
Date: Mon, 05 May 2014 06:25:34 -0700

> When presenting a draft at tools.ietf.org, datatracker.ietf.org, etc., that is beyond its original shelf life but is on life-support for some IESG or RFC editor action, a prominent note needs to be…

Isn't it simpler to merely resubmit the draft, to reset the timer?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 May 2014 15:35:54 +0200

> Isn't it simpler to merely resubmit the draft, to reset the timer?

I believe increasing the version number after submission (or approval) 
would be very confusing.

(At least unless there actually *is* a change in the spec)

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 May 2014 15:37:08 +0200

> Isn't it simpler to merely resubmit the draft, to reset the timer?

Maybe, but that is likely to create even more confusion:
— in the various bodies where the extended processing occurs (IESG possibly, RFC-Editor more likely)
— with the implementers (are we implementing the approved draft 18 or draft 19?)

Strictly speaking, the boilerplate is wrong, but in the age of the Web this could be papered over by adding a note where the draft is presented.  (The few people who get the drafts by rsync are less likely to be confused.)

[Of course, the best thing would be to get rid of the unnecessary process obstacles.
But this is tools-discuss, not process-discuss...]

Grüße, Carsten

---

From: Dave Crocker <[email-masked]>
Date: Mon, 05 May 2014 06:41:07 -0700

On 5/5/2014 6:35 AM, Julian Reschke wrote:
>>> When presenting a draft at tools.ietf.org, datatracker.ietf.org,
>>> etc., that is beyond its original shelf life but is on life-support
>>> for some IESG or RFC editor action, a prominent note needs to be
>>> displayed that the expiry date in the document is no longer correct.
>>
>>

1. I would have thought that this problem is not very frequent.

2. Adding cruft to the software, to cover a rare problem seems a poor
tradeoff.  As a natural part of keeping a tool clean-ish and simple-ish,
we need push-back on the constant pressures to add cruft.

3. I wouldn't think that this sort of thing it would be all /that/
confusing for the elite IESG members, who already have to juggle the
nuances and complexities of IETF process...

d/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 May 2014 15:47:58 +0200

> But this is tools-discuss, not process-discuss...]

Right.

A simple approach would be to remove the "Expires" information 
altogether, and instead have a link to the data tracker for that draft.

Best regards, Julian

---

From: Dave Crocker <[email-masked]>
Date: Mon, 05 May 2014 06:51:18 -0700

> altogether, and instead have a link to the data tracker for that draft.

Which means that any existing copies of the document -- which already
have the Expires date on them -- will be wrong!

This prompts a new line of concern:

     Effectively, we'd be changing a document in place.

We don't do that for RFCs and I'll suggest that we should not do that
for drafts.  ANY change to a draft should cause a new version of the
draft...

d/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 May 2014 15:55:35 +0200

On 2014-05-05 15:51, Dave Crocker wrote:
> ...

You misunderstood. My proposal is not to include the "expires" 
information in the first place.

It's misleading in any case, because a draft frequently is irrelevant 
for other reasons (such as being replaced by a newer version).

> for drafts.  ANY change to a draft should cause a new version of the

I agree with that.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 May 2014 16:07:11 +0200

> we need push-back on the constant pressures to add cruft.

Changing software is a small change.
(No, it’s not a rare problem, and even if fixes to the processes made it one, it is still an important problem in those now rare cases.)

Doing what Julian proposes probably is the right thing to do, but it is a big change, with process implications.

All I wanted to do is point out that our current web materials are spreading falsehoods, and propose a simple solution.
But I wouldn’t be unhappy with doing the right thing, except that may require too many decidotrons that we need elsewhere.

Grüße, Carsten

---

From: Dave Crocker <[email-masked]>
Date: Mon, 05 May 2014 07:10:33 -0700

> All I wanted to do is point out that our current web materials are spreading falsehoods, and propose a simple solution.

In classic terms of experimental methodology, this situations offers a
choice between a Type I error and a Type II error.  False positive or
false negative.

Is it worse for someone to think a draft might have expired (and
therefore think they need to check for a newer one) than to have no idea
that it expired?

d

---

From: Dave Crocker <[email-masked]>
Date: Mon, 05 May 2014 07:15:08 -0700

> information in the first place.

Ahh.  You are proposing a change to /all/ I-Ds.  So no new I-D would
contain the expiry information?

Many readers of I-Ds do not have a deep understanding of IETF details;
even those who do often do to invoke that information when reading an
I-D.  (It's a usability, user attention kind of thing.)

So this removes the only means of helping a reader understand that the
IETF intends drafts to be highly ephemeral.

In terms of the pragmatics of circulating I-Ds around the world, this
essentially produces a paradigm change in the perception of the
documents, to cover a relatively rare case that is, at worst, a minor
inconvenience.

(Note the separate observation I made to Carsten, about Type I/II errors.)

> for other reasons (such as being replaced by a newer version).

Interesting point.

It suggests that rather than removing the expiry date, it should be
re-labeled something like "Expires By" and readers should be given
explicit text and point to encourage verifying the most current version
of the draft.  The expiry data gives them a sense of /maximum/ lifetime.

d/

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 May 2014 16:15:49 +0200

> therefore think they need to check for a newer one) than to have no idea

The problem is that the information is misleading in any case. For 
instance, 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-http2-08.html> says 
"Expires: May 15, 2014", but it already has been updated four times since.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 5 May 2014 16:16:35 +0200

> therefore think they need to check for a newer one) than to have no idea

Both.

I thought Julian’s proposal was to say “This draft expires after a short while.  Please see http://a/b/ for details.”
(add suitable wording), so there is no false negative.
(Yes, “suitable wording” needs more than a kilodecidotron.  “Best before”?  
That’s why I wasn’t suggesting fixing the falsehood, but papering over it.)

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 May 2014 16:24:03 +0200

> IETF intends drafts to be highly ephemeral.

No, it does not.

The drafts already say:

"Internet-Drafts are working documents of the Internet Engineering Task 
Force (IETF). Note that other groups may also distribute working 
documents as Internet-Drafts. The list of current Internet-Drafts is at 
http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months 
and may be updated, replaced, or obsoleted by other documents at any 
time. It is inappropriate to use Internet-Drafts as reference material 
or to cite them other than as “work in progress”."

What I propose is to replace the subsequent statement:

"This Internet-Draft will expire on ..."

By text that links to the datatracker page, providing accurate 
information about the draft's status.

Best regards, Julian

---

From: Dave Crocker <[email-masked]>
Date: Mon, 05 May 2014 07:35:41 -0700

> information about the draft's status.

Ack.

However, in terms of human factors design, we tend to think that merely
making information exist means it is useful.

Unfortunately, boilerplate is useful only when the reader chooses to do
a close inspection of the text, which essentially means never. Although
of course a reader can miss the Expires header field, it's position
makes it far more likely to be seen and understood.

The information about currency needs to be prominent, not buried in
boilerplate.

So I suggest that a removal of the Expires field needs to mean the
addition of a new header field, such as Current-Version:, with a
datatracker URL specific to the draft.

Given how long the field will be this will be visually obnoxious, but
for information about expiration/currency, that's seems a Good Thing.

d/

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 5 May 2014 07:55:48 -0700

Folks:

We are not in charge of the IESG and RFC Editor's processes: they are. Us having a discussion of how they should do things, given that they didn't ask us and are aware of the problem, seems like a waste of time. If an individual here believes that their proposed solution is best, take it to the IESG and RFC Editor.

--Paul Hoffman

---

From: Julian Reschke <[email-masked]>
Date: Mon, 05 May 2014 17:03:24 +0200

> We are not in charge of the IESG and RFC Editor's processes: they are. Us having a discussion of how they should do things, given that they didn't ask us and are aware of the problem, seems like a…

I agree that we are not in charge, but I disagree that discussing it 
here is a waste of time.

For instance, we might come up with a change proposal we all agree on, 
and then take that to the IESG.

Best regards, Julian

---

From: Dave Crocker <[email-masked]>
Date: Mon, 05 May 2014 08:22:17 -0700

> and then take that to the IESG.

+1

I think this exchange is proving enlightening and might even turn out to
develop some useful guidance.

d/

ps. but yes, we need to be clear that what is at issue here is a
meaningful policy change and, no, this group does not get to decide that.

---

From: Nico Williams <[email-masked]>
Date: Mon, 5 May 2014 11:01:51 -0500

Re-submission of a fresh I-D with an "Expires: <unspecified; see I-D
tracker>" could be required to move forward past approval for
publication.

Nico
--

---

From: Tony Hansen <[email-masked]>
Date: Mon, 05 May 2014 15:10:59 -0400

On 5/5/14, 10:24 AM, Julian Reschke wrote:
> The drafts already say:
>
> "Internet-Drafts are working documents of the Internet Engineering 
> Task Force (IETF). Note that other groups may also distribute working 
> documents as Internet-Drafts. The list of current Internet-Drafts is 
> at http://datatracker.ietf.org/drafts/current/.
>

Another option would be to modify the boilerplate to say something like:

     This Internet-Draft expires on or after MMM NN, YYYY, or may be 
superseded by newer versions.

I think that covers just about all of the bases.

     Tony Hansen

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 5 May 2014 12:34:07 -0700

On May 5, 2014, at 12:10 PM, Tony Hansen <[email-masked]> wrote:

>    This Internet-Draft expires on or after MMM NN, YYYY, or may be superseded by newer versions.
> 

Actually, it doesn't cover the two cases that prompted the thread: the draft is stuck in IESG consideration past its expiration, or the draft is stuck in the RFC Editor queue past its expiration.

--Paul Hoffman

---

From: Tony Hansen <[email-masked]>
Date: Tue, 06 May 2014 15:14:20 -0400

> Actually, it doesn't cover the two cases that prompted the thread: the draft is stuck in IESG consideration past its expiration, or the draft is stuck in the RFC Editor queue past its expiration.

Sure it does. Note the "or after".

     Tony Hansen

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 6 May 2014 12:40:27 -0700

> Sure it does. Note the "or after".

Subtle. It would be more natural to read your wording as "on that date or immediately after". That feels more like a programming error than something that anyone is expected to understand.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Thu, 8 May 2014 18:29:10 -0400

On Monday, May 5, 2014, Paul Hoffman <[email-masked]> wrote:

> On May 5, 2014, at 12:10 PM, Tony Hansen <[email-masked] <javascript:;>>
> wrote:
>
> Actually, it doesn't cover the two cases that prompted the thread: the
> draft is stuck in IESG consideration past its expiration, or the draft is
> stuck in the RFC Editor queue past its expiration.
>

Yeah, I recently started a thread on the same topic on WG-Chairs -- I have
a draft that expired back in August 2012, stuck in RFC Ed (waiting on a
reference). Someone asked me why I had abandoned the doc, and could I
please revive it.

The consensus was that we should simply ignore these edge cases / explain
the process to folk if they didn't know / realize -- this seemed like a
perfectly fine answer to me.

W

>
> --Paul Hoffman
> --
> Tools-discuss mailing list
> [email-masked] <javascript:;>
> https://www.ietf.org/mailman/listinfo/tools-discuss
>
> Please reports datatracker.ietf.org bugs at
> http://tools.ietf.org/tools/ietfdb
> Please reports tools.ietf.org bugs at http://tools.ietf.org/tools/issuesor
> send email to [email-masked] <javascript:;>
>