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

From: Brian E Carpenter <[email-masked]>
Date: Fri, 21 Jan 2022 13:22:05 +1300

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

Regards
    Brian Carpenter

On 21-Jan-22 11:33, The IESG wrote:
> 
> The IESG has received a request from an individual participant to make the
> following status changes:
> 
> - RFC911 from Unknown to Historic
>      (EGP Gateway under Berkeley UNIX 4.2)
> 
> The supporting document for this request can be found here:
> 
> https://datatracker.ietf.org/doc/status-change-rfc911-to-historic/
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2022-02-18. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> 
> The affected document can be obtained via
> https://datatracker.ietf.org/doc/rfc911/
> 
> IESG discussion of this request can be tracked via
> https://datatracker.ietf.org/doc/status-change-rfc911-to-historic/ballot/
> 
> 
> 
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: John C Klensin <[email-masked]>
Date: Fri, 21 Jan 2022 00:11:03 -0500

--On Friday, January 21, 2022 13:22 +1300 Brian E Carpenter
<[email-masked]> 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

---

From: Lars Eggert <[email-masked]>
Date: Fri, 21 Jan 2022 09:24:28 +0200

Hi,

just pointing out that this is not something the IESG initiated. As the email says, the request came from the community.

Also want to point out that asking the RFC Editor to develop the ability to take on these evaluations of pre-IETF documents is a significant ask, especially as the ideas in many of them have moved to the the IETF stream in later years. In practice, I’d assume that the RFC editor would consult the IESG in pretty much all cases.

Thanks,
Lars

-- 
Sent from a mobile device; please excuse typos.

> On Jan 21, 2022, at 00:34, The IESG <[email-masked]> wrote:
> 
>

---

From: Martin J. Dürst <[email-masked]>
Date: Fri, 21 Jan 2022 16:47:01 +0900

> Also want to point out that asking the RFC Editor to develop the ability to take on these evaluations of pre-IETF documents is a significant ask, especially as the ideas in many of them have moved…

Yes indeed. Probably the simplest thing would be for the RFC editor to 
propose to move all of them to historic (because they're all pretty old 
now, anyway), and give the IETF and others a way to tell them when 
that's not appropriate, e.g. because an old RFC is still relied on.

Regards,   Martin.

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 21 Jan 2022 14:25:13 +0000

On January 20, 2022 at 7:22:50 PM, Brian E Carpenter wrote:

Brian:

Hi!

> change the status of this RFC, which is dated 1984, two years before

Definitely a good topic for discussion.

However, I wonder how other RFCs-of-the-time (RFC904, for example)
were reclassified as Historic.  Unfortunately, there's no history in
the datatracker, and I couldn't find relevant information in the
archives.  Maybe someone here remembers.

I'm not saying that if we could do it before we should do it
again...just curious.  Also, that history may provide insight on a
general way forward.

Thanks!

Alvaro.

---

From: Alvaro Retana <[email-masked]>
Date: Fri, 21 Jan 2022 14:25:39 +0000

On January 21, 2022 at 2:24:45 AM, Lars Eggert wrote:

Hi!

> just pointing out that this is not something the IESG initiated. As the
> email says, the request came from the community.

Correct.

As the shepherding AD...  The request was sent to the RTG ADs.  The
three of us talked about it, and I then consulted with the idr WG
where there was no opposition to this action.  idr (Inter-Domain
Routing) is not chartered with working on EGP, but it is the closest
we have to a group that would be interested and knowledgeable about
it.

Alvaro.

---

From: John C Klensin <[email-masked]>
Date: Fri, 21 Jan 2022 10:44:08 -0500

--On Friday, January 21, 2022 14:25 +0000 Alvaro Retana
<[email-masked]> wrote:

>> just pointing out that this is not something the IESG
>> initiated. As the email says, the request came from the
>> community.
> 
> Correct.
> 
> As the shepherding AD...  The request was sent to the RTG
> ADs.  The three of us talked about it, and I then consulted
> with the idr WG where there was no opposition to this action.
>  idr (Inter-Domain Routing) is not chartered with working on
> EGP, but it is the closest we have to a group that would be
> interested and knowledgeable about it.

