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

[Greg Skinner <[e-mail]>]

> On Jan 21, 2022, at 11:58 AM, Brian E Carpenter <[e-mail]> wrote:
> 
> On 22-Jan-22 04:52, Salz, Rich wrote:
>>>    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
>> 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.
> 
> 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

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