Something Better Than Errata
draft-farrell-errata-01

Network Working Group                                         S. Farrell
Internet-Draft                                    Trinity College Dublin
Intended status: Informational                          18 December 2024
Expires: 21 June 2025

                      Something Better Than Errata
                        draft-farrell-errata-01

Abstract

   This document outlines some ideas for a new errata handling policy
   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 21 June 2025.

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 21 June 2025                  [Page 1]
Internet-Draft             Better Than Errata              December 2024

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Policy versus Implementation  . . . . . . . . . . . . . . . .   3
   3.  A Possible New System . . . . . . . . . . . . . . . . . . . .   3
   4.  Handing existing errata . . . . . . . . . . . . . . . . . . .   4
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   5
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .   5
     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 set out some ideas for a new errata handling policy
   and, as an exemplar, 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 intended to provide a new route for revision of RFCs.

   For simplicity, we describe the example 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
   example system as if everyone reads RFCs via one interface such as
   that provided by the IETF datatracker.

   The author is not invested in the details here, anything
   approximating what's described here would probably be fine, e.g.
   another draft [I-D.rescorla-rfc-jit] describes a much broader
   proposal that includes some aspects quite similar to those described
   below.

   If useful, comments/issues/PRs are welcome at:
   https://github.com/sftcd/errata/

Farrell                   Expires 21 June 2025                  [Page 2]
Internet-Draft             Better Than Errata              December 2024

2.  Policy versus Implementation

   Many 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.

   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.  A Possible New System

   Once an RFC is published, then, e.g. on the datatracker web page for
   viewing that RFC, there will be a "comment/discuss" button that
   allows readers with a relevant account to submit comments on, or
   questions about, that RFC.  Threaded discussions on comments can
   follow, not unlike issue discussion on services like 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/RG chairs will recieve notification when new
   discussion threads are started.

   Each RFC stream may define its own procedure for the relevant
   privileges involved; for example, discussion threads on IETF stream
   documents would be expected to be redirected to an IETF mailing list
   at some point, but the "when" and "how" decision would be made by the
   IETF, not by the RFC Editor.  By default, old documents not assigned
   to a particular stream are treated as if they were IETF stream,
   unless another stream manager claims them.

   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] in accordance with stream-manager policies.

   One way to label a specific comment that contains a suggested change
   is as a reported erratum.

Farrell                   Expires 21 June 2025                  [Page 3]
Internet-Draft             Better Than Errata              December 2024

   Comments labelled as reported 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].  Note that the idea of up/down-
   voting here only applies to discussion threads and is envisaged to
   precede (and definitely not replace) stream-specific approval
   processes for errata.

   Once a comment labelled as an erratum has sufficient upvotes, then it
   is brought to the attention of relevant stream-specific approvers,
   e.g. via a mail to the relevant approvers, WG or area list.  For the
   IETF stream, any AD can always mark a sufficiently upvoted erratum as
   approved.  Additional stream-specific approval mechanisms can also be
   defiened, e.g. allowing two relevant WG chairs 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.  Approvers can also
   change a discussion thread into a proposed erratum without requiring
   upvoting.

   It must be possible 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].

   The typical HTML view of RFCs should be that with errata applied.
   The list of applied errata however do need to be viewable (e.g. via a
   button), as should discussion from the initial report up to and
   including 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.

   *  One possibility is that no action is required with respect to
      current, posted but unprocessed, errata reports.  The argument for
      this is that 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.

Farrell                   Expires 21 June 2025                  [Page 4]
Internet-Draft             Better Than Errata              December 2024

   *  Another possibility is to try import existing unprocessed errata
      reports into the new system, however the author isn't sure how
      that might be done in a useful way (so currently favours the "no
      action" possibility) but that's a topic to discuss.

   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

   Thanks to those on the rfc-interest list for discussion of this
   topic, in particular Brian Carpenter, for specific comments on the
   text.

   All bad ideas, errors and omissions of course remain the fault of the
   author.

8.  References

8.1.  Normative References

   [RPCTBD]   RPC, "somewhere the RPC publish stuff", 2024.

8.2.  Informative References

   [I-D.rescorla-rfc-jit]
              Rescorla, E., "Just-In-Time RFC Publication", Work in
              Progress, Internet-Draft, draft-rescorla-rfc-jit-00, 11
              February 2024, <https://datatracker.ietf.org/doc/html/
              draft-rescorla-rfc-jit-00>.

Appendix A.  Change Log

A.1.  Draft-00 to -01

   *  Incorporated feedback from rfc-interest list.

Author's Address

Farrell                   Expires 21 June 2025                  [Page 5]
Internet-Draft             Better Than Errata              December 2024

   Stephen Farrell
   Trinity College Dublin
   College Green
   Dublin
   Ireland
   Email: stephen.farrell@cs.tcd.ie

Farrell                   Expires 21 June 2025                  [Page 6]