Alvaro (and Lars),

IMO, the above should be reflected in the proposed statement of
why this is being proposed/done.  If nothing else, and
reflecting on your note sent moments earlier, if someone comes
back a few years from now and wants to know how or why this was
done, that is important information.

More broadly (and as explained in probably too much detail in a
note I sent last night), I think that either the IETF (or,
better, the RFC Editor Function as Brian suggested) should
initiate a project to clean out those old specs(perhaps along
the lines of the RFC 4450 one for old Proposed Standards) and
consider this as part of that -or- the statement should include
an explanation of why the IESG and the community should be
spending time on this particular spec at this particular time.
In particular "it is causing harm and/or confusion because..."
would be a very helpful statement but I am guessing that, in
this case, there is no such harm or risk.

thanks,
  john

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 21 Jan 2022 15:52:25 +0000

note I sent last night), I think that either the IETF (or,
    better, the RFC Editor Function as Brian suggested) should
    initiate a project to clean out those old specs

Such a project sounds good, but I worry about the best being the enemy of the goodXXXX any incremental progress.

And the RFC Editor doesn't seem to have the technical knowledge, or industry segment experience to decide.

---

From: John C Klensin <[email-masked]>
Date: Fri, 21 Jan 2022 10:55:26 -0500

--On Friday, January 21, 2022 16:47 +0900 "Martin J. Dürst"
<[email-masked]> wrote:

