Hi all,
Some notes about final states for reports below --
On 12/20/24 1:50 PM, John C Klensin wrote:
--On Saturday, December 21, 2024 08:04 +1300 Brian E Carpenter
<brian.e.carpen...@gmail.com> wrote:
On 21-Dec-24 04:14, S Moonesamy wrote:
Hi Brian,
At 05:13 PM 19-12-2024, Brian E Carpenter wrote:
Why? What if it describes a serious problem? How do we know that
the 4 open reports from 2010 are of no value without looking at
them?
I doubt that a person would believe that the RFC Editor is taking
the 2010 errata reports seriously if there wasn't any action on
those reports for the last 14 years. I would not describe a
report which I receive as being of no value.
The bug is that it isn't the RFC Editor that is responsible for
taking
action, beyond notifying the stream. The new system needs to ensure
that
there is a clear chain of responsibility (and probably some nagging
mechanism when no action occurs).
I note that most bug-fix fora have a possible end state of "won't
fix".
There's no reason we can't have a "won't fix" equivalent for errata.
Such fora also usually have a "re-open" action if a "won't fix" bug
turns out to really matter. I think the analogy is quite strong.
If we replace "rejected" by "won't fix", then an error report from
2010 could be re-opened in 2030 if appropriate.
Brian,
Agreed, except that, IMO, one reasonable interpretation of "hold for
document update" is "won't fix in current version but will review
this (e.g., automatic re-open) if we ever come back to that
document". If that interpretation is, in fact, reasonable, they we
have been misusing the existing category and, absent other changes,
there may be no reason to assume that the people/process who have
left a report open rather than assigning it to "hold for document
update" would not simply leave it open rather than going to the
effort of assigning "won't fix".
[JM] Note that the IESG updated its guidance to verifiers in 2021 [1] so
the interpretation and application of final states have changed over
time. Previous guidance was dated 2008 [2].
Here's a summary of changes:
Verified
- All technical items that have clear resolution in line
with original intent (rather than only those that could
cause implementation or deployment issues). Non-problematic
issues were HFDU previously.
- Grammar and typo corrections (were previously HFDU)
- Broken URLs (not mentioned in previous guidance)
Rejected
- Added rejecting reports made on Obsoleted RFCs
HFDU
- In addition to changes that modify the working of the
protocol or different than consensus, any clearly wrong
item that doesn't have a clear resolution.
Having just three final states is limiting. More states and/or labels
could help. Examples of labels: Verified - Nit, Verified - Minor, HFDU -
Enhancement, HFDU - Major, etc.
Best regards,
Jean
[1]
https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/
[2]
https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20080730/
All of this, IMO, brings us closer to the hypothesis of Stephen and
others that the current system is fundamentally broken and that it is
time to discard it and start over.
best.
john
--
rswg mailing list -- rswg@rfc-editor.org
To unsubscribe send an email to rswg-le...@rfc-editor.org
