idnits 2.17.1 draft-ietf-poised95-std-proc-3-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-16) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: 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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** 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 322 has weird spacing: '... itself as lo...' -- 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 (January 1996) is 10319 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: '7' is mentioned on line 266, but not defined == Unused Reference: '3' is defined on line 1286, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1295, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Downref: Normative reference to an Informational RFC: RFC 1311 (ref. '4') ** Obsolete normative reference: RFC 1543 (ref. '5') (Obsoleted by RFC 2223) ** Downref: Normative reference to an Historic RFC: RFC 1818 (ref. '6') Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Bradner 2 Internet-Draft Harvard University 3 Editor 4 January 1996 5 Expires in six months 7 The Internet Standards Process -- Revision 3 9 a proposed revision of part of RFC 1602 11 13 Status of this Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as ``work in progress.'' 25 To learn the current status of any Internet-Draft, please check the 26 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 27 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 28 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 29 ftp.isi.edu (US West Coast). 31 Abstract 33 This memo documents the process used by the Internet community for 34 the standardization of protocols and procedures. It defines the 35 stages in the standardization process, the requirements for moving a 36 document between stages and the types of documents used during this 37 process. It also addresses the intellectual property rights and 38 copyright issues associated with the standards process. 40 Table of Contents 42 Status of this Memo.................................................1 43 Abstract............................................................1 44 1. INTRODUCTION....................................................3 45 1.1 Internet Standards...........................................3 46 1.2 The Internet Standards Process...............................3 47 1.3 Organization of This Document................................5 48 2. INTERNET STANDARDS-RELATED PUBLICATIONS.........................5 49 2.1 Requests for Comments (RFCs).................................5 50 2.2 Internet-Drafts..............................................7 51 3. INTERNET STANDARD SPECIFICATIONS................................8 52 3.1 Technical Specification (TS).................................8 53 3.2 Applicability Statement (AS).................................8 54 3.3 Requirement Levels...........................................9 55 4. THE INTERNET STANDARDS TRACK...................................10 56 4.1 Standards Track Maturity Levels.............................10 57 4.1.1 Proposed Standard.......................................10 58 4.1.2 Draft Standard..........................................11 59 4.1.3 Internet Standard.......................................12 60 4.2 Non-Standards Track Maturity Levels.........................12 61 4.2.1 Experimental............................................12 62 4.2.2 Informational...........................................13 63 4.2.3 Procedures for Experimental and Informational RFCs......13 64 4.2.4 Historic................................................14 65 5. BEST CURRENT PRACTICE (BCP) RFCs...............................14 66 5.1 BCP Review Process..........................................15 67 6. THE INTERNET STANDARDS PROCESS.................................15 68 6.1 Standards Actions...........................................16 69 6.1.1 Initiation of Action....................................16 70 6.1.2 IESG Review and Approval................................16 71 6.1.3 Publication.............................................17 72 6.2 Advancing in the Standards Track............................17 73 6.3 Revising a Standard.........................................19 74 6.4 Retiring a Standard.........................................19 75 6.5 Conflict Resolution and Appeals.............................19 76 7. EXTERNAL STANDARDS AND SPECIFICATIONS..........................21 77 7.1 Use of External Specifications..............................21 78 7.1.1 Incorporation of an Open Standard.......................22 79 7.1.2 Incorporation of a Vendor Standard......................22 80 7.1.3 Assumption..............................................22 81 8 NOTICES AND RECORD KEEPING......................................22 82 9. INTELLECTUAL PROPERTY RIGHTS...................................23 83 9.1. General Policy.............................................23 84 9.2 Confidentiality Obligations................................23 85 9.3. Rights and Permissions.....................................24 86 9.3.1. All Contributions.......................................24 87 9.4.2. Standards Track Documents...............................24 88 9.4.3 Determination of Reasonable and 89 Non-discriminatory Terms................................25 90 9.5. Notices....................................................25 91 10. ACKNOWLEDGMENTS................................................27 92 11. SECURITY CONSIDERATIONS........................................27 93 12. REFERENCES.....................................................27 94 13 .AUTHORS' ADDRESS...............................................28 96 APPENDIX A: DEFINITIONS OF TERMS...................................28 97 APPENDIX B: GLOSSARY OF ACRONYMS...................................28 99 1. INTRODUCTION 101 This memo documents the process currently used by the Internet 102 community for the standardization of protocols and procedures. The 103 Internet Standards process is an activity of the Internet Society 104 that is organized and managed on behalf of the Internet community by 105 the Internet Architecture Board (IAB) and the Internet Engineering 106 Steering Group (IESG). 108 1.1 Internet Standards 110 The Internet, a loosely-organized international collaboration of 111 autonomous, interconnected networks, supports host-to-host 112 communication through voluntary adherence to open protocols and 113 procedures defined by Internet Standards. There are also many 114 isolated internets, i.e., sets of interconnected networks, which are 115 not connected to the global Internet but use the Internet Standards. 117 The Internet standards process described in this document is 118 concerned with all protocols, procedures, and conventions that are 119 used in or by the Internet, whether or not they are part of the 120 TCP/IP protocol suite. In the case of protocols developed and/or 121 standardized by non-Internet organizations, however, the Internet 122 standards process normally applies to the application of the protocol 123 or procedure in the Internet context, not to the specification of the 124 protocol itself. 126 In general, an Internet Standard is a specification that is stable 127 and well-understood, is technically competent, has multiple, 128 independent, and interoperable implementations with substantial 129 operational experience, enjoys significant public support, and is 130 recognizably useful in some or all parts of the Internet. 132 1.2 The Internet Standards Process 133 In outline, the process of creating an Internet Standard is 134 straightforward: a specification undergoes a period of development 135 and several iterations of review by the Internet community and 136 revision based upon experience, is adopted as a Standard by the 137 appropriate body (see below), and is published. In practice, the 138 process is more complicated, due to (1) the difficulty of creating 139 specifications of high technical quality; (2) the need to consider 140 the interests of all of the affected parties; (3) the importance of 141 establishing widespread community consensus; and (4) the difficulty 142 of evaluating the utility of a particular specification for the 143 Internet community. 145 The goals of the Internet standards process are: 146 o technical excellence; 147 o prior implementation and testing; 148 o clear, concise, and easily understandable documentation; 149 o openness and fairness; and 150 o timeliness. 152 The procedures described in this document are designed to be fair, 153 open, and objective; to reflect existing (proven) practice; and to 154 be flexible. 156 o These procedures are intended to provide a fair, open, and 157 objective basis for developing, evaluating, and adopting Internet 158 Standards. They provide ample opportunity for participation and 159 comment by all interested parties. At each stage of the 160 standardization process, a specification is repeatedly discussed 161 and its merits debated in open meetings and/or public electronic 162 mailing lists, and it is made available for review via world-wide 163 on-line directories. 165 o These procedures are explicitly aimed at recognizing and adopting 166 generally-accepted practices. Thus, a candidate specification 167 must be implemented and tested for correct operation and 168 interoperability by multiple independent parties and utilized in 169 increasingly demanding environments, before it can be adopted as 170 an Internet Standard. 172 o These procedures provide a great deal of flexibility to adapt to 173 the wide variety of circumstances that occur in the 174 standardization process. Experience has shown this flexibility to 175 be vital in achieving the goals listed above. 177 The goal of technical competence, the requirement for prior 178 implementation and testing, and the need to allow all interested 179 parties to comment all require significant time and effort. On the 180 other hand, today's rapid development of networking technology 181 demands timely development of standards. The Internet standards 182 process is intended to balance these conflicting goals. The process 183 is believed to be as short and simple as possible without sacrificing 184 technical excellence, thorough testing before adoption of a standard, 185 or openness and fairness. 187 From its inception, the Internet has been, and is expected to remain, 188 an evolving system whose participants regularly factor new 189 requirements and technology into its design and implementation. Users 190 of the Internet and providers of the equipment, software, and 191 services that support it should anticipate and embrace this evolution 192 as a major tenet of Internet philosophy. 194 The procedures described in this document are the result of a number 195 of years of evolution, driven both by the needs of the growing and 196 increasingly diverse Internet community, and by experience. 198 1.3 Organization of This Document 200 Section 2 describes the publications and archives of the Internet 201 standards process, and specifies the requirements for record-keeping 202 and public access to information. Section 3 describes the Internet 203 standards track. Section 4 describes the types of Internet standard 204 specification. Section 5 describes the process and rules for Internet 205 standardization. Section 6 specifies the way in which externally- 206 sponsored specifications and practices, developed and controlled by 207 other standards bodies or by vendors, are handled within the Internet 208 standards process. Section 7 presents the rules that are required to 209 protect intellectual property rights in the context of the 210 development and use of Internet Standards. Section 8 contains a list 211 of numbered references. 213 Appendix A contains definitions of some of the terms used in this 214 document. Appendix B contains a list of frequently-used acronyms. 216 2. INTERNET STANDARDS-RELATED PUBLICATIONS 218 2.1 Requests for Comments (RFCs) 220 Each distinct version of an Internet standards-related specification 221 is published as part of the "Request for Comments" (RFC) document 222 series. This archival series is the official publication channel for 223 Internet standards documents and other publications of the IESG, IAB, 224 and Internet community. RFCs can be obtained from a number of 225 Internet hosts using anonymous FTP, gopher, World Wide Web, and other 226 Internet document-retrieval systems. 228 The RFC series of documents on networking began in 1969 as part of 229 the original ARPA wide-area networking (ARPANET) project (see 230 Appendix A for glossary of acronyms). RFCs cover a wide range of 231 topics in addition to Internet Standards, from early discussion of 232 new research concepts to status memos about the Internet. RFC 233 publication is the direct responsibility of the RFC Editor, under the 234 general direction of the IAB. 236 The rules for formatting and submitting an RFC are defined in [5]. 237 Every RFC is available in ASCII text. Some RFCs are also available 238 in PostScript(R). The PostScript(R) version of an RFC may contain 239 material (such as diagrams and figures) that is not present in the 240 ASCII version, and it may be formatted differently. 242 ********************************************************* 243 * * 244 * A stricter requirement applies to standards-track * 245 * specifications: the ASCII text version is the * 246 * definitive reference, and therefore it must be a * 247 * complete and accurate specification of the standard, * 248 * including all necessary diagrams and illustrations. * 249 * * 250 ********************************************************* 252 The status of Internet protocol and service specifications is 253 summarized periodically in an RFC entitled "Internet Official 254 Protocol Standards" [1]. This RFC shows the level of maturity and 255 other helpful information for each Internet protocol or service 256 specification (see section 3). 258 Some RFCs document Internet Standards. These RFCs form the 'STD' 259 subseries of the RFC series [4]. When a specification has been 260 adopted as an Internet Standard, it is given the additional label 261 "STDxxx", but it keeps its RFC number and its place in the RFC 262 series. (see section 4.1.3) 264 Some RFCs describe the best current thinking about practices in the 265 Internet community These RFCs form the 'BCP' (Best Current Practice) 266 subseries of the RFC series. [7] When a specification has been 267 adopted as a BCP, it is given the additional label "BCPxxx", but it 268 keeps its RFC number and its place in the RFC series. (see section 5) 270 Not all specifications of protocols or services for the Internet 271 should or will become Internet Standards or BCPs. Such non-standards 272 track specifications are not subject to the rules for Internet 273 standardization. Non-standards track specifications may be published 274 directly as "Experimental" or "Informational" RFCs at the discretion 275 of the RFC Editor in consultation with the IESG (see section 4.2). 277 ******************************************************** 278 * * 279 * It is important to remember that not all RFCs * 280 * are standards track documents, and that not all * 281 * standards track documents reach the level of * 282 * Internet Standard. In the same way, not all RFCs * 283 * which describe current practices have been given * 284 * the review and approval to become BCPs. See * 285 * RFC-1796 for further information. * 286 * * 287 ******************************************************** 289 2.2 Internet-Drafts 291 During the development of a specification, draft versions of the 292 document are made available for informal review and comment by 293 placing them in the IETF's "Internet-Drafts" directory, which is 294 replicated on a number of Internet hosts. This makes an evolving 295 working document readily available to a wide audience, facilitating 296 the process of review and revision. 298 An Internet-Draft that is published as an RFC, or that has remained 299 unchanged in the Internet-Drafts directory for more than six months 300 without being recommended by the IESG for publication as an RFC, is 301 simply removed from the Internet-Drafts directory. At any time, an 302 Internet-Draft may be replaced by a more recent version of the same 303 specification, restarting the six-month timeout period. 305 An Internet-Draft is NOT a means of "publishing" a specification; 306 specifications are published through the RFC mechanism described in 307 the previous section. Internet-Drafts have no formal status, and are 308 subject to change or removal at any time. 310 ******************************************************** 311 * * 312 * Under no circumstances should an Internet-Draft * 313 * be referenced by any paper, report, or Request- * 314 * for-Proposal, nor should a vendor claim compliance * 315 * with an Internet-Draft. * 316 * * 317 ******************************************************** 319 Note: It is acceptable to reference a standards-track specification 320 that may reasonably be expected to be published as an RFC using the 321 phrase "Work in Progress" without referencing an Internet-Draft. 322 This may also be done in a standards track document itself as long 323 as the specification in which the reference is made would stand as a 324 complete and understandable document with or without the reference to 325 the "Work in Progress". 327 3. INTERNET STANDARD SPECIFICATIONS 329 Specifications subject to the Internet standards process fall into 330 one of two categories: Technical Specification (TS) and 331 Applicability Statement (AS). 333 3.1 Technical Specification (TS) 335 A Technical Specification is any description of a protocol, service, 336 procedure, convention, or format. It may completely describe all of 337 the relevant aspects of its subject, or it may leave one or more 338 parameters or options unspecified. A TS may be completely self- 339 contained, or it may incorporate material from other specifications 340 by reference to other documents (which may or may not be Internet 341 Standards). 343 A TS shall include a statement of its scope and the general intent 344 for its use (domain of applicability). Thus, a TS that is inherently 345 specific to a particular context shall contain a statement to that 346 effect. However, a TS does not specify requirements for its use 347 within the Internet; these requirements, which depend on the 348 particular context in which the TS is incorporated by different 349 system configurations, are defined by an Applicability Statement. 351 3.2 Applicability Statement (AS) 353 An Applicability Statement specifies how, and under what 354 circumstances, one or more TSs may be applied to support a particular 355 Internet capability. An AS may specify uses for TSs that are not 356 Internet Standards, as discussed in Section 7. 358 An AS identifies the relevant TSs and the specific way in which they 359 are to be combined, and may also specify particular values or ranges 360 of TS parameters or subfunctions of a TS protocol that must be 361 implemented. An AS also specifies the circumstances in which the use 362 of a particular TS is required, recommended, or elective (see section 363 3.3). 365 An AS may describe particular methods of using a TS in a restricted 366 "domain of applicability", such as Internet routers, terminal 367 servers, Internet systems that interface to Ethernets, or datagram- 368 based database servers. 370 The broadest type of AS is a comprehensive conformance specification, 371 commonly called a "requirements document", for a particular class of 372 Internet systems, such as Internet routers or Internet hosts. 374 An AS may not have a higher maturity level in the standards track 375 than any standards-track TS on which the AS relies (see section 4.1). 376 For example, a TS at Draft Standard level may be referenced by an AS 377 at the Proposed Standard or Draft Standard level, but not by an AS at 378 the Standard level. 380 3.3 Requirement Levels 382 An AS shall apply one of the following "requirement levels" to each 383 of the TSs to which it refers: 385 (a) Required: Implementation of the referenced TS, as specified by 386 the AS, is required to achieve minimal conformance. For example, 387 IP and ICMP must be implemented by all Internet systems using the 388 TCP/IP Protocol Suite. 390 (b) Recommended: Implementation of the referenced TS is not 391 required for minimal conformance, but experience and/or generally 392 accepted technical wisdom suggest its desirability in the domain 393 of applicability of the AS. Vendors are strongly encouraged to 394 include the functions, features, and protocols of Recommended TSs 395 in their products, and should omit them only if the omission is 396 justified by some special circumstance. 398 (c) Elective: Implementation of the referenced TS is optional 399 within the domain of applicability of the AS; that is, the AS 400 creates no explicit necessity to apply the TS. However, a 401 particular vendor may decide to implement it, or a particular user 402 may decide that it is a necessity in a specific environment. 404 As noted in section 4.1, there are TSs that are not in the 405 standards track or that have been retired from the standards 406 track, and are therefore not required, recommended, or elective. 407 Two additional "requirement level" designations are available for 408 these TSs: 410 (d) Limited Use: The TS is considered to be appropriate for use 411 only in limited or unique circumstances. For example, the usage 412 of a protocol with the "Experimental" designation should generally 413 be limited to those actively involved with the experiment. 415 (e) Not Recommended: A TS that is considered to be inappropriate 416 for general use is labeled "Not Recommended". This may be because 417 of its limited functionality, specialized nature, or historic 418 status. 420 Although TSs and ASs are conceptually separate, in practice a 421 standards-track document may combine an AS and one or more related 422 TSs. For example, Technical Specifications that are developed 423 specifically and exclusively for some particular domain of 424 applicability, e.g., for mail server hosts, often contain within a 425 single specification all of the relevant AS and TS information. In 426 such cases, no useful purpose would be served by deliberately 427 distributing the information among several documents just to preserve 428 the formal AS/TS distinction. However, a TS that is likely to apply 429 to more than one domain of applicability should be developed in a 430 modular fashion, to facilitate its incorporation by multiple ASs. 432 The "Official Protocol Standards" RFC (STD1) lists a general 433 requirement level for each TS, using the nomenclature defined in this 434 section. This RFC is updated periodically. In many cases, more 435 detailed descriptions of the requirement levels of particular 436 protocols and of individual features of the protocols will be found 437 in appropriate ASs. 439 4. THE INTERNET STANDARDS TRACK 441 Specifications that are intended to become Internet Standards evolve 442 through a set of maturity levels known as the "standards track". 443 These maturity levels -- "Proposed Standard", "Draft Standard", and 444 "Standard" -- are defined and discussed in section 4.1. The way in 445 which specifications move along the standards track is described in 446 section 6. 448 Even after a specification has been adopted as an Internet Standard, 449 further evolution often occurs based on experience and the 450 recognition of new requirements. The nomenclature and procedures of 451 Internet standardization provide for the replacement of old Internet 452 Standards with new ones, and the assignment of descriptive labels to 453 indicate the status of "retired" Internet Standards. A set of 454 maturity levels is defined in section 4.2 to cover these and other 455 specifications that are not considered to be on the standards track. 457 4.1 Standards Track Maturity Levels 459 Internet specifications go through stages of development, testing, 460 and acceptance. Within the Internet standards process, these stages 461 are formally labeled "maturity levels". 463 This section describes the maturity levels and the expected 464 characteristics of specifications at each level. 466 4.1.1 Proposed Standard 468 The entry-level maturity for the standards track is "Proposed 469 Standard". A specific action by the IESG is required to move a 470 specification onto the standards track at the "Proposed Standard" 471 level. 473 A Proposed Standard specification is generally stable, has resolved 474 known design choices, is believed to be well-understood, has received 475 significant community review, and appears to enjoy enough community 476 interest to be considered valuable. However, further experience 477 might result in a change or even retraction of the specification 478 before it advances. 480 Usually, neither implementation nor operational experience is 481 required for the designation of a specification as a Proposed 482 Standard. However, such experience is highly desirable, and will 483 usually represent a strong argument in favor of a Proposed Standard 484 designation. 486 The IESG may require implementation and/or operational experience 487 prior to granting Proposed Standard status to a specification that 488 materially affects the core Internet protocols or that specifies 489 behavior that may have significant operational impact on the 490 Internet. 492 A Proposed Standard should have no known technical omissions with 493 respect to the requirements placed upon it. However, the IESG may 494 waive this requirement in order to allow a specification to advance 495 to the Proposed Standard state when it is considered to be useful and 496 necessary (and timely) even with known technical omissions. 498 Implementors should treat Proposed Standards as immature 499 specifications. It is desirable to implement them in order to gain 500 experience and to validate, test, and clarify the specification. 501 However, since the content of Proposed Standards may be changed if 502 problems are found or better solutions are identified, deploying 503 implementations of such standards into a disruption-sensitive 504 customer base is not recommended. 506 4.1.2 Draft Standard 508 A specification from which at least two independent and interoperable 509 implementations from different code bases have been developed, and 510 for which sufficient successful operational experience has been 511 obtained, may be elevated to the "Draft Standard" level. If patented 512 or otherwise controlled technology is required for implementation, 513 the separate implementations must also have resulted from separate 514 exercise of the licensing process. Elevation to Draft Standard is a 515 major advance in status, indicating a strong belief that the 516 specification is mature and will be useful. 518 The requirement for at least two independent and interoperable 519 implementations applies to all of the options and features of the 520 specification. In cases in which one or more options or features 521 have not been demonstrated in at least two interoperable 522 implementations, the specification may advance to the Draft Standard 523 level only if those options or features are removed. 525 A Draft Standard must be well-understood and known to be quite 526 stable, both in its semantics and as a basis for developing an 527 implementation. A Draft Standard may still require additional or 528 more widespread field experience, since it is possible for 529 implementations based on Draft Standard specifications to demonstrate 530 unforeseen behavior when subjected to large-scale use in production 531 environments. 533 A Draft Standard is normally considered to be a final specification, 534 and changes are likely to be made only to solve specific problems 535 encountered. In most circumstances, it is reasonable for vendors to 536 deploy implementations of Draft Standards into the customer base. 538 4.1.3 Internet Standard 540 A specification for which significant implementation and successful 541 operational experience has been obtained may be elevated to the 542 Internet Standard level. An Internet Standard (which may simply be 543 referred to as a Standard) is characterized by a high degree of 544 technical maturity and by a generally held belief that the specified 545 protocol or service provides significant benefit to the Internet 546 community. 548 A specification that reaches the status of Standard is assigned a 549 number in the STD series while retaining its RFC number. 551 4.2 Non-Standards Track Maturity Levels 553 Not every specification is on the standards track. A specification 554 may not be intended to be an Internet Standard, or it may be intended 555 for eventual standardization but not yet ready to enter the standards 556 track. A specification may have been superseded by a more recent 557 Internet Standard, or have otherwise fallen into disuse or disfavor. 559 Specifications that are not on the standards track are labeled with 560 one of three "off-track" maturity levels: "Experimental", 561 "Informational", or "Historic". The documents bearing these labels 562 are not Internet Standards in any sense. 564 4.2.1 Experimental 565 The "Experimental" designation typically denotes a specification that 566 is part of some research or development effort. Such a specification 567 is published for the general information of the Internet technical 568 community and as an archival record of the work, subject only to 569 editorial considerations and to verification that there has been 570 adequate coordination with the standards process (see below). An 571 Experimental specification may be the output of an organized Internet 572 research effort (e.g., a Research Group of the IRTF), an IETF Working 573 Group, or it may be an individual contribution. 575 4.2.2 Informational 577 An "Informational" specification is published for the general 578 information of the Internet community, and does not represent an 579 Internet community consensus or recommendation. The Informational 580 designation is intended to provide for the timely publication of a 581 very broad range of responsible informational documents from many 582 sources, subject only to editorial considerations and to verification 583 that there has been adequate coordination with the standards process 584 (see section 4.2.3). 586 Specifications that have been prepared outside of the Internet 587 community and are not incorporated into the Internet standards 588 process by any of the provisions of section 9 may be published as 589 Informational RFCs, with the permission of the owner and the 590 concurrence of the RFC Editor. 592 4.2.3 Procedures for Experimental and Informational RFCs 594 Unless they are the result of IETF working group action, documents 595 intended to be published with Experimental or Informational status 596 should be submitted directly to the RFC Editor. The RFC Editor will 597 publish any such documents as Internet-Drafts which have not already 598 been so published. In order to differentiate these Internet-Drafts 599 they will be labeled or grouped in the I-D directory so they are 600 easily recognizable. The RFC Editor will wait two weeks after this 601 publication for comments before proceeding further. The RFC Editor 602 is expected to exercise his or her judgment concerning the editorial 603 suitability of a document for publication with Experimental or 604 Informational status, and may refuse to publish a document which, in 605 the expert opinion of the RFC Editor, is unrelated to Internet 606 activity or falls below the technical and/or editorial standard for 607 RFCs. 609 To ensure that the non-standards track Experimental and Informational 610 designations are not misused to circumvent the Internet standards 611 process, the IESG and the RFC Editor have agreed that the RFC Editor 612 will refer to the IESG any document submitted for Experimental or 613 Informational publication which, in the opinion of the RFC Editor, 614 may be related to work being done, or expected to be done, within the 615 IETF community. The IESG shall review such a referred document 616 within a reasonable period of time, and recommend either that it be 617 published as originally submitted or referred to the IETF as a 618 contribution to the Internet standards process. 620 If (a) the IESG recommends that the document be brought within the 621 IETF and progressed within the IETF context, but the author declines 622 to do so, or (b) the IESG considers that the document proposes 623 something that conflicts with, or is actually inimical to, an 624 established IETF effort, the document may still be published as an 625 Experimental or Informational RFC. In these cases, however, the IESG 626 may insert appropriate "disclaimer" text into the RFC either in or 627 immediately following the "Status of this Memo" section in order to 628 make the circumstances of its publication clear to readers. 630 Documents proposed for Experimental and Informational RFCs by IETF 631 working groups go through IESG review. The review is initiated using 632 the process described in section 6.1.1. 634 4.2.4 Historic 636 A specification that has been superseded by a more recent 637 specification or is for any other reason considered to be obsolete is 638 assigned to the "Historic" level. (Purists have suggested that the 639 word should be "Historical"; however, at this point the use of 640 "Historic" is historical.) 642 5. BEST CURRENT THINKING ABOUT PRACTICE (BCP) RFCs 644 The BCP subseries of the RFC series is designed to be a way to 645 standardize practices and the results of community deliberations. A 646 BCP document is subject to the same basic set of procedures as 647 standards track documents and thus is a vehicle by which the IETF 648 community can define and ratify the communities' best current 649 thinking on a statement of principle or on what is the best way to 650 perform some function. 652 Historically Internet standards have generally been concerned with 653 the technical specifications for hardware and software required for 654 computer communication across interconnected networks. However, 655 since the Internet itself is composed of networks operated by a great 656 variety of organizations, with diverse goals and rules, good user 657 service requires that the operators and administrators of the 658 Internet follow some common guidelines for policies and operations. 659 While these guidelines are generally different in scope and style 660 from protocol standards, their establishment needs a similar process 661 for consensus building. 663 While it is recognized that entities such as the IAB and IESG are 664 composed of individuals who may participate, as individuals, in the 665 technical work of the IETF, it is also recognized that the entities 666 themselves have an existence as leaders in the community. As leaders 667 in the Internet technical community, these entities should have an 668 outlet to propose ideas to stimulate work in a particular area, to 669 raise the community's sensitivity to a certain issue, to make a 670 statement of architectural principle, or to communicate their 671 thoughts on other matters. The BCP subseries creates a smoothly 672 structured way for these management entities to insert proposals into 673 the consensus-building machinery of the IETF while gauging the 674 community's view of that issue. 676 Finally, the BCP series may be used to document the operation of the 677 IETF itself. For example, this document defines the IETF standards 678 process and is published as a BCP. 680 5.1 BCP Review Process 682 Unlike standards-track documents, the mechanisms described in BCPs 683 are not well suited to the phased roll-in nature of the three stage 684 standards track and instead generally only make sense for full and 685 immediate instantiation. 687 The BCP process is similar to that for proposed standards. The BCP 688 is submitted to the IESG for review, (see section 6.1.1) and the 689 existing review process applies, including a Last-Call on the IETF 690 Announce mailing list. However, once the IESG has approved the 691 document, the process ends and the document is published. The 692 resulting document is viewed as having the technical approval of the 693 IETF, but it is not, and cannot become an official Internet Standard. 695 Specifically, a document to be considered for the status of BCP must 696 undergo the procedures outlined in sections 6.1, and 6.5 of this 697 document. It is also under the restrictions of section 6.2 and the 698 process may be appealed according to the procedures in section 6.6. 700 Because BCPs are meant to express community consensus but are arrived 701 at more quickly than standards, BCPs require particular care. 702 Specifically, BCPs should not be viewed simply as stronger 703 Informational RFCs, but rather should be viewed as documents suitable 704 for a content unique from Informational RFCs. 706 A specification that has been approved as a BCP is assigned a number 707 in the BCP series while retaining its RFC number. 709 6. THE INTERNET STANDARDS PROCESS 711 The mechanics of the Internet standards process involve decisions of 712 the IESG concerning the elevation of a specification onto the 713 standards track or the movement of a standards-track specification 714 from one maturity level to another. Although a number of reasonably 715 objective criteria (described below and in section 4) are available 716 to guide the IESG in making a decision to move a specification onto, 717 along, or off the standards track, there is no algorithmic guarantee 718 of elevation to or progression along the standards track for any 719 specification. The experienced collective judgment of the IESG 720 concerning the technical quality of a specification proposed for 721 elevation to or advancement in the standards track is an essential 722 component of the decision-making process. 724 6.1 Standards Actions 726 A "standards action" -- entering a particular specification into, 727 advancing it within, or removing it from, the standards track -- must 728 be approved by the IESG. 730 6.1.1 Initiation of Action 732 A specification that is intended to enter or advance in the Internet 733 standards track shall first be posted as an Internet-Draft (see 734 section 2.2) unless it has not changed since publication as an RFC. 735 It shall remain as an Internet-Draft for a period of time, not less 736 than two weeks, that permits useful community review, after which a 737 recommendation for action may be initiated. 739 A standards action is initiated by a recommendation by the IETF 740 Working group responsible for a specification to its Area Director, 741 copied to the IETF Secretary or, in the case of a specification not 742 associated with a Working Group, a recommendation by an individual to 743 the IESG. 745 6.1.2 IESG Review and Approval 747 The IESG shall determine whether or not a specification submitted to 748 it according to section 6.1.1 satisfies the applicable criteria for 749 the recommended action (see sections 4.1 and 4.2), and shall in 750 addition determine whether or not the technical quality and clarity 751 of the specification is consistent with that expected for the 752 maturity level to which the specification is recommended. 754 In order to obtain all of the information necessary to make these 755 determinations, particularly when the specification is considered by 756 the IESG to be extremely important in terms of its potential impact 757 on the Internet or on the suite of Internet protocols, the IESG may, 758 at its discretion, commission an independent technical review of the 759 specification. 761 The IESG will send notice to the IETF of the pending IESG 762 consideration of the document(s) to permit a final review by the 763 general Internet community. This "Last-Call" notification shall be 764 via electronic mail to the IETF Announce mailing list. Comments on a 765 Last-Call shall be accepted from anyone, and should be sent to the 766 email address specified in the Last-Call. 768 The Last-Call period shall be no shorter than two weeks except in 769 those cases where the proposed standards action was not initiated by 770 an IETF Working Group, in which case the Last-Call period shall be no 771 shorter than four weeks. If the IESG believes that the community 772 interest would be served by allowing more time for comment, it may 773 decide on a longer Last-Call period or to explicitly lengthen a 774 current Last-Call period. 776 The IETF may decide to recommend the formation of a new Working Group 777 in the case of significant controversy in response to a specification 778 not originating from an IETF Working Group. 780 In a timely fashion after the expiration of the Last-Call period, the 781 IESG shall make its final determination of whether or not to approve 782 the standards action, and shall notify the IETF of its decision via 783 electronic mail to the IETF Announce mailing list. 785 6.1.3 Publication 787 If a standards action is approved, notification is sent to the RFC 788 Editor and copied to the IETF with instructions to publish the 789 specification as an RFC. The specification shall at that point be 790 removed from the Internet-Drafts directory. 792 An official summary of standards actions completed and pending shall 793 appear in each issue of the Internet Society's newsletter. This 794 shall constitute the "publication of record" for Internet standards 795 actions. 797 The RFC Editor shall publish periodically an "Internet Official 798 Protocol Standards" RFC [1], summarizing the status of all Internet 799 protocol and service specifications. 801 6.2 Advancing in the Standards Track 803 The procedure described in section 6.1 is followed for each action 804 that attends the advancement of a specification along the standards 805 track. 807 A specification shall remain at the Proposed Standard level for at 808 least six (6) months. 810 A specification shall remain at the Draft Standard level for at least 811 four (4) months, or until at least one IETF meeting has occurred, 812 whichever comes later. 814 These minimum periods are intended to ensure adequate opportunity for 815 community review without severely impacting timeliness. These 816 intervals shall be measured from the date of publication of the 817 corresponding RFC(s), or, if the action does not result in RFC 818 publication, the date of the announcement of the IESG approval of the 819 action. 821 A specification may be (indeed, is likely to be) revised as it 822 advances through the standards track. At each stage, the IESG shall 823 determine the scope and significance of the revision to the 824 specification, and, if necessary and appropriate, modify the 825 recommended action. Minor revisions are expected, but a significant 826 revision may require that the specification accumulate more 827 experience at its current maturity level before progressing. Finally, 828 if the specification has been changed very significantly, the IESG 829 may recommend that the revision be treated as a new document, re- 830 entering the standards track at the beginning. 832 Change of status shall result in republication of the specification 833 as an RFC, except in the rare case that there have been no changes at 834 all in the specification since the last publication. Generally, 835 desired changes will be "batched" for incorporation at the next level 836 in the standards track. However, deferral of changes to the next 837 standards action on the specification will not always be possible or 838 desirable; for example, an important typographical error, or a 839 technical error that does not represent a change in overall function 840 of the specification, may need to be corrected immediately. In such 841 cases, the IESG or RFC Editor may be asked to republish the RFC (with 842 a new number) with corrections, and this will not reset the minimum 843 time-at-level clock. 845 When a standards-track specification has not reached the Internet 846 Standard level but has remained at the same maturity level for 847 twenty-four (24) months, and every twelve (12) months thereafter 848 until the status is changed, the IESG shall review the viability of 849 the standardization effort responsible for that specification and the 850 usefulness of the technology. Following each such review, the IESG 851 shall approve termination or continuation of the development effort, 852 at the same time the IESG shall decide to maintain the specification 853 at the same maturity level or to move it to Historic status. This 854 decision shall be communicated to the IETF by electronic mail to the 855 IETF Announce mailing list to allow the Internet community an 856 opportunity to comment. This provision is not intended to threaten a 857 legitimate and active Working Group effort, but rather to provide an 858 administrative mechanism for terminating a moribund effort. 860 6.3 Revising a Standard 862 A new version of an established Internet Standard must progress 863 through the full Internet standardization process as if it were a 864 completely new specification. Once the new version has reached the 865 Standard level, it will usually replace the previous version, which 866 will be moved to Historic status. However, in some cases both 867 versions may remain as Internet Standards to honor the requirements 868 of an installed base. In this situation, the relationship between 869 the previous and the new versions must be explicitly stated in the 870 text of the new version or in another appropriate document (e.g., an 871 Applicability Statement; see section 3.2). 873 6.4 Retiring a Standard 875 As the technology changes and matures, it is possible for a new 876 Standard specification to be so clearly superior technically that one 877 or more existing standards track specifications for the same function 878 should be retired. In this case, or when it is felt for some other 879 reason that an existing standards track specification should be 880 retired, the IESG shall approve a change of status of the old 881 specification(s) to Historic. This recommendation shall be issued 882 with the same Last-Call and notification procedures used for any 883 other standards action. A request to retire an existing standard can 884 originate from a Working Group, an Area Director or some other 885 interested party. 887 6.5 Conflict Resolution and Appeals 889 IETF Working Groups are generally able to reach consensus, which 890 sometimes requires difficult compromises between or among different 891 technical proposals. However, there are times when even the most 892 reasonable and knowledgeable people are unable to agree. To achieve 893 the goals of openness and fairness, such conflicts must be resolved 894 by a process of open review and discussion. This section specifies 895 the procedures that shall be followed to deal with Internet standards 896 issues that cannot be resolved through the normal processes whereby 897 IETF Working Groups and other Internet standards process participants 898 ordinarily reach consensus. 900 An individual (whether a participant in the relevant Working Group or 901 not) may disagree with a Working Group recommendation based on his or 902 her belief that either (a) his or her own views have not been 903 adequately considered by the Working Group, or (b) the Working Group 904 has made an incorrect technical choice which places the quality 905 and/or integrity of the Working Group's product(s) in significant 906 jeopardy. The first issue is a difficulty with Working Group 907 process; the latter is an assertion of technical error. These two 908 types of disagreement are quite different, but both are handled by 909 the same process of review. 911 A person who disagrees with a Working Group recommendation shall 912 always first discuss the matter with the Working Group's chair(s), 913 who may involve other members of the Working Group (or the Working 914 Group as a whole) in the discussion. 916 If the disagreement cannot be resolved in this way, any of the 917 parties involved may bring it to the attention of the Area 918 Director(s) for the area in which the Working Group is chartered. 919 The Area Director(s) shall attempt to resolve the dispute. 921 If the disagreement cannot be resolved by the Area Director(s) any of 922 the parties involved may then appeal to the IESG as a whole. The 923 IESG shall then review the situation and attempt to resolve it in a 924 manner of its own choosing. 926 If the disagreement is not resolved to the satisfaction of the 927 parties at the IESG level, any of the parties involved may appeal the 928 decision to the IAB. The IAB shall then review the situation and 929 attempt to resolve it in a manner of its own choosing. 931 The IAB decision is final with respect to the question of whether or 932 not the Internet standards procedures have been followed and with 933 respect to all questions of technical merit. 935 Further recourse is available only in cases in which the procedures 936 themselves (i.e., the procedures described in this document) are 937 claimed to be inadequate or insufficient to the protection of the 938 rights of all parties in a fair and open Internet standards process. 939 Claims on this basis may be made to the Internet Society Board of 940 Trustees. The President of the Internet Society shall acknowledge 941 such an appeal within two weeks, and shall at the time of 942 acknowledgment advise the petitioner of the expected duration of the 943 Trustees' review of the appeal. The Trustees' decision upon 944 completion of their review shall be final with respect to all aspects 945 of the dispute. 947 All appeals must include a detailed and specific description of the 948 facts of the dispute. 950 At all stages of the appeals process, the individuals or bodies 951 responsible for making the decisions have the discretion to define 952 the specific procedures they will follow in the process of making 953 their decision. 955 In all cases a decision concerning the disposition of the dispute, 956 and the communication of that decision to the parties involved, must 957 be accomplished within a reasonable period of time. 959 [NOTE: These procedures intentionally and explicitly do not 960 establish a fixed maximum time period that shall be considered 961 "reasonable" in all cases. The Internet standards process places a 962 premium on consensus and efforts to achieve it, and deliberately 963 foregoes deterministically swift execution of procedures in favor of 964 a latitude within which more genuine technical agreements may be 965 reached.] 967 7. EXTERNAL STANDARDS AND SPECIFICATIONS 969 Many standards groups other than the IETF create and publish 970 standards documents for network protocols and services. When these 971 external specifications play an important role in the Internet, it is 972 desirable to reach common agreements on their usage -- i.e., to 973 establish Internet Standards relating to these external 974 specifications. 976 There are two categories of external specifications: 978 (1) Open Standards 980 Various national and international standards bodies, such as ANSI, 981 ISO, IEEE, and ITU-T, develop a variety of protocol and service 982 specifications that are similar to Technical Specifications 983 defined here. National and international groups also publish 984 "implementors' agreements" that are analogous to Applicability 985 Statements, capturing a body of implementation-specific detail 986 concerned with the practical application of their standards. All 987 of these are considered to be "open external standards" for the 988 purposes of the Internet standards process. 990 (2) Vendor Specifications 992 A vendor-proprietary specification that has come to be widely used 993 in the Internet may be treated by the Internet community as if it 994 were a "standard". Such a specification is not generally 995 developed in an open fashion, is typically proprietary, and is 996 controlled by the vendor or vendors that produced it. 998 7.1 Use of External Specifications 1000 To avoid conflict between competing versions of a specification, the 1001 Internet community will not standardize a specification that is 1002 simply an "Internet version" of an existing external specification 1003 unless an explicit cooperative arrangement to do so has been made. 1004 However, there are several ways in which an external specification 1005 that is important for the operation and/or evolution of the Internet 1006 may be adopted for Internet use. 1008 7.1.1 Incorporation of an Open Standard 1010 An Internet Standard TS or AS may incorporate an open external 1011 standard by reference. For example, many Internet Standards 1012 incorporate by reference the ANSI standard character set "ASCII" 1013 [2]. Whenever possible, the referenced specification shall be 1014 available online. 1016 7.1.2 Incorporation of a Vendor Specification 1018 Vendor-proprietary specifications may be incorporated by reference 1019 to a specific version of the vendor standard as long as the 1020 proprietor meets the requirements of section 8. If the vendor- 1021 proprietary specification is not widely and readily available, the 1022 IESG may request that it be published as an Informational RFC. 1024 The IESG generally should not favor a particular vendor's 1025 proprietary specification over the technically equivalent and 1026 competing specification(s) of other vendors by making any 1027 incorporated vendor specification "required" or "recommended". 1029 7.1.3 Assumption 1031 An IETF Working Group may start from an external specification and 1032 develop it into an Internet specification. This is acceptable if 1033 (1) the specification is provided to the Working Group in 1034 compliance with the requirements of section 9, and (2) change 1035 control has been conveyed to IETF by the original developer of the 1036 specification for the specification or for specifications derived 1037 from the original specification. 1039 8. NOTICES AND RECORD KEEPING 1041 Each of the organizations involved in the development and approval 1042 of Internet Standards shall publicly announce, and shall maintain 1043 a publicly accessible record of, every activity in which it 1044 engages, to the extent that the activity represents the 1045 prosecution of any part of the Internet standards process. For 1046 purposes of this section, the organizations involved in the 1047 development and approval of Internet Standards includes the IETF, 1048 the IESG, the IAB, all IETF working groups, and the Internet 1049 Society Board of Trustees. 1051 For IETF and working group meetings announcements shall be made by 1052 electronic mail to the IETF Announce mailing list and shall be 1053 made sufficiently far in advance of the activity to permit all 1054 interested parties to effectively participate. The announcement 1055 shall contain (or provide pointers to) all of the information that 1056 is necessary to support the participation of any interested 1057 individual. In the case of a meeting, for example, the 1058 announcement shall include an agenda that specifies the standards- 1059 related issues that will be discussed. 1061 The formal record of an organization's standards-related activity 1062 shall include at least the following: 1064 o the charter of the organization (or a defining document equivalent 1065 to a charter); 1066 o complete and accurate minutes of meetings; 1067 o the archives of the working group electronic mail mailing lists; 1068 and 1069 o all written contributions (in paper or electronic form) from 1070 participants that pertain to the organization's standards-related 1071 activity. 1073 As a practical matter, the formal record of all Internet standards 1074 process activities is maintained by the IETF Secretariat, and is the 1075 responsibility of the IESG Secretary except that each IETF working 1076 group is expected to maintain their own email list archive and must 1077 make a best effort to ensure that all traffic is captured and 1078 included in the archives. Internet drafts that have been removed 1079 (for any reason) from the Internet-Drafts directories shall be 1080 archived by the IETF Secretariat for the sole purpose of preserving 1081 an historical record of Internet standards activity and thus are not 1082 retrievable except in special circumstances. 1084 9. INTELLECTUAL PROPERTY RIGHTS 1086 9.1. General Policy 1088 In all matters of intellectual property rights and procedures, the 1089 intention is to benefit the Internet community and the public at 1090 large, while respecting the legitimate rights of others. 1092 9.2 Confidentiality Obligations 1093 No contribution that is subject to any requirement of confidentiality 1094 or any restriction on its dissemination may be considered in any part 1095 of the Internet standards process, and there must be no assumption of 1096 any confidentiality obligation with respect to any such contribution. 1098 9.3. Rights and Permissions 1100 In the course of standards work, the IETF receives contributions in 1101 various forms and from many persons. To best facilitate the 1102 dissemination of these contributions, it is necessary to understand 1103 any intellectual property rights (IPR) relating to the contributions. 1105 9.3.1. All Contributions 1107 By submission of a contribution, each person actually submitting the 1108 contribution is deemed to agree to the following terms and conditions 1109 on his own behalf and/or on behalf of the organization he represents. 1110 Where a submission identifies contributors in addition to the 1111 contributor(s) who provide the actual submission, the actual 1112 submitter(s)represent that each other named contributor was made 1113 aware of and agreed to accept the same terms and conditions on his 1114 own behalf and/or on behalf of any organization he may represent. 1116 l. Contributor grants a perpetual, non-exclusive, royalty-free, 1117 world-wide right and license to the ISOC under Contributor's 1118 copyrights to publish and distribute in any way the contribution, 1119 and to develop derivative works that are based on or incorporate 1120 all or part of the contribution, and that such derivative works 1121 will inherit the right and license of the original contribution. 1123 2. The contributor acknowledges that the IETF has no duty to publish 1124 or otherwise use or disseminate every contribution. 1126 3. The contributor grants permission to reference the name(s) and 1127 address(s) of the contributor. 1129 4. The contributor represents that there are no limits to the 1130 contributor's ability to make the grants and acknowledgments above 1131 that are reasonably and personally known to the contributor. 1133 5. The contributor represents that contributions and any derivative 1134 works properly acknowledge major contributors. 1136 By ratifying this description of the IETF process the Internet 1137 Society warrants that it will not inhibit the traditional open and 1138 free access to IETF documents for which license and right have 1139 been assigned according to the procedures set forth in this 1140 section, including Internet-Drafts and RFCs. This warrant is 1141 perpetual and will not be revoked by the Internet Society or its 1142 successors or assigns. 1144 9.3.2. Standards Track Documents 1146 (A) Where any patents, patent applications, or other proprietary 1147 rights are known, or claimed, with respect to any specification on 1148 the standards track, and brought to the attention of the IESG, the 1149 IESG shall not advance the specification without including in the 1150 document a note indicating the existence of such rights, or 1151 claimed rights. Where implementations are required before 1152 advancement of a specification, only implementations that have, by 1153 statement of the implementers, taken adequate steps to comply with 1154 any such rights, or claimed rights, shall be considered for the 1155 purpose of showing the adequacy of the specification. 1156 (B) The IESG disclaims any responsibility for identifying the 1157 existence of or for evaluating the applicability of any claimed 1158 copyrights, patents, patent applications, or other rights in the 1159 fulfilling of the its obligations under (A), and will take no 1160 position on the validity or scope of any such rights. 1161 (C) Where the IESG knows of rights, or claimed rights under (A), the 1162 IESG Secretary shall attempt to obtain from the claimant of such 1163 rights, a written assurance that upon approval by the IESG of the 1164 relevant Interment standards track specification(s), any party 1165 will be able to obtain the right to implement, use and distribute 1166 the technology or works when implementing, using or distributing 1167 technology based upon the specific specification(s) under openly 1168 specified, reasonable, non-discriminatory terms. The working 1169 group proposing the use of the technology with respect to which 1170 the proprietary rights are claimed may assist the IESG Secretary 1171 in this effort. The results of this procedure shall not affect 1172 advancement of a specification along the standards track, though 1173 the IESG may defer approval where a delay may facilitate the 1174 obtaining of such assurances. The results will, however, be 1175 recorded by the IESG Secretary, and made available online. The 1176 IESG may also direct that a summary of the results be included in 1177 any RFC published containing the specification. 1179 9.3.3 Determination of Reasonable and Non-discriminatory Terms 1181 The IESG will not make any explicit determination that the assurance 1182 of reasonable and non-discriminatory terms for the use of a 1183 technology has been fulfilled in practice. It will instead use the 1184 normal requirements for the advancement of Internet Standards to 1185 verify that the terms for use are reasonable. If the two unrelated 1186 implementations of the standard that are required to advance from 1187 Proposed to Draft have been produced by different organizations or 1188 individuals or if the "significant implementation and successful 1189 operational experience" required to advance from Draft to full 1190 Standard has been achieved the assumption is that the terms must be 1191 reasonable and to some degree, non-discriminatory. This assumption 1192 may be challenged during the Last-Call period. 1194 9.4. Notices 1196 (A) Standards track documents shall include the following notice: 1198 "The IETF takes no position on the validity or scope of any 1199 claimed rights to the implementation or use of the technology 1200 described in this document, nor that it has made any effort to 1201 identify any such intellectual property rights. Information on 1202 the IETF's procedures with respect to rights in standards and 1203 standards-related documentation can be found in BCP-xxx, dated 1204 in the future. Copies of claims of rights made available for 1205 publication and the result of an attempt made to obtain a 1206 general license or permission for the use of such proprietary 1207 rights by implementors or users of this specification can be 1208 found online at a location, or locations, nominated from time 1209 to time by the IESG Secretary." 1211 (B) The IETF encourages all interested parties to bring to its 1212 attention, at the earliest possible time, the existence of any 1213 intellectual property rights pertaining to Internet Standards. 1214 For this purpose, each standards document shall include the 1215 following invitation: 1217 "The IETF invites any interested party to bring to its 1218 attention any copyrights, patents or patent applications, or 1219 other proprietary rights which may cover technology that may be 1220 required to practice this standard. Please address the 1221 information to the IESG Secretary" 1223 (C) The following copyright notice and disclaimer shall be included 1224 in all ISOC standards-related documentation: 1226 "Copyright (year) The Internet Society. All Rights Reserved. 1227 This document may be copied and furnished to others without 1228 restriction of any kind. 1230 The permissions granted above are perpetual and will not be 1231 revoked by the Internet Society or its successors or assigns. 1233 The document may not be modified in any way, such as by 1234 removing this copyright notice or references to The Internet 1235 Society or other Internet organizations except as needed for 1236 the purpose of developing Internet standards in which case the 1237 procedures for copyrights defined in the Internet Standards 1238 process must be followed. 1240 This document and the information contained herein is provided 1241 on an "AS IS" basis and THE INTERNET SOCIETY DISCLAIMS ALL 1242 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 1243 ANY WARRANTY OF NON INFRINGEMENT OF THIRD PARTY RIGHTS OR ANY 1244 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1245 PARTICULAR PURPOSE." 1247 (D) Where the IESG is aware of proprietary rights claimed with 1248 respect to a standards track document, or the technology described 1249 or referenced therein, such document shall contain the following 1250 notice: 1252 "The IETF has been notified of intellectual property rights 1253 claimed in regard to some or all of the specification contained 1254 in this document. For more information consult the online list 1255 of claimed rights." 1257 10. ACKNOWLEDGMENTS 1259 There have been a number of people involved with the development of 1260 the documents defining the IETF standards process over the years. 1261 The process was first described in RFC 1310 then revised in RFC 1602 1262 before the current effort (which relies heavily on its predecessors). 1263 Specific acknowledgments must be extended to Lyman Chapin, Phill 1264 Gross and Christian Huitema as the editors of the previous versions, 1265 to Jon Postel and Dave Crocker for their inputs to those versions, 1266 and to Andy Ireland, Geoff Stewart, Jim Lampert and Dick Holleman for 1267 their reviews of the legal aspects of the procedures described 1268 herein. 1270 In addition much of the credit for the refinement of the details of 1271 the IETF processes belongs to the many members of the various 1272 incarnations of the POISED working group. 1274 11. SECURITY CONSIDERATIONS 1276 Security issues are not discussed in this memo. 1278 12. REFERENCES 1280 [1] Postel, J., "Internet Official Protocol Standards", STD 1, 1281 USC/Information Sciences Institute, November 1995. 1283 [2] ANSI, Coded Character Set -- 7-Bit American Standard Code for 1284 Information Interchange, ANSI X3.4-1986. 1286 [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 1287 USC/Information Sciences Institute, October 1994. 1289 [4] Postel, J., "Introduction to the STD Notes", RFC 1311, 1290 USC/Information Sciences Institute, March 1992. 1292 [5] Postel, J., "Instructions to RFC Authors", RFC 1543, 1293 USC/Information Sciences Institute, October 1993. 1295 [6] Postel, J., T. Li, and Y. Rekhter "Best Current Practices, RFC 1296 1818, USC/Information Sciences Institute, Cisco Systems, August 1297 1995. 1299 13 AUTHORS' ADDRESS 1301 Scott O. Bradner 1302 Harvard University 1303 Holyoke Center, Room 813 1304 1350 Mass. Ave. 1305 Cambridge, MA 02138 1306 USA +1 617 495 3864 1308 sob@harvard.edu 1310 APPENDIX A: DEFINITIONS 1312 IETF Area - A management division within the IETF. An Area consists 1313 of Working Groups related to a general topic such as routing. An 1314 Area is managed by one or two Area Directors. 1315 Area Director - The manager of an IETF Area. The Area Directors 1316 along with the IETF Chair comprise the Internet Engineering 1317 Steering Group (IESG). 1318 File Transfer Protocol (FTP) - An Internet application used to 1319 transfer files in a TCP/IP network. 1320 gopher - An Internet application used to interactively select and 1321 retrieve files in a TCP/IP network. 1322 Internet Architecture Board (IAB) - An appointed group that assists 1323 in the management of the IETF standards process. 1324 Internet Engineering Steering Group (IESG) - A group comprised of the 1325 IETF Area Directors and the IETF Chair. The IESG is responsible 1326 for the management, along with the IAB, of the IETF and is the 1327 standards approval board for the IETF. 1328 Last-Call - A public comment period used to gage the level of 1329 consensus about the reasonableness of a proposed standards action. 1331 (see section 6.1.2) 1332 online - Relating to information made available over the Internet. 1333 When referenced in this document material is said to be online 1334 when it is retrievable without restriction or undue fee using 1335 standard Internet applications such as anonymous FTP, gopher or 1336 the WWW. 1337 Working Group - A group chartered by the IESG and IAB to work on a 1338 specific specification, set of specifications or topic. 1340 APPENDIX B: GLOSSARY OF ACRONYMS 1342 ANSI: American National Standards Institute 1343 ARPA: (U.S.) Advanced Research Projects Agency 1344 AS: Applicability Statement 1345 FTP: File Transfer Protocol 1346 ASCII: American Standard Code for Information Interchange 1347 ITU-T: Telecommunications Standardization sector of the 1348 International Telecommunications Union (ITU), a UN 1349 treaty organization; ITU-T was formerly called CCITT. 1350 IAB: Internet Architecture Board 1351 IANA: Internet Assigned Numbers Authority 1352 IEEE: Institute of Electrical and Electronics Engineers 1353 ICMP: Internet Control Message Protocol 1354 IESG: Internet Engineering Steering Group 1355 IETF: Internet Engineering Task Force 1356 IP: Internet Protocol 1357 IRSG Internet Research Steering Group 1358 IRTF: Internet Research Task Force 1359 ISO: International Organization for Standardization 1360 ISOC: Internet Society 1361 MIB: Management Information Base 1362 OSI: Open Systems Interconnection 1363 RFC: Request for Comments 1364 TCP: Transmission Control Protocol 1365 TS: Technical Specification 1366 WWW: World Wide Web