Greg,
See below...
On 24-Jan-22 21:13, Greg Skinner wrote:
On Jan 21, 2022, at 11:58 AM, Brian E Carpenter <brian.e.carpenter@xxxxxxxxx> 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?
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
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