>> Also want to point out that asking the RFC Editor to develop
>> the ability to take on these evaluations of pre-IETF
>> documents is a significant ask, especially as the ideas in
>> many of them have moved to the the IETF stream in later
>> years. In practice, I'd assume that the RFC editor would
>> consult the IESG in pretty much all cases.
> 
> Yes indeed. Probably the simplest thing would be for the RFC
> editor to propose to move all of them to historic (because
> they're all pretty old now, anyway), and give the IETF and
> others a way to tell them when that's not appropriate, e.g.
> because an old RFC is still relied on.

And that strikes me as a good way to handle things.  An equally
good one would be for the IESG to organize a process and make a
proposed list of old documents to the treated as if they were in
the IETF Stream.  A Last Call on that list (again, more or less
following the RFC 4450 model) and pruning as appropriate. would
then leave a collection of things that could be processed
normally in the IETF.

thanks,
   john

---

From: John C Klensin <[email-masked]>
Date: Fri, 21 Jan 2022 11:10:37 -0500

--On Friday, January 21, 2022 15:52 +0000 "Salz, Rich"
<[email-masked]> wrote:

> Such a project sounds good, but I worry about the best being
> the enemy of the goodXXXX any incremental progress.

On the other hand, considering all of the pre-IETF documents
that have so far been listed as "UNKNOWN", one at a time with
one Last Call per document and on-list negotiation of how the
permanent statement about the action should read strikes me a
horribly expensive in IETF Community and IESG time even though
it would probably constitute "incremental progress".
Conversely, if this particular document is sufficiently special
that it should be treated as a one-off, with no notion of
incremental-anything, I don't think we have seen an explanation
of that special-ness yet.

> And the RFC Editor doesn't seem to have the technical
> knowledge, or industry segment experience to decide.

Brian probably has a better explanation, but the RFC Editor
Function is the only group that has a legitimate claim of
responsibility for those old documents.  If the new RFC Editor
Model cannot organize a process to deal with them, a process
that might include assigning some of them and their fate to the
IETF, we had both better scurry over to that mailing list and
figure out how to fix that.

   john

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 21 Jan 2022 08:38:34 -0800

Why is any of this worth any effort from the IETF or the RFC Editor? Are 
there readers of RFCs who are confused about specific three-digit RFCs 
and think "I need to implement/operate this, it's current"? Even if so, 
would those same implementers/operators be the kind of people who would 
know where to find out that an RFC has been marked as historic, and what 
that means?

This seems like a lot of effort for no defined (or discernible) value to 
the RFC-reading community.

--Paul Hoffman

---

From: tom petch <[email-masked]>
Date: Fri, 21 Jan 2022 17:07:33 +0000

> the RFC-reading community.

I agree.  It would be far simpler to create a new category 'Unknown' 
which means that the RFC were created before the current processes were 
in place and so cannot be placed in any of the other categories. Nor do 
they conform in many other ways e.g. Security Considerations, IANA 
Considerations, because the need for them was not then apparent.

Those that matter- e.g. 793 - get updated eventually and it would be 
more productive to put effort into those.

Tom Petch

---

From: David Farmer <[email-masked]>
Date: Fri, 21 Jan 2022 11:19:16 -0600

> it would probably constitute "incremental progress".

What if we looked at this from the converse, is there anything with a
status of "UNKNOWN" that is currently useful information to the standards
process, which is controlled by the IETF and IESG, other than as historical
context?
If there is, then the IETF and the IESG should promote such documents with
a relevant status within the standards process, be that "Informational",
"BCP", or something else in the standards track. For example, as was done
with RFC20 a few years ago. Once such a review for relevance to the
standards process is completed, by the IETF and IESG, then the RFC Editor
at their discretion can make the decision about the status of these older
RFCs with a status of "UNKNOWN".

So, relating to the RFCs with "UNKNOWN" status, it is the IETF and IESG's
job to determine if they have current relevance to the standards process,
baring such current relevance the status of these documents should be the
responsibility of the RFC Editor.

Thanks.

-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 21 Jan 2022 17:23:01 +0000

> the RFC-reading community.

what's the long term plan with rfc garbage collection at the ietf?  To 
leave obsolete documents accrete indefinitely, or to implement some form 
of pruning, either ad-hoc or more systematic?

Nick

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 21 Jan 2022 18:30:34 +0100

On 2022-01-21, at 17:38, Paul Hoffman <[email-masked]> wrote:
> 
> This seems like a lot of effort for no defined (or discernible) value to the RFC-reading community.

I’d like to hear the backstory from the original submitter…
Did RFC 911 pop up in an RFP and was hard to get rid of as a requirement?
Just speculating…

Grüße, Carsten

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 21 Jan 2022 12:34:22 -0500

> of pruning, either ad-hoc or more systematic?

Why isn't the obsoleting of RFCs by later versions and the occasional
declaration of an RFC as Historic sufficient pruning?

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [email-masked]

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 21 Jan 2022 18:25:14 +0000

> declaration of an RFC as Historic sufficient pruning?

if there are documents in the rfc library which are defunct, but neither 
obsoleted nor declared historical, then there is an argument to say that 
there's insufficient pruning.  Eyeballing rfc-index, there seems to be 
quite a number of documents of this form.

Nick

---

From: Christian Huitema <[email-masked]>
Date: Fri, 21 Jan 2022 09:25:15 -1000

> responsibility of the RFC Editor.

One thing that the IETF could do is treat all references to an RFC of 
status "UNKNOWN" as down-reference. This will automatically require an 
exception process before adding normative references to old RFCs.

-- Christian Huitema

---

From: Lars Eggert <[email-masked]>
Date: Fri, 21 Jan 2022 21:32:58 +0200

Only when they are cited normatively, and I think this would already happen now - they just don’t get (normatively) cited much.

Lars

> On Jan 21, 2022, at 21:25, Christian Huitema <[email-masked]> wrote:
> 
> One thing that the IETF could do is treat all references to an RFC of status "UNKNOWN" as down-reference. This will automatically require an exception process before adding normative references to old RFCs.
> 
> -- Christian Huitema
> 
> -- 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Jan 2022 08:58:54 +1300

> And the RFC Editor doesn't seem to have the technical knowledge, or industry segment experience to decide.

I carefully wrote "the RFC Editor function". Of course this is an
issue for the wider community - that's *exactly* why we are proposing
a completely new community process for the policy aspect of the
updated RFC Editor function.
  
If anyone cares, I raised the issue of the "unknown" RFCs with
the RFC Editor in 2015, and basically it was put on the "too hard"
list then. Doing 900 last calls like the present one clearly doesn't
scale, and doing just one of them seems pointless.

    Brian

---

From: Michael StJohns <[email-masked]>
Date: Fri, 21 Jan 2022 15:04:52 -0500

> Did RFC 911 pop up in an RFP and was hard to get rid of as a requirement?
Carsten -

Quite a lot of the early RFC documents were either implicit or explicit 
deliverables under various US Gov't contracts.  In the current case, I 
believe that NSF was funding the Berkeley 4.2 network implementations in 
addition to the funding the author got from Telecom Austria, or that the 
author was getting indirect funding via ISI-USC from ARPA or NSF.  This 
was simply a report of his work that could be published with minimal 
effort and provide information for a community that cared.  Sadly, that 
no longer describes the RFC series.

These aren't "HISTORICAL" documents in the normal IETF meaning. This was 
never an IETF document, nor did any documents created in the IETF depend 
on it, or extend it.   Some of the BGP work probably took note, but for 
those purposes this is exactly the same as any external cite of a 
published technical report in any channel say for instance an IEEE 
document and we don't really treat those as special (e.g. downref).

We've got a few documents that were created prior to the IETF (e.g. 
RFC791) on which we've hung IETF tags (i.e. STD 5) for our own purposes, 
but RFC791 was originally created to document a DOD standard (and I 
believe still does) so, while  removing the STD 5 tag and applying to a 
new document at some future time might be appropriate, declaring RFC791 
HISTORIC would probably never be appropriate because, while it's an RFC, 
it's not an IETF RFC. That's just one example.

