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

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

Brian,

(possible further clarification_

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

> 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:
>> On 23-Jan-22 13:03, Greg Skinner wrote:
>>> 
>>> 
>>>> On Jan 21, 2022, at 6:25 AM, Alvaro Retana
>>>> <[e-mail] <mailto:[e-mail]>>
>>>> wrote:
>>>> 
>>>> On January 20, 2022 at 7:22:50 PM, Brian E Carpenter wrote:
>>>> 
>>>> 
>>>> Brian:
>>>> 
>>>> 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.
>>>> 
>>>> 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.
>>> 
>>> 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_O8MvJxk4th1n
>>> 1oyr0q3Xk/ 
> <https://mailarchive.ietf.org/arch/msg/bgp/b8sUF_O8MvJxk4th1n1
> oyr0q3Xk/>
>>> 
>>> A Last-Call was issued a couple of weeks later:
>>> 
>>> https://mailarchive.ietf.org/arch/msg/ietf/47X9CUDKjDEEV8qiB
>>> Cj_uO_jqmY/
>> <https://mailarchive.ietf.org/arch/msg/ietf/47X9CUDKjDEEV8qiB
>> Cj_uO_jqmY/>
>>> 
>>> The Protocol Action to move it to Historic took place about
>>> three weeks
>> later:
>>> 
>>> https://mailarchive.ietf.org/arch/msg/ietf/ztXGVqhjtjverb49x
>>> o6xVUPEnI8/
>> <https://mailarchive.ietf.org/arch/msg/ietf/ztXGVqhjtjverb49x
>> o6xVUPEnI8/>
>> 
>> 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 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 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