Sorry, meant to send this earlier (overlap with SM's comment noted)...
--On Friday, December 20, 2024 09:07 +1300 Brian E Carpenter
<[email protected]> wrote:
> On 20-Dec-24 04:46, Jean Mahoney wrote:
> ...
>> To deal with the backlog, should we just close reports that have
>> been open for a long time?
>
> I know this is tempting but who's to say that a report from 5 years
> ago wrong?
> One suggestion (and it doesn't need a new process) is to send an
> email to the reporter of each open report >N years old, saying "Is
> this still valid? Unless you reply within one month, we will close
> it."
But the lack of a reply within one month (or any other set period)
could as easily mean "gave up on this issue and no longer care" or
"gave up on the IETF and its processes after hearing nothing for more
than four years" as "not valid". In addition, several of the things
that have been said about junk imply that the original submitter
might not be the best judge of validity. That idea is yet another
reason why we need to move beyond "errata" and the current system
(Stephen's variation, mine, or something else). For this case, a
posting to a relevant WG list (even if the WG is no longer active)
or, if necessary, an Area one, of a list of outstanding errata
relevant to those lists with a request that anyone who believes that
particular old reports are worth further energy start a discussion.
Put differently, the present system assumes that the RFC System
and/or IETF (or other streams) are going to take error reports
seriously. Ones that "we" do not intend to take seriously should be
swiftly rejected (as spam, trash, or whatever) or dropped into "hold
for document update" (the latter category is more or less what I
think Christian and I are proposing for just about everything and,
IMO, more or less consistent with Stephen's "start a discussion").
If five years later, the evidence is that "we" have dropped the ball
on that commitment, then we can either issue a last call for a
discussion to start, classify it as "hold for document update" where
it will sit until such a discussion starts, or decide that, if there
has been no discussion after five years, no one cares. I think we
should be very hesitant to assume the latter (whether we try to ask
the reporter about "validity" or not) because the present system
provides too many possibilities (and maybe incentives) for things to
fall through the cracks.
Of course, a simpler version of the above and several other proposals
would be to just reclassify everything that is more than a year or so
old, without any evidence of significant progress in the interim, as
"hold for document update". Formally, that would treat it as
resolved, but it will sit until someone chooses to start thinking
about the document. That would be almost the same as what I proposed
earlier and/or Stephen's proposal except that we would continue
misrepresenting to ourselves and the community about what is
happening.
Continuing with that logic...
>> The definition of "long time" would need to be
>> determined.
>
> There are currently the following open reports:
>
> 2010: 4
> 2013: 5
> 2014: 17
> 2015: 30
> 2016: 45
> 2017: 50
> 2018: 65
> 2019: 59
> 2020: 77
> 2021: 62
> 2022: 81
> 2023: 69
> 2024: 149
>
> Total: 713
>
> Here's a suggested plan:
>
> - Arbitrarily close all reports on Legacy stream and Historic or
> Obsoleted or Unknown RFCs. (And don't allow them in future.)
Consistent with earlier suggestions and independent of the rest of
this.
> For all reports before 2020:
>
> - Close all editorial reports.
> - Send "Is this still valid?" messages for the rest, and close
> them a month later if no reply.
See above... unless such messages to go more than erratum authors.
>> Or should the RPC host a hackathon at an upcoming IETF
>> meeting where verifiers work through as many open reports as
>> possible? We could bring pizza :-)
>
> Something like that for the reports since 2020; or launch an online
> hackathon.
For an RFC or a report obscure enough that no one has felt like
noticing it and putting energy into it for years, either almost
guarantees that people will be making decisions about documents they
don't understand.
Let me try a made-up example to which I'm sensitive for other
reasons. Let's assume there was an error report on RFC 5892, one
that addressed a rather subtle issue with how Unicode or IDN works,
and that had been unresolved for "a long time" [1]. Even
understanding such an erratum to the degree needed to evaluate it
requires significant expertise with IDNA and maybe Unicode,
relationships to other work, etc. To paraphrase comments that have
been made about other aspects of IDNA (and PRECIS, etc.) there are
very few people in the IETF who actually have that level of
expertise. To make things more complicated, there have been, over
the years, several who thought they did and turned out to be wrong.
So now we are going to hold a (general purpose) hackathon and hope
the right people will show up and be able to properly evaluate such
an error report, understand the context and possible side-effects of
their recommendations, etc.? I think the phrase is YMBK.
On the other hand, taking a look at such an erratum and dropping it
into "hold for document update" (because those involved with IDNA2008
have been fairly good at addressing errata and this hypothetical one
being ignored suggests, contrary to that, that no one is likely to
look at it until such a revision/update effort gets started) does not
require a hackathon and could reasonably be done by default.
On the other hand, if one wants to invent a more complicated process
in the hope that might help, looking at documents for which (i) there
is a good track record of other errata reports being considered and
resolved (somehow) and (ii) some errata have been outstanding for "a
long tine") might provide useful information.
best,
john
[1] There isn't. There has been exactly one errata report filed on
that document, it was filed by the original author after some
community discussion, and then immediately verified. A very
different case from the ones we have been discussing. Even then, the
errata report record mentions "The RFC has been updated by RFC 8753".
But RFC 8753 explicitly includes an update that makes this error
report obsolete and the current system does not allow the error
report record to say that.
https://www.rfc-editor.org/errata_search.php?rfc=5892&rec_status=15&presentation=records.
>
> Regards
> Brian
>>
>> Thanks!
>> Jean
>>
>>
>>> We should chuck
>>> it out and replace it entirely.
>>>
>>> Cheers,
>>> S.
>>>
>>>
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
