Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level
A Best Current Practice update that gives the IESG more flexibility when reviewing downrefs.
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>.
@misc{rfc8067,
series = {Request for Comments},
number = 8067,
howpublished = {RFC 8067},
publisher = {RFC Editor},
doi = {10.17487/RFC8067},
url = {https://www.rfc-editor.org/info/rfc8067},
author = {B. Leiba},
title = {{Updating When Standards Track Documents May Refer Normatively to Documents at a Lower Level}},
pagetotal = 3,
year = 2017,
month = jan,
} RFC text
Contents
Internet Engineering Task Force (IETF) B. Leiba
Request for Comments: 8067 Huawei Technologies
BCP: 97 January 2017
Updates: 3967
Category: Best Current Practice
ISSN: 2070-1721
Updating When Standards Track Documents May Refer Normatively to
Documents at a Lower Level
Abstract
RFC 3967 specifies a process for allowing normative references to
documents at lower maturity levels ("downrefs"), which involves
calling out the downref explicitly in the Last Call notice. That
requirement has proven to be unnecessarily strict, and this document
updates RFC 3967, allowing the IESG more flexibility in accepting
downrefs in Standards Track documents.
Status of This Memo
This memo documents an Internet Best Current Practice.
This document is a product of the Internet Engineering Task Force
(IETF). It has been approved for publication by the Internet
Engineering Steering Group (IESG). Further information on BCPs is
available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc8067.
Copyright Notice
Copyright (c) 2017 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
(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. The IESG's Responsibility with Respect to Downrefs . . . . . 2
3. Security Considerations . . . . . . . . . . . . . . . . . . . 3
4. Normative References . . . . . . . . . . . . . . . . . . . . 3
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 3
1. Introduction
[RFC3967] notes the importance of assuring that normative references
from Standards Track and Best Current Practice (BCP) documents are
appropriately mature, and specifies a process for allowing normative
references to documents at lower maturity levels ("downrefs"). That
process starts at IETF Last Call (see Section 3 of [RFC3967]):
For Standards Track or BCP documents requiring normative reference
to documents of lower maturity, the normal IETF Last Call
procedure will be issued, with the need for the downward reference
explicitly documented in the Last Call itself. Any community
comments on the appropriateness of downward references will be
considered by the IESG as part of its deliberations.
Section 2 of [RFC3967] lists some conditions under which downrefs may
make sense. In addition to those, it has become common for working
groups to produce foundational documents (which contain important
information such as terminology definitions and architectural design
and considerations) at Informational status, and those documents are
often needed as normative references in the Standards Track protocol
documents that follow.
The requirement to explicitly mention the downrefs and the need for
them in the Last Call message has proven to be unnecessarily
restrictive and has often resulted in unnecessary repetitions of Last
Call, with the corresponding delay and with no real benefit.
2. The IESG's Responsibility with Respect to Downrefs
The process in RFC 3967 is hereby updated to specify that explicitly
documenting the downward references in the Last Call message is
strongly recommended but not required. The responsible AD should
still check for downrefs before sending out the Last Call notice, but
if an undetected downref is noticed during Last Call or IESG review,
any need to repeat the Last Call is at the discretion of the IESG.
However, the process in RFC 3967 is not fundamentally altered: If the
IESG decides not to repeat the Last Call, the status of the affected
downrefs is not changed, and the process in RFC 3967 will still apply
if those downrefs are used in the future.
This gives the IESG the responsibility to determine the actual
maturity level of the downward reference with respect to the document
at hand, and to decide whether or not it is necessary to explicitly
ask the IETF community for comments on the downref on a case-by-case
basis. In making that decision, the IESG should take into account
the general discussion in RFC 3967. The responsible AD should make
sure that the omission is recorded as a comment in the datatracker.
3. Security Considerations
Referencing immature protocols can have security and stability
implications, and the IESG should take that into account when
deciding whether re-consulting the community is useful.
4. Normative References
[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, <http://www.rfc-editor.org/info/rfc3967>.
Author's Address
Barry Leiba
Huawei Technologies
Phone: +1 646 827 0648
Email: barryleiba@computer.org
URI: http://internetmessagingtechnology.org/
ISO Plain Language
On this page
§1The Downref Process
A normative reference is one a document relies on as part of its requirements. RFC 3967 describes how a Standards Track or Best Current Practice document can refer normatively to a document at a lower maturity level, a practice called a downref.
The earlier process required the need for a downref to be called out in the IETF Last Call. RFC 8067 says this requirement proved unnecessarily restrictive and sometimes caused a Last Call to be repeated without real benefit.
A standards document may rely on a document at a lower maturity level. The previous process required that this be called out during Last Call.
§2IESG Review of Downrefs
Explicitly documenting downrefs in the Last Call is now strongly recommended, but it is not required. The responsible Area Director should still check for downrefs before sending the notice.
If a downref is found during Last Call or IESG review, the IESG decides whether to repeat Last Call. If it does not, the downref's maturity status does not change, and RFC 3967 still applies if the downref is used in the future. The responsible Area Director should record an omission in the datatracker.
The Area Director should check for downrefs before Last Call. If one is found late, the IESG decides whether the community needs another review.
§3Security and Stability
The RFC notes that references to immature protocols can have security and stability implications. The IESG should consider those implications when deciding whether another community consultation is useful.
A less mature protocol can raise security or stability concerns. The IESG should consider those risks when deciding whether to ask for more review.