Internet DRAFT - draft-farrell-errata
draft-farrell-errata
Network Working Group S. Farrell
Internet-Draft Trinity College Dublin
Intended status: Informational 11 February 2024
Expires: 14 August 2024
Something Better Than Errata
draft-farrell-errata-00
Abstract
This document outlines some ideas for a system that would (in the
author's view) be better than current errata handling. This is for
discussion and is not expected to become an RFC.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 14 August 2024.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Farrell Expires 14 August 2024 [Page 1]
Internet-Draft Better Than Errata February 2024
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Policy versus Implementation . . . . . . . . . . . . . . . . 2
3. The New System . . . . . . . . . . . . . . . . . . . . . . . 3
4. Handing existing errata . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
8. Normative References . . . . . . . . . . . . . . . . . . . . 4
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 4
A.1. Draft-00 to -01 . . . . . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction
Current handling of errata for RFCs is a pain, for all concerned, and
is also fairly ineffective in terms of soliciting comment on RFCs,
arriving at new text when errors are discovered, likely to see many
errata not be processed or be processed at glacial speed, and the
current system is also terrible at making changes visible to RFC
readers. It's basically a mess.
In this draft, we sugggest an alternative way of handling the
discussion and dispositon of errors in RFC text. We maintain the
idea that this system aims only to correct errors in RFC text, but is
not indended to provide a new route for revision of RFCs.
For simplicity, we describe the system as if it existed. We make no
real effort to determine if putting such a system in place would be
very easy or very hard and expensive. We also describe the system as
if everyone reads RFCs via the datatracker.
The author is not invested in the details here, anything
approximating what's described here would probably be fine.
If useful, comments/issues/PRs are welcome at:
https://github.com/sftcd/errata/
2. Policy versus Implementation
Some of the details below are provided via indirection, using the
[RPCTBD], reference. In those cases, the intent is that the
referenced documents are maintained by, and under the change control
of, the RPC, but that those details MUST ensure that control over the
content of RFCs remains with the community and is never given to the
RPC or IETF LLC. The RPC are expected to consult with the community
as changes are considered.
Farrell Expires 14 August 2024 [Page 2]
Internet-Draft Better Than Errata February 2024
There is one exception - where user-provided input is allowed, then
spam will follow. The RPC are empowered to delete obvious spam as
soon as possible. The RPC should periodically (perhaps yearly)
report to the RSAB on recent trends related to spam in this system.
3. The New System
Once an RFC is published, then, on the datatracker web page for
viewing that RFC, there will be a "comment/discuss" button that
allows readers with a datatracker account to submit comments on, or
questions about, that RFC. Threaded discussions on comments can
follow, not unlike issue discussion on github.
Discussion threads for RFCs can be browsed/searched.
Discussion threads are expected to be re-directed to an IETF mailing
list as warranted. Discussions can be closed if warranted, e.g. as
off-topic. A set of users will have relevant powers, probably
including some new role(s) specifically for managing such discussions
where nobody else might notice, e.g. on some ancient RFC.
By default, RFC authors and relevant WG chairs will recieve
notification when new discussion threads are started.
Comments can be labelled in various ways, by the original poster or
by other users with additional privileges, e.g. authors, (former) WG
chairs, ADs or IRSG members. The set of priviliges associated with
this system are expected to change slowly over time and are
documented at [RPCTBD].
One way to label a specific comment that contains a suggested change
is as an erratum.
Comments labelled as errata can be upvoted or downvoted. Voting
power can vary depending on the user, with authors of the RFC in
question, (former) WG chairs, ADs, etc having more voting power. The
set of up/down voting rules are expected to change slowly over time
and are documented at [RPCTBD].
Once a comment labelled as an erratum has sufficient upvotes, then it
can be approved by a relevant approver. For the IETF stream any AD
can mark a sufficiently upvoted erratum as approved. Two relevant WG
chairs can also do so if there is a relevant WG that is still open or
only closed within the previous five years. If an errata for an IETF
stream RFC is erroneously approved then that can be reversed by an
AD.
Farrell Expires 14 August 2024 [Page 3]
Internet-Draft Better Than Errata February 2024
It must be possibly to automatically apply the change resulting from
an erratum before it is approved. The required formatting may change
over time and the current requirements are documented at [RPCTBD].
Other streams will define other approval schemes.
The default HTML view of RFCs will be that with errata applied. The
list of applied errata can be viewed via a button, as can any
conversation leading up to an approval.
4. Handing existing errata
Some of the issues arising in migrating to the new system include:
* Existing approved errata need to be imported into the new system
so as to be displayed as if they had been approved.
* No action is required with respect to current, posted but
unprocessed, errata. If any of those are really useful, they'll
be remembered or re-discovered. The expectation is that
discussions using the new system will be started for some of these
unprocessed errata and that that will prove to be an easier way to
finally process the actually useful subset of those.
The current errata system should remain available in read-only mode
so that editors revising RFCs can access e.g. relevant HDFU errata.
5. IANA Considerations
This document makes no request of IANA.
6. Security Considerations
Spam comments and flamewars could distract and damage the reputation
of the RFC series.
7. Acknowledgements
TBD
8. Normative References
[RPCTBD] RPC, "somewhere the RPC publish stuff", 2024.
Appendix A. Change Log
Farrell Expires 14 August 2024 [Page 4]
Internet-Draft Better Than Errata February 2024
A.1. Draft-00 to -01
* TBD
Author's Address
Stephen Farrell
Trinity College Dublin
College Green
Dublin
Ireland
Email: stephen.farrell@cs.tcd.ie
Farrell Expires 14 August 2024 [Page 5]
