Updating RFCs
draft-wilde-updating-rfcs-00

Document Type Active Internet-Draft (individual)
Last updated 2016-09-14
Stream (None)
Intended RFC status (None)
Formats plain text xml pdf html bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                           E. Wilde
Internet-Draft                                           CA Technologies
Intended status: Standards Track                      September 14, 2016
Expires: March 18, 2017

                             Updating RFCs
                      draft-wilde-updating-rfcs-00

Abstract

   As part of document metadata, RFCs can reference existing RFC that
   they update or obsolete.  While obsoleting is well-understood
   (replace the obsoleted RFC in its entirety), updating has more
   nuances because the updated RFC remains valid.  This document
   contains some clarifications about how to handle updating in a way
   that makes it easier for readers to understand how the original and
   the updating RFC relate.

Note to Readers

   This draft should be discussed on the wgchairs mailing list [1].

   Online access to all versions and files is available on github [2].

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 http://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 March 18, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Wilde                    Expires March 18, 2017                 [Page 1]
Internet-Draft                Updating RFCs               September 2016

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Reasons for updating RFC 7233 . . . . . . . . . . . . . . . .   2
   3.  Documenting the Update Reasons  . . . . . . . . . . . . . . .   3
   4.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Normative References  . . . . . . . . . . . . . . . . . .   4
     4.2.  Non-Normative References  . . . . . . . . . . . . . . . .   4
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   4
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   4

1.  Introduction

   The "RFC Style Guide" [1] defines two possible ways in which an RFC
   can relate to existing RFCs: It can obsolete existing RFCs, and/or it
   can update existing RFCs.  When obsoleting an RFC, the obsoleted RFC
   is effectively replaced in its entirety by the obsoleting RFC (or
   parts of it).  For updates, the relationship is a little less clear.

   The obsoleted "Instructions to RFC Authors" [2] in Section 12
   describe what "Updates" and "Obsoletes" mean.  These descriptions do
   not appear in RFC 7322, and even if they did, they might still not
   always be sufficient to understand the exact nature of the update.

   This memo therefore recommends that RFC authors should include
   explicit information about any updates that their RFC makes, and
   include this in a place where it is easy to locate.  This way,
   readers of the updated RFC as well as those of the updating RFC can
   easily understand how the two documents relate.

2.  Reasons for updating RFC 7233

   This document clarifies the way in which RFCs should describe their
   relationship to updated RFCs.  It proposes to include individual
   "Reasons for updating RFC ..." sections for all updated RFCs as
   section(s) early on in the document.  These sections are supposed to
   supplement the more formal "Updates" metadata and are not intended to
   replace it.

Wilde                    Expires March 18, 2017                 [Page 2]
Internet-Draft                Updating RFCs               September 2016

3.  Documenting the Update Reasons
Show full document text