ietf
[Top] [All Lists]

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

2015-08-12 07:27:20

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

On 12/08/15 09:45, John C Klensin wrote:
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:

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.


      (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