idnits 2.17.1 draft-rousskov-newtrk-id-state-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack 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.) ** There are 9 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (April 5, 2004) is 7325 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: 'RFC XXXX' is mentioned on line 559, but not defined ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 New IETF Standards Track A. Rousskov 2 Internet-Draft The Measurement Factory 3 Expires: October 4, 2004 April 5, 2004 5 Declaring the State of an Internet Draft 6 draft-rousskov-newtrk-id-state-00 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at http:// 23 www.ietf.org/ietf/1id-abstracts.txt. 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This Internet-Draft will expire on October 4, 2004. 30 Copyright Notice 32 Copyright (C) The Internet Society (2004). All Rights Reserved. 34 Abstract 36 This memo describes a mechanism to relay the state(s) of an Internet 37 Draft to the reader. This mechanism may be used, in part, to 38 encourage or discourage review submission, test suite creation, and 39 prototype implementation of the entire draft or its portions. The 40 state of the draft is declared using a human-friendly notation 41 suitable for automated extraction of standard states. 43 Table of Contents 45 1. State of this Draft . . . . . . . . . . . . . . . . . . . . . 3 46 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 5. Overall Operation . . . . . . . . . . . . . . . . . . . . . . 5 50 6. Declaration Format . . . . . . . . . . . . . . . . . . . . . . 6 51 7. Declaration Elements . . . . . . . . . . . . . . . . . . . . . 8 52 7.1 Boilerplate . . . . . . . . . . . . . . . . . . . . . . . . . 8 53 7.2 Draft-Name . . . . . . . . . . . . . . . . . . . . . . . . . . 8 54 7.3 Draft Parts . . . . . . . . . . . . . . . . . . . . . . . . . 9 55 7.4 Part States . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 7.5 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 57 7.6 Trailer . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 59 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 60 9.1 Soliciting a review . . . . . . . . . . . . . . . . . . . . . 11 61 9.2 Testing a Feature . . . . . . . . . . . . . . . . . . . . . . 11 62 9.3 Combination of states . . . . . . . . . . . . . . . . . . . . 12 63 9.4 Discouraging feedback . . . . . . . . . . . . . . . . . . . . 12 64 9.5 Providing a hook for future use . . . . . . . . . . . . . . . 13 65 9.6 Minimum information . . . . . . . . . . . . . . . . . . . . . 13 66 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 67 Normative References . . . . . . . . . . . . . . . . . . . . . 13 68 Informative References . . . . . . . . . . . . . . . . . . . . 13 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 70 Intellectual Property and Copyright Statements . . . . . . . . 15 72 1. State of this Draft 74 This document complies with the Draft State specification[RFC XXXX]. 75 Formal code following this paragraph provides the document version 76 and describes the state of the document. More information about the 77 document state may follow the code. If the actual version of this 78 document does not match the encoded one, please disregard the entire 79 state declaration as it is most likely stale. 81 draft-rousskov-newtrk-id-state-00 state := { 82 Draft :- Review 83 Section "Security Considerations" :- Ignore 84 } 86 Please provide an early high-level review of this draft. Is an 87 IETF-wide standard for documenting draft states needed? Is this draft 88 a step in the right direction towards specifying such a standard? 89 Should NEWTRK WG adopt this draft as a working group draft? 91 The next revision of this draft is scheduled for 2004/04/15; reviews 92 submitted prior to 2004/04/11 are likely to affect the next revision. 94 Always check the latest published revision of this document for 95 up-to-date information. 97 2. Motivation 99 IETF publishes thousands of Internet Draft (ID) revisions per year. 100 For a given ID, IETF versioning mechanism reflects the order of 101 revision publications. While later revisions often correspond to more 102 mature documents, it is generally impossible for the reader to know 103 whether a particular revision of the draft is highly unstable, ready 104 for thorough review, or suitable for a prototype implementation, etc. 105 This uncertainty is even greater at the section of feature level of 106 the draft because the state of one section or feature may be very 107 different from another, even related section or feature. To make 108 matters worse, it is common for working group drafts not to reflect 109 working group opinion as a whole (until the draft is submitted for an 110 archival publication). 112 Usually, only draft authors and those closely following the draft 113 have enough information to make statements about its state. This 114 creates serious problems for others interested in the draft. For 115 example, reviewers may not submit reviews assuming that the draft is 116 too unstable or, vice versa, may submit a detailed review of the 117 draft revision that is going to be hopelessly obsolete when the next 118 revision is published the following morning. 120 While it is sometimes easy to contact the draft authors for an 121 advice, such a contact cannot be automated, often takes too much 122 time, may not be possible for commercial secrecy reasons, or may be 123 hindered by communication barriers. Moreover, authors or WG Chair 124 opinion on the draft may not represent WG consensus, and contacting 125 the entire WG may be an even less productive endeavor than contacting 126 individuals. 128 IETF RFCs solve a similar problem by using a set of RFC categories. 129 Each category is well documented. While RFC categories have their own 130 flaws (to be addressed by the New IETF Standards Track working 131 group), they usually imply the state of an RFC with sufficient 132 precision. Internet Drafts do not have similar categories. 134 This document specifies a mechanism that explicitly tells the reader 135 of an Internet Draft the state of that draft. The following effects 136 are expected from wide use of the Draft State Declarations by IETF 137 authors and groups: 139 1. Authors and WGs would think about and document the state of draft 140 parts more often. This may prevent some of the late surprises in 141 draft development and make it easier for new folks to contribute. 143 2. More draft readers will know what actions (e.g., review or 144 prototyping) are appropriate. This may encourage review and 145 testing. 147 3. Tools will be developed to facilitate the above changes. This 148 may make it easy and quick to find drafts that are prime for 149 review and allow for semi-automated monitoring of draft states by 150 liaisons or technology users. That, in turn, may make early 151 review solicitations more effective. 153 3. Scope 155 The draft state declaration mechanism is designed for IETF Internet 156 Drafts. The mechanism is applicable for both Working Group (WG) 157 drafts and individual drafts. The mechanism is applicable to 158 standards track and non-standards track drafts. The state declaration 159 is removed when the draft becomes an archival document (XXX: why? do 160 all archival documents have a sufficiently known state?). 162 For WG drafts, published draft state declaration reflects WG rough 163 consensus. Standard IETF rules apply to sensing or appealing such 164 consensus. These rules and related caveats are beyond the scope of 165 this draft. Similarly, for non-WG drafts, published draft state 166 declaration reflects author(s) rough consensus. The ways to achieve 167 or appeal such consensus are beyond the scope of this draft. Dealing 168 with rogue or irresponsible authors or WGs is also beyond the scope 169 of this draft. 171 As any information in an Internet Draft, the state declaration does 172 not require (but may receive) an IESG or other external review. As 173 any ID publication, publication of an ID with the state declaration 174 does not require an IESG or AD notification or approval. Other 175 mechanisms that use draft state as a tool may require such reviews, 176 notifications, approvals, etc. 178 This document does not specify whether or how the state of the draft 179 is communicated in the draft file name or in various draft indexes. 181 4. Terminology 183 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in [RFC2119]. When used 186 with the normative meanings, these keywords will be all uppercase. 187 Occurrences of these words in lowercase comprise normal prose usage, 188 with no normative implications. 190 The purpose of the remaining definitions is to simplify presentation 191 by removing the necessity to distinguish individual drafts from WG 192 drafts, single author from multiple authors, the entire draft from 193 its parts, etc. The draft state declaration mechanism does not depend 194 on those distinctions. 196 author: ID author, authors, editor, or editors. 198 WG: IETF working group or, in case of an individual ID, the author of 199 the ID. 201 draft part or portion: The entire Internet Draft or any, not 202 necessarily sequential, portion of thereof. 204 section: ID section, without regard to its nesting level (i.e., 205 subsection, subsubsection, etc.). 207 reader: Any draft reader or user, including internal and external 208 reviewers, new WG participants, other WGs, IETF Area Director 209 (AD), IESG, WG liaisons, and various automation tools. 211 5. Overall Operation 213 When a WG reaches first rough consensus on a portion of the draft, 214 the draft author SHOULD document that consensus in the draft. The 215 author MAY use a dedicated section (XXX: which may cause section 216 renumbering when the declaration is stripped from an RFC; should we 217 address that?) or MAY place the declaration in an already existing 218 section. The author MUST NOT create more than one state declarations 219 per draft. The author submits the draft with the declaration for 220 publication using the standard IETF submission procedure. 222 For each revision of the draft that contains a draft state 223 declaration, the author MUST validate the contents of the declaration 224 against current WG rough consensus (WG consensus may change between 225 publications). Replacing the outdated declaration content with a 226 standard "unknown draft state" boilerplate is one way of keeping the 227 declaration up to date. 229 A reader of an Internet Draft familiar with the state declaration 230 concept, searches for a reference to this specification or the 231 boilerplate text. If found, the nearby formal record and informal 232 comments relay WG opinion (at the draft submission time) on the draft 233 state to the reader. Such opinion may, for example, encourage early 234 review or discourage prototyping of certain features. The declaration 235 trailer reminds the reader to look for the most recent revision of 236 the draft. 238 Internet Draft indexes and databases may extract and process formal 239 records from draft state declarations to facilitate navigation 240 through ID space or manage review solicitations. 242 (XXX: add definition of full compliance elsewhere). 244 6. Declaration Format 246 This section documents the draft state declaration format. Authors 247 MUST use this format. Its trivial syntax allows for easy manual 248 typesetting, for simple auto-processing of state declarations, and 249 for reduction of stale declarations. 251 The following template specifies format of the major draft state 252 declaration parts, using the ABNF [RFC2234]. 254 declaration = boilerplate [formal-record] [comments] trailer 256 boilerplate = text 257 formal-record = LF draft-name "state := {" LF states LF "}" 258 comments = text 259 trailer = text 261 draft-name = token 262 states = 1*part-state 263 part-state = part ":-" state 265 part = token 266 state = token 268 token = VCHAR *CHAR VCHAR ; subject to restrictions below 270 phrase = 1*CHAR 271 text = 1*phrase 273 In addition to the explicit syntax rules defined by the above ABNF, 274 the following rules apply: 276 o Formal-record always follows "known state" boilerplate and never 277 "unknown state" boilerplates (see Section 7.1 for boilerplates 278 definitions. 280 o Grammar elements can be surrounded by OPTIONAL whitespace. Besides 281 traditional linear whitespace (LWSP), declaration whitespace 282 includes draft headers, draft footers, and similar typesetting 283 delimiters. 285 o Tokens do not contain ":-", ":=", or LF. 287 Draft formatting tools such as Marshall Rose's xml2rfc might 288 eventually provide macros or dialogs to assist authors in declaring 289 draft states. However, formatting tools MUST NOT insert or update the 290 encoded draft revisions as it will defeat the mechanism for detecting 291 stale declarations. 293 (XXX: is this too formal? can we make it simpler but still allow for 294 easy auto-extraction of draft name, revision, and states?) 296 (XXX: is this too informal, especially the whitespace definition 297 part? Will parsers be able to find/extract states without many 298 hacks?) 300 7. Declaration Elements 302 This section describes major elements of a draft state declaration. 304 7.1 Boilerplate 306 The following are the two boilerplate definitions, for known and 307 unknown states. Authors MUST NOT use other boilerplates. 309 known-state-boilerplate: This document complies with the Draft State 310 specification[RFC XXXX]. Formal code following this paragraph 311 provides the document version and describes the state of the 312 document. More information about the document state may follow the 313 code. If the actual version of this document does not match the 314 encoded one, please disregard the entire state declaration as it 315 is most likely stale. 317 unknown-state-boilerplate: This document complies with the Draft 318 State specification[RFC XXXX]. The state of this document is 319 unknown. Later revisions of this document are likely to contain 320 specific state information. 322 Since not all WGs are aware or use draft state declarations, placing 323 an unknown-state-boilerplate provides the reader with more 324 information than simply omitting the section. It also makes it 325 possible for IESG to require draft state declarations without 326 requiring WGs to reach rough consensus on at least some part of each 327 WG draft. 329 7.2 Draft-Name 331 The author MUST replace the parameter in the 332 formal-record element of the draft state declaration with the name 333 and revision number of the draft being submitted for publication. 334 This requirement is meant to help readers detect (and ignore) stale 335 state information. (XXX: is there a better name/label for the 336 draft-name element?) 338 To obtain up-to-date published state information, human readers MUST 339 find the most recent published draft and MUST check whether the 340 in the declaration corresponds to that draft version. 342 If the in draft state declaration does not match the 343 actual draft name (including revision number), automated readers MUST 344 NOT use or relay the state information in a way that implies the 345 information is up-to-date. In other words, while it is OK to ignore 346 (or warn about) mismatching draft-names, it is a violation of this 347 specification to not check for the mismatch as failure to check will 348 mislead human readers. 350 7.3 Draft Parts 352 Standard part values are provided below along with their semantics. 353 Authors MUST NOT provide descriptions for these standard parts in the 354 comments section. This rule avoids misinterpretation of part 355 semantics by readers, especially automated ones. Column characters 356 (":") following part names below are formatting delimiters and are 357 not part of the values. 359 Draft: This part value refers to the entire document 361 Section X: This part value refers to a specific section. The X 362 parameter contains the number, title, or a similar visible section 363 label that uniquely identifies the section within the document. 364 Authors SHOULD NOT manually enter labels to avoid typos and 365 inconsistencies with actual sections in the draft. 367 When two overlapping parts are used with conflicting states, the 368 state of the most specific part takes precedence for the overlapping 369 region. For example, a review of the entire draft may be requested 370 with an explicit instruction to ignore certain sections. 372 When standard part values are not sufficient, authors MAY use other 373 (extension) part values. 375 7.4 Part States 377 Standard state values are provided below along with their semantics. 378 Authors MUST NOT provide descriptions for these standard parts in the 379 comments section. This rule avoids misinterpretation of state 380 semantics by readers, especially automated ones. Column characters 381 (":") following part names below are formatting delimiters and are 382 not part of the values. 384 Ignore: WG expects to rewrite the corresponding part in some major, 385 profound way. While IETF peer reviews can be submitted at any 386 time, reviewing this part is likely to be a waste of time. 388 Review: WG solicits reviews of the corresponding part. Informal 389 comments following the formal record may provide details about the 390 review, including any deadlines. The WG expects to modify the 391 corresponding part to address reviewer comments. 393 Test: WG encourages early prototypes, experiments, and test suites to 394 be developed for the corresponding part. The WG expects to modify 395 the corresponding part to reflect early trials feedback. While 396 IETF peer reviews can be submitted at any time, actual test 397 results would be preferred to convince WG to change the 398 corresponding part. 400 Done: WG does not expect to modify the corresponding part in any way. 401 WG expects the final version of the draft to be submitted with 402 this part as it is written in this draft. Note that WG plans might 403 change and that WG is not the only entity that can modify a draft. 404 While IETF peer reviews can be submitted at any time, it would be 405 difficult to convince WG to change the corresponding part. 407 (XXX: should we add a standard "Help" state to indicate that the WG 408 is looking for help writing the spec, not just review?) 410 (XXX: should we add a standard "Consensus" state to indicate that the 411 WG reached consensus for the specified part and implying that drafts 412 without such state may not have WG consensus?) 414 (XXX: should we add standard time/event conditions such as "frozen 415 until YYYY/MM/DD"?) 417 When standard state values are not sufficient, authors MAY use other 418 (extension) state values. 420 7.5 Comments 422 Authors MAY use the comment element to supply additional information 423 related to some of the formally declared states. Comments become 424 essential when non-standard part or state values are used, as their 425 semantics would otherwise remain unknown. As already required above, 426 authors must not redefine semantics of the standard parts and states 427 using the comments element. 429 7.6 Trailer 431 The following is the trailer text. The same trailer is used for known 432 and unknown states. Authors MUST NOT use other trailers. 434 trailer: Always check the latest published revision of this document 435 for up-to-date information. 437 The primary purpose of the trailer is to serve as a terminator of the 438 draft state declaration, so that automated tools can extract or 439 render the entire declaration. Without the trailer (e.g., if its 440 information is moved to the boilerplates), it would be often 441 impossible to auto-detect the presence of a comment or to find the 442 end of a comment. RFC Editor may use this feature to automatically 443 strip draft state declarations from Internet Drafts about to become 444 RFCs. 446 8. Security Considerations 448 None. 450 9. Examples 452 This section contains informative examples of draft state 453 declarations. 455 9.1 Soliciting a review 457 This document complies with the Draft State specification[RFC XXXX]. 458 Formal code following this paragraph provides the document version 459 and describes the state of the document. More information about the 460 document state may follow the code. If the actual version of this 461 document does not match the encoded one, please disregard the entire 462 state declaration as it is most likely stale. 464 draft-ietf-opes-edge2edge-01 state := { 465 Draft :- Review 466 } 468 Please provide an early review of this draft by 2004/04/30. Do not 469 pay much attention to details. We are basically looking for 470 architecture-level comments at this point. We are especially 471 uncertain about Section 3.4 and the caching feature. 473 Always check the latest published revision of this document for 474 up-to-date information. 476 9.2 Testing a Feature 478 This document complies with the Draft State specification[RFC XXXX]. 479 Formal code following this paragraph provides the document version 480 and describes the state of the document. More information about the 481 document state may follow the code. If the actual version of this 482 document does not match the encoded one, please disregard the entire 483 state declaration as it is most likely stale. 485 draft-ietf-tcp-proxy-04 state := { 486 TCP splicing (IEEE:X.Zb) :- Test 487 } 489 While we received positive reviews, we are not sure that TCP splicing 490 works, especially on pigeon networks. If you have resources, please 491 test this feature, at least on the MUST level. Is it feasible to 492 implement at all? 494 Always check the latest published revision of this document for 495 up-to-date information. 497 9.3 Combination of states 499 This document complies with the Draft State specification[RFC XXXX]. 500 Formal code following this paragraph provides the document version 501 and describes the state of the document. More information about the 502 document state may follow the code. If the actual version of this 503 document does not match the encoded one, please disregard the entire 504 state declaration as it is most likely stale. 506 draft-ietf-cool-proto-11 state := { 507 Draft :- Review 508 Section 13.5 :- Ignore 509 Section 13.6 :- Ignore 510 client side rendering :- Test 511 } 513 Alan Smithee has reviewed client-side rendering rules (see Sections 514 3-5 and some bits in Section 10). It would be great to have a working 515 compliance test suite _now_, before vendors rush this to market. 517 If you review these and other sections, please try to send us 518 feedback before the New Year. We plan to start working on the next 519 generation server-side rules (sections 13.5 and 13.6) after that. 521 Always check the latest published revision of this document for 522 up-to-date information. 524 9.4 Discouraging feedback 526 This document complies with the Draft State specification[RFC XXXX]. 527 Formal code following this paragraph provides the document version 528 and describes the state of the document. More information about the 529 document state may follow the code. If the actual version of this 530 document does not match the encoded one, please disregard the entire 531 state declaration as it is most likely stale. 533 draft-smithee-deadp-14 state := { 534 Draft :- Done 535 } 537 I am going to submit this to RFC Editor for publication as an 538 Informational RFC next week. There are already two implementations of 539 this protocol. I am changing jobs and do not expect to work on this 540 any more. IETF NG working group is going to work on the next 541 generation of the protocol. 543 Always check the latest published revision of this document for 544 up-to-date information. 546 9.5 Providing a hook for future use 548 This document complies with the Draft State specification[RFC XXXX]. 549 The state of this document is unknown. Later revisions of this 550 document are likely to contain specific state information. 552 We expect to provide sate info after WG f2f meeting in May. 554 Always check the latest published revision of this document for 555 up-to-date information. 557 9.6 Minimum information 559 This document complies with the Draft State specification[RFC XXXX]. 560 The state of this document is unknown. Later revisions of this 561 document are likely to contain specific state information.Always 562 check the latest published revision of this document for up-to-date 563 information. 565 Appendix A. Acknowledgments 567 The discussion about Working Group Snapshots [I-D.dawkins-newtrk-wgs] 568 on the New IETF Standards Track (NEWTRK) WG mailing list inspired the 569 creation of this document. Harald Tveit Alvestrand suggested adding 570 formal descriptors to state declarations and reviewed an early 571 version of this specification. 573 Normative References 575 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 576 Requirement Levels", BCP 14, RFC 2119, March 1997. 578 [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 579 Specifications: ABNF", RFC 2234, November 1997. 581 Informative References 583 [I-D.dawkins-newtrk-wgs] 584 Dawkins, S., "Working Group Snapshot (WGS)", 585 draft-dawkins-newtrk-wgs-00 (work in progress), March 586 2004. 588 Author's Address 590 Alex Rousskov 591 The Measurement Factory 593 EMail: rousskov@measurement-factory.com 594 URI: http://www.measurement-factory.com/ 596 Intellectual Property Statement 598 The IETF takes no position regarding the validity or scope of any 599 intellectual property or other rights that might be claimed to 600 pertain to the implementation or use of the technology described in 601 this document or the extent to which any license under such rights 602 might or might not be available; neither does it represent that it 603 has made any effort to identify any such rights. Information on the 604 IETF's procedures with respect to rights in standards-track and 605 standards-related documentation can be found in BCP-11. Copies of 606 claims of rights made available for publication and any assurances of 607 licenses to be made available, or the result of an attempt made to 608 obtain a general license or permission for the use of such 609 proprietary rights by implementors or users of this specification can 610 be obtained from the IETF Secretariat. 612 The IETF invites any interested party to bring to its attention any 613 copyrights, patents or patent applications, or other proprietary 614 rights which may cover technology that may be required to practice 615 this standard. Please address the information to the IETF Executive 616 Director. 618 Full Copyright Statement 620 Copyright (C) The Internet Society (2004). All Rights Reserved. 622 This document and translations of it may be copied and furnished to 623 others, and derivative works that comment on or otherwise explain it 624 or assist in its implementation may be prepared, copied, published 625 and distributed, in whole or in part, without restriction of any 626 kind, provided that the above copyright notice and this paragraph are 627 included on all such copies and derivative works. However, this 628 document itself may not be modified in any way, such as by removing 629 the copyright notice or references to the Internet Society or other 630 Internet organizations, except as needed for the purpose of 631 developing Internet standards in which case the procedures for 632 copyrights defined in the Internet Standards process must be 633 followed, or as required to translate it into languages other than 634 English. 636 The limited permissions granted above are perpetual and will not be 637 revoked by the Internet Society or its successors or assignees. 639 This document and the information contained herein is provided on an 640 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 641 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 642 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 643 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 644 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 646 Acknowledgment 648 Funding for the RFC Editor function is currently provided by the 649 Internet Society.