idnits 2.17.1
draft-klensin-std-numbers-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
-- The draft header indicates that this document updates RFC1311, but the
abstract doesn't seem to mention this, which it should.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
(Using the creation date from RFC1311, updated by this document, for
RFC5378 checks: 1991-12-05)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (February 14, 2011) is 4820 days in the past. Is this
intentional?
Checking references for intended status: Best Current Practice
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Obsolete informational reference (is this intentional?): RFC 2629 (ref.
'3') (Obsoleted by RFC 7749)
Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Klensin
3 Internet-Draft February 14, 2011
4 Updates: 1311, 2026
5 (if approved)
6 Intended status: BCP
7 Expires: August 18, 2011
9 STD Numbers and the IETF Standards Track
10 draft-klensin-std-numbers-01
12 Abstract
14 STD numbers are assigned to IETF Standards Track specifications in
15 order to provide a stable reference even when RFCs are revised and
16 the underlying documents change. However, the numbers are only
17 assigned when the specifications reach Full Standard maturity level,
18 significantly reducing their utility in the contemporary world in
19 which few specifications advance beyond the first standardization
20 maturity level. For that reason, one recent proposal suggested
21 eliminating the numbers entirely. This document argues that stable
22 references for Standards Track specifications are actually useful and
23 that the solution is not to abolish the numbers but to change the
24 point at which they are assigned.
26 Status of this Memo
28 This Internet-Draft is submitted in full conformance with the
29 provisions of BCP 78 and BCP 79.
31 Internet-Drafts are working documents of the Internet Engineering
32 Task Force (IETF). Note that other groups may also distribute
33 working documents as Internet-Drafts. The list of current Internet-
34 Drafts is at http://datatracker.ietf.org/drafts/current/.
36 Internet-Drafts are draft documents valid for a maximum of six months
37 and may be updated, replaced, or obsoleted by other documents at any
38 time. It is inappropriate to use Internet-Drafts as reference
39 material or to cite them other than as "work in progress."
41 This Internet-Draft will expire on August 18, 2011.
43 Copyright Notice
45 Copyright (c) 2011 IETF Trust and the persons identified as the
46 document authors. All rights reserved.
48 This document is subject to BCP 78 and the IETF Trust's Legal
49 Provisions Relating to IETF Documents
50 (http://trustee.ietf.org/license-info) in effect on the date of
51 publication of this document. Please review these documents
52 carefully, as they describe your rights and restrictions with respect
53 to this document. Code Components extracted from this document must
54 include Simplified BSD License text as described in Section 4.e of
55 the Trust Legal Provisions and are provided without warranty as
56 described in the Simplified BSD License.
58 Table of Contents
60 1. Introduction and Rationale . . . . . . . . . . . . . . . . . . 3
61 2. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
62 2.1. Changes to RFC 2026 . . . . . . . . . . . . . . . . . . . . 3
63 2.2. RFC 1311 Changes . . . . . . . . . . . . . . . . . . . . . 4
64 3. Transition . . . . . . . . . . . . . . . . . . . . . . . . . . 4
65 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5
66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
67 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
68 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
69 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
70 7.2. Informative References . . . . . . . . . . . . . . . . . . 6
71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6
73 1. Introduction and Rationale
75 STD numbers [1] are assigned to IETF Standards Track specifications
76 in order to provide a stable reference even when RFCs are revised and
77 the underlying documents change. However, as specified in BCP 9 [1],
78 the numbers are only assigned when the specifications reach Full
79 Standard maturity level, significantly reducing their utility in the
80 contemporary world in which few specifications advance beyond the
81 first ("Proposed") standardization level. For that reason, an early
82 version of one recent proposal [2] suggested eliminating the numbers
83 entirely. The more recent version leaves the question open, but
84 poses the question as a choice between elimination of the STD numbers
85 and retaining the current system.
87 This document argues that stable references for Standards Track
88 specifications are actually useful and that the solution is neither
89 to abolish the numbers nor to retain the assignment only to Full
90 Standards specified in RFC 2026, but to change the point at which
91 they are assigned.
93 We note that similar stable references have proven to be very useful
94 in the BCP case and might be even more useful if better supported by
95 available tools (there are no provisions in xml2rfc (RFC 2629 et seq.
96 [3]) for easily constructing references to multiple-document BCPs or
97 STDs, nor does the current RFC Style Manual provide guidance as to
98 how such references should be laid out).
100 Note in Draft: The author strongly prefers a more comprehensive
101 solution to current perceived problems with maturity levels and STD
102 numbers, a solution such as that described in [4], but it seems
103 useful to get a narrowly-scoped proposal about STD numbers on the
104 table at this time.
106 2. Proposal
108 2.1. Changes to RFC 2026
110 Update RFC 2026, BCP 9, as follows:
112 Section 2.1, paragraph 5
113 Change: "Some RFCs document Internet Standards"
114 To: "Some RFCs document IETF Standards at various maturity
115 lavels".
117 Change the note: "(see section 4.1.3)"
118 To: "(see Section 4)"
120 Section 4 Add a new paragraph after the first paragraph of this
121 section ("Specifications that are intended to become...") that
122 reads:
124 A specification that reaches the status of Proposed Standard is
125 assigned a number in the STD series. It retains that STD number
126 as it progresses along the Standards Track (that progression
127 usually involves a change in RFC numbers). The STD number is also
128 retained when the relevant protocol is updated or replaced for
129 other reasons (see [5]).
131 Section 4.1.3 Remove the second paragraph, which begins "A
132 specification that reaches..."
134 2.2. RFC 1311 Changes
136 Informally, this document also updates the Informational RFC 1311 to
137 make it refer to all Standards Track documents. It may be useful to
138 replace RFC 1311 at some point, but that should not be a high-
139 priority task, nor should it block approval of the change suggested
140 in this document.
142 3. Transition
144 STD numbers are useful for documentation and other references.
145 Whether they are assigned or not does not change the actual status of
146 any given document. STD numbers have historically been assigned by
147 the RFC Editor and this document does not propose to change that
148 responsibility (even though, in the current multi-stream model for
149 RFCs, having them assigned by the Secretariat under IESG supervision
150 might make more sense). In the interest of avoiding both heavyweight
151 processes and the need for a period of concentrated effort, STD
152 numbers will be assigned only when:
154 1. A new Standards Track specification is published, at any maturity
155 level.
157 2. An update or replacement is published for a Standards track
158 specification for which an STD number has not already been
159 assigned, specifically including changes or grade or recycling in
160 grade. Authors, WGs, or ADs responsible for such specifications
161 are strongly encouraged to supply the RFC Editor with any desired
162 grouping information, i.e., the identification of specifications
163 that should also be assigned the same STD number.
165 3. On the request of any Area Director who concludes that assignment
166 of an STD number to a particular specification or group of
167 specifications would facilitate documentation, understanding of
168 the specification, or other uses. Especially when the number is
169 to be assigned to a group of specifications, Area Directors are
170 encouraged to seek community input on the decisions being made,
171 but neither such input nor a more formal Last Call are required
172 by this document.
174 This transition approach explicitly recognizes the principle that STD
175 numbers that would not be used need not be assigned and that not
176 assigning them does no harm. It prefers a "when approved" approach
177 for new specification and a "just in time" one for existing
178 specifications.
180 4. Acknowledgements
182 This document is an intellectual descendant of a NEWTRK WG
183 specification called "Identifying Standards Track Documents" [6]. It
184 differs from that specification largely by suggesting an even
185 lighter-weight transition process. The present work would not have
186 been possible without those earlier discussions.
188 5. IANA Considerations
190 [[Comment.1: RFC Editor: Please remove this section before
191 publication.]]
193 This memo includes no requests to or actions for IANA.
195 6. Security Considerations
197 This document affects an IETF administrative procedure and has no
198 direct effect on the Security of the Internet. However, better use
199 of stable identifiers for Standards Track document and related groups
200 of such documents may make critical information easier to find.
201 That, may, in turn, have positive security implications.
203 7. References
205 7.1. Normative References
207 [1] Bradner, S., "The Internet Standards Process -- Revision 3",
208 BCP 9, RFC 2026, October 1996.
210 7.2. Informative References
212 [2] Housley, R., Crocker, D., and E. Burger, "Reducing the Standards
213 Track to Two Maturity Levels", January 2011, .
216 [3] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
217 June 1999.
219 [4] Klensin, J., "Internet Standards Documentation (ISDs) and
220 Maturity Levels", July 2010,
221 .
223 [5] Postel, J., "Introduction to the STD Notes", RFC 1311,
224 March 1992.
226 [6] Klensin, J., "Identifying Standards Track Documents",
227 February 2006,
228 .
230 Author's Address
232 John C Klensin
233 1770 Massachusetts Ave, Ste 322
234 Cambridge, MA 02140
235 USA
237 Phone: +1 617 245 1457
238 Email: john+ietf@jck.com