Clarifying IETF Document Status
draft-nottingham-where-does-that-come-from-00

Document Type Active Internet-Draft (individual)
Author Mark Nottingham 
Last updated 2021-03-11
Stream (None)
Intended RFC status (None)
Formats pdf htmlized 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                                      M. Nottingham
Internet-Draft                                             12 March 2021
Intended status: Informational                                          
Expires: 13 September 2021

                    Clarifying IETF Document Status
             draft-nottingham-where-does-that-come-from-00

Abstract

   There is widespread confusion about the status of Internet-Drafts and
   RFCs, especially regarding their association with the IETF and other
   streams.  This document recommends several interventions to more
   closely align reader perceptions with actual document status.

Note to Readers

   _RFC EDITOR: please remove this section before publication_

   The issues list for this draft can be found at
   https://github.com/mnot/I-D/labels/where-does-that-come-from
   (https://github.com/mnot/I-D/labels/where-does-that-come-from).

   The most recent (often, unpublished) draft is at
   https://mnot.github.io/I-D/where-does-that-come-from/
   (https://mnot.github.io/I-D/where-does-that-come-from/).

   Recent changes are listed at https://github.com/mnot/I-D/commits/gh-
   pages/where-does-that-come-from (https://github.com/mnot/I-D/commits/
   gh-pages/where-does-that-come-from).

   See also the draft's current status in the IETF datatracker, at
   https://datatracker.ietf.org/doc/draft-nottingham-where-does-that-
   come-from/ (https://datatracker.ietf.org/doc/draft-nottingham-where-
   does-that-come-from/).

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

Nottingham              Expires 13 September 2021               [Page 1]
Internet-Draft       Clarifying IETF Document Status          March 2021

   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 13 September 2021.

Copyright Notice

   Copyright (c) 2021 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.  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
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   3
   2.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  RFCs  . . . . . . . . . . . . . . . . . . . . . . . . . .   3
       2.1.1.  Proposal 1: logo usage  . . . . . . . . . . . . . . .   3
       2.1.2.  Proposal 2: visual distinction  . . . . . . . . . . .   4
       2.1.3.  Proposal 3: domain usage  . . . . . . . . . . . . . .   4
     2.2.  Internet-Drafts . . . . . . . . . . . . . . . . . . . . .   5
       2.2.1.  Proposal 4: logo usage  . . . . . . . . . . . . . . .   5
       2.2.2.  Proposal 5: visual distinction  . . . . . . . . . . .   5
       2.2.3.  Proposal 6: domain usage  . . . . . . . . . . . . . .   5
       2.2.4.  Proposal 7: boilerplate . . . . . . . . . . . . . . .   6
   3.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   4.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   There is widespread confusion about the status of Internet-Drafts and
   RFCs -- specifically, regarding their association with the IETF and
   other streams.  It is commonly perceived that all RFCs and all
   Internet-Drafts are associated with and approved by the IETF.

Nottingham              Expires 13 September 2021               [Page 2]
Internet-Draft       Clarifying IETF Document Status          March 2021

   This is likely due to the conflation of the IETF and RFC brands; most
   people think of them in close association, and do not appreciate the
   concept of streams, because it is not surfaced obviously in the
   documents.  These impressions are reinforced by our reuse of IETF
   infrastructure for publishing and managing drafts on other streams,
   as well as drafts on no stream.

   These observations are not new.  In the past, changes to boilerplate
   have been proposed and implemented to distinguish document status.
   However, the current boilerplate is obscure; it requires a knowledge
   of the Internet Standards Process to interpret, and furthermore, many
   readers gloss over boilerplate language.

   This problem is also important to solve.  Beyond confusion in the
   press and by implementers, standards-based interoperability is
   increasingly being considered by competition regulators as a remedy
   to abuse of power in Internet-related markets.  Consensus status and
   stream association is critical to their interpretation of a given
   specification.

   Additionally, the still in-progress change to the v3 format for
   Internet-Drafts and RFCs affords an opportunity to adjust how these
   documents are rendered in a manner that leads to more appropriate
   perceptions about their status.

   Therefore, Section 2 contains several recommendations for strong,
   clear interventions along these lines.

1.1.  Notational Conventions

   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.

2.  Recommendations

2.1.  RFCs

   The following recommendations apply to the publication of RFCs.

2.1.1.  Proposal 1: logo usage

   The purpose of this proposal is to create a strong, clear link
   between document status and logo usage.

Nottingham              Expires 13 September 2021               [Page 3]
Internet-Draft       Clarifying IETF Document Status          March 2021

   The IETF, IRTF and IAB stream managers MUST ask the RFC Editor to
   place their respective logos on HTML, HTMLized and PDF renderings of
   RFCs on the applicable stream, and only on those documents.  The logo
   should be displayed prominently at the top of the document.

   The Independent Submissions Editor MAY designate a logo for
   equivalent use.

   The tools team is directed to honour these requests in any renderings
   of these RFCs on sites under their control.  This includes the
   negative condition; i.e., IETF, IRTF, and IAB logos should not appear
   on or in association with RFCs on other streams.

2.1.2.  Proposal 2: visual distinction

   The purpose of this proposal is to create a strong, clear link
   between document status and document presentation.

   The RFC Editor is directed to propose stream-specific presentation of
   RFCs that vary in visually significant ways; e.g., use of typeface,
   decoration, formatting such as alignment and spacing, and other
   typographic controls.

2.1.3.  Proposal 3: domain usage

   The purpose of this proposal is to create a strong, clear link
   between document status and the domain name(s) where the document is
   found.

   The IETF, IRTF and IAB stream managers SHOULD designate what
   hostname(s) RFCs from their streams are to be available upon.
   Initially, this is likely to be datatracker.ietf.org, although stream
   managers might designate a more specific place (such as
   specs.irtf.org) instead of or in addition to that location.

   The Independent Submission Editor SHOULD designate what hostname(s)
   RFCs from their stream are to be available upon, if any.  Independent
   Submissions MUST NOT be designated to appear on ietf.org, irtf.org or
   iab.org hostnames.

   The tools team is directed to assure that these instructions are
   carried out - in particular, that each stream's RFCs appear only on
   the designated hostnames (within the scope of hostnames that the
   tools team has access to), and RFCs from other streams do not appear
   on the designated hostnames.

Nottingham              Expires 13 September 2021               [Page 4]
Internet-Draft       Clarifying IETF Document Status          March 2021

   Note that placeholder documents MAY be used to indicate where a
   document on another stream can be found, while clearly stating that
   the target document is not associated with the stream in question;
   however, automatic redirects MUST NOT be used.

   Note that if a stream manager does not indicate any domains for such
   use, it implies that those RFCs will only appear on rfc-editor.org,
   not any tools team-controlled sites.

2.2.  Internet-Drafts

   The following recommendations apply to the publication of Internet-
   Drafts.

2.2.1.  Proposal 4: logo usage

   The purpose of this proposal is to create a strong, clear link
   between document status and logo usage.

   The tools team is directed to display the logos of the IETF, IRTF and
   IAB prominently at the top of HTML, HTMLized, and PDF renderings of
   Internet-Drafts on those streams (using the appropriate logo), and
   only drafts on those streams.  These logos should not appear anywhere
   on documents that are not on these streams, nor should the appear on
   pages associated with them (e.g., datatracker metadata).

2.2.2.  Proposal 5: visual distinction

   The purpose of this proposal is to create a strong, clear link
   between document status and document presentation.

   The tools team is directed to propose stream-specific presentation of
   Internet-Drafts that vary in visually significant ways; e.g., use of
   typeface, decoration (e.g., 'DRAFT' background images), formatting
   such as alignment and spacing, and other typographic controls.

2.2.3.  Proposal 6: domain usage

   The purpose of this proposal is to create a strong, clear link
   between document status and the domain name(s) where the document
   (and metadata about it) is found.

   The tools team is directed to request control of the 'internet-
   drafts.org' domain name from ISOC (with assistance from the LLC), and
   to use this domain for publishing drafts not associated with a
   stream, along with any other material generic to Internet-Drafts
   (such as the master index of drafts).  Drafts on a given stream MAY
   be published there with consent from that stream's manager.

Nottingham              Expires 13 September 2021               [Page 5]
Internet-Draft       Clarifying IETF Document Status          March 2021

   The IETF, IRTF and IAB stream managers MAY designate what hostname(s)
   Internet-Drafts on their streams are to be available upon.
   Initially, this is likely to be datatracker.ietf.org, although stream
   managers might designate a more specific place (such as
   drafts.irtf.org) instead of or in addition to that location.

   The Independent Submission Editor MAY designate a hostname that
   Internet-Drafts from their stream are to be available upon.
   Independent Submissions MUST NOT be designated to appear on ietf.org,
   irtf.org or iab.org hostnames.

   The tools team is directed to assure that these instructions are
   carried out - in particular, that each stream's drafts appear only on
   the designated hostnames (within the scope of hostnames that the
   tools team has access to), and drafts from other streams do not
   appear on the designated hostnames.

   Note that placeholder documents MAY be used to indicate where a
   document on another stream can be found (including on internet-
   drafts.org), while clearly stating that the target document is not
   associated with the stream in question; however, automatic redirects
   MUST NOT be used.

2.2.4.  Proposal 7: boilerplate

   The purpose of this proposal is to create a strong, clear statement
   of the document's actual association (or lack thereof) with a stream
   in its boilerplate.

   The tools team is directed to modify this text in the Internet-Draft
   boilerplate:

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

   to, in the case of IETF stream documents:

   This Internet-Draft is a working document of the Internet Engineering
   Task Force (IETF). Note that other parties are able to distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://internet-drafts.org/drafts/current/.

   in the case of IRTF stream documents:

Nottingham              Expires 13 September 2021               [Page 6]
Internet-Draft       Clarifying IETF Document Status          March 2021

   This Internet-Draft is a working document of the Internet Research
   Task Force (IRTF). Note that other parties are able to distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://internet-drafts.org/drafts/current/.

   in the case of IAB stream documents:

  This Internet-Draft is a working document of the Internet Architecture
  Board (IAB). Note that other parties are able to distribute
  working documents as Internet-Drafts.  The list of current Internet-
  Drafts is at https://internet-drafts.org/drafts/current/.

   in the case of Independent stream documents:

 This Internet-Draft is an Independent Submission for publication in the
 RFC Series. Note that other parties are able to distribute
 working documents as Internet-Drafts.  The list of current Internet-
 Drafts is at https://internet-drafts.org/drafts/current/.

   in the case of documents not associated with a stream:

   This Internet-Draft is a working document that has not been adopted
   by any stream that would lead to RFC publication. The list of current
   Internet-Drafts is at https://internet-drafts.org/drafts/current/.

3.  Security Considerations

   This document has no direct security impact.

4.  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/info/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/info/rfc8174>.

Author's Address

   Mark Nottingham
   Prahran VIC
   Australia

   Email: mnot@mnot.net
   URI:   https://www.mnot.net/

Nottingham              Expires 13 September 2021               [Page 7]