idnits 2.17.1 draft-carpenter-rfc2026-changes-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1276. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1300. 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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. -- The draft header indicates that this document updates RFC2026, but the abstract doesn't seem to directly say this. It does mention RFC2026 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC2026, updated by this document, for RFC5378 checks: 1995-09-12) -- 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 16, 2008) is 5944 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) -- Looks like a reference, but probably isn't: '1' on line 827 -- Looks like a reference, but probably isn't: '4' on line 204 -- Looks like a reference, but probably isn't: '5' on line 1154 ** Obsolete normative reference: RFC 3932 (Obsoleted by RFC 5742) ** Obsolete normative reference: RFC 3978 (Obsoleted by RFC 5378) ** Obsolete normative reference: RFC 3979 (Obsoleted by RFC 8179) ** Obsolete normative reference: RFC 4071 (Obsoleted by RFC 8711) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 4844 (Obsoleted by RFC 8729) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft Univ. of Auckland 4 Updates: 2026 (if approved) January 16, 2008 5 Intended status: Best Current 6 Practice 7 Expires: July 19, 2008 9 Changes to the Internet Standards Process defined by RFC 2026 10 draft-carpenter-rfc2026-changes-02 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 19, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document defines a number of changes to RFC 2026, the basic 44 definition of the IETF standards process. While some of them are 45 definite changes to the rules, the intention is to preserve the main 46 intent of the original rules, while adapting them to experience and 47 current practice. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Overview of Changes . . . . . . . . . . . . . . . . . . . . . 3 53 3. Detailed Changes . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Change to Section 1.1 Internet Standards . . . . . . . . 4 55 3.2. Changes to Section 2.1 Requests for Comments (RFCs) . . . 4 56 3.3. Changes to Section 2.2 Internet-Drafts . . . . . . . . . 6 57 3.4. Changes to Section 3.1 Technical Specification (TS) . . . 7 58 3.5. Changes to Section 3.2 Applicability Statement (AS) . . . 8 59 3.6. Changes to Section 3.3 Requirement Levels . . . . . . . . 9 60 3.7. Changes to Section 4.1.1 Proposed Standard . . . . . . . 10 61 3.8. Changes to Section 4.1.2 Draft Standard . . . . . . . . . 11 62 3.9. Changes to Section 4.1.3 Internet Standard . . . . . . . 13 63 3.10. Changes to Section 4.2.2 Informational . . . . . . . . . 13 64 3.11. Changes to Section 4.2.3 Procedures for Experimental 65 and Informational RFCs . . . . . . . . . . . . . . . . . . 14 66 3.12. Changes to Section 4.2.4 Historic . . . . . . . . . . . . 16 67 3.13. Change to Section 5. BEST CURRENT PRACTICE (BCP) RFCs . . 17 68 3.14. Change to Section 6.1.1 Initiation of Action . . . . . . 17 69 3.15. Changes to Section 6.1.3 Publication . . . . . . . . . . 18 70 3.16. Changes to Section 6.2 Advancing in the Standards 71 Track . . . . . . . . . . . . . . . . . . . . . . . . . . 18 72 3.17. Changes to Section 6.5 Conflict Resolution and Appeals . 20 73 3.18. Change to Section 8. NOTICES AND RECORD KEEPING . . . . . 21 74 3.19. Change to Section 9. VARYING THE PROCESS . . . . . . . . 21 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 22 76 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 77 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 78 7. Change log [RFC Editor: please remove this section] . . . . . 22 79 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 80 8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 81 8.2. Informative References . . . . . . . . . . . . . . . . . . 23 82 Appendix A. Editorial Corrections . . . . . . . . . . . . . . . . 24 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 84 Intellectual Property and Copyright Statements . . . . . . . . . . 28 86 1. Introduction 88 BCP 9 [RFC2026] has been the basis for the IETF standards process for 89 many years. RFC 2026 has been in force since 1996, and has proved 90 robust and adequately flexible for the main part. However, some 91 provisions have led to practical difficulties or lack clarity. The 92 changes defined here are intended to tackle those issues. 94 This document is organized as follows. Firstly, there is an overview 95 of the changes. Then, the substantive changes are listed and 96 explained in textual sequence, illustrated with extracts from RFC 97 2026. Even single-word changes are listed if they are considered 98 substantive. Then, the mandatory sections of any RFC are included. 99 Finally, an Appendix lists purely editorial changes in RFC 2026. 101 2. Overview of Changes 103 This section summarizes the changes made to RFC 2026. Additional 104 explanation is included below, among the details of the changes. 105 o Rationalize the way in which standards are referenced and 106 numbered, by: 107 1. Assigning acronyms and numbers to standards at each stage of 108 the standards track, not just at the final stage; 109 2. Clarifying in all indexes that more recent standards obsolete 110 older ones regardless of their respective stages on the 111 standards track; 112 3. Formally abolishing the "STD 1" RFCs. 113 o Tidy up terminology and explanatory text in the standards track 114 definition. The changes are based on the existing three stage 115 standards track, with goal of adjusting the rules to make it fully 116 workable. 117 o Place responsibility for initiating the advancement or deprecation 118 of stalled documents back in the community rather than expecting 119 the IESG to do it. 120 o Formalize the reality that non-Working Group documents of any kind 121 may be processed by the IETF and approved by the IESG. 122 o Clarify the description of Applicability Statements. 123 o Collate in one place the principles about normative references. 124 o Give the IESG explicit authority to define the granularity of 125 interoperability testing. 126 o Simplify the variance process. 127 o Clarify that the appeals process applies to all decisions. 129 Additionally, there are several smaller changes that are intended 130 only for clarification and alignment with reality. An Appendix lists 131 purely editorial changes. 133 3. Detailed Changes 135 Extracts from RFC 2026 are presented verbatim in quotation marks, 136 preceded and followed by these markers: 137 "---------Begin Extract--------- 138 -----------End Extract---------" 139 Proposed changes are presented as plain text. 141 3.1. Change to Section 1.1 Internet Standards 143 "---------Begin Extract--------- 145 The Internet Standards Process described in this document is 146 concerned with all protocols, procedures, and conventions that are 147 used in or by the Internet, whether or not they are part of the 148 TCP/IP protocol suite. In the case of protocols developed and/or 149 standardized by non-Internet organizations, however, the Internet 150 Standards Process normally applies to the application of the protocol 151 or procedure in the Internet context, not to the specification of the 152 protocol itself. 154 -----------End Extract---------" 156 CHANGE: Replace the last sentence by: 158 In the case of protocols developed and/or standardized outside the 159 IETF, the Internet Standards Process may be applied to the use of the 160 protocol in the Internet context. Similarly, IETF protocols may be 161 cited in specifications developed elsewhere. The IETF will not 162 normally modify protocols developed elsewhere, and does not normally 163 permit its protocols to be modified elsewhere. 165 RATIONALE: The previous text did not allow for the complexity of 166 interaction between IETF and non-IETF protocols, nor set the proper 167 context for liaison relationships. 169 3.2. Changes to Section 2.1 Requests for Comments (RFCs) 171 "---------Begin Extract--------- 173 The status of Internet protocol and service specifications is 174 summarized periodically in an RFC entitled "Internet Official 175 Protocol Standards" [1]. This RFC shows the level of maturity and 176 other helpful information for each Internet protocol or service 177 specification (see section 3). 179 -----------End Extract---------" 180 CHANGE: Delete this paragraph and all other references to STD1. 182 RATIONALE: This was written before a hyperlinked index was available 183 on line. 185 "---------Begin Extract--------- 187 Some RFCs document Internet Standards. These RFCs form the 'STD' 188 subseries of the RFC series [4]. When a specification has been 189 adopted as an Internet Standard, it is given the additional label 190 "STDxxx", but it keeps its RFC number and its place in the RFC 191 series. (see section 4.1.3) 193 -----------End Extract---------" 195 CHANGE: Replace the last sentence by: 197 When a specification has been approved for publication on the 198 standards track, it is assigned a Standard Number (e.g. 10) and a 199 Standard Acronym (e.g. SMTP), independent of its RFC number and its 200 place in the RFC series. As a specification changes status within 201 the standards track, its Standard Number remains the same, and is 202 associated with the most recent version of the specification, 203 regardless of its maturity level. Historically, RFCs that document 204 Internet Standards formed the 'STD' subseries of the RFC series [4]. 206 Acronyms may comprise sub-acronyms (e.g. SMTP/Submission) in the 207 case of multipart standards. 209 RATIONALE: The fact that only full Standards receive an STD number, 210 and possibly an acronym, is today a major source of confusion to 211 users of the standards, since these numbers and acronyms are not 212 associatd with PS and DS documents. Users do not, in fact, know 213 where to look for the latest standard, since a DS may obsolete an 214 STD, and a PS may obsolete either. It would be much less confusing 215 if a new or existing acronym was assigned as part of the initial 216 standards action (thus RFC 2821 would have been associated with 217 SMTP). Similarly, the STD number should be assigned at PS stage for 218 simpler tracking - thus RFC 2821 would also be known as PS10, 219 replacing the older RFC 821 previously known as STD10. (Also see 220 comments on section 4.1.3.) 222 "---------Begin Extract--------- 223 Not all specifications of protocols or services for the Internet 224 should or will become Internet Standards or BCPs. Such non-standards 225 track specifications are not subject to the rules for Internet 226 standardization. Non-standards track specifications may be published 227 directly as "Experimental" or "Informational" RFCs at the discretion 228 of the RFC Editor in consultation with the IESG (see section 4.2). 230 -----------End Extract---------" 232 CHANGE: Replace this paragraph by: 234 Not all specifications of protocols or services for the Internet 235 should or will become Internet Standards or BCPs. The various paths 236 to publication are defined in [RFC4844]. Non-standards track IETF 237 specifications may be published as "Experimental" or "Informational" 238 RFCs if approved by the IESG. When non-standards track 239 specifications are produced within the IETF, they are subject to the 240 rules of the IETF except those specific to Section 5 and Sections 6.1 241 through 6.4 of [RFC2026]. 243 RATIONALE: IETF Experimental or Informational RFCs are distinct from 244 independent submissions to the RFC Editor, which are now processed 245 under [RFC4846] and [RFC3932], and from IAB [RFC4845] and IRTF 246 documents. Also, we want all IETF documents to be subject to many of 247 our rules, such as the IPR rules and the appeals process. 249 3.3. Changes to Section 2.2 Internet-Drafts 251 "---------Begin Extract--------- 253 During the development of a specification, draft versions of the 254 document are made available for informal review and comment by 255 placing them in the IETF's "Internet-Drafts" directory, which is 256 replicated on a number of Internet hosts. This makes an evolving 257 working document readily available to a wide audience, facilitating 258 the process of review and revision. 260 An Internet-Draft that is published as an RFC, or that has remained 261 unchanged in the Internet-Drafts directory for more than six months 262 without being recommended by the IESG for publication as an RFC, is 263 simply removed from the Internet-Drafts directory. 265 -----------End Extract---------" 267 CHANGE: Replace 'recommended' by 'considered'. 269 RATIONALE: Expiry is inhibited when a draft enters IESG 270 consideration, not when it is approved. 272 CHANGE: Add the following two paragraphs: 274 Internet-Drafts are also removed from the directory after publication 275 as an RFC. However, all versions of all Internet-Drafts are retained 276 in the IETF archive for legal reasons and may be subject to subpoena. 277 Authors should be aware that expired Internet-Drafts are unofficially 278 available in many places. Authors may request expired Internet- 279 Drafts to be removed from such availability, but this is outside the 280 control of the IETF. 282 The published RFC will not be textually identical to the final 283 version of the Internet-Draft. Not only will the required 284 boilerplate text be finalized; the RFC Editor will also make 285 editorial corrections, and apply minor technical changes approved by 286 the sponsoring Area Director or the IESG. 288 RATIONALE: Aligning with reality. 290 3.4. Changes to Section 3.1 Technical Specification (TS) 292 "---------Begin Extract--------- 294 A Technical Specification is any description of a protocol, service, 295 procedure, convention, or format. 297 -----------End Extract---------" 299 CHANGE: Add the following paragraph: 301 Thus a TS is not limited to defining a protocol; it may for example 302 define an Application Programming Interface (i.e. a convention) or a 303 data definition such as a MIB or an IANA registry (i.e. a format). 304 However, a TS must be both implementable and testable. 306 RATIONALE: Although clearly within the intended scope of RFC 2026, 307 these types of TS have been a source of debate and deserve 308 clarification. Also see later comments on implementation reports. 310 "---------Begin Extract--------- 312 A TS shall include a statement of its scope and the general intent 313 for its use (domain of applicability). Thus, a TS that is inherently 314 specific to a particular context shall contain a statement to that 315 effect. However, a TS does not specify requirements for its use 316 within the Internet; these requirements, which depend on the 317 particular context in which the TS is incorporated by different 318 system configurations, are defined by an Applicability Statement. 320 -----------End Extract---------" 322 CHANGE: Delete the 3rd sentence. 324 RATIONALE: The last sentence very unclear. Is it saying that a TS 325 doesn't contain operational guidelines? Quite often, the Operations 326 Area comments on a draft TS are, in effect, asking for operational 327 guidelines. If a TS refers to a timeout or some other behavioural 328 parameter, Operations people may insist on specifying a default value 329 and guidance about when to change the default. But the above 330 sentence could suggest that this belongs in a separate AS. In 331 practice, few authors separate such things from the basic 332 specification. The simplest resolution is to drop the whole 333 sentence. 335 3.5. Changes to Section 3.2 Applicability Statement (AS) 337 "---------Begin Extract--------- 339 An Applicability Statement specifies how, and under what 340 circumstances, one or more TSs may be applied to support a particular 341 Internet capability. An AS may specify uses for TSs that are not 342 Internet Standards, as discussed in Section 7. 344 -----------End Extract---------" 346 CHANGE: Insert the following after this paragraph: 348 The following description refers to an AS as if it were a separate 349 document. In practice, the applicability information is commonly 350 embedded in the relevant TS. 352 RATIONALE: The community really doesn't have the habit of writing 353 separate AS documents; it's rare, and very rare in WG charters. Such 354 a document has more significance than an Informational document, but 355 can only be placed on the standards track along with relevant TSs, 356 because it can't be implemented and tested in itself. 358 "---------Begin Extract--------- 360 The broadest type of AS is a comprehensive conformance specification, 361 commonly called a "requirements document", for a particular class of 362 Internet systems, such as Internet routers or Internet hosts. 364 -----------End Extract---------" 366 CHANGE: Delete this paragraph. 368 RATIONALE: Firstly, this is not the community's normal understanding 369 of a conformance specification, which generally refers to product 370 certification. Secondly, in the IETF today, we use the word 371 "requirements" much more broadly, typically for an Informational 372 document describing the problem to be solved by one or more TS 373 documents. 375 "---------Begin Extract--------- 377 An AS may not have a higher maturity level in the standards track 378 than any standards-track TS on which the AS relies (see section 4.1). 379 For example, a TS at Draft Standard level may be referenced by an AS 380 at the Proposed Standard or Draft Standard level, but not by an AS at 381 the Standard level. 383 -----------End Extract---------" 385 CHANGE: Move this paragraph to a new general section on normative 386 reference requirements, and rewrite as: 388 A standards-track document should not have a higher maturity level in 389 the standards track than any standards-track document on which it 390 relies normatively. 392 RATIONALE: There is nothing specific to ASes in this rule; it is 393 applied globally wherever normative references occur. See comment 394 below on 4.2.4. 396 3.6. Changes to Section 3.3 Requirement Levels 398 "---------Begin Extract--------- 400 An AS shall apply one of the following "requirement levels" to each 401 of the TSs to which it refers: 403 -----------End Extract---------" 405 CHANGE: Replace by: 407 A specification or BCP shall apply one of the following "requirement 408 levels" to each specification or BCP to which it refers: 410 CHANGE: Throughout the following clauses (a) through (e), read 411 "referenced specification or BCP" for each occurrence of "referenced 412 TS", and "referring specification or BCP" for each occurrence of 413 "AS". 415 RATIONALE: There is nothing specific to AS vs TS vs BCP in these 416 requirement levels. 418 "---------Begin Extract--------- 420 The "Official Protocol Standards" RFC (STD1) lists a general 421 requirement level for each TS, using the nomenclature defined in this 422 section. This RFC is updated periodically. In many cases, more 423 detailed descriptions of the requirement levels of particular 424 protocols and of individual features of the protocols will be found 425 in appropriate ASs. 427 -----------End Extract---------" 429 CHANGE: Replace the first two sentences by: 431 The RFC Editor web site displays the current maturity level of each 432 standards track document, as well as the status of all RFCs. 434 RATIONALE: Aligning with reality. 436 3.7. Changes to Section 4.1.1 Proposed Standard 438 "---------Begin Extract--------- 440 Implementors should treat Proposed Standards as immature 441 specifications. It is desirable to implement them in order to gain 442 experience and to validate, test, and clarify the specification. 443 However, since the content of Proposed Standards may be changed if 444 problems are found or better solutions are identified, deploying 445 implementations of such standards into a disruption-sensitive 446 environment is not recommended. 448 -----------End Extract---------" 450 CHANGES: 452 1. Rename PS as Preliminary Standard. 454 2. Add the following text: 456 Preliminary Standard is indeed the preliminary level. Implementors 457 should be aware that a PS may be revised or even withdrawn. However, 458 it is nevertheless common to use PS implementations operationally. 459 Many documents spend their entire active life as PS. Certain types 460 of specification, e.g. data formats such as MIBs, are likely to be 461 recycled at PS as they evolve rather than being promoted. This may 462 be a result of complexity, or due to intrinsic difficulties in 463 interoperability testing and normative dependencies. 465 RATIONALE: It is well known that to a large extent the warnings about 466 PS have been ignored, and that the Internet "runs on Proposed 467 Standards." Also, as the MIB doctors have observed, some types of 468 specification may benefit from being recycled at this level rather 469 than being "promoted." The name change makes the status more 470 immediately obvious. 472 3.8. Changes to Section 4.1.2 Draft Standard 474 CHANGE: Rename as Deployable Standard. 476 RATIONALE: Just as "proposed" standard is effectively interpreted as 477 "preliminary", "draft standard" is effectively interpreted as much 478 more than a draft. Also we have the problem of confusion with 479 "Internet-Draft." The name change reduces this risk of confusion and 480 clarifies the factual status. 482 "---------Begin Extract--------- 484 A specification from which at least two independent and interoperable 485 implementations from different code bases have been developed, and 486 for which sufficient successful operational experience has been 487 obtained, may be elevated to the "Draft Standard" level. For the 488 purposes of this section, "interoperable" means to be functionally 489 equivalent or interchangeable components of the system or process in 490 which they are used. If patented or otherwise controlled technology 491 is required for implementation, the separate implementations must 492 also have resulted from separate exercise of the licensing process. 493 Elevation to Draft Standard is a major advance in status, indicating 494 a strong belief that the specification is mature and will be useful. 496 The requirement for at least two independent and interoperable 497 implementations applies to all of the options and features of the 498 specification. 500 -----------End Extract---------" 502 CHANGE: Add the following paragraph: 504 The IESG is empowered (subject to community consensus) to define the 505 level of granularity required in interpreting this requirement, and 506 how to demonstrate interoperability for specifications that do not 507 define protocols or have a single-ended nature. 509 RATIONALE: At least the four significant questions below arise 510 repeatedly in interpreting this rule. It seems best to leave this to 511 the IESG and its assessment of community consensus, rather than to 512 set rigid rules. 514 1. What is a "feature"? This can be interpreted in many ways. For 515 a TLV field is every separate type code a feature? Is every use 516 of a normative keyword [RFC2119] a feature? 517 2. Is it acceptable if features A and B are shown to be 518 interoperable between implementations X and Y, and features C and 519 D are shown to be interoperable between implentations P and Q? 520 In that case we have shown interoperability of features A, B, C 521 and D but have not shown that any implementation successfully 522 interoperates with all of them. 524 Since the goal is to use running code to verify that the 525 specification in question enables interoperability, not to test 526 whether the implementations comply, the answer appears to be yes. 527 Also note that as far as validating the specification is 528 concerned, all features must be tested, regardless of whether 529 they are optional, recommended or mandatory to implement or to 530 use. 531 3. Is it acceptable if both implementations X and Y show 532 interoperability with implementation Q, but the implementor of Q 533 is not party to the tests and does not make any statements about 534 features supported? In other words Q has merely served as an 535 active mirror in the tests. 536 4. How should we handle the issue of "single-ended" technical 537 specifications such as data formats, where there is no new 538 protocol whose interoperation we can verify? A practical 539 solution for MIBs has been documented [RFC2438] and some 540 generalisation of this seems to be needed. 542 "---------Begin Extract--------- 544 In cases in which one or more options or features 545 have not been demonstrated in at least two interoperable 546 implementations, the specification may advance to the Draft Standard 547 level only if those options or features are removed. 549 The Working Group chair is responsible for documenting the specific 550 implementations which qualify the specification for Draft or Internet 551 Standard status along with documentation about testing of the 552 interoperation of these implementations. The documentation must 553 include information about the support of each of the individual 554 options and features. This documentation should be submitted to the 555 Area Director with the protocol action request. (see Section 6) 557 -----------End Extract---------" 559 CHANGE: Add this sentence: 561 The Area Director and the IESG must be satisfied that the the level 562 of detail in such implementation reports is sufficient to satisfy the 563 interoperation requirements. 565 RATIONALE: Examining the database of reports collected over the years 566 at , the quality is 567 highly variable and some are very sparse and uninformative. 569 3.9. Changes to Section 4.1.3 Internet Standard 571 "---------Begin Extract--------- 573 A specification that reaches the status of Standard is assigned a 574 number in the STD series while retaining its RFC number. 576 -----------End Extract---------" 578 CHANGE: Replace by: 580 A specification that reaches the status of Standard is assigned the 581 same Standard number as its predecessors at PS and DS status, as well 582 as an RFC number. 584 RATIONALE: see above re section 2.1. 586 3.10. Changes to Section 4.2.2 Informational 588 "---------Begin Extract--------- 590 An "Informational" specification is published for the general 591 information of the Internet community, and does not represent an 592 Internet community consensus or recommendation. The Informational 593 designation is intended to provide for the timely publication of a 594 very broad range of responsible informational documents from many 595 sources, subject only to editorial considerations and to verification 596 that there has been adequate coordination with the standards process 597 (see section 4.2.3). 599 -----------End Extract---------" 601 CHANGE: Add: 603 In practice, some Informational and Experimental RFCs that are 604 published following IESG Approval are very close to being a TS or AS 605 and are evaluated almost as carefully. Others are more general. 607 RATIONALE: Aligning with reality. In particular, requirements 608 documents that will guide future work deserve more careful review by 609 the IESG than other Informational RFCs. 611 "---------Begin Extract--------- 613 Specifications that have been prepared outside of the Internet 614 community and are not incorporated into the Internet Standards 615 Process by any of the provisions of section 10 may be published as 616 Informational RFCs, with the permission of the owner and the 617 concurrence of the RFC Editor. 619 -----------End Extract---------" 621 CHANGE: Replace by: 623 As mentioned above, some RFCs are published outside the IETF process; 624 see [RFC4844] and [RFC4846]. 626 RATIONALE: Should not duplicate this material, to avoid 627 inconsistency. 629 3.11. Changes to Section 4.2.3 Procedures for Experimental and 630 Informational RFCs 632 "---------Begin Extract--------- 634 Unless they are the result of IETF Working Group action, documents 635 intended to be published with Experimental or Informational status 636 should be submitted directly to the RFC Editor. 638 -----------End Extract---------" 640 CHANGE: Replace by: 642 Documents intended to be published with Experimental or Informational 643 status via the IETF process, that are not the result of IETF Working 644 Group action, must be sponsored by an Area Director, in the same way 645 as a standards track or BCP document that is not the result of IETF 646 Working Group action, using procedures defined by the IESG. 648 Documents intended to be published independently of the IETF with 649 Experimental or Informational status should be submitted directly to 650 the RFC Editor. 652 RATIONALE: Aligning with reality. 654 "---------Begin Extract--------- 655 The RFC Editor will 656 publish any such documents as Internet-Drafts which have not already 657 been so published. In order to differentiate these Internet-Drafts 658 they will be labeled or grouped in the I-D directory so they are 659 easily recognizable. The RFC Editor will wait two weeks after this 660 publication for comments before proceeding further. The RFC Editor 661 is expected to exercise his or her judgment concerning the editorial 662 suitability of a document for publication with Experimental or 663 Informational status, and may refuse to publish a document which, in 664 the expert opinion of the RFC Editor, is unrelated to Internet 665 activity or falls below the technical and/or editorial standard for 666 RFCs. 668 -----------End Extract---------" 670 CHANGE: Replace by: 672 The RFC Editor will publish any such documents in accordance with 673 [RFC4846]. 675 RATIONALE: Should not duplicate this material, to avoid 676 inconsistency. 678 "---------Begin Extract--------- 680 To ensure that the non-standards track Experimental and Informational 681 designations are not misused to circumvent the Internet Standards 682 Process, the IESG and the RFC Editor have agreed that the RFC Editor 683 will refer to the IESG any document submitted for Experimental or 684 Informational publication which, in the opinion of the RFC Editor, 685 may be related to work being done, or expected to be done, within the 686 IETF community. The IESG shall review such a referred document 687 within a reasonable period of time, and recommend either that it be 688 published as originally submitted or referred to the IETF as a 689 contribution to the Internet Standards Process. 691 -----------End Extract---------" 693 CHANGE: Replace by: 695 To ensure that the independent submissions track is not misused to 696 circumvent the Internet Standards Process, the IESG, the IAB and the 697 RFC Editor have agreed that the RFC Editor will refer to the IESG any 698 document submitted for Experimental or Informational publication 699 which, in the opinion of the RFC Editor, may be related to work being 700 done, or expected to be done, within the IETF community. The IESG 701 shall review such a referred document within a reasonable period of 702 time, and recommend a course of action to the RFC Editor [RFC4846], 704 [RFC3932]. 706 RATIONALE: Aligning with reality. 708 3.12. Changes to Section 4.2.4 Historic 710 "---------Begin Extract--------- 712 A specification that has been superseded by a more recent 713 specification or is for any other reason considered to be obsolete is 714 assigned to the "Historic" level. (Purists have suggested that the 715 word should be "Historical"; however, at this point the use of 716 "Historic" is historical.) 718 -----------End Extract---------" 720 CHANGE: Replace this paragraph by: 722 A specification that has been superseded by a more recent 723 specification or is for any other reason considered to be obsolete 724 may be assigned to the "Historic" level by the IESG. (Purists have 725 suggested that the word should be "Historical"; however, at this 726 point the use of "Historic" is historical.) 728 RATIONALE: Aligning with reality. 730 "---------Begin Extract--------- 732 Note: Standards track specifications normally must not depend on 733 other standards track specifications which are at a lower maturity 734 level or on non standards track specifications other than referenced 735 specifications from other standards bodies. (See Section 7.) 737 -----------End Extract---------" 739 CHANGE: move this paragraph to the new section proposed in the 740 comments on section 3.2. Also add there: 742 Standards track and BCP documents must, and other documents should, 743 distinguish between normative and informative references. Normative 744 references are those that are required reading to correctly 745 understand and implement a specification. Procedures exist to allow 746 normative references to less mature documents [RFC3967], [RFC4897]. 748 RATIONALE: we need to clarify and collate the rules about normative 749 references. 751 3.13. Change to Section 5. BEST CURRENT PRACTICE (BCP) RFCs 753 "---------Begin Extract--------- 755 While it is recognized that entities such as the IAB and IESG are 756 composed of individuals who may participate, as individuals, in the 757 technical work of the IETF, it is also recognized that the entities 758 themselves have an existence as leaders in the community. As leaders 759 in the Internet technical community, these entities should have an 760 outlet to propose ideas to stimulate work in a particular area, to 761 raise the community's sensitivity to a certain issue, to make a 762 statement of architectural principle, or to communicate their 763 thoughts on other matters. The BCP subseries creates a smoothly 764 structured way for these management entities to insert proposals into 765 the consensus-building machinery of the IETF while gauging the 766 community's view of that issue. 768 -----------End Extract---------" 770 CHANGE: Add: 772 Such BCPs are subject to the normal process of IETF review and IESG 773 approval. 775 RATIONALE: Important clarification. 777 3.14. Change to Section 6.1.1 Initiation of Action 779 "---------Begin Extract--------- 781 A specification that is intended to enter or advance in the Internet 782 standards track shall first be posted as an Internet-Draft (see 783 section 2.2) unless it has not changed since publication as an RFC. 784 It shall remain as an Internet-Draft for a period of time, not less 785 than two weeks, that permits useful community review, after which a 786 recommendation for action may be initiated. 788 A standards action is initiated by a recommendation by the IETF 789 Working group responsible for a specification to its Area Director, 790 copied to the IETF Secretariat or, in the case of a specification not 791 associated with a Working Group, a recommendation by an individual to 792 the IESG. 794 -----------End Extract---------" 796 CHANGE: Replace second paragraph by: 798 A standards action is initiated by a recommendation by the IETF 799 Working group responsible for a specification to an Area Director, 800 copied to the IETF Secretariat or, in the case of a specification not 801 associated with a Working Group, an agreement by an Area Director to 802 recommend a specification to the IESG. The IESG defines the 803 procedures for this. An Area Director will normally be recused from 804 sponsoring a document to which he or she has made a substantial 805 contribution. 807 RATIONALE: Aligning with reality. 809 3.15. Changes to Section 6.1.3 Publication 811 "---------Begin Extract--------- 813 An official summary of standards actions completed and pending shall 814 appear in each issue of the Internet Society's newsletter. This 815 shall constitute the "publication of record" for Internet standards 816 actions. 818 -----------End Extract---------" 820 CHANGE: Delete this. 822 RATIONALE: Pointless since the web came along. 824 "---------Begin Extract--------- 826 The RFC Editor shall publish periodically an "Internet Official 827 Protocol Standards" RFC [1], summarizing the status of all Internet 828 protocol and service specifications. 830 -----------End Extract---------" 832 CHANGE: Delete this. 834 RATIONALE: Pointless since the web came along. 836 3.16. Changes to Section 6.2 Advancing in the Standards Track 838 "---------Begin Extract--------- 839 Change of status shall result in republication of the specification 840 as an RFC, except in the rare case that there have been no changes at 841 all in the specification since the last publication. Generally, 842 desired changes will be "batched" for incorporation at the next level 843 in the standards track. However, deferral of changes to the next 844 standards action on the specification will not always be possible or 845 desirable; for example, an important typographical error, or a 846 technical error that does not represent a change in overall function 847 of the specification, may need to be corrected immediately. In such 848 cases, the IESG or RFC Editor may be asked to republish the RFC (with 849 a new number) with corrections, and this will not reset the minimum 850 time-at-level clock. 852 -----------End Extract---------" 854 CHANGE: Add this: 856 Note that the RFC Editor maintains errata for published RFCs. 858 RATIONALE: Important clarification. 860 "---------Begin Extract--------- 862 When a standards-track specification has not reached the Internet 863 Standard level but has remained at the same maturity level for 864 twenty-four (24) months, and every twelve (12) months thereafter 865 until the status is changed, the IESG shall review the viability of 866 the standardization effort responsible for that specification and the 867 usefulness of the technology. Following each such review, the IESG 868 shall approve termination or continuation of the development effort, 869 at the same time the IESG shall decide to maintain the specification 870 at the same maturity level or to move it to Historic status. This 871 decision shall be communicated to the IETF by electronic mail to the 872 IETF Announce mailing list to allow the Internet community an 873 opportunity to comment. This provision is not intended to threaten a 874 legitimate and active Working Group effort, but rather to provide an 875 administrative mechanism for terminating a moribund effort. 877 -----------End Extract---------" 879 CHANGE: Replace this by: 881 In normal practice, the IESG may be requested to advance any 882 standards-track specification that has been long enough in grade, or 883 to replace or deprecate any IETF document, by the relevant Working 884 Group if it exists, or by one or more individual participants if not. 886 Additionally, when a standards-track specification has not reached 887 the highest level, but has remained at the same maturity level for at 888 least the required minimum period plus one year, any participant may 889 request the IESG to review the viability of the standardization 890 effort responsible for that specification and the usefulness of the 891 technology. Such a request should include a proposed action, with a 892 justification and suitable Internet-Drafts if appropriate. Following 893 each such request, the IESG shall approve termination or continuation 894 of the development effort. At the same time the IESG shall decide 895 whether to maintain the specification at the same maturity level or 896 to move it to Historic status. This intention shall be communicated 897 to the IETF by electronic mail to the IETF Announce mailing list to 898 allow the Internet community an opportunity to comment. This 899 provision is not intended to threaten a legitimate and active Working 900 Group effort, but rather to provide an administrative mechanism for 901 reviving or terminating a moribund effort, and for marking obsolete 902 specifications as such. 904 RATIONALE: This shifts the responsibility to initiate advancement or 905 deprecation of specifications to the community. No IESG has ever had 906 the cycles to initiate such actions, and it is much better practice 907 to delegate this responsibility. It also clarifies the difference 908 between normal advancement and the handling of moribund efforts. 910 3.17. Changes to Section 6.5 Conflict Resolution and Appeals 912 "---------Begin Extract--------- 914 Disputes are possible at various stages during the IETF process. As 915 much as possible the process is designed so that compromises can be 916 made, and genuine consensus achieved, however there are times when 917 even the most reasonable and knowledgeable people are unable to 918 agree. To achieve the goals of openness and fairness, such conflicts 919 must be resolved by a process of open review and discussion. This 920 section specifies the procedures that shall be followed to deal with 921 Internet standards issues that cannot be resolved through the normal 922 processes whereby IETF Working Groups and other Internet Standards 923 Process participants ordinarily reach consensus. 925 -----------End Extract---------" 927 CHANGES: Add the following after the above paragraph: 929 All decisions taken by the IESG and by Working Group chairs and other 930 persons appointed to IETF roles by the IESG are subject to these 931 procedures. 933 RATIONALE: It's possible to read the current sub-section 6.5 as 934 applying only to WG and IESG actions described in section 6. The 935 IESG and IAB have preferred to read it as applying to any decision 936 whatever. 938 3.18. Change to Section 8. NOTICES AND RECORD KEEPING 940 "---------Begin Extract--------- 942 As a practical matter, the formal record of all Internet Standards 943 Process activities is maintained by the IETF Secretariat, and is the 944 responsibility of the IETF Secretariat except that each IETF Working 945 Group is expected to maintain their own email list archive and must 946 make a best effort to ensure that all traffic is captured and 947 included in the archives. 949 -----------End Extract---------" 951 CHANGE: Replace by: 953 As a practical matter, the formal record of all Internet Standards 954 Process activities is maintained by the IETF Secretariat, and is the 955 responsibility of the IETF Secretariat. Each IETF Working Group must 956 maintain an email list archive, which may be that maintained by the 957 Secretariat, and must make a best effort to ensure that all relevant 958 and applicable traffic is captured and included in the archives. It 959 is legitimate to delete irrelevant traffic such as unsolicited 960 commercial email. 962 RATIONALE: Aligning with reality. 964 3.19. Change to Section 9. VARYING THE PROCESS 966 "---------Begin Extract--------- 968 The proposed variance must detail the problem perceived, explain the 969 precise provision of this document which is causing the need for a 970 variance, and the results of the IESG's considerations including 971 consideration of points (a) through (d) in the previous paragraph. 972 The proposed variance shall be issued as an Internet Draft. The IESG 973 shall then issue an extended Last-Call, of no less than 4 weeks, to 974 allow for community comment upon the proposal. 976 -----------End Extract---------" 978 CHANGE: Add the following text: 980 Alternatively, the proposed variance may be included in the document 981 concerned, in a separate section named "Process Variance". The 982 extended Last-Call requirement will still apply. 984 RATIONALE: The present process is clumsy. Why should the variance 985 not be built into the document that will benefit from it? 987 4. Security Considerations 989 This document has no security implications for the Internet. 991 5. IANA Considerations 993 This document requires no action by the IANA. 995 6. Acknowledgements 997 This document was initially constructed on the basis of an earlier 998 draft, draft-carpenter-rfc2026-critique. Useful comments on that 999 draft were made by Eric Gray, Luc Pardon, Pekka Savola, Magnus 1000 Westerlund, Jeff Hutzelman, Mike Heard, Alfred Hoenes and others. 1002 Later comments and suggestions were made by Douglas Otis, Robert 1003 Sayre, Robert Elz, and others. Russ Housley made a very thorough 1004 review. 1006 Many suggestions in the present document are far from original and 1007 many people deserve acknowledgement. Discussions in the former 1008 NEWTRK working group and various drafts written in the context of 1009 that WG or following its closure, and in the former PESCI design 1010 team, were particularly influential. A bibliography of those drafts 1011 has not been provided, since they have all expired under Section 2.2 1012 of [RFC2026]. 1014 This document was produced using the xml2rfc tool [RFC2629]. 1016 7. Change log [RFC Editor: please remove this section] 1018 draft-carpenter-rfc2026-changes-02: clarifications and editorial 1019 updates following AD review; removed editorial questions and 1020 comments; categorised as BCP9 update, 2008-01-15 1022 draft-carpenter-rfc2026-changes-01: minor updates (sub-acronyms, 1023 tightening argument about mandatory-to-implement features, 1024 editorial), 2007-09-25 1026 draft-carpenter-rfc2026-changes-00: original version, extracted and 1027 modified from draft-carpenter-rfc2026-critique, 2007-06-27 1029 8. References 1031 8.1. Normative References 1033 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 1034 3", BCP 9, RFC 2026, October 1996. 1036 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1037 Requirement Levels", BCP 14, RFC 2119, March 1997. 1039 [RFC2438] O'Dell, M., Alvestrand, H., Wijnen, B., and S. Bradner, 1040 "Advancement of MIB specifications on the IETF Standards 1041 Track", BCP 27, RFC 2438, October 1998. 1043 [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: 1044 Procedures", BCP 92, RFC 3932, October 2004. 1046 [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track 1047 Documents may Refer Normatively to Documents at a Lower 1048 Level", BCP 97, RFC 3967, December 2004. 1050 [RFC3978] Bradner, S., "IETF Rights in Contributions", BCP 78, 1051 RFC 3978, March 2005. 1053 [RFC3979] Bradner, S., "Intellectual Property Rights in IETF 1054 Technology", BCP 79, RFC 3979, March 2005. 1056 [RFC4071] Austein, R. and B. Wijnen, "Structure of the IETF 1057 Administrative Support Activity (IASA)", BCP 101, 1058 RFC 4071, April 2005. 1060 [RFC4897] Klensin, J. and S. Hartman, "Handling Normative References 1061 to Standards-Track Documents", BCP 97, RFC 4897, 1062 June 2007. 1064 8.2. Informative References 1066 [I-D.rfc-editor-rfc2223bis] 1067 Reynolds, J. and R. Braden, "Instructions to Request for 1068 Comments (RFC) Authors", draft-rfc-editor-rfc2223bis-08 1069 (work in progress), July 2004. 1071 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 1072 June 1999. 1074 [RFC4844] Daigle, L. and Internet Architecture Board, "The RFC 1075 Series and RFC Editor", RFC 4844, July 2007. 1077 [RFC4845] Daigle, L. and Internet Architecture Board, "Process for 1078 Publication of IAB RFCs", RFC 4845, July 2007. 1080 [RFC4846] Klensin, J. and D. Thaler, "Independent Submissions to the 1081 RFC Editor", RFC 4846, July 2007. 1083 Appendix A. Editorial Corrections 1085 This Appendix lists simple editorial issues in RFC 2026 that have 1086 been noted during the preparation of the present document. 1088 "---------Begin Extract--------- 1090 Abstract 1092 This memo documents the process used by the Internet community for 1093 the standardization of protocols and procedures. It defines the 1094 stages in the standardization process, the requirements for moving a 1095 document between stages and the types of documents used during this 1096 process. It also addresses the intellectual property rights and 1097 copyright issues associated with the standards process. 1099 -----------End Extract---------" 1101 The last sentence is obsolete (see comment on Section 10). 1103 "---------Begin Extract--------- 1105 1.1 Internet Standards 1107 The Internet, a loosely-organized international collaboration of 1108 autonomous, interconnected networks, supports host-to-host 1109 communication through voluntary adherence to open protocols and 1110 procedures defined by Internet Standards. There are also many 1111 isolated interconnected networks, which are not connected to the 1112 global Internet but use the Internet Standards. 1114 -----------End Extract---------" 1116 "Host-to-host" is strictly accurate, but today we tend to emphasise 1117 the need for "end-to-end" communication. Also, our experience is 1118 that isolated networks tend to get connected sooner or later. 1119 However, these are subtle questions and it is proposed to delete the 1120 architectural summary from this process document. 1122 "---------Begin Extract--------- 1124 2.1 Requests for Comments (RFCs) 1126 Each distinct version of an Internet standards-related specification 1127 is published as part of the "Request for Comments" (RFC) document 1128 series. This archival series is the official publication channel for 1129 Internet standards documents and other publications of the IESG, IAB, 1130 and Internet community. RFCs can be obtained from a number of 1131 Internet hosts using anonymous FTP, gopher, World Wide Web, and other 1132 Internet document-retrieval systems. 1134 -----------End Extract---------" 1136 Remove the reference to gopher. 1138 "---------Begin Extract--------- 1140 The RFC series of documents on networking began in 1969 as part of 1141 the original ARPA wide-area networking (ARPANET) project (see 1142 Appendix A for glossary of acronyms). RFCs cover a wide range of 1143 topics in addition to Internet Standards, from early discussion of 1144 new research concepts to status memos about the Internet. RFC 1145 publication is the direct responsibility of the RFC Editor, under the 1146 general direction of the IAB. 1148 -----------End Extract---------" 1150 Add citations of [RFC4844] and [RFC4071]. 1152 "---------Begin Extract--------- 1154 The rules for formatting and submitting an RFC are defined in [5]. 1156 -----------End Extract---------" 1158 Note that [I-D.rfc-editor-rfc2223bis] is applied today. 1160 It would probably be better to restate this sentence as: 1162 The rules for formatting and submitting an RFC are defined by the RFC 1163 Editor. 1165 "---------Begin Extract--------- 1167 3.3 Requirement Levels 1168 ... 1169 (c) Elective: Implementation of the referenced TS is optional 1170 within the domain of applicability of the AS; that is, the AS 1171 creates no explicit necessity to apply the TS. However, a 1172 particular vendor may decide to implement it, or a particular user 1173 may decide that it is a necessity in a specific environment. For 1174 example, the DECNET MIB could be seen as valuable in an 1175 environment where the DECNET protocol is used. 1177 -----------End Extract---------" 1179 Update the last sentence: 1181 For example, the MIB for a given protocol could be seen as valuable 1182 only in an environment where that protocol is used. 1184 "---------Begin Extract--------- 1186 ... 1187 Although TSs and ASs are conceptually separate, in practice a 1188 standards-track document may combine an AS and one or more related 1189 TSs. 1191 -----------End Extract---------" 1193 It would be much clearer to the reader if this was said at the 1194 beginning of this section. 1196 "---------Begin Extract--------- 1198 4.2.3 Procedures for Experimental and Informational RFCs 1199 ... 1200 Documents proposed for Experimental and Informational RFCs by IETF 1201 Working Groups go through IESG review. The review is initiated using 1202 the process described in section 6.1.1. 1204 -----------End Extract---------" 1206 Move up front in this section. 1208 "---------Begin Extract--------- 1210 6.1.3 Publication 1212 If a standards action is approved, notification is sent to the RFC 1213 Editor and copied to the IETF with instructions to publish the 1214 specification as an RFC. The specification shall at that point be 1215 removed from the Internet-Drafts directory. 1217 -----------End Extract---------" 1219 "At that point" refers to the moment of publication of the RFC. 1221 "---------Begin Extract--------- 1223 7.1 Use of External Specifications 1225 To avoid conflict between competing versions of a specification, the 1226 Internet community will not standardize a specification that is 1227 simply an "Internet version" of an existing external specification 1229 -----------End Extract---------" 1231 "IETF version" 1233 "---------Begin Extract--------- 1235 9. VARYING THE PROCESS 1236 ... 1237 This variance procedure is for use when a one-time waving of some 1239 -----------End Extract---------" 1241 The word is 'waiving'. 1243 "---------Begin Extract--------- 1245 10. INTELLECTUAL PROPERTY RIGHTS 1247 -----------End Extract---------" 1249 This section is superseded by BCP 78 [RFC3978] and BCP 79 [RFC3979]. 1251 Author's Address 1253 Brian Carpenter 1254 Department of Computer Science 1255 University of Auckland 1256 PB 92019 1257 Auckland, 1142 1258 New Zealand 1260 Email: brian.e.carpenter@gmail.com 1262 Full Copyright Statement 1264 Copyright (C) The IETF Trust (2008). 1266 This document is subject to the rights, licenses and restrictions 1267 contained in BCP 78, and except as set forth therein, the authors 1268 retain all their rights. 1270 This document and the information contained herein are provided on an 1271 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1272 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1273 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1274 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1275 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1276 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1278 Intellectual Property 1280 The IETF takes no position regarding the validity or scope of any 1281 Intellectual Property Rights or other rights that might be claimed to 1282 pertain to the implementation or use of the technology described in 1283 this document or the extent to which any license under such rights 1284 might or might not be available; nor does it represent that it has 1285 made any independent effort to identify any such rights. Information 1286 on the procedures with respect to rights in RFC documents can be 1287 found in BCP 78 and BCP 79. 1289 Copies of IPR disclosures made to the IETF Secretariat and any 1290 assurances of licenses to be made available, or the result of an 1291 attempt made to obtain a general license or permission for the use of 1292 such proprietary rights by implementers or users of this 1293 specification can be obtained from the IETF on-line IPR repository at 1294 http://www.ietf.org/ipr. 1296 The IETF invites any interested party to bring to its attention any 1297 copyrights, patents or patent applications, or other proprietary 1298 rights that may cover technology that may be required to implement 1299 this standard. Please address the information to the IETF at 1300 ietf-ipr@ietf.org. 1302 Acknowledgment 1304 Funding for the RFC Editor function is provided by the IETF 1305 Administrative Support Activity (IASA).