idnits 2.17.1 draft-ietf-proto-wgchair-doc-shepherding-05.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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 563. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 : ---------------------------------------------------------------------------- No issues found here. 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 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 (March 15, 2005) is 6982 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) == Unused Reference: 'RFC2028' is defined on line 489, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2028 (Obsoleted by RFC 9281) Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Proto Team A. Falk 3 Internet-Draft ISI 4 Expires: September 16, 2005 H. Levkowetz 5 Ericsson 6 D. Meyer 7 Cisco/University of Oregon 8 March 15, 2005 10 The PROTO Process: Working Group Chair Document Shepherding 11 draft-ietf-proto-wgchair-doc-shepherding-05 13 Status of this Memo 15 This document is an Internet-Draft and is subject to all provisions 16 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 17 author represents that any applicable patent or other IPR claims of 18 which he or she is aware have been or will be disclosed, and any of 19 which he or she become aware will be disclosed, in accordance with 20 RFC 3668. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as 25 Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on September 16, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 The methodologies described in this document have been designed to 47 improve and facilitate IETF document flow processing. A set of 48 processes and procedures, known as the PROTO process, are specified 49 in which a working group chair serves as the primary document 50 shepherd for a document which has been submitted to the IESG for 51 publication. Note that this role has traditionally been filled by 52 the AD responsible for the working group. 54 The shepherd's responsibilities include: 56 1. Providing the write-up accompanying a document that is forwarded 57 to the IESG for publication. Note that this write-up had 58 traditionally been provided by the "Shepherding Area Director". 59 Under the processes and procedures described here, the working 60 group chair provides this write-up. 62 2. Following up on AD Evaluation comments to the authors and working 63 group, and 65 3. Following up on all IESG comments ("DISCUSSes") related to the 66 shepherded draft. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 71 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3. Process Description . . . . . . . . . . . . . . . . . . . . . 5 73 3.1 WG Chair Write-Up for Publication Request . . . . . . . . 5 74 3.2 AD Review Shepherding . . . . . . . . . . . . . . . . . . 8 75 3.3 IESG Discuss Shepherding . . . . . . . . . . . . . . . . . 9 76 4. When Not to Use PROTO . . . . . . . . . . . . . . . . . . . . 11 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 8. Informative References . . . . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 82 A. Working documents . . . . . . . . . . . . . . . . . . . . . . 13 83 Intellectual Property and Copyright Statements . . . . . . . . 14 85 1. Introduction 87 Early in 2004, the IESG undertook several experiments aimed at 88 evaluating whether any of the proposed changes to the IETF document 89 flow process would yield qualitative improvements in document 90 throughput and quality. One such experiment, referred to as PROTO 91 [PROTO], is a set of methodologies designed to involve the working 92 group chairs more directly in their documents' approval life cycle. 93 In particular, the PROTO team focused on that part of the document's 94 life cycle which occurs after the working group and document editor 95 would have traditionally forwarded the document to the IESG for 96 publication. 98 The methodologies developed and piloted by the PROTO team (hereafter 99 referred to as the "PROTO process" or simply "PROTO") focus on the 100 working group chair as the primary document shepherd. In this 101 context, the shepherd's responsibilities include: 103 1. Providing the write-up accompanying a document that has been 104 forwarded to the IESG for publication. This write-up had 105 traditionally been provided by the "Shepherding Area Director". 106 Under PROTO, the Working Group Chair provides this write-up. 108 2. Following up on AD Evaluation comments to the authors and working 109 group, and 111 3. Following up on all IESG comments ("DISCUSSes") related to the 112 shepherded draft. 114 By the end of 2004, the IESG had evaluated the utility of the PROTO 115 methodologies based on data obtained though several pilot projects 116 which had run throughout the year, and subsequently decided to adopt 117 the PROTO process. 119 The primary objective of the PROTO process is to improve document 120 throughput and quality by enabling a partnership between the 121 Responsible Area Director and the Shepherding Working Group Chair 122 (note that the Working Group Chair, in consultation with the 123 Responsible Area Director, may designate the Working Group Secretary, 124 if one exists, to be the shepherd for a particular document). In 125 particular, this partnership has the explicit goal of empowering the 126 Shepherding WG Chair while at the same time offloading a specific 127 part of the follow-up work which had traditionally been 128 responsibility of the Responsible Area Director. As such, PROTO has 129 been scoped to include both the follow-up after the Responsible Area 130 Director has read through and evaluated a document submitted to the 131 IESG for publication, as well as follow-up on all IESG comments on a 132 document (i.e., DISCUSSes). Finally, it is important to note that 133 PROTO does not cover follow-up for drafts which do not originate in a 134 working group. 136 The remainder of this document is organised as follows: Section 3 137 outlines the overall PROTO process. Section 3.1 describes the 138 write-up which accompanies the publication request, Section 3.2 139 describes the AD Review shepherding process, and Section 3.3 140 describes IESG Discuss Shepherding. Finally, Section 4 describes 141 those cases in which the PROTO process should not be used. 143 2. Terminology 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in BCP 14, RFC 2119 148 [RFC2119]. 150 3. Process Description 152 The PROTO process involves Area Directors of selected areas, and some 153 or all of the chairs for which the Area Director is Area Advisor. 155 The PROTO process is divided into three tasks: 157 o Doing a WG Chair Write-Up for a document (Section 3.1), 159 o Following up on AD review comments (Section 3.2), and 161 o Following up on IESG DISCUSS comments (Section 3.3) 163 3.1 WG Chair Write-Up for Publication Request 165 When a draft is ready to be submitted for publication, it is the task 166 of the Shepherding WG Chair to do a document write-up for the draft. 168 There are two parts to this task. First, the Shepherding WG Chair 169 answers questions 1.a to 1.h below to give the Responsible Area 170 Director insight into the working group process as applied to this 171 draft. Note that while these questions may appear redundant in some 172 cases, they are written to elicit information that the AD must be 173 aware of (to this end, pointers to relevant entries in the WG archive 174 will be helpful). The goal here is to inform the AD about any issues 175 that may have come up in IETF meetings, on the mailing list, or in 176 private communication that they should be aware of prior to IESG 177 evaluation of the shepherded draft. Any significant issues mentioned 178 in the questionnaire will probably lead to a follow-up discussion 179 with the AD. 181 The second part of the task is to prepare the "Protocol Write-Up" 182 which is used both for the ballot write-up for the IESG telechat and 183 for the the IETF-wide protocol announcement. Item number 1.i 184 describes the elements of the write-up. Please see other protocol 185 announcements in the IETF Announce archive for examples of such 186 write-ups. 188 1.a) Have the chairs personally reviewed this version of the Internet 189 Draft (ID), and in particular, do they believe this ID is ready 190 to forward to the IESG for publication? 192 1.b) Has the document had adequate review from both key WG members 193 and key non-WG members? Do you have any concerns about the 194 depth or breadth of the reviews that have been performed? 196 1.c) Do you have concerns that the document needs more review from a 197 particular (broader) perspective (e.g., security, operational 198 complexity, someone familiar with AAA, etc.)? 200 1.d) Do you have any specific concerns/issues with this document that 201 you believe the ADs and/or IESG should be aware of? For 202 example, perhaps you are uncomfortable with certain parts of the 203 document, or have concerns whether there really is a need for 204 it. In any event, if your issues have been discussed in the WG 205 and the WG has indicated it that it still wishes to advance the 206 document, detail those concerns in the write-up. 208 1.e) How solid is the WG consensus behind this document? Does it 209 represent the strong concurrence of a few individuals, with 210 others being silent, or does the WG as a whole understand and 211 agree with it? 213 1.f) Has anyone threatened an appeal or otherwise indicated extreme 214 discontent? If so, please summarise the areas of conflict in 215 separate email to the Responsible Area Director. 217 1.g) Have the chairs verified that the document adheres to all of the 218 ID nits? (see http://www.ietf.org/ID-Checklist.html). 220 1.h) Is the document split into normative and informative references? 221 Are there normative references to IDs, where the IDs are not 222 also ready for advancement or are otherwise in an unclear state? 223 (note here that the RFC editor will not publish an RFC with 224 normative references to IDs, it will delay publication until all 225 such IDs are also ready for publication as RFCs.) 227 1.i) For Standards Track and BCP documents, the IESG approval 228 announcement includes a write-up section with the following 229 sections: 231 * Technical Summary 233 * Working Group Summary 235 * Protocol Quality 237 1.j) Please provide such a write-up. Recent examples can be found in 238 the "protocol action" announcements for approved documents. 240 1.k) Note: 242 * The relevant information for the technical summary can 243 frequently be found in the abstract and/or introduction of 244 the document. If not, this may be an indication that there 245 are deficiencies in the abstract or introduction. 247 * For the Working Group Summary: Was there anything in WG 248 process that is worth noting? For example, was there 249 controversy about particular points, decisions where 250 consensus was particularly rough, etc. 252 * For the protocol quality, useful information includes: 254 + Are there existing implementations of the protocol? 256 + Have a significant number of vendors indicated they 257 plan to implement the specification? 259 + Are there any reviewers that merit special mention as 260 having done a thorough review (i.e., that resulted in 261 important changes or a conclusion that the document 262 had no substantive issues)? 264 The questionnaire and write-up is sent to the ADs and 265 iesg-secretary@ietf.org with a request to publish the document. The 266 questionnaire and write-up, minus any discussion of possible appeals, 267 is also sent to the working group mailing list. The publication 268 request SHOULD also indicate which chair will be shepherding the 269 document (this will be entered into the ID Tracker [IDTRACKER]). In 270 addition to making life easier for the ADs, this lets the IETF chair 271 know where to send Gen-ART [GEN-ART] reviews. 273 3.2 AD Review Shepherding 275 The steps for working group chair shepherding of AD reviews are as 276 follows: 278 2.a) If there is more than one chair, the chairs decide on which one 279 should be responsible for ensuring that the needed fixes are 280 done when the AD returns comments. This MUST be done before the 281 publication request is sent, so that the information can be 282 included in the request, as mentioned above. This MUST be an 283 explicit agreement among the working group chairs. 285 2.b) The AD reads, evaluates and comments on the draft (as is the 286 case when not using PROTO). 288 2.c) Depending on the magnitude of the issues found, the AD returns 289 the full review to the chairs, and requests that either: 291 * Further editorial work must be done on the document before 292 it can be published, or, 294 * ID Nits must be fixed before the document before it can be 295 published, or 297 * A revised draft is is required to resolve issues that have 298 been found in subsequent IESG review. 300 As covered below, the comments will be posted to the working 301 group mailing list. The comments will normally also be posted 302 by the AD in the ID Tracker [IDTRACKER]. Working groups that 303 use issue tracking should also record the issues (and eventually 304 their resolution) in the issue tracker. 306 2.d) The Shepherding WG Chair reads through the AD Evaluation 307 comments, making very certain that all comments are understood, 308 so that it is possible to follow up on them with the authors and 309 working group. If there is some uncertainty as to what is 310 requested, this must be resolved with the Area Director. 312 2.e) The Shepherding WG Chair sends the comments to the author(s) and 313 to the working group mailing list, in order to have a permanent 314 record of the comments. It is recommended that the chair 315 solicit from the author(s) an estimate on when the fixes will be 316 done, that is, when the revised draft can be expected. 318 2.f) When incorporating the fixes in the new version of the draft, it 319 is strongly RECOMMENDED that the editor keep a list showing how 320 each issue was addressed and showing what the revised text is. 322 It is strongly RECOMMENDED that this list be forwarded to the 323 Responsible Area Director with the revised draft. 325 2.g) The Shepherding WG Chair iterates with the authors (and working 326 group if required) until the outstanding issues have been 327 resolved and a revised draft has been submitted. At this point, 328 the AD is notified and provided with the summary list of issues 329 and resulting text changes. 331 In the event that the working group disagrees with a comment 332 raised by the AD or has previously considered and dismissed the 333 issue, the Shepherding WG Chair MUST resolve the issue with the 334 AD before a revised draft can be submitted. 336 2.h) The Area Director verifies that the issues he found during AD 337 Evaluation are resolved by the new version of the draft. 339 2.i) The shepherding process normally terminates at this point. 340 However, in the event that no resolution can be found, the 341 process goes to 1. above (i.e., essentially restarts). 343 3.3 IESG Discuss Shepherding 345 In this section we detail the steps that a Shepherding WG Chair will 346 take in resolving the DISCUSS items against a given ID. The steps 347 are given below, in the order that they are to be executed. Note 348 that occasionally DISCUSSes are written in a manner that makes their 349 primary intent unclear. In these cases, the Shepherding WG Chair 350 (and possibly the document editor) and DISCUSSing AD SHOULD meet 351 (either in person or electronically) to resolve the issue. In 352 addition, the Responsible Area Director SHOULD be notified of the 353 meeting. If this process fails to clarify or resolve the DISCUSS, 354 the Shepherding WG Chair MAY further involve the Responsible Area 355 Director in the resolution process. 357 3.a) Immediately after the weekly IESG conference call, the 358 Shepherding WG Chair queries the ID tracker [IDTRACKER] to 359 collect any DISCUSS comments raised against the ID. In order to 360 accomplish this, the Shepherding WG Chair's email address is 361 added to the "State Change Notice To:" field in the ID tracker. 362 This will result in an email to the Shepherding WG Chair when 363 the document changes state from the "IESG Evaluation" state to 364 one of the states requiring Shepherd actions (i.e., "IESG 365 Evaluation: Revised ID Needed", "IESG Evaluation: AD Followup"). 366 This notification indicates to the the Shepherding WG Chair that 367 the DISCUSS comments have been registered. 369 Note that there may be exceptional cases when DISCUSS comments 370 are registered after the IESG teleconference. In these cases, 371 the DISCUSSing AD should notify the Shepherding WG Chair that 372 new comments have been entered. 374 3.b) The Shepherding WG Chair analyses comments from the tracker, and 375 initialises contact with any AD's who have placed comments 376 (blocking or non-blocking) on the draft that is being 377 shepherded. In particular, the Shepherding WG Chair MUST notify 378 the relevant ADs that the Shepherding WG Chair is the current 379 document shepherd. Note that the Responsible Area Director MUST 380 be copied on this correspondence. 382 +------+ Comments +--------+ Comments +-------+ 383 | (3.a)| ------------> | (3.b) | -------------> | (3.c) | 384 +------+ Collected +--------+ Understood +-------+ 385 /|\ | 386 | | Comments not fully understood 387 | | (Further AD/Shepherding WG 388 | | Chair Discussion Required) 389 | | 390 +----+ 392 3.c) The Shepherding WG Chair then coordinates DISCUSS comments, and 393 builds a a consistent interpretation of the comments. This step 394 may require iteration with step (2). above. That is: 396 +------+ Consistent +-------+ 397 | (3.b)| ---------------> | (3.c) | 398 +------+ Interpretation +-------+ 399 /|\ | 400 | | Further AD/Shepherding WG 401 | | Chair discussion required 402 +--------------------------+ 404 3.d) The DISCUSS comments are then communicated to the working group. 406 3.e) After the author(s) resolve the issues provided by the 407 Shepherding WG Chair (i.e., the summarised DISCUSS issues), the 408 Shepherding WG Chair reviews the updated document to ensure that 409 (in her/his option) the DISCUSS issues have been resolved. 411 Note that the Shepherding WG Chair may also propose resolutions 412 to these issues, file them in an issue tracker, or do other 413 steps to streamline the resolution of the comments. 415 3.f) The Shepherding WG Chair communicates the resolution-so-far to 416 the responsible AD and the DISCUSSing AD(s). 418 3.g) DISCUSSing AD removes DISCUSS comment, or tells the Shepherding 419 WG Chair and adds information to the ID tracker explaining why 420 the comment is not resolved. The Shepherding WG Chair informs 421 the working group accordingly. 423 If the DISCUSS comment in question was not resolved to the 424 satisfaction of the DISCUSSing AD(s) and Responsible Area 425 Director, two possibilities exist: 427 (a) The process returns to step (3.c), or 429 (b) If no progress can be made on the resolution of the DISCUSS 430 with the DISCUSSING AD, despite clarification and 431 additional involvement of the Responsible Area Director, 432 the Shepherding WG Chair and the WG might at last resort 433 consider an appeal in accordance with the procedures 434 described in RFC 2026 [RFC2026] and referred to in RFC 2418 435 [RFC2418]. 437 Otherwise, the process continues with step (3.h). 439 3.h) The Responsible Area Director moves document to APPROVED state, 440 or if the changes are deemed significant, there may be a new WG 441 last call. Finally, the document goes to the full IESG for 442 re-review. 444 4. When Not to Use PROTO 446 As mentioned above, there are several cases in which the PROTO 447 process SHOULD NOT be used. These include 449 1. Those cases in which the WG chair primary document author or 450 editor, or the WG chair is the primary author or editor of a 451 large percentage of the documents produced by the working group, 453 2. Those cases in which the Responsible Area Director expects 454 communication difficulties with the WG chair (either due to 455 experience, strong views stated by the chair, or other issues), 456 and 458 3. Those cases in which the working group itself is either very old, 459 losing energy, or winding down. i.e., those cases in which it 460 would not be productive to initiate new processes or procedures. 462 Finally, note these guidelines are intended to help the Responsible 463 Area Director determine when to use the PROTO process. The final 464 determination as to whether to use the PROTO process or not is left 465 to the Responsible Area Director's discretion. 467 5. Security Considerations 469 This document specifies a change to IETF document flow procedures. 470 As such, it neither raises nor considers protocol-specific security 471 issues. 473 6. Acknowledgments 475 This document is the product of PROTO team, which includes authors as 476 well as Allison Mankin, Bill Fenner, Barbara Fuller, and Margaret 477 Wasserman. 479 7. IANA Considerations 481 This document creates no new requirements on IANA namespaces or other 482 IANA requirements. 484 8. Informative References 486 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 487 3", BCP 9, RFC 2026, October 1996. 489 [RFC2028] Hovey, R. and S. Bradner, "The Organizations Involved in 490 the IETF Standards Process", BCP 11, RFC 2028, October 491 1996. 493 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 494 Requirement Levels", BCP 14, RFC 2119, March 1997. 496 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 497 Procedures", BCP 25, RFC 2418, September 1998. 499 [IDTRACKER] 500 "The IETF Draft Tracker", Web 501 Application: https://datatracker.ietf.org/, 2004. 503 [PROTO] "The IESG Process and Tools (PROTO) Team", Web 504 Page: http://psg.com/~mrw/PROTO-Team, 2004. 506 [GEN-ART] "The General Area Review Team (GEN-ART)", Web 507 Page: http://www.alvestrand.no/ietf/gen/review-guidelines. 508 html, 2005. 510 Authors' Addresses 512 Aaron Falk 514 Email: falk@isi.edu 516 Henrik Levkowetz 517 Torsgatan 71 518 Stockholm S-113 37 519 SWEDEN 521 Phone: +46 708 32 16 08 522 Email: henrik@levkowetz.com 524 David Meyer 525 1225 Kincaid St 526 Eugene, OR 97403 527 USA 529 Phone: +1.541.346.1747 530 Email: dmm@1-4-5.net 532 Appendix A. Working documents 534 (This section should be removed by the RFC editor before publication) 536 The current working documents for this draft are available at this 537 web site: 539 http://ietf.levkowetz.com/drafts/proto/wgchair-doc-shepherding/ 541 Intellectual Property Statement 543 The IETF takes no position regarding the validity or scope of any 544 Intellectual Property Rights or other rights that might be claimed to 545 pertain to the implementation or use of the technology described in 546 this document or the extent to which any license under such rights 547 might or might not be available; nor does it represent that it has 548 made any independent effort to identify any such rights. Information 549 on the procedures with respect to rights in RFC documents can be 550 found in BCP 78 and BCP 79. 552 Copies of IPR disclosures made to the IETF Secretariat and any 553 assurances of licenses to be made available, or the result of an 554 attempt made to obtain a general license or permission for the use of 555 such proprietary rights by implementers or users of this 556 specification can be obtained from the IETF on-line IPR repository at 557 http://www.ietf.org/ipr. 559 The IETF invites any interested party to bring to its attention any 560 copyrights, patents or patent applications, or other proprietary 561 rights that may cover technology that may be required to implement 562 this standard. Please address the information to the IETF at 563 ietf-ipr@ietf.org. 565 Disclaimer of Validity 567 This document and the information contained herein are provided on an 568 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 569 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 570 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 571 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 572 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 573 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 575 Copyright Statement 577 Copyright (C) The Internet Society (2005). This document is subject 578 to the rights, licenses and restrictions contained in BCP 78, and 579 except as set forth therein, the authors retain all their rights. 581 Acknowledgment 583 Funding for the RFC Editor function is currently provided by the 584 Internet Society.