Internet DRAFT - draft-atlas-external-normref
draft-atlas-external-normref
Network Working Group A. Atlas
Internet-Draft Juniper Networks
Intended status: Best Current Practice E. Lear
Expires: May 2, 2018 Cisco
J. Halpern
Ericsson
H. Flanagan
RFC Editor
J. Tantsura
Individual
October 29, 2017
Normative References in RFCs from Open Source
draft-atlas-external-normref-00
Abstract
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
acceptable.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119, BCP 14
[RFC2119].
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
document.
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
implementations?
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
technology?
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,
<https://www.rfc-editor.org/info/rfc2026>.
[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>.
[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,
<https://www.rfc-editor.org/info/rfc4858>.
[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,
<https://www.rfc-editor.org/info/rfc8067>.
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
Cisco
Email: lear@cisco.com
Joel Halpern
Ericsson
Email: Joel.Halpern@ericsson.com
Heather Flanagan
RFC Editor
Email: rse@rfc-editor.org
Jeff Tantsura
Individual
Email: jefftant.ietf@gmail.com
Atlas, et al. Expires May 2, 2018 [Page 6]
