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