Subject: The RFC 20 rationale (was: Re: Last Call: Recognising RFC1984 as a BCP)

From: John C Klensin <[email-masked]>
Date: Wed, 12 Aug 2015 04:45:12 -0400

Hi.

(Changing the subject line because this is a little bit of a
diversion)

The proposed status writeup for this change contains the
statement:

	"The closest precedent we have for this status chage is
	the change of RFC20 to Internet Standard. [4] That shows
	that if the text of an RFC is acceptable, the age of the
	RFC isn't material in discussing proper RFC status. "

Because this proposed action may be precedent-setting whether it
is approved or not, I'd like to see that paragraph removed.  If
RFC 20 is the nearest precedent, then I suggest we have no
precedent at all because:

	(1) The status change to RFC 20 was from a status of
	"unknown" to a status of "Standard".  It was not a
	change from one state defined in RFC 2026 to another
	(2026 doesn't even mention "unknown").
	
	(2) Whatever else RFC 20 may be, it is a technical
	specification.  The status change was justified on the
	basis of deployed (and "running") code and existing
	practices.  Both of those hypothesis can be demonstrated
	by examining the current Internet and noting that RFC
	20-conformant ASCII is in very wide use (including in
	the text and message handling of this discussion thread).
	
	(3) Because of that "obviously deployed and in use"
	property, part of the argument for reclassifying RFC 20
	was that "Unknown" was an error, albeit one that
	resulted naturally from the fact that there was no
	systematic case-by-case community review of older
	document when status designations were assigned to RFCs.
	In that respect, "unknown" in more of a missing value in
	the database than a specific status and the RFC 20
	action filled in or corrected that missing value for
	that RFC.

Other documents have been changed in status from one 2026
category to another without issuing new RFCs.  Perhaps one or
more of them is a precedent for this proposed action.  But the
RFC 20 status change is not and should not be cited as one in
the writeup/ rationale, especially if the writeup is expected to
be the only permanent documentation or what was discussed and
done here.

best,
    john

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Aug 2015 13:27:01 +0100

FWIW, I'd have no problem modifying or removing that part of the
status change document. A bit more below...

> precedent at all because:

To clarify: I don't think RFC20 is a precedent for saying
yes to this status change and the above wasn't intended to
imply that. The only precedent I think we get from RFC20 is
that the argument "that text is old" is not *by itself*
reason enough to say no to the status change.

As far as I know there aren't any other status changes that
provide us with useful precedent here, but I could be wrong
on that.

So we could modify or remove that paragraph fairly easily
I think. (Mind you I'm also not getting why that is an
important change to make.)

If nobody suggests an alternative, or to keep it, I can
remove it. (Might be better done in a week or so, around the
middle of the LC in case there are other accumulated changes.)

S.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 12 Aug 2015 15:34:19 +0200

> provide us with useful precedent here, but I could be wrong

These go the other way (from Proposed to Historic), but we have some
transitions that were managed by publishing RFCs:

3638 Applicability Statement for Reclassification of RFC 1643 to
     Historic Status

4223 Reclassification of RFC 1863 to Historic.

5125 Reclassification of RFC 3525 to Historic.

7142 Reclassification of RFC 1142 to Historic.

And the following RFC that did a whole slew of reclassifications:

4450 Getting Rid of the Cruft: Report from an Experiment in
     Identifying and Reclassifying Obsolete Standards Documents.

The pattern here, which may or may not be something we want to emulate,
is that when we make a decision, we publish a document saying why.

RFC numbers are cheap. (The debate required to agree on the text may not
be.)

---

From: Nico Williams <[email-masked]>
Date: Wed, 12 Aug 2015 10:52:53 -0500

> RFC numbers are cheap. (The debate required to agree on the text may not

And the labor to edit new RFCs is also not cheap.  We could have
produced a modern replacement for RFC 20.

Nico
--

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Aug 2015 13:01:05 -0400

--On Wednesday, August 12, 2015 10:52 -0500 Nico Williams
<[email-masked]> wrote:

>> RFC numbers are cheap. (The debate required to agree on the
>> text may not be.)
> 
> And the labor to edit new RFCs is also not cheap.  We could
> have produced a modern replacement for RFC 20.

But, Nico, what do you mean by a "modern replacement"?  The
references could have been updated, but there is no "modern
ASCII" that is more modern than what RFC 20 talks about and, for
the very rare cases where it makes a difference, it is the RFC
20 ASCII (aka X3.4-1968) that is deployed on the Internet.
Now, one could of course specify a "modern replacement for
ASCII", but that is different from a replacement for RFC 20 and
its ASCII definition.  One could also argue that is just what
RFC 2277 and 2279 do, modulo whatever one feels a need to say
about profiles, normalization, etc., at least some of which we
have said in the IDNA and PRECIS work and elsewhere.

There was a least one additional reason for reclassifying RFC 20
in place, which is that it is normatively referenced from a
number of standards-track technical specifications and
referenced in a way that is critical to understanding those
specifications.   We could, of course, have tracked all of them
down and updated them, but that appeared to be a lot of work
that would be justified on procedural-ritual reasons only.
Again, part of the issue is that a reference to a document with
a missing ("unknown") status category is different from a
"downref" to a different category.

In any event, the action taken wrt RFC 20 and how it was taken
are not at issue here (and it is too late to even appeal), only
whether that action on RFC 20 has anything to do with, or is a
precedent for, the proposed status change for 1984.

>> provide us with useful precedent here, but I could be wrong

My recollection is that we did at least one reclassification
from Proposed to Full (Internet) Standard by making a note in
the tracker and did so a year or two ago.  There were arguments
at the time that numbers were cheap and we'd be better off
documenting the reasons for the change (and doing whatever other
calibration was needed) in a new RFC but the IESG ultimately
decided to go through with the "no new document"
reclassification. At least some of us who were opposed to doing
things that way ran out of energy or had other priorities and so
gave up rather than wanting to fight it further.  

I'm fairly certain the reclassified document was in the
Applications Area and only a bit less certain that Barry was the
responsible AD.  Perhaps he can remember the number if you need
an example.  Whether Proposed-> Full is an appropriate precedent
for an Informational-> BCP change is, of course, another matter.
The RFC 20 change was, IMO, not really a status change at all,
just assigning the obvious status category to a document that
previously did not have one.

> These go the other way (from Proposed to Historic), but we
> have some transitions that were managed by publishing RFCs:
>...

Most of which occurred before the IESG decided that
reclassification without documentation outside the tracker was a
fine procedure.

> The pattern here, which may or may not be something we want to
> emulate, is that when we make a decision, we publish a
> document saying why.
> 
> RFC numbers are cheap. (The debate required to agree on the
> text may not be.)

That was certainly the precedent prior to that other
reclassification and then to the RFC 20 action.   But the IESG
changed the rules.  Whatever one thinks of the changes, they
were not secretive about it.   If the community wants documents,
the community needs to figure out how to say so.  IIR, in the
wake of the decision by the IESG to start reclassifying
documents by tracker notes rather than RFC publication, Scott
Bradner and I suggested a specific model for moves to Historic
that would have allowed tracker notes in some cases but not
others [1].  Again, IIR, we were unable to get the IESG to take
any interest in that document or a more general discussion of
the topic, so we gave up and let it expire (and I, at least, got
much more cynical about the possibility for any process change
that was not initiated, or at least actively pushed, from within
the IESG).

best,
     john

[1] draft-klensin-historical-definition-01

---

From: Nico Williams <[email-masked]>
Date: Wed, 12 Aug 2015 12:53:25 -0500

> But, Nico, what do you mean by a "modern replacement"?  The

Modern formatting.  Nothing else.

---

From: John C Klensin <[email-masked]>
Date: Wed, 12 Aug 2015 19:40:36 -0400

> reason enough to say no to the status change.

That is fair.   I read it as saying something more like "RFC 20
sets the precedent for moving almost anything, of any status,
onto the standards track (or BCP), with only a Last Call and
note in the tracker".   As you have gathered, I interpret the
RFC 20 experience much more narrowly and, in particular, see
"move things from one category to another" as potentially
different from "assign a category to something previously listed
as 'unknown'".   From my point of view, one way to avoid
removing that paragraph would be to clarify what you think the
precedent is and the above is fine.  On the other hand, given
that the IESG, with sufficient community consensus, can change
or make exceptions to almost anything, I'm not sure your
claiming precedents is really helpful.    On the other hand, if
you want to cite something, Section 2.2 of RFC 6410 makes it
quite clear that reclassification of a document, at least from
Proposed Standard to Internet Standard, is permitted without a
new RFC being required.  I think extrapolating from that to BCP
is at least as reasonable as extrapolating from the somewhat
special case of a previously "unknown" status spec like RFC 20.
Neither is really a precedent for a change from Informational to
anything else or from something else to BCP.

> provide us with useful precedent here, but I could be wrong

See earlier notes.  Several moves to Historic and, I think, at
least one exercise of the Proposed-> Internet Standard
transition without issuance of new RFCs.

> important change to make.)

See above.  My concern is about claiming a precedent that could
be too broadly interpreted and that would then get us in trouble
later.   Personally, I'd be happy if you said "this is an
unusual action, but circumstances seem to justify it and it is
generally consistent with things we do by exception as long as
community consensus is present".  If you need precedent or
authorization for that, Section 9 of RFC 2026 seems quite clear
to me.
 
> middle of the LC in case there are other accumulated changes.)

Ack.

best,
   john