--On Wednesday, August 12, 2015 10:52 -0500 Nico Williams
<nico(_at_)cryptonector(_dot_)com> wrote:
On Wed, Aug 12, 2015 at 03:34:19PM +0200, Harald Alvestrand
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.
--On Wednesday, August 12, 2015 15:34 +0200 Harald Alvestrand
<harald(_at_)alvestrand(_dot_)no> wrote:
Den 12. aug. 2015 14:27, skrev Stephen Farrell:
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.
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