Unless we've first hung one of our tags on the document indicating that 
we are depending on it, we probably shouldn't be twiddling with those 
documents not originated in the IETF process.  Specifically, calling 
this (RFC 911) document HISTORIC is a pretty arrogant arrogation of 
authority over a document that was never an IETF(or IAB or IRTF) 
document and never will be.

There are also a few RFCs published after the creation of the IETF that 
are not IETF documents and we should leave them be as well, lest someone 
claim that anything created after the Boulder IETF is under the IETF's 
purview.

Later, Mike

---

From: Rob Sayre <[email-masked]>
Date: Fri, 21 Jan 2022 12:06:52 -0800

> scale, and doing just one of them seems pointless.

I don't see the harm in just leaving them as-is. Maybe someone could write
a draft explaining that most of them will be left that way, on purpose.

thanks,
Rob

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 22 Jan 2022 09:07:07 +1300

Nick,
> quite a number of documents of this form.

For example:

0760 DoD standard Internet Protocol. J. Postel. January 1980. (Format:
      TXT, HTML) (Obsoletes IEN123) (Obsoleted by RFC0791) (Updated by
      RFC0777) (Status: UNKNOWN) (DOI: 10.17487/RFC0760)

That's IMNSHO exactly why we need a policy on this and a mechanism
for detecting any cases that shouldn't simply be marked HISTORIC,
and that's one reason why we need the new RFC Editor model that will
be formally proposed Real Soon Now.

I don't think we need to spend IESG time on this, however.

    Brian

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 21 Jan 2022 16:55:48 -0500

RFCs are immutable objects. I think of them as books on a shelf.
Mostly labels and categories are imposed on them for the convenience
of the IETF and other users of the documents. Early RFCs, unlike more
recent ones, generally did not have such labeling within the document.
But I have always thought that it would not be that hard to classify
almost all the "Unknown" status RFCs into our modern categories.
Trying to do this for all of them at once would be a large, perhaps
impractical task but doing it as convenient when early RFCs are
encountered or noticed doesn't seem so hard. It is fairly clear to me
that RFC 911 and similar documentation of specific implementations
should be labeled Informational while RFC 760 should be labeled
Standards Track. I don't see that the IETF deciding that some early
RFC should have some particular label for IETF purposes as interfering
with the authority of the RFC Editor. It's not like the early RFCs,
which are immutable, are actually being changed. The book on the shelf
remains the same.

I suppose this is somewhat orthogonal to whether RFC 911 should be
Historic and who should decide that. Probably for early enough RFCs,
that should be under the authority of the RFC Editor but I'm not sure
why the RFC Editor would want the burden and would probably be happy
to delegate it to the IETF.

