Just-In-Time RFC Publication
draft-rescorla-rfc-jit-00

RFC Series Working Group                                     E. Rescorla
Internet-Draft                                   Windy Hill Systems, LLC
Intended status: Informational                          11 February 2024
Expires: 14 August 2024

                      Just-In-Time RFC Publication
                       draft-rescorla-rfc-jit-00

Abstract

   This document describes a new approach to RFC publication that is
   intended to allow easy revisions without re-running the entire RFC
   publication process.

Discussion Venues

   This note is to be removed before publishing as an RFC.

   Source for this draft and an issue tracker can be found at
   https://github.com/ekr/draft-rescorla-rfc-jit.

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.

Rescorla                 Expires 14 August 2024                 [Page 1]
Internet-Draft                   RFC JIT                   February 2024

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   3
   3.  Requirements  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Generic Structure . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Mapping onto the RFC Series . . . . . . . . . . . . . . . . .   4
   6.  IETF Consensus  . . . . . . . . . . . . . . . . . . . . . . .   4
   7.  Version Publication Logistics . . . . . . . . . . . . . . . .   5
   8.  Published Version Adjustments . . . . . . . . . . . . . . . .   6
     8.1.  Published Versions  . . . . . . . . . . . . . . . . . . .   6
     8.2.  XML . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     11.1.  Normative References . . . . . . . . . . . . . . . . . .   7
     11.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The current RFC publication process is unwieldy and slow.  This is a
   poor match for an environment where protocol specifications routinely
   see wide deployment well in advance of IESG approval, let alone RFC
   publication.  Despite the long publication time, RFCs also routinely
   contain errors (as an example, TLS 1.3 [RFC8446] currently has >40
   errata).  However, fixing these errors is prohibitively difficult as
   it currently requires publishing a new RFC, which incurs new delay,
   at which point new errors will have accumulated and the cycle begins
   again.

   This document proposes a new approach to RFC publication, termed
   "just-in-time" (JIT) publication, which is designed to address this
   issue.  JIT publication is centered around two basic ideas:

   *  A series of documents which are intended to be semantically
      identical, even though the text may be different.

   *  The ability to rapidly publish new documents within a series as
      soon as the requisite level of approval has been obtained.

Rescorla                 Expires 14 August 2024                 [Page 2]
Internet-Draft                   RFC JIT                   February 2024

   When put together, these allow us to cheaply address issues as they
   are discovered.  This document focuses on the IETF Stream as that is
   the dominant source of RFCs.  However, the contents potentially apply
   to other streams as well.

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

3.  Requirements

   The method in this document is intended to balance a number of
   requirements.

   *  Easy updating: Once a document is published it MUST be easy to
      make non-semantic changes (editorial fixes, clarifications, etc.)
      without re-running the whole process.

   *  Referential Integrity: It MUST be possible to reference a specific
      version of a document (i.e., the exact bits).

   *  Semantic References: It MUST be possible to reference a document
      as a semantic entity, including whatever editorial updates have
      been made.

4.  Generic Structure

   This section describes a generic publication structure that does not
   take into account the RFC Series.  In Section 5 we describe how it
   might be mapped onto the existing RFC Series.  It makes use of a two-
   level structure of Document and Version.

   *  Documents refer to the semantics of a given specification and thus
      may appear in multiple Versions.  Each document has a document
      identifier D which is persistent through the life of the document
      and refers to the latest Version.

   *  Versions refer to specific instances of a Document.  All versions
      of a given document have the same semantics.  Each version has a
      unique version identifier under the document, as in D.V,
      indicating version V of document D.

Rescorla                 Expires 14 August 2024                 [Page 3]
Internet-Draft                   RFC JIT                   February 2024

   In this design, documents would proceed through the process as usual
   until they were first published as an RFC.  At the point where they
   were published by the RPC they would receive a document identifier
   and the initial version would be published, e.g., at https://rfc-
   editor.org/documents/D.0.

   Once the initial version was published, new versions could be
   immediately published based on approval from the Area Director (or
   perhaps the WG Chair), who would be responsible for confirming that
   the changes did not change the document semantics.

   This process allows for errata, etc. to be immediately applied to the
   document in place.  Note that this is consistent with AUTH48 process
   because the AD can sign off on changes after IESG approval (see
   Section 6 for more on this).  Moreover, the stakes here are quite low
   because we can always publish a new Version that reverts any change
   which has been inappropriately applied.

5.  Mapping onto the RFC Series

   There are at least two ways to map this onto the existing RFC Series,
   which only has one level with each RFC being unchanging.

   *  Add a new level of Document identifiers with RFCs as versions
      (e.g., D1234.1 -> RFC 123456)

   *  Add a new level of Version below RFC (e.g., RFC8446.0, RFC8446.1,
      etc.), with the main RFC# pointing to the most current version.

   Either of these would probably work, and which people prefer to some
   extent depends on their priors.  However, it's worth noting that the
   former approach would create a new reference that people would
   generally be pointed to that wasn't RFCs, whereas the second would
   not.  In addition, it would start to burn through the RFC numbers
   very quickly, especially if each erratum creates a new version.

