Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09)

[John C Klensin <[e-mail]>]

Warning/disclaimer: I believe that reclassifying RFC 20 to match
unquestionable reality is so obvious that I'm somewhat annoyed
at having to spend time (and the community's time) discussing
it.  If the IESG feels justified in applying fast track
procedures to documents that are far more controversial (and for
which there is not even five or ten years of successful
operational experience, much less 45), we really shouldn't need
to spend time debating what can or should be done with RFC 20.
If that annoyance comes through below and is unreasonable, my
apologies.

--On Saturday, December 06, 2014 15:02 +0000 "Stewart Bryant
(stbryant)" <[e-mail]> wrote:

> If it is just for IETF purposes it could be added to the
> downref list without being reclassified.

Well, actually, it probably can't.  In addition to what I hope
is a better and more substantive explanation below, this note
concludes with a little protocol-lawyer explanation that could
be the basis for an appeal of any attempt to use that approach.

My understanding, and I think that of the community, was that
the reason for RFC 6410 was to increase the number of document
that we classified as Internet Standards by reducing the
barriers to doing so.  It would be truly unfortunate, IMO, if we
now started introducing additional obstacles such as "this could
be accomplished in some other way".

In addition, there is nothing about the status of RFC 20 that is
unknown.  The way the maturity classification system was
introduced resulted in identifying the status of many early
document with "Unknown" as a short way to say "formal status not
reviewed and assigned", but that is not because we didn't know.
It is because the RFC Editor and the community didn't believe
that going through those documents was worth spending time on.
Those were kinder, gentler, and less procedurally constipated
times; today, the failure to assign a classification to RFC 20
looks in retropsect more like an isolated error in judgment.
The technology the document describes is in very heavy use
(including in the specification that allowed these messages
about it to be sent and interpreted), the RFC itself is
extensively referenced in other IETF specs (not that such
references are a requirement for Internet Standard even under
2026), and it is arguably the most stable RFC-published
specification we still use (all lower-numbered RFCs are either
status reports, associated with the NCP ARPANET, or
documentation specifications that have been replaced by the RFC
Format specification documents  that start with RFC 825 and
cumulate in the recently-approved RFC 7322).  


The Protocol-lawyer speaks:

Strictly speaking and AFAIK, we've got two consensus documents
that modify the RFC 2026 requirements about downrefs.   The
first is RFC 3967.  It is fairly broad about what can be
referenced, but requires an explicit statement in the Last Call
announcement about what is being done.  That can be waived for a
given document, but only if there have been several such Last
Call announcements in the past.  There have been, again AFAIK,
no such announcements for RFC 20, so a single Last Call to
reclassify it would actually involve less work and time than
applying that particular RFC 3967 rule.  More important, RFC
3967 is quite explicit that use of a downref procedure is
inappropriate for cases like this.  The relevant sentence reads:

	"This procedure should not be used if the proper step is
	to move the document to which the reference is being
	made into the appropriate category."

and the text that follows just strengthens that message.

There is also no support in the more flexible RFC 4897 because
it applies only to standards-track documents.  If RFC 20 is not
considered a standards-track document because it is listed with
a status of "Unknown", then 4897 cannot be applied.   If it is
really a standards-track document in spite of that placeholder
designation in the RFC Index, then there is no basis for
treating it as other than a full standard and its listing as
"unknown" is a clerical error that the RFC Editor should be
directed to correct forthwith (with no reclassification
procedure required).

    john