Re: [Last-Call] Last Call: Moving RFC911 to Historic

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

--On Friday, January 21, 2022 13:22 +1300 Brian E Carpenter
<[e-mail]> wrote:

> Hi,
> 
> In my opinion, the IETF, and therefore the IESG, has no right
> to change the status of this RFC, which is dated 1984, two
> years before the IETF existed.
 
> I believe that the status of many early RFCs should be
> reviewed, but by the RFC Editor function, not by the IETF.
> Probably, Historic is the correct status for most of them.
> However, it isn't an urgent matter as we have managed for the
> last 35+ years with these RFCs unclassified, and we can
> certainly wait until the new RFC Editor model is in place.
> This will provide a proper mechanism to develop policies such
> as "what to do about the 904 RFCs with status UNKNOWN".

Brian,

While I am skeptical about whether getting involved with the
"rights" of the IETF is productive, I largely agree with the
above.  I found myself wondering why the effort described in RFC
4450 did not pick this one up.  Having now looked that document,
it reinforces your point of view: the IETF apparently decided at
the point that cruft-cleaning should be focused on Standards
Track (and hence IETF) documents (Eliot or Harald may be able to
shed more light on that decision as my memory is very vague).

It would certainly seem appropriate to turn  the problem over to
the new version of the RFC Editor model.  Perhaps figuring out
how to proceed might even be a good initial project for the RSWG
-- interesting and complex, but not likely to stir up deep
passions and conflicts.  But I could be wrong about that.

On the other hand, if the IESG is determined to go through with
this, I think the community should insist that the status change
notice be expanded to explain why it is important to make this
particular change at this particular time... noting for example
that 4.2 BSD isn't being used much any more but has not been for
many years.  It this is an effort to clean out documents with
status "UNKNOWN", then why single out this one rather than
mounting an organized cleanup effort (again, preferably in
conjunction with the RFC Editor Function) along the same lines
as the RFC 4450 review.

   john