Thanks,
Donald

---

From: Greg Skinner <[email-masked]>
Date: Sat, 22 Jan 2022 16:03:39 -0800

> On Jan 21, 2022, at 6:25 AM, Alvaro Retana <[email-masked]> wrote:
> 

I was able to trace the reclassification of RFC904 to Historic from the August 1994 BGP/IDRP-IP WG meeting, at which it was decided "to move EGP in all forms to a historical status.”

https://mailarchive.ietf.org/arch/msg/bgp/b8sUF_O8MvJxk4th1n1oyr0q3Xk/ <https://mailarchive.ietf.org/arch/msg/bgp/b8sUF_O8MvJxk4th1n1oyr0q3Xk/>

A Last-Call was issued a couple of weeks later:

https://mailarchive.ietf.org/arch/msg/ietf/47X9CUDKjDEEV8qiBCj_uO_jqmY/ <https://mailarchive.ietf.org/arch/msg/ietf/47X9CUDKjDEEV8qiBCj_uO_jqmY/>

The Protocol Action to move it to Historic took place about three weeks later:

https://mailarchive.ietf.org/arch/msg/ietf/ztXGVqhjtjverb49xo6xVUPEnI8/ <https://mailarchive.ietf.org/arch/msg/ietf/ztXGVqhjtjverb49xo6xVUPEnI8/>

In response to Brian’s suggestion that the RFC Editor function should be responsible for reclassifying the status of non-IETF RFCs, perhaps, but what happens if the IETF winds up having to do the work anyway?

Regards, Greg

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 23 Jan 2022 13:16:55 +1300

On 23-Jan-22 13:03, Greg Skinner wrote:
> 
> 
>> On Jan 21, 2022, at 6:25 AM, Alvaro Retana <[email-masked] <mailto:[email-masked]>> wrote:
>>
> I was able to trace the reclassification of RFC904 to Historic from the 
August 1994 BGP/IDRP-IP WG meeting, at which it was decided "to move 
EGP in all forms to a historical status.”
> https://mailarchive.ietf.org/arch/msg/ietf/47X9CUDKjDEEV8qiBCj_uO_jqmY/ 
<https://mailarchive.ietf.org/arch/msg/ietf/47X9CUDKjDEEV8qiBCj_uO_jqmY/>
> https://mailarchive.ietf.org/arch/msg/ietf/ztXGVqhjtjverb49xo6xVUPEnI8/ 
<https://mailarchive.ietf.org/arch/msg/ietf/ztXGVqhjtjverb49xo6xVUPEnI8/>

Thanks for the archaeology.

> In response to Brian’s suggestion that the RFC Editor function should be responsible for reclassifying the status of non-IETF RFCs, perhaps, but what happens if the IETF winds up having to do the w…

It will always need to be a community decision. For documents that somehow infringe on IETF territory, the IETF needs to be involved, of course. But that doesn't mean that the IETF can decide alone about non-IETF documents.

(The current concept of RFC streams didn't exist in 1994, and neither did 
the clear separation of the RFC Editor function from the IETF, so the situation was entirely different.)

Regards
     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Jan 2022 09:38:00 +1300

Hi,

It's been suggested to me that what I wrote could be misunderstood.
Please see my clarification at the end...
On 23-Jan-22 13:16, Brian E Carpenter wrote:
>> https://mailarchive.ietf.org/arch/msg/bgp/b8sUF_O8MvJxk4th1n1oyr0q3Xk/ 
<https://mailarchive.ietf.org/arch/msg/bgp/b8sUF_O8MvJxk4th1n1oyr0q3Xk/>
>> In response to Brian’s suggestion that the RFC Editor function 
should be responsible for reclassifying the status of non-IETF RFCs, perhaps, but what happens if the IETF winds up having to do the work anyway?
> 
> It will always need to be a community decision. For documents that somehow infringe on IETF territory, the IETF needs to be involved, of course. 
But that doesn't mean that the IETF can decide alone about non-IETF documents.
> the clear separation of the RFC Editor function from the IETF, so the situation was entirely different.)

