idnits 2.17.1 draft-loughney-what-standards-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 194 has weird spacing: '... tech recom...' == Line 243 has weird spacing: '... tech recom...' -- 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 2004) is 7376 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '1' is mentioned on line 251, but not defined -- Looks like a reference, but probably isn't: 'PROB' on line 90 == Missing Reference: '2' is mentioned on line 253, but not defined == Missing Reference: '3' is mentioned on line 254, but not defined == Unused Reference: '2026' is defined on line 279, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft J. Loughney 3 Document: draft-loughney-what-standards-01.txt Nokia 4 Expires: August 2004 February 2004 6 Standards, What Standards? 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026 [1]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other 20 documents at any time. It is inappropriate to use Internet-Drafts 21 as reference material or to cite them other than as "work in 22 progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document proposes a split between the RFC number of a 32 specification and the label for a protocol or protocol set. The 33 Problem Working Group identified problems with the way in which the 34 IETF manages the document series. This document discusses some of 35 the problems caused by the current state of affairs and suggests 36 some improvements. 38 Table of Contents 40 1. Introduction..................................................3 41 1.1 The Problem(s)............................................3 42 2. Further Analysis of Identified Problems.......................4 43 2.1 Few Specifications Progress Beyond Proposed Standard......4 44 2.2 There is no Formal Bug Reporting or Tracking System.......4 45 2.3 Periodic Reviews of Protocols are not Being Carried Out...4 46 2.4 There is no Maintenance Team Responsible for a Protocol...5 47 3. Suggested Solution............................................5 48 3.1 Mock Example..............................................5 49 3.2 Open Issues...............................................6 50 4. Simple Example Based on an Existing Standard..................6 51 5. Security Considerations.......................................7 52 6. IANA Considerations...........................................7 53 References.......................................................7 54 Acknowledgments..................................................7 55 Author's Addresses...............................................7 56 Appendix A - A Pathological Example..............................7 58 1. Introduction 60 The IETF has produced a large (and useful) body of work. In many 61 ways, the IETF has been a victim of its own (or at least of IP's) 62 success. It is reasonable to expect that as standards see 63 deployment and uses not envisioned by the original authors, bugs 64 will be found or clarification will be needed. 66 Additionally, as the standards with the IETF produces see wider 67 deployment by parties outside of the IETF, the system of 68 documentation and updating within the IETF may cause some amount of 69 confusion. 71 There may be different expectations of what IETF standards may 72 mean. Vendors often implement protocols based upon drafts; a 73 proposed standard is seen as adequate enough for ensuring 74 interoperability; any bugs found in the specification can be 75 handled by code updates. Other Standards Development Organizations 76 may require Draft Standard status, at a minimum, for referencing in 77 their documentations. Government Agencies, however, may take the 78 standards levels literally and assume only Full Standards can be 79 considered as true standards. 81 Finally, the RFC numbering scheme does not lend itself for easily 82 tracking development on a specific protocol or protocol area. There 83 isn't any relationship between RFC numbers, so often one must rely 84 on the RFC Editor's search engine to find all relevant standards on 85 a specific protocol. See Appendix A for a pathological example. 87 1.1 The Problem(s) 89 The following problems are excerpted from Section 2.4 of the IETF 90 Problem statement [PROB]. 92 o Relatively few specifications are now progressed beyond 93 Proposed Standard (PS) to Draft Standard (DS) level, and 94 even fewer to Full Standard (FS). 96 o There is no formal bug reporting or tracking system in 97 place for IETF specifications. 99 o The periodic review of protocols at PS and DS levels 100 specified in [1] are not being carried out, allowing 101 protocols to persist in these lower maturity levels for 102 extended periods of time, whereas the process would 103 normally expect them to progress or be relegated to 104 Historic status. 106 o No individual or body is given the task of 'maintaining' 107 a specification after the original WG has closed down. 108 Specifications are generally only updated when a need 109 for a new version is perceived. No attempt is normally 110 made to correct bugs in the specification (whether they 111 affect operation or not) and the specification is not 112 updated to reflect parts of the specification that have 113 fallen into disuse or were, in fact, never implemented. 114 This is in part because the current procedures would 115 require a standard to revert to the PS maturity level 116 even when specification maintenance is carried out which 117 can be demonstrated to have no or minimal effect on an 118 existing protocol at DS or FS level. 120 This document does not take a stand on the issue of the relevance 121 of the current standards track, but to note that in any given 122 moment, a standard may be on-going work to progress the document. 124 2. Further Analysis of Identified Problems 126 This section looks in greater detail the affects of the problems 127 listed in section 1. Many of these issues are interlinked or 128 compound each other. 130 2.1 Few Specifications Progress Beyond Proposed Standard 132 The IETF, as of late, does not have a good track record of moving 133 protocols beyond Proposed Standard. In fact, the goal of most 134 Working Groups is to produce a set of RFCs and then shut down. 135 Working groups that do this are considered to have succeeded. 136 There are only a handful of long-lived working groups, such as 137 IPv6, whose charters include progressing standards beyond Proposed 138 Standards. 140 2.2 There is no Formal Bug Reporting or Tracking System 142 Bugs in a specification can be found at any point. There have been 143 bugs found in even in Full Standards. How do we ensure the 144 correctness in our own standards? 146 2.3 Periodic Reviews of Protocols are not Being Carried Out 148 Many protocols suffer from benign neglect. The working group 149 charged with developing the protocol has gone dormant or shut down. 150 The principal authors of the specification may no longer be 151 involved in the IETF. Further development of the protocol may even 152 be officially discouraged. 154 Other SDOs may consider extensions or modification to the 155 protocols. This causes problems for parties interested in the 156 technology, as it becomes unclear as to exactly what specifies a 157 particular protocol. Additionally, it makes it hard to track 158 errors or update in a specification or protocol. 160 2.4 There is no Maintenance Team Responsible for a Protocol 162 Specifications are generally only updated when a need for a new 163 version is perceived. No attempt is normally made to correct bugs 164 in the specification (whether they affect operation or not) and the 165 specification is not updated to reflect parts of the specification 166 that have fallen into disuse or were, in fact, never implemented. 167 This is in part because the current procedures would require a 168 standard to revert to the PS maturity level even when specification 169 maintenance is carried out which can be demonstrated to have no or 170 minimal effect on an existing protocol at DS or FS level. 172 3. Suggested Solution 174 This document proposes a simple solution that provides a label for 175 a specification that is separate from the RFC Number. This label 176 should be the protocol name. 178 This document would authorize an additional link on the IETF main 179 page, which would provide a link to the listing of specification 180 labels. 182 3.1 Mock Example 184 In this section we provide a fictitious example, known as the Foo 185 MIB. Note that three versions of the Foo MIB have been made RFCs 186 4120, 4560 and 7890. RFC 4560 was a flawed attempt to do what 7890 187 did, which reached wide deployment before the flaw was discovered. 189 The specification label listing for "Ethernet MIB" could say: 191 Standard last updated: July 1, 2004 193 Stable IETF 1 Mult Deployed Known 194 tech recommend impl impl widely harmful 196 RFC 4120 Y N Y Y Y N 197 RFC 4560 Y N Y Y Y Y 198 RFC 7890 Y Y Y N N N 199 Draft-foo-bis N N Y N N N 201 The IETF recommends deployment of RFC 4120. 202 The IETF recommends implementation of RFC 7890. 204 The IETF recommends experimentation with 205 draft-foo-bis. 207 The IETF recommends against implementing RFC 4560. 209 Important errata known for RFC 4120, 4560 and 7890 are: 210 212 One could imagine a team or an appointed expert in charge of 213 gathering experience with the documents. As implementation reports 214 and deployment experience gathers, the "scorecard" - but NOT the 215 RFCs - would be updated. Other documents, rather than referring to 216 a specific RFC, would, when possible, refer to the protocol label. 218 3.2 Open Issues 220 In order to populate the label system work, there would need to be 221 a web location for this registry. This would require some amount 222 of work on the IETF Secretariat's part. In addition, experts and/or 223 maintenance teams would need to be formed. Most likely document 224 authors and work group chairs would be possible candidates. A 225 reasonable proposal would be to have an expert or set of experts 226 for specific protocols appointed by Area Directors, at least in a 227 trial phase. 229 One should note that the IETF already has a precedent set for 230 protocol experts in the form of IANA designated experts. 232 A reasonable next step would be to produce a web-based example 233 based upon this proposal. 235 4. Simple Example Based on an Existing Standard 237 SCTP has been chosen because it is a relatively new protocol but 238 also because the author is familiar with it. 240 Stream Control Transmission Protocol 242 Stable IETF 1 Mult Deployed Known 243 tech recommend impl impl widely harmful 245 RFC 2960 Y Y Y Y N N 246 RFC 3309 Y Y Y Y N N 247 Imp Guide [1] N N Y Y N N 248 Add IP [2] N N Y Y N N 249 PR-SCTP [3] N N Y Y N N 251 [1] draft-ietf-tsvwg-sctpimpguide-10.txt 253 [2] draft-ietf-tsvwg-addip-sctp-08.txt 254 [3] draft-ietf-tsvwg-prsctp-03.txt 256 Information References: 257 RFC 3257 Stream Control Transmission Protocol 258 Applicability Statement 259 RFC 3286 An Introduction to the Stream Control 260 Transmission Protocol (SCTP) 262 The IETF recommends implementing RFC 2960 with the updated checksum 263 coverage documented in RFC 3309. draft-ietf-tsvwg-sctpimpguide 264 contains updated information found during conformance tests. 266 5. Security Considerations 268 This document in and of itself does not of itself have security 269 implications. 271 6. IANA Considerations 273 Currently there are no IANA implications. However, should this 274 solution be deployed, there may be a need to link the specification 275 label with the IANA registry for a particular protocol. 277 References 279 [2026] Bradner, S., "The Internet Standards Process -- Revision 280 3", BCP 9, RFC 2026, October 1996. 282 Acknowledgments 284 The author would like to thank Harald Alvestrand for making the 285 author the 'designated expert' on this particular topic. The 286 author wants to thank John Klensen for warning that there may be 287 dragons ahead. Thanks to Spencer Dawkins, Jordi Palet Martinez, 288 Keith Moore and Mike Pierce for reading & commenting. 290 Author's Addresses 292 John Loughney 293 Nokia 294 Email: john.loughney@nokia.com 296 Appendix A - A Pathological Example 297 TCP has been a wildly successful protocol by any measure. One of 298 the benefits of TCP has been that it has enabled interoperable 299 services running on top of it, irrespective of the layers below it. 300 This success has come at a price. 302 For example there have been discussions on the e2e mailing list 303 about what is TCP (http://www.postel.org/pipermail/end2end- 304 interest/). This has resulted in a new working group being formed 305 to, essentially, clean up the set of TCP standards. 307 Using the RFC Editor's page, (http://www.rfc-editor.org/cgi- 308 bin/rfcsearch.pl), my first search retured: "Based on your search 309 of [tcp] in the Title field 93 matches were found." Then, a second 310 search: "Based on your search of [Transmission Control Protocol] in 311 the Title field 13 matches were found." This points to a fact that 312 there are a large number of RFCs at least partly related to TCP.