]> Removing Expiration Notices from Internet-Drafts Mozilla
mt@lowentropy.net
ICANN
paul.hoffman@icann.org
General General Area Dispatch dead mans switch The long-standing policy of requiring that Internet-Drafts bear an expiration date is no longer necessary. This document removes requirements for expiration for Internet-Drafts from RFC 2026/BCP 9 and RFC 2418/BCP 25. In place of expiration, this document introduces Internet-Drafts being labeled "active" and "inactive" in the IETF tooling. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the General Area Dispatch Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .
Introduction The Content Guidelines for Internet Drafts requires that Internet-Drafts include an expiration statement. Tooling and IETF practice insist on Internet-Drafts including an expiry date 185 days after their posting. After this expiration date, some systems might display an Internet-Draft differently or not at all, with some exceptions, such as when the document is under IESG review. Expiration is believed to prevent the use of an Internet-Draft for reference purposes, so that they do not become stable references in other work. Expiration also existed to encourage authors to update drafts that they wish to discuss. Originally, expired drafts were deleted from IETF servers completely; more recently, expiration only caused the document to be hidden from certain views or searches. Copies of expired drafts are retained and can be obtained using other services. Expired drafts are routinely cited and referenced. Published RFCs routinely include informative references to drafts, which then usually expire. Many IANA registries refer to expired drafts. Thus, statements about it being inappropriate to cite drafts are incorrect and can lead readers not familiar with IETF processes to misunderstand how old drafts are actually used. This document does the following:
  • Updates to eliminate the removal of an Internet-Draft when the latest version is unchanged for more than six months.
  • Updates to eliminate the inclusion of an expiration date in Internet-Drafts.
  • Updates the Content Guidelines to remove references to expiration.
  • Updates the boilerplate text for Internet-Drafts to no longer include the "Expires:" field.
  • Introduces a status for Internet-Drafts which can be set to either "active" or "inactive" in tooling without specifying how this is implemented.
No More Expiration and Automatic Removal Forced expiration serves no purpose that is not adequately served by the publication date on the document. The date of posting for an Internet-Draft is the best -- or perhaps only -- information available that can be added to a document the time of publication that might help readers understand whether the content is valid. Future events might invalidate the content virtually immediately; conversely, an Internet-Draft could also remain relevant for an arbitrarily long period of time.
Changes to Existing RFCs and Guidelines RFC 2026 talks about removal of Internet-Drafts in the second paragraph of Section , which reads:
An Internet-Draft that is published as an RFC, or that has remained unchanged in the Internet-Drafts directory for more than six months without being recommended by the IESG for publication as an RFC, is simply removed from the Internet-Drafts directory. At any time, an Internet-Draft may be replaced by a more recent version of the same specification, restarting the six-month timeout period.
This paragraph is replaced with:
At any time, an Internet-Draft may be replaced by a more recent version of the same specification.
RFC 2418 talks about header information in Internet-Drafts in Section . The bullet point "- The expiration date for the I-D." from that section is removed. The Content Guidelines refers to boilerplate that will be updated; see . Content Guidelines also says "A statement specifying the expiry date of the Internet-Draft." This statement and the description of how to specify the expiry date is removed.
Removing the Expires field from Internet-Drafts This document specifies that the "Expires:" field be removed from the header of submitted Internet-Drafts, and that the boilerplate be amended as follows: OLD:
  • 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."
NEW:
  • Internet-Drafts are draft documents that may be updated, replaced, or obsoleted at any time. It is inappropriate to cite them other than as "work in progress."
Active and Inactive Status for Internet-Drafts The tooling maintained by the IETF (such as the Datatracker) can mark the latest version of a draft as "active" or "inactive". When a new version of a draft is published, it is immediately marked as "active", and all earlier versions of that draft are marked as "inactive". Other reasons that a draft might be marked "active" or "inactive" are open, but will be informed by the IETF community. Suggestions have already been made for automatically marking drafts as "inactive" after a certain period of time, for allowing working group chairs to control the marking for working group drafts, and for authors being able to change the status of their draft, either to mark a draft that has been overcome by events as "inactive" or mark a draft as "active" when there is renewed interest.
Replacement Procedures Originally, the expiration of a draft was intended to ensure that the topic is disqualified from consideration. Updating a draft before expiration was intended to indicate continued interest from the authors. Expiration was also used as a reminder to authors to update documents. Without expiration, a substitute might be to provide a note in advance of planned sessions. For instance, for an upcoming session N+1, a reminder might be issued for drafts that have not been updated in the interval between session N and session N+1, but were updated between session N-1 and session N. The "active" and "inactive" markings can also be used nudge authors to update drafts before a meeting. People might choose to concentrate their efforts on drafts that have been recently updated. With "active" and "inactive" markings, those people will have another indicator for which documents might be of interest.
Referencing Internet-Drafts Documents referencing Internet-Drafts should always include the two-digit version number of the draft. Documents referencing Internet-Drafts should always reference using URLs for the IETF Datatracker because this is expected to be the most stable URL for a particular version of a draft.
Security and Privacy Considerations This document has no direct implications on security or privacy.
IANA Considerations This document makes no request of IANA.
Normative References Content guidelines overview The Internet Standards Process -- Revision 3 This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. IETF Working Group Guidelines and Procedures This document describes the guidelines and procedures for formation and operation of IETF working groups. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.