[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                           A. Atlas
Internet-Draft                                          Juniper Networks
Intended status: Best Current Practice                           E. Lear
Expires: May 2, 2018                                               Cisco
                                                              J. Halpern
                                                             H. Flanagan
                                                              RFC Editor
                                                             J. Tantsura
                                                        October 29, 2017

             Normative References in RFCs from Open Source


   IETF procedures generally require that a standards track RFC may not
   have a normative reference to a non standards track specification
   except those from other
   standards bodies.  This document creates an External Specification
   registry, similar to the DownRef registry that has been created based
   on [RFC3967] and permits normative references to community accepted
   external specifications.

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 May 2, 2018.

Copyright Notice

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

Atlas, et al.              Expires May 2, 2018                  [Page 1]

Internet-Draft                     I-D                      October 2017

   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
   2.  What Can Be Normatively Referenced? . . . . . . . . . . . . .   3
   3.  Procedure to be Used  . . . . . . . . . . . . . . . . . . . .   4
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   5
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   5
     7.3.  URIs  . . . . . . . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The IETF follows the Standards Process [RFC2026] that describes to
   what a standards track RFC can normatively refer.  Information that
   is normatively referenced is required to be understood and may be
   necessary for implementation of the RFC.  Essentially, if a
   technology can be normatively referenced, then a standards track RFC
   can be created that uses that technology.

   Of course, the need to collaboratively build Internet technology is
   well discussed in [RFC2026] Section 7 and the ability to reference
   external Open Standard specifications as well as proprietary
   specifications is described.  Specifically,

      Other proprietary specifications may be incorporated by reference
      to a version of the specification as long as the proprietor meets
      the requirements of section 10.  If the other proprietary
      specification is not widely and readily available, the IESG may
      request that it be published as an Informational RFC.

   The ID-nits checklist at https://www.ietf.org/id-info/checklist.html
   [1] warns:

Atlas, et al.              Expires May 2, 2018                  [Page 2]

Internet-Draft                     I-D                      October 2017

      Normative and informative references to non-IETF documents are
      permitted.  However, it is best to minimize such normative
      references, because assessing their status when the IETF document
      advances on the standards-track is very difficult.  It is
      important to use the exact title, author name(s), organization and
      publication date.

   When a Working Group wishes to build based upon existing Open Source
   technology, the lack of clarity around how that technology's status
   will be assessed can either discourage such a dependency or add
   unnecessary work by requiring republication as an Independent Stream
   RFC, which will still require a downwards reference [RFC3967].

   This document provides clarity and a simple process to make it easy
   to reference Open Source technology that the IETF community agrees is

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119, BCP 14

2.  What Can Be Normatively Referenced?

   There are five basic requirements for a normative reference.

   1.  Is it stable, mature, and immutable (except for errata)?

       Stable means that there are not expected to be frequent updated
       versions.  Mature is equivalent to being at least similar to a
       Proposed Standard RFC.  Immutable means that the referenced
       content is not expected to change after RFC publication, except
       for minor error corrections.  This might be achieved by
       referencing a particular dated version or a subsection of the

   2.  Is it generally easily accessible and not subject to
       confidentiality restrictions?

   3.  Is it a specification that describes the technology in sufficient
       detail that someone else can design their own implementation to
       properly interoperate with it and others' different

       The IETF generally prefers specifications over code.  Code itself
       lacks context to fully understand the intent or support an
       interoperable different implementation.  There may, of course, be
       exceptions where an algorithm or codec is really most clearly

Atlas, et al.              Expires May 2, 2018                  [Page 3]

Internet-Draft                     I-D                      October 2017

       described in code.  For example, while [RFC6716] has normative
       code, there is also detailed documentation.  If it is necessary
       to reference code, a distribution is preferred because that can
       be clear on the public interfaces and intent of the code.

   4.  Is it intended as a public interface?

   5.  Are the IPR associated with the normative reference clearly and
       publicly documented so that the Working Group participants can
       make an informed decision about building on top of the specified

3.  Procedure to be Used

   This procedure is modeled on that defined in [RFC3967] and [RFC8067]
   for managing down references in RFCs.  A registry of external non-SDO
   references that have been accepted by the community, as indicated by
   at least the first published RFC with a normative references to a
   particular item, SHOULD be maintained for references that may see
   reuse.  That registry should indicate the reference, the RFC(s)
   normatively referring to it, and a pointer to any IPR information
   that is provided by the same source (e.g.  Open Source Organization)
   as the external non-SDO reference.  A mechanism for this registry
   could be the same as is done in datatracker for the DownRef registry
   where the sponsoring AD updates the registry.

   The following procedures apply to external non-SDO references that
   are not yet in the External References registry.  Information
   included in calls for Working Group adoption, Working Group Last
   Call, and IETF Last Call SHOULD include any normative references to
   external non-SDO technology and a pointer to any IPR that is provided
   by the same source as the external non-SDO technology.  Working Group
   and IETF participants should use this information in their
   evaluations.  The Document Shepherd [RFC4858] SHOULD indicate in her
   or his report whether the document contains any external non-SDO
   references that are not in the external references registry.  This
   will call the responsible Area Director's attention to verify that
   the referenced item is acceptable.

   The Working Group Chairs and responsible Area Director SHOULD verify
   that the referenced item meets the requirements described earlier.
   If the desired reference is to code, then the responsible Area
   Director MUST determine whether it provides sufficient context,
   clarity of intent, and intentional public interfaces.  Judgement
   calls are expected here as circumstances will vary.

Atlas, et al.              Expires May 2, 2018                  [Page 4]

Internet-Draft                     I-D                      October 2017

4.  Security Considerations

   It is possible that external technology does not meet the security or
   privacy expectations for Standards Track RFCs.  This may require
   additional considerations from the referring document.

5.  IANA Considerations

   There are no IANA considerations.

6.  Acknowledgements

   Thanks to Lucy Lynch for encouraging more thought on what can be done
   to better the interaction between the IETF and Open Source work.

7.  References

7.1.  Normative References

   [RFC2026]  Bradner, S., "The Internet Standards Process -- Revision
              3", BCP 9, RFC 2026, DOI 10.17487/RFC2026, October 1996,

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC3967]  Bush, R. and T. Narten, "Clarifying when Standards Track
              Documents may Refer Normatively to Documents at a Lower
              Level", BCP 97, RFC 3967, DOI 10.17487/RFC3967, December
              2004, <https://www.rfc-editor.org/info/rfc3967>.

   [RFC4858]  Levkowetz, H., Meyer, D., Eggert, L., and A. Mankin,
              "Document Shepherding from Working Group Last Call to
              Publication", RFC 4858, DOI 10.17487/RFC4858, May 2007,

   [RFC8067]  Leiba, B., "Updating When Standards Track Documents May
              Refer Normatively to Documents at a Lower Level", BCP 97,
              RFC 8067, DOI 10.17487/RFC8067, January 2017,

7.2.  Informative References

   [RFC6716]  Valin, JM., Vos, K., and T. Terriberry, "Definition of the
              Opus Audio Codec", RFC 6716, DOI 10.17487/RFC6716,
              September 2012, <https://www.rfc-editor.org/info/rfc6716>.

Atlas, et al.              Expires May 2, 2018                  [Page 5]

Internet-Draft                     I-D                      October 2017

7.3.  URIs

   [1] https://www.ietf.org/id-info/checklist.html

Authors' Addresses

   Alia Atlas
   Juniper Networks

   Email: akatlas@juniper.net

   Eliot Lear

   Email: lear@cisco.com

   Joel Halpern

   Email: Joel.Halpern@ericsson.com

   Heather Flanagan
   RFC Editor

   Email: rse@rfc-editor.org

   Jeff Tantsura

   Email: jefftant.ietf@gmail.com

Atlas, et al.              Expires May 2, 2018                  [Page 6]

Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/