idnits 2.17.1 draft-ietf-xcon-floor-control-req-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.a on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 564. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 548. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 554. ** 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 == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 10) being 71 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) 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 (October 23, 2004) is 7124 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: '1' is defined on line 462, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 478, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-02 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-conferencing-framework (ref. '3') == Outdated reference: A later version (-01) exists of draft-ietf-mmusic-sccp-00 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Transport Area P. Koskelainen 2 Internet-Draft Nokia 3 Expires: April 23, 2005 J. Ott 4 Uni Bremen TZI 5 H. Schulzrinne 6 X. Wu 7 Columbia University 8 October 23, 2004 10 Requirements for Floor Control Protocol 11 draft-ietf-xcon-floor-control-req-02.txt 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 April 23, 2005. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). 44 Abstract 46 Floor control is a means to manage joint or exclusive access to 47 shared resource in a (multiparty) conferencing environment. Thereby, 48 floor control complements other functions -- such as conference and 49 media session setup, conference policy manipulation, and media 50 control -- that are realized by other protocols. This document 51 defines the requirements for a floor control protocol for multiparty 52 conferences in the context of an existing framework. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 58 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5. Integration with Conferencing . . . . . . . . . . . . . . . . 7 61 6. Assumptions about a Conference Policy . . . . . . . . . . . . 8 62 7. Floor Control Protocol Requirements . . . . . . . . . . . . . 10 63 7.1 Communication between Participant and Server . . . . . . . 10 64 7.2 Communicaton between Chair and Server . . . . . . . . . . 11 65 7.3 General Protocol Requirements . . . . . . . . . . . . . . 12 66 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 67 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 68 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 69 9.2 Informative References . . . . . . . . . . . . . . . . . . . 14 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 71 Intellectual Property and Copyright Statements . . . . . . . . 16 73 1. Introduction 75 Conference applications often have shared resources such as the right 76 to talk, input access to a limited-bandwidth video channel, or a 77 pointer or input focus in a shared application. 79 In many cases, it is desirable to be able to control who can provide 80 input (send/write/control, depending on the application) to the 81 shared resource. 83 Floor control enables applications or users to gain safe and mutually 84 exclusive or non-exclusive input access to the shared object or 85 resource. The floor is an individual temporary access or 86 manipulation permission for a specific shared resource (or group of 87 resources) [7]. 89 Floor control is an optional feature for conferencing applications. 90 SIP [2] conferencing applications may also decide not to support this 91 feature at all. Two-party applications may use floor control outside 92 conferencing, although the usefulness of this kind of scenario is 93 limited. Floor control may be used together with conference policy 94 control protocol (CPCP) [8], or it may be used as independent 95 standalone protocol, e.g. with SIP but without CPCP. 97 Floor control has been studied extensively over the years, (e.g. 98 [9], [7], [6]) therefore earlier work can be leveraged here. 100 The present document describes the requirements for a floor control 101 protocol. As a requirements specification, the document makes no 102 assumptions about the later implementation of the respective 103 requirements as parts of one or more protocols and about the entities 104 implementing it/them and their roles. 106 This document may be used in conjunction with other documents, such 107 as the Conferencing framework document [3]. In particular, when 108 speaking about a floor control server, this entity may be identical 109 to or co-located with the focus or a conference policy server defined 110 in the framework document, while participants and floor chairs 111 referred to in this specificiation may be regular participants as 112 introduced in the conferencing framework document. The term "floor 113 control protocol" is used in an abstract sense in this specification 114 and may ultimately be mapped to any of the existing conference 115 control or other signaling protocols (including CPCP and SIP). But 116 defining those relationships is left to a concrete floor control 117 protocol specification. 119 2. Conventions Used in This Document 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in RFC 2119. 125 3. Terminology 127 This document uses the definitions from [3]. 129 The following additional definitions apply: 131 Floor: A permission to temporarily access or manipulate a specific 132 shared resource or set of resources. 134 Conference owner: A privileged user who controls the conference, 135 creates floors and assigns and deassigns floor chairs. The 136 conference owner does not have to be a member in a conference. 138 Floor chair: A user (or an entity) who manages one floor (grants, 139 denies or revokes a floor). The floor chair does not have to be a 140 member in a conference. 142 Floor control: A mechanism that enables applications or users to gain 143 safe and mutually exclusive or non-exclusive input access to the 144 shared object or resource. 146 Floor control server: A logical entity that maintains the state of 147 the floor(s) including which floors exists, who the floor chairs are, 148 who holds a floor, etc. Requests to manipulate a floor are directed 149 at the floor control server. 151 Floor request set: A logical data structure holding all requests for 152 a particular floor at a given point in time. 154 Floor holder set: A logical data structure identifying all 155 participants who currently hold the floor. 157 4. Model 159 The model for floor control comprises three logical entities: a 160 single floor control server, one or more floor chairs (moderators), 161 and any number of regular conference participants. 163 A floor control protocol is used to convey the floor control messages 164 among the floor chairs (moderators) of the conference, the floor 165 control server, and the participants of the conference. A 166 centralized architecture is assumed in which all messages go via one 167 point, the floor control server. Processing (granting or rejecting) 168 floor control requests is done by the one or more floor chairs or by 169 the server itself, depending on the policy. 171 Floor requests from the participants are received by the floor 172 control server and kept in an -- at the level of the floor control 173 protocol -- floor request set (i.e. are not ordered in any 174 particular fashion). The current floor holders are reflected in a 175 current floor holder set. Floor chairs are capable of manipulating 176 both sets to e.g. grant, revoke, reject, and pass the floor. 178 The order in which requests are processed, whether they are granted 179 or rejected, how many participants obtain a floor simultaneously, is 180 determined by a higher layer application operating on these sets and 181 is not confined by the floor control protocol. 183 A floor is associated with one or more media sessions. The 184 centralized conference server manages the floors and thus controls 185 access to the media sessions. There are two aspects to this: 1) The 186 server maintains and distributes consistent state information about 187 who has a certain floor at a certain point in time and does so 188 following some rule set. This provides all participants with the 189 necessary information about who is allowed to e.g. speak, but relies 190 on a cooperative behavior among all participants. 2) In addition, to 191 prevent individuals from ignoring the "hints" given by the floor 192 control server, the latter may -- e.g. in cooperation with other 193 functional entities -- enforce compliance with floor status, e.g. by 194 blocking media streams from participants not entitled to speak. The 195 floor control server controls the floors at least at the signaling 196 level (1); actively controlling also the actual (physical) media 197 resources (2) is highly recommended, but beyond the scope of this 198 document. 200 As noted in the introduction, an actual protocol specification 201 fulfilling the requirements defined in this memo may map the 202 components of the above model onto the conferencing components 203 defined in the conferencing framework document. Some of these 204 aspects are discussed briefly in the next subsection. 206 5. Integration with Conferencing 208 Floor control itself does not support privileges such as creating 209 floors and appointing floor chairs, handing over chair privileges to 210 other users (or taking them away). Instead, some external mechanism, 211 such as conference management (e.g. CPCP or web interface for policy 212 manipulation) is used for that. 214 The conference policy (and thus the conference owner or creator) 215 defines whether floor control is in use or not. Actually enforcing 216 conference media distribution in line with the respective media's 217 floor status (e.g. controlling an audio bridge) is beyond the scope 218 of this document. Floor control itself does not define media 219 enforcement. It is up to the conference and media policies to define 220 which media streams may be used in a conference and which ones are 221 floor controlled. 223 Typically, the conference owner creates the floor(s) using conference 224 policy control protocol (or some other mechanism) and appoints the 225 floor chair. The conference owner can remove the floor anytime (so 226 that a media session is not floor-controlled anymore) or change floor 227 chair or floor parameters. 229 The floor chair just controls the access to the floor(s), according 230 to the conference policy. 232 A floor control server is a separate logical entity, typically 233 co-located with focus and/or conference policy server. Therefore, 234 the floor control server can interact with focus, conference Policy 235 Server and media servers as needed. Communication mechanisms between 236 floor control server and other central conferencing entities are not 237 within the scope of the floor control protocol requirements described 238 in this document. 240 Conferences may be cascaded and hence a single participant in one 241 conference representing a second conference (called subconference). 242 From a floor control perspective there is no difference between a 243 participant (identified by its URI) representing a single person or 244 another (set of) subconference(s). 246 Note: In the latter case, it is the responsibility of the 247 subconference to internally negotiate floor requests before passing 248 on a request to the conference and to internally assign a floor upon 249 receiving a floor grant. This may be done recursively by employing 250 the floor control protocol with a different floor control server in 251 the subconference. 253 6. Assumptions about a Conference Policy 255 The floor control protocol is supposed to be used to manage access to 256 shared resources in the context of a conference. It is up to this 257 conference -- more precisely: its conference policy [4] -- to define 258 the rules for the operation of the floor control protocol. 259 Furthermore, a conference policy control protocol [4] may define 260 mechanisms to alter those rules during the course of a conference. 261 This section briefly outlines the assumptions made by a floor control 262 protocol about the conference policy and means for its modification. 264 The conference policy is expected to define the rules for floor 265 control -- which particularly implies that it is not the 266 responsibility of the floor control protocol to establish or 267 communicate those rules. 269 In general, it is assumed that the conference policy also defines who 270 is allowed to create, change and remove a floor in a conference. 272 Conference participants and floor chairs should be able to get and 273 set floor-related parameters. The conference policy may restrict who 274 may access or alter which parameters. Note that not all parameters 275 maintained for a floor are also interpreted by the floor control 276 protocol (e.g. floor policy descriptions may be stored associated 277 with a floor but may be interpreted by a higher layer application). 278 Note also that changes to the floor control policy outside the scope 279 of the floor control protocol and e.g. to be carried out by a 280 conference policy control protocol. 282 (For example, it may be useful to see who the floor chair is, what 283 kind of policy is in use, time limits, number of simultanous floor 284 holders and current floor holder.) 286 These following requirements on a conference policy related to floor 287 control are identified in [4]: 289 REQ-F1: It MUST be possible to define whether floor control is in use 290 or not. 292 REQ-F2: It MUST be possible to define the algorithm to be used in 293 granting the floor. (Note: Example algorithms might be e.g. 294 moderator-controlled, FCFS, random.) 296 Note: it must be possible to use an automated floor policy where the 297 floor control server decides autonomously about granting, and 298 rejecting floor requests as well as revoking the floor. It must also 299 be possible to use a chair-controlled floor policy in which the floor 300 control server notifies the floor chair and waits for the chair to 301 make a decision. This enables the chair to fully control who has the 302 floor. The server MAY forward all requests immediately to the floor 303 chair, or it may do filtering and send only occasional notifications 304 to the chair. 306 REQ-F3: It MUST be possible to define how many users can have the 307 floor at the same time. 309 REQ-F4: It MUST be possible to have one floor for one or more media 310 types. 312 REQ-F5: It MUST be possible to have multiple floors in a conference. 314 REQ-F6: It MUST be possible to define whether a floor is 315 moderator-controlled or not. 317 REQ-F7: If the floor is moderator-controlled, it MUST be possible to 318 assign and replace the floor moderator. 320 7. Floor Control Protocol Requirements 322 This section covers the requirements on a floor control protocol. 323 The requirements are grouped as follows: 1) floor control protocol 324 between participant and server; 2) floor control protocol between 325 floor chairs and server; 3) floor control server management, and 4) 326 general protocol requirements. 328 7.1 Communication between Participant and Server 330 REQ-PS-1: Participants MUST be able to request (claim) a floor. 332 REQ-PS-2: It SHOULD be possible for a participant requesting a floor 333 to give additional information about the request, such as the topic 334 of the question for an audio floor. Note: In some scenarios, the 335 floor control server or the floor chair may use this information when 336 granting the floor to the user, or when making manipulation to the 337 floor sets at the server. 339 REQ-PS-3: It MUST be possible for a participant to modify (e.g. 340 cancel) a previously placed floor request. 342 REQ-PS-4: It SHOULD be possible for a participant to initiate a floor 343 control operation (e.g. floor request, release) on behalf of another 344 participant (third-party floor control) provided that he is 345 authorized to do so. 347 REQ-PS-5: A participant MUST be informed that she has been granted 348 the floor. 350 REQ-PS-6: A participant MUST be informed that his floor request has 351 been rejected. 353 REQ-PS-7: A participant MUST be informed that the floor was revoked 354 from her. 356 REQ-PS-8: A participant SHOULD be informed that her floor request is 357 pending and will be processed later. 359 REQ-PS-9: A floor holder MUST be able to release a floor. 361 REQ-PS-10: It MUST be possible to notify conference participants 362 (changes to) the floor holder(s) 364 REQ-PS-11: It MUST be possible to notify conference participants when 365 a new floor request is being made. 367 RRQ-PS-12: It MUST be possible for a floor requester to request 368 privacy for claiming the floor. 370 anonymous: the participants (including the floor chair) cannot see 371 the floor requester's identity. The floor chairs grant the floor 372 based on the claim id and the topic of the claim. 374 known to the floor chair: only the floor chair is able to see the 375 floor requester's identity; all other participants do not obtain this 376 information. 378 public: all the participants can see the floor requester's identity. 380 REQ-PS-13: It MUST be possible for a participant to request privacy 381 for holding the floor along with a floor request. Note that identity 382 information about the particpant may become available to others 383 through different means (e.g. application/media protocols or the 384 mmedia itself such as the voice). 386 7.2 Communicaton between Chair and Server 388 REQ-CS-1: It MUST be possible to inform the floor chairs, if present, 389 about a participant's floor request. 391 It SHOULD be possible to convey additional information the 392 participant may have provided along with her request. 394 It MUST be possible to hide the requesting participant's identity 395 from the chair, i.e. not include this identity information in the 396 floor request. 398 REQ-CS-2: It MUST be possible to grant a floor to a participant. 400 REQ-CS-3: It MUST be possible to reject a participant's floor 401 request. 403 REQ-CS-4: The floor chair MUST be able to revoke a floor from (one 404 of) its current holder(s). Note that the floor chair may also remove 405 pending floor requests from the request set (by rejecting them). 407 REQ-CS-5: It MUST be possible to notify floor chairs about changes to 408 the floor holder(s) 410 REQ-CS-6: There SHOULD be operations to manipulate the request set 411 available for floor chair(s). Such request set SHOULD at least 412 include creating, maintaining, and re-ordering floor requests a queue 413 and clearing the floor control queue. 415 RRQ-CS-7: It MUST be possible to hide the identity of a floor chair 416 from a subset or all participants of a conference. 418 REQ-CS-8: It MUST be possible for a newly assigned floor chair to 419 learn about (e.g. inquire) the existing floor request set. 421 7.3 General Protocol Requirements 423 REQ-GEN-1: Bandwidth and terminal limitations SHOULD be taken into 424 account in order to ensure that floor control can be efficiently used 425 in mobile environments. 427 It should be noted that efficient communication by means of minimal 428 sized messages may contradict the desire to express reasons for 429 requesting a floor along with other information. Therefore, a floor 430 control protocol SHOULD be designed in a way that it allow for 431 expressive as well as minimal messaging, as (negotiable) 432 configuration option and/or selectable on a per-message basis. 434 REQ-GEN-2: The floor control MUST be a reliable client-server 435 protocol. Hence, it MUST provide a positive response indicating that 436 a request has been received or an error response if an error has 437 occurred. 439 REQ-GEN-3: It MUST be possible for the floor control server to 440 authenticate participants and chairs. 442 REQ-GEN-4: It MUST be possible for the participants and chairs to 443 authenticate the server. 445 REQ-GEN-5: It MUST be possible to ensure message integrity between 446 participants and chairs and the floor control server. 448 REQ-GEN-6: It MUST be possible to ensure privacy of messages 449 exchanged between participants and chairs and the floor control 450 server. 452 8. Acknowledgements 454 The authors would like to thank IETF conferencing design team and 455 Keith Drage, Marcus Brunner, Sanjoy Sen, Eric Burger, Brian Rosen, 456 and Nermeen Ismail for their feedback. 458 9. References 460 9.1 Normative References 462 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 463 Levels", RFC 2119, BCD 14, March 1997. 465 [2] Rosenberg et al., J., "SIP: Session Initiation Protocol", RFC 466 3261, June 2002. 468 [3] Rosenberg, J., "A Framework for Conferencing with the Session 469 Initiation Protocol", 470 draft-ietf-sipping-conferencing-framework-02.txt (work in 471 progress), June 2004. 473 9.2 Informative References 475 [4] Koskelainen, P. and H. Khartabil, "Additional Requirements to 476 Conferencing", August 2004. 478 [5] Wu, X., Schulzrinne, H. and P. Koskelainen, "Use of SIP and SOAP 479 for conference floor control", January 2003. 481 [6] Koskelainen, P., Schulzrinne, H. and X. Wu, "A sip-based 482 conference control framework", Nossdav'2002 Miami Beach, May 483 2002. 485 [7] Dommel, H. and J. Garcia-Luna-Aceves, "Floor control for 486 activity coordination in networked multimedia applications", 487 Proc. of 2nd Asian-pacific Conference on Communications APPC, 488 Osaka Japan, June 1995. 490 [8] Koskelainen, P., Khartabil, H. and A. Niemi, "The Conference 491 Policy Control Protocol (CPCP)", draft-ietf-xcon-cpcp-01.txt 492 (work in progress), October 2004. 494 [9] Borman, C., Kutscher, D., Ott, J. and D. Trossen, "Simple 495 conference control protocol service specification", 496 draft-ietf-mmusic-sccp-00.txt (work in progress), March 2001. 498 Authors' Addresses 500 Petri Koskelainen 501 Nokia 502 5 Wayside Road 503 Burlington 01803 504 USA 506 EMail: petri.koskelainen@nokia.com 508 Joerg Ott 509 Uni Bremen TZI 510 Bibliothekstr. 1 511 Bremen D-28359 512 Germany 514 EMail: jo@tzi.uni-bremen.de 516 Henning Schulzrinne 517 Columbia University 518 1214 Amsterdam Avenue 519 New York 10027 520 USA 522 EMail: hgs@cs.columbia.edu 524 Xiaotao Wu 525 Columbia University 526 1214 Amsterdam Avenue 527 New York 10027 528 USA 530 EMail: xiaotaow@cs.columbia.edu 532 Intellectual Property Statement 534 The IETF takes no position regarding the validity or scope of any 535 Intellectual Property Rights or other rights that might be claimed to 536 pertain to the implementation or use of the technology described in 537 this document or the extent to which any license under such rights 538 might or might not be available; nor does it represent that it has 539 made any independent effort to identify any such rights. Information 540 on the procedures with respect to rights in RFC documents can be 541 found in BCP 78 and BCP 79. 543 Copies of IPR disclosures made to the IETF Secretariat and any 544 assurances of licenses to be made available, or the result of an 545 attempt made to obtain a general license or permission for the use of 546 such proprietary rights by implementers or users of this 547 specification can be obtained from the IETF on-line IPR repository at 548 http://www.ietf.org/ipr. 550 The IETF invites any interested party to bring to its attention any 551 copyrights, patents or patent applications, or other proprietary 552 rights that may cover technology that may be required to implement 553 this standard. Please address the information to the IETF at 554 ietf-ipr@ietf.org. 556 Disclaimer of Validity 558 This document and the information contained herein are provided on an 559 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 560 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 561 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 562 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 563 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 564 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 566 Copyright Statement 568 Copyright (C) The Internet Society (2004). This document is subject 569 to the rights, licenses and restrictions contained in BCP 78, and 570 except as set forth therein, the authors retain all their rights. 572 Acknowledgment 574 Funding for the RFC Editor function is currently provided by the 575 Internet Society.