6.  IETF Consensus

   All IETF Stream documents require IETF rough consensus [RFC8789].  As
   with the existing publication process, the combination of IETF Last
   Call and IESG review is intended to ensure that the initial published
   document as reviewed by the IESG has IETF Consensus.  The JIT
   publication process in principle allows for subsequent revisions to
   incorporate material that does not have consensus.  This would be a
   process violation because ADs are supposed to only approve non-
   semantic changes, but of course ADs might make mistakes.

Rescorla                 Expires 14 August 2024                 [Page 4]
Internet-Draft                   RFC JIT                   February 2024

   However, it is _already_ possible to introduce non-consensus changes
   in RFCs during AUTH48.  Authors routinely make changes to RFCs during
   the AUTH48 process; the RPC does not prevent these changes but just
   requires that substantive changes be approved by the appropriate AD.
   This proposal extends the period when changes can be made past
   initial RFC publication but the risk of non-consensus changes being
   mistakenly made is mitigated by several factors:

   1.  Changes are explicitly restricted to those without any semantic
       content, whereas AUTH48 changes can be semantically meaningful at
       the ADs discretion.  The RPC could detect at least some of these
       cases, as they do now.

   2.  Any such changes are clearly visible as a diff from the previous
       version, so this situation is readily detectable.  One could
       imagine having a short "objection period" between approval and
       publication to allow for incorrect changes to be detected.

   3.  It is trivial to publish a new version reverting any non-
       consensus changes.

   Together, these changes minimize the risk of semantic changes being
   introduced to published RFCs.

   As a side effect, JIT publication may also make AUTH48 faster, as
   authors would not need to worry so much about having every single
   sentence be perfect.

7.  Version Publication Logistics

   Once the RPC has published the initial version of an RFC, it should
   be trivial to make a change and re-spin the document without
   significant work by the RPC.  Ideally, there would be a simple
   process in which the changes were proposed, approved by the ADs,
   vetted by the RPC and then mechanically published as a new RFC
   version.  This should only require changing the specific text, rather
   than metadata, etc., which should all change automatically.

   For readers familiar with GitHub, one could imagine this a workflow
   powered by GitHub actions:

   1.  Once the RFC is published, the XML is published on GitHub (e.g.,
       in a repo containing the XML for every RFC).

   2.  The proposed change is submitted as a pull request to the XML.

   3.  A GitHub action automatically generates the resulting publication
       formats (HTML, TXT, PDF) for review.

Rescorla                 Expires 14 August 2024                 [Page 5]
Internet-Draft                   RFC JIT                   February 2024

   4.  The AD approves the pull request.

   5.  Upon AD approval and verification that no inappropriate changes
       have been made, the RPC merges the pull request.

   6.  A GitHub action publishes the RFC Version.

   Obviously, these processes need not be based on GitHub, but this
   example illustrates the desired level of automation.

8.  Published Version Adjustments

8.1.  Published Versions

   With JIT RFC publication, we will have multiple versions of the same
   semantic document, which means that we need some way to help readers
   keep track of the state of the documents.  Minimally:

   *  There needs to be a semantic reference that points to the most
      recent Version of the document.  This reference is stable but the
      target is updated whenever a new version is published.

   *  There should be an associated document/page which lists each
      Version of the document along with a brief summary of the changes
      (think "git log").

   *  Each Version of the document should have an affordance which
      allows the reader to (1) find previous Versions of the document
      and (2) see what changes were made in this Version

   For instance, if we were to use RFC number as the stable reference,
   then:

   *  A reader could always get the most recent Version of a document by
      going to the semantic reference at https://rfc-
      editor.org/documents/RFC12345

   *  The individual versions of the documents would be at https://rfc-
      editor.org/documents/RFC12345.0, https://rfc-editor.org/documents/
      RFC12345.1, etc.

   *  The list of all Versions might live at https://rfc-
      editor.org/versions/RFC12345

Rescorla                 Expires 14 August 2024                 [Page 6]
Internet-Draft                   RFC JIT                   February 2024

8.2.  XML

   If we expect people to make changes directly to the published XML,
   it's important that that the XML be as legible as possible.
   Currently, the XML produced by the preptool is significantly harder
   to read than the editorial XML that people work on.  Simplifying that
   XML would be valuable in terms of user ergonomics, but can be pursued
   in parallel to the changes proposed here.

9.  Security Considerations

   This document in theory might make it possible to make semantically
   relevant changes to RFCs post-publication, which could have security
   implications.  In the event that this happens, it is straightforward
   to revert these changes.

10.  IANA Considerations

   This document has no IANA actions.

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

11.2.  Informative References

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8446>.

   [RFC8789]  Halpern, J., Ed. and E. Rescorla, Ed., "IETF Stream
              Documents Require IETF Rough Consensus", BCP 9, RFC 8789,
              DOI 10.17487/RFC8789, June 2020,
              <https://www.rfc-editor.org/rfc/rfc8789>.

Acknowledgments

   TODO acknowledge.

Rescorla                 Expires 14 August 2024                 [Page 7]
Internet-Draft                   RFC JIT                   February 2024

Author's Address

   Eric Rescorla
   Windy Hill Systems, LLC
   Email: ekr@rtfm.com

Rescorla                 Expires 14 August 2024                 [Page 8]