Formally, the separation existed, and there's no doubt that Jon Postel
and Joyce Reynolds took independent decisions about RFC status etc.
However, they were personally involved in IETF discussions and
certainly would have understood immediately that deprecating EGP was
the right thing to do. Today, we can't assume that RFC Editor staff
are closely involved in technical discussions. That makes things
different.

Regards
     Brian

---

From: John C Klensin <[email-masked]>
Date: Sun, 23 Jan 2022 17:06:48 -0500

Brian,

(possible further clarification_

--On Monday, 24 January, 2022 09:38 +1300 Brian E Carpenter
<[email-masked]> wrote:

>>>> On Jan 21, 2022, at 6:25 AM, Alvaro Retana
>>>> <[email-masked] <mailto:[email-masked]>>
>>>> wrote:
>>>> 
>>>>> 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.
>>>> 
>>>> However, I wonder how other RFCs-of-the-time (RFC904, for
>>>> example) were reclassified as Historic.  Unfortunately,
>>>> there's no history
>> in
>>>> the datatracker, and I couldn't find relevant information
>>>> in the archives.  Maybe someone here remembers.
>>>> 
>>>> again...just curious.  Also, that history may provide
>>>> insight on 
> a
>>>> general way forward.
>>>> 
>>>> 
>>>> Thanks!
>>>> 
>>>> Alvaro.
>>> 
>> August 1994 BGP/IDRP-IP WG meeting, at which it was decided
>> "to move EGP in all forms to a historical status."
>>> 
>>> The Protocol Action to move it to Historic took place about
>>> three weeks
>> later:
>>> 
>>> In response to Brian's suggestion that the RFC Editor
>>> function 
> should be responsible for reclassifying the status of non-IETF
> RFCs, perhaps, but what happens if the IETF winds up having to
> do the work anyway?
>> 
>> It will always need to be a community decision. For documents
>> that somehow infringe on IETF territory, the IETF needs to be
>> involved, of course. 
>> (The current concept of RFC streams didn't exist in 1994, and
>> neither did the clear separation of the RFC Editor function
>> from the IETF, so the situation was entirely different.)
> 
> Formally, the separation existed, and there's no doubt that
> Jon Postel and Joyce Reynolds took independent decisions about
> RFC status etc. However, they were personally involved in IETF
> discussions and certainly would have understood immediately
> that deprecating EGP was the right thing to do. Today, we
> can't assume that RFC Editor staff are closely involved in
> technical discussions. That makes things different.

First, I assume you meant "Formerly", not "Formally".  If not, I
don't quite understand.

There is another distinction that is more important.  While
things were somewhat different pre-Kobe, in general documents
created by the IETF could, in general, be updated or obsoleted
only by the IETF or with IETF permission.  Little has changed
there since at least the early 1990s.  In practice, the only
status changes that were in the hands of the RFC Editor after
the early 1990s involved the use of Historic and it was clear
not long after the mid-1990s (when Jon and Joyce were still in
charge) that such changes were not to be made to IETF documents
without IESG involvement.  

The present situation, as your original note pointed out, is
about a very narrow set of cases: documents with status
"UNKNOWN" published either prior to the IETF coming into
existence or published other than at IETF request (a distinction
that existed long before the Stream Model).

   --john

---

From: Greg Skinner <[email-masked]>
Date: Mon, 24 Jan 2022 00:13:50 -0800

> On Jan 21, 2022, at 11:58 AM, Brian E Carpenter <[email-masked]> wrote:
> 

Brian,

Are you more concerned about the scalability issue you raised, the “predates the existence of the IETF” issue, or something else?

Some others asked why moving RFC911 to Historic wasn’t part of a larger effort, such as was documented in RFC7805, which moved RFC896 to Historic.  (Arguably, RFC896 falls into the “predates the existence of the IETF” category.)  I agree that there is a legit scalability concern, but I’m not sure it would always be mitigated by requiring any status change to be part of a larger effort.  (Arguably, each of the documents in the effort would need to be reviewed, even if each IESG member is only required to provide one response for all of the documents.)

Greg

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 25 Jan 2022 09:55:00 +1300

Greg,

See below...

> Are you more concerned about the scalability issue you raised, the “predates the existence of the IETF” issue, or something else?

I have a mixture of concerns here:

1) Concern about clarity of responsibility. I think the upcoming
proposal for the RFC Editor model will clarify much of that, so we
should just wait for it.

2) Concern about IESG workload. Not for this one case, but there
are 900 other such RFCs, most of which predate the IETF. The IESG
has better things to do, and we have recurrent difficulties caused
by IESG workload. So if the RFC Series community decides that this
issue deserves attention, the solution should certainly not include
900 IESG reviews and decisions.

Of course there are exceptions, the elevation of RFC20 being a precedent.

To be clear, moving RFC911 to Historic is *obviously* the right thing
to do and should have happened years ago. I just don't think this is
the right way to do it.

> Some others asked why moving RFC911 to Historic wasn’t part of a larger effort, such as was documented in RFC7805, which moved RFC896 to 
Historic.  (Arguably, RFC896 falls into the “predates the existence of the IETF” category.)  I agree that there is a legit scalability concern, but I’m not sure it would always be mitigated by requiring any status change to be part of a larger effort.  (Arguably, each 
of the documents in the effort would need to be reviewed, even if each IESG member is only required to provide one response for all of the documents.)

Once we have the new RFC Editor model in place, I might well write a
draft proposing a scalable solution to this problem. But not now.

Regards
     Brian

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 26 Jan 2022 06:53:46 +0200

I don't think it is UNKNOWN, many IT participants know RFC911.  I think it
is in a wrong place to be stated unknown, it SHOULD be in a KNOWN status.
However, any document is known by the author(s) and readers, why did IETF
make such status while it produces documents for technology.
Finally, I don't mind if any old document goes to historic, because in the
end we still will remember important authors and important documents.

Best Regards
AB

---

From: Greg Skinner <[email-masked]>
Date: Thu, 27 Jan 2022 21:22:43 -0800

AB,

My understanding is that Unknown is a default status, given to documents that don’t fall into any of the other categories.  You can see this by clicking on the Uncategorized link <https://www.rfc-editor.org/search/rfc_search_detail.php?sortkey=Number&sorting=DESC&page=All&pubstatus%5B%5D=Unknown> from the RFC Editor page, then clicking on Additional Criteria.

Some of the documents on that list were published after the IETF came into existence.  The most recent one is RFC1125, dated November 1989.

Regards, Greg

> On Jan 25, 2022, at 8:53 PM, Abdussalam Baryun <[email-masked]> wrote:
> 
> I don't think it is UNKNOWN, many IT participants know RFC911.  I think it is in a wrong place to be stated unknown, it SHOULD be in a KNOWN status.
> However, any document is known by the author(s) and readers, why did IETF make such status while it produces documents for technology. 
> Finally, I don't mind if any old document goes to historic, because in the end we still will remember important authors and important documents.
> 
> Best Regards
> AB
> 
> On Fri, Jan 21, 2022 at 2:22 AM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> Hi,
> 
> > https://datatracker.ietf.org/doc/status-change-rfc911-to-historic/ <https://datatracker.ietf.org/doc/status-change-rfc911-to-historic/>
> > 
> > [email-masked] <mailto:[email-masked]> mailing lists by 2022-02-18. Exceptionally, comments may
> > be sent to [email-masked] <mailto:[email-masked]> instead. In either case, please retain the beginning
> > https://datatracker.ietf.org/doc/rfc911/ <https://datatracker.ietf.org/doc/rfc911/>
> > 
> > https://datatracker.ietf.org/doc/status-change-rfc911-to-historic/ballot/ <https://datatracker.ietf.org/doc/status-change-rfc911-to-historic/ballot/>
> > 
> > 
> > 
> > [email-masked] <mailto:[email-masked]>
> > https://www.ietf.org/mailman/listinfo/ietf-announce <https://www.ietf.org/mailman/listinfo/ietf-announce>
> > 
> 
> -- 
> last-call mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/last-call <https://www.ietf.org/mailman/listinfo/last-call>