idnits 2.17.1 draft-govindan-capwap-objectives-00.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 521. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 528. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 534. ** 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 18 longer pages, the longest (page 12) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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 2004) is 7132 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'TBD' is mentioned on line 411, but not defined -- Possible downref: Normative reference to a draft: ref. 'I-D.cheng-capwap-classifications' == Outdated reference: A later version (-06) exists of draft-ietf-capwap-arch-05 ** Downref: Normative reference to an Informational draft: draft-ietf-capwap-arch (ref. 'I-D.ietf-capwap-arch') ** Downref: Normative reference to an Informational draft: draft-ietf-capwap-problem-statement (ref. 'I-D.ietf-capwap-problem-statement') Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group S. Govindan 2 Internet-Draft H. Cheng 3 Expires: April 2005 S. Iino 4 M. Sugiura 5 Panasonic 6 October 2004 8 Objectives for Control and Provisioning of Wireless Access Points 9 (CAPWAP) 10 draft-govindan-capwap-objectives-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire in April 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 43 Abstract 45 This document presents objectives for the Control and Provisioning of 46 Wireless Access Points (CAPWAP) framework. Primarily it presents a 47 fundamental objective for interoperability among wireless local area 48 network (WLAN) devices of different designs. The document also 49 describes additional objectives for shared WLAN infrastructure and 50 QoS. 52 Table of Contents 54 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3. Adaptive Interfaces Objective . . . . . . . . . . . . . . . . 5 57 3.1 Objective Details . . . . . . . . . . . . . . . . . . . . 5 58 3.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 5 59 3.3 Relation to Problem Statement . . . . . . . . . . . . . . 5 60 3.4 Customer Requirements . . . . . . . . . . . . . . . . . . 6 61 4. Logical Networks Support . . . . . . . . . . . . . . . . . . . 7 62 4.1 Objective Details . . . . . . . . . . . . . . . . . . . . 7 63 4.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 7 64 4.3 Relation to Problem Statement . . . . . . . . . . . . . . 7 65 4.4 Customer Requirements . . . . . . . . . . . . . . . . . . 7 66 5. Coexistence of Multiple Authentication Mechanisms . . . . . . 9 67 5.1 Objective Details . . . . . . . . . . . . . . . . . . . . 9 68 5.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 9 69 5.3 Relation to Problem Statement . . . . . . . . . . . . . . 9 70 5.4 Customer Requirements . . . . . . . . . . . . . . . . . . 9 71 6. Automated Processes Objective . . . . . . . . . . . . . . . . 10 72 6.1 Objective Details . . . . . . . . . . . . . . . . . . . . 10 73 6.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 10 74 6.3 Relation to Problem Statement . . . . . . . . . . . . . . 10 75 6.4 Customer Requirements . . . . . . . . . . . . . . . . . . 10 76 7. WLAN Status Monitoring Objective . . . . . . . . . . . . . . . 11 77 7.1 Objective Details . . . . . . . . . . . . . . . . . . . . 11 78 7.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 11 79 7.3 Relation to Problem Statement . . . . . . . . . . . . . . 11 80 7.4 Customer Requirements . . . . . . . . . . . . . . . . . . 11 81 8. QoS Objective . . . . . . . . . . . . . . . . . . . . . . . . 12 82 8.1 Objective Details . . . . . . . . . . . . . . . . . . . . 12 83 8.2 Protocol Benefits . . . . . . . . . . . . . . . . . . . . 12 84 8.3 Relation to Problem Statement . . . . . . . . . . . . . . 12 85 8.4 Customer Requirements . . . . . . . . . . . . . . . . . . 13 86 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 10. Security Considerations . . . . . . . . . . . . . . . . . . 15 88 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 91 Intellectual Property and Copyright Statements . . . . . . . . 18 93 1. Requirements notation 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 2. Introduction 101 The first phase of standardization for the Control and Provisioning 102 of Wireless Access Points (CAPWAP) has resulted in the recognition of 103 major problems associated with large scale wireless local area 104 network (WLAN) deployments [I-D.ietf-capwap-problem-statement]. 105 Briefly, these relate to management complexity, configuration 106 consistency, management of wireless medium and WLAN security. 108 The WLAN landscape, in the context of design variants, was also 109 surveyed as part of this initial phase. The Architecture Taxonomy 110 [I-D.ietf-capwap-arch] classifies WLANs in to three major 111 architecture families; remote MAC, split MAC and local MAC. Each 112 differs in the degree of separation of MAC layer capabilities among 113 access points (APs) and WLAN controller. 115 This document puts forth critical objectives for realizing 116 interoperability in a CAPWAP framework. It presents a basic 117 objective for APs of different architectural designs to interoperate 118 within a single WLAN controller domain. The realization of this 119 objective will enable true interoperability in that major WLAN 120 designs may be integrally deployed and managed. 122 Additional objectives put forth in this document relate to Qos and 123 shared infrastructure deployments. Such deployments are increasingly 124 popular in the commercial market as they offer cost benefits and 125 flexibility. Details of the deployment scenario are provided in 126 [I-D.cheng-capwap-classifications]. 128 3. Adaptive Interfaces Objective 130 With the focusing of standardization efforts on local MAC and split 131 MAC designs, it is crucial to ensure mutual interoperation among 132 them. This is emphasized in the first objective. 134 3.1 Objective Details 136 The first objective for CAPWAP is to ensure that APs designed for 137 both local MAC and split MAC architectures are capable of 138 interoperation within a single WLAN. On the basis of this objective, 139 the CAPWAP protocol will utilize adaptive interfaces corresponding to 140 the design variants. [I-D.cheng-capwap-classifications] presents 141 additional details on how flexibility in the CAPWAP protocol may be 142 achieved so as to realize this objective. 144 This objective also addresses the need for flexibly configuring APs 145 based on their design types and other setup aspects. 147 3.2 Protocol Benefits 149 The benefits of realizing the adaptive interfaces objective are both 150 technical and practical. First, there are substantial overlaps in 151 the control operations between the local MAC and split MAC 152 architectures. As a result, it is technically practical to devise a 153 single protocol that manages both types of devices. 155 Next, the ability to operate a CAPWAP protocol for both types of 156 architectural designs enhances its practical prospects as it will 157 have wider appeal. 159 Furthermore, the additional complexity resulting from such adaptive 160 interfaces is marginal. Consequently, the benefits of this objective 161 will far outweigh any cost of realizing it. 163 3.3 Relation to Problem Statement 165 The objective for adaptive interfaces between APs and WLAN 166 controllers is fundamental to addressing the Problem Statement 167 [I-D.ietf-capwap-problem-statement]. It forms the basis for those 168 problems to be uniformly addressed across the major WLAN 169 architectures. This is the ultimate aim of standardization efforts. 170 The realization of this first objective will ensure that the 171 solutions for [I-D.ietf-capwap-problem-statement] are consistent for 172 both WLAN designs. 174 3.4 Customer Requirements 176 A number of service providers and equipment vendors see benefits with 177 the combined usage of both local MAC and split MAC designs. APs of 178 different designs are placed in different locations so as to 179 selectively take advantage of their respective characteristics. The 180 adaptive interface objective therefore addresses critical needs for 181 the market. 183 Furthermore, since there are products of each design type already in 184 the market and widely deployed, it is necessary for CAPWAP protocol 185 to support both of them. 187 [TBD] 189 4. Logical Networks Support 191 Large WLANs are complex systems that need to be closely managed for 192 optimal performance. Furthermore, they are expensive to deploy and 193 enterprises are under pressure to improve the efficiency of their 194 expenditures. These issues are being addressed by means of deploying 195 a number of logical networks over a single physical WLAN 196 infrastructure. This way the cost of deployment and management can 197 be shared. A scenario together with additional details for such 198 shared WLANs is presented in [I-D.cheng-capwap-classifications]. 200 4.1 Objective Details 202 The objective for supporting logical networks involves mutual 203 separation of control and communications among them. Large WLANs are 204 therefore controlled in terms of distinct logical networks. So, a 205 number of service providers may jointly utilize network 206 infrastructure thereby sharing expenditures. 208 4.2 Protocol Benefits 210 Given the realities of cost and complexity of WLANs, a CAPWAP 211 protocol that incorporates this objective ensures simpler and cost 212 effective WLAN management and deployment. A protocol that realizes 213 this is therefore consistent with the goal of reducing complexity in 214 large scale WLANs. 216 4.3 Relation to Problem Statement 218 This objective for supporting logical networks directly addresses 219 problem of management complexity. It is solved by breaking 220 complexity in to manageable levels. So different logical networks 221 are separated and then individually managed. 223 4.4 Customer Requirements 225 Businesses require the benefits of management ease by the most cost 226 effective means. This can be achieved with the objective of 227 supporting logical networks within a single set of physical WLAN 228 equipment. There are a number of ways of realizing this objective 229 some being virtual APs, VLAN tunnels and other tunnels. 231 This objective also allows for separation between providers of 232 infrastructure from services. Logical networks allows for the 233 separation of physical deployment and maintenance from actual 234 management of WLANs. This helps lower costs and responsibilities for 235 service providers. 237 [TBD] 239 5. Coexistence of Multiple Authentication Mechanisms 241 As WLANs grow in size and utility, there are increasing means of 242 authenticating subscribers. The choice of which to use depends on 243 the deployment scenario, service provider preference and other design 244 aspects. This objective addresses such diversity. 246 5.1 Objective Details 248 The objective is to include support for multiple authentication 249 mechanisms. This is to ensure that a CAPWAP protocol has a framework 250 where different types of authentication may coexist. In practice, 251 the different mechanisms may coexist within a single logical WLAN or 252 among a number of them. In either case, protocol support is 253 critical. 255 5.2 Protocol Benefits 257 A protocol that includes support for a number of authentication 258 mechanisms will be applicable in a wide range of deployments and 259 scenarios. 261 5.3 Relation to Problem Statement 263 This objective relates to large WLAN deployments where there are a 264 variety of requirements from service providers, subscribers and 265 regulators. Authentication mechanisms will therefore differ for 266 various requirements. In order to accommodate all these differences, 267 the CAPWAP protocol must support multiple authentication mechanisms. 269 5.4 Customer Requirements 271 Customers are demanding choice and flexibility in the way in which 272 they use WLANs. For example, service providers want different ways 273 of authenticating different subscriber groups; some groups need IEEE 274 802.1X while others web-based authentication. Furthermore, there are 275 trends for temporary authentications where the duration of 276 authentication is adapted. This objective is in response to such 277 requirements. 279 [TBD] 281 6. Automated Processes Objective 283 WLANs are increasing in complexity due to the sheer size of 284 deployments. As a result, the cost of operating and managing 285 wireless networks is becoming substantial. This section presents an 286 objective for automating key processes of WLAN control by which 287 operational costs may be reduced. 289 6.1 Objective Details 291 The objective is to simplify and automate discovery and 292 initialization processes. New AP designs being inexpensive and easy 293 to install, allow for frequent alterations to the physical WLAN 294 according to deployment needs. This calls for automating the 295 processes for setting up new WLAN devices. 297 6.2 Protocol Benefits 299 Automation is a key benefit to a CAPWAP protocol as it makes for 300 cost-effective deployment. This has a direct effect on the adoption 301 of the protocol. 303 6.3 Relation to Problem Statement 305 This objective for automation is derived from the problem of managing 306 complexity. The problem relates to large scale deployments in which 307 discovery and initialization are intensive, error-prone and 308 consequently, costly, operations. Realization of this objective will 309 be a direct solution to this problem. 311 6.4 Customer Requirements 313 Wireless network service providers have consistently required 314 cost-effective solutions. As these providers are predominantly 315 commercial, this objective is crucial for realization. 317 [TBD] 319 7. WLAN Status Monitoring Objective 321 The scale of WLANs that CAPWAP addresses results in a number of 322 challenges. Among them, is the possibility of multiple points of 323 failure at different time instances. 325 7.1 Objective Details 327 This objective is for monitoring the status of WLANs, including 328 various devices, so as to appropriately configure and manage them. 329 WLAN status is used broadly here to include statistics, keepalive 330 signals and other input information. Status information may 331 therefore be combined in the realization of this objective. 333 7.2 Protocol Benefits 335 The effectiveness of a protocol is based on the relevance of 336 information on which it operates. So, the fulfillment of this 337 objective will ensure that such information is made available to a 338 CAPWAP protocol. 340 7.3 Relation to Problem Statement 342 This objective addresses the problems of management complexity and 343 WLAN configuration for which solutions require appropriate 344 information. For the former problem, the scale, type and active 345 status of the WLAN is required, while in the latter, consistent 346 configurations are maintained based on timely information. 348 7.4 Customer Requirements 350 WLAN equipment customers require effective management solutions for 351 their networks. This objective will ensure such a solution by 352 providing the appropriate information on traffic conditions and 353 network status. 355 [TBD] 357 8. QoS Objective 359 Integral to the success of any wireless network system is the 360 performance and quality it can offer its subscribers. So for large 361 scale WLANs, system-wide QoS is particularly important. 363 8.1 Objective Details 365 The objective is for QoS over the entire WLAN system which includes 366 the switching segment and the wireless medium. Given the fundamental 367 differences between the two, it is likely that there are alternate 368 QoS mechanisms between APs and wireless service subscribers and 369 between APs and WLAN controllers. So resources need to be adjusted 370 over both portions of the system so as to ensure throughput and other 371 performance. 373 8.2 Protocol Benefits 375 A protocol that addresses QoS aspects of WLAN systems will deliver 376 high performance thereby beneficial for wireless subscribers and 377 resource utilization. Since CAPWAP deals with APs directly and with 378 the wireless medium indirectly, both of these must be considered for 379 performance. 381 For the wireless medium portion, QoS aspects in the protocol enable 382 high quality communications within the domain of a WLAN controller. 383 Since each domain generally covers an enterprise, such protocol 384 performance affects enterprise-wide communications. 386 Within the switching segment of CAPWAP, a QoS-enabled protocol 387 minimizes the adverse effects of dynamic traffic characteristics so 388 as to ensure system-wide performance. 390 8.3 Relation to Problem Statement 392 QoS control is critical to large WLANs and relates to a number of 393 aspects. In particular, this objective addresses the problem of 394 accommodating dynamic conditions of the wireless medium. 396 Furthermore, traffic characteristics in large scale WLANs are 397 constantly varying. So network utilization becomes inefficient and 398 user experience is unpredictable. 400 The interaction and coordination between the two aspects of 401 system-wide QoS is therefore critical for performance. 403 8.4 Customer Requirements 405 VoIP is a major application over WLANs. The basic requirement for 406 such applications is QoS. Furthermore, end-users demand quality 407 means of communications, so service providers in turn emphasize on 408 the QoS capabilities of WLAN systems. Adopting this objective will 409 ensure all demands are met. 411 [TBD] 413 9. Conclusion 415 This draft presents critical objectives for the CAPWAP framework. 416 Most importantly, it lays down the need for enabling CAPWAP over 417 adaptive interfaces so that APs of both local MAC and split MAC 418 designs are integrally manageable and controlled. The document also 419 provides additional objectives for shared infrastructure and QoS. 421 10. Security Considerations 423 The adaptive interface objective covers the interoperability of APs 424 from both local MAC and split MAC designs. As such, a WLAN 425 controller must be capable of securing both of these design types. 426 This may include handling different degrees of security or 427 authentication processing for the two types of APs. 429 In shared deployments with a number of a when a number logical 430 networks, it is crucial to ensure mutual separation of traffic among 431 them. Access control should therefore be distinct for each of the 432 logical networks. Furthermore, subscribers to different service 433 providers need to be managed based on their respective requirements, 434 subscriptions, etc. Cross exchanges need to be secured against. 436 It should be ensured that any stray exchange be prevented with the 437 automation of discovery and initialization processes. 439 The objective for WLAN status monitoring relates to security also. 440 Wireless systems need to be constantly monitored for potential 441 threats in the form of rogue APs or terminals. For example, profiles 442 for DoS and replay attacks need to be monitored. 444 11. Acknowledgements 446 The authors gratefully thank T. Sridhar for reviewing an earlier 447 version of this draft. 449 12 References 451 [I-D.cheng-capwap-classifications] 452 Cheng, H., Iino, S. and Govindan S., "Funcationality 453 Classifications for Control and Provisioning of Wireless 454 Access Points", draft-cheng-capwap-classifications-01 455 (work in progress), July 2004. 457 [I-D.ietf-capwap-arch] 458 Yang, L., Zerfos, P. and E. Sadot, "Architecture Taxonomy 459 for Control and Provisioning of Wireless Access 460 Points(CAPWAP)", draft-ietf-capwap-arch-05 (work in 461 progress), August 2004. 463 [I-D.ietf-capwap-problem-statement] 464 Calhoun, P., "CAPWAP Problem Statement", 465 draft-ietf-capwap-problem-statement-02 (work in progress), 466 September 2004. 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, March 1997. 471 Authors' Addresses 473 S. Govindan 474 Panasonic Singapore Laboratories 475 Block 1022, Tai Seng Industrial Estate 476 #06-3530, Tai Seng Avenue 477 Singapore 534415 478 Singapore 480 Phone: +65 6550 5441 481 EMail: sgovindan@psl.com.sg 482 H. Cheng 483 Panasonic Singapore Laboratories 484 Block 1022, Tai Seng Industrial Estate 485 #06-3530, Tai Seng Avenue 486 Singapore 534415 487 Singapore 489 Phone: +65 6550 5477 490 EMail: hcheng@psl.com.sg 492 S. Iino 493 Panasonic Mobile Communications 494 600, Saedo-cho 495 Tsuzuki-ku 496 Yokohama 224-8539 497 Japan 499 Phone: +81 45 938 3789 500 EMail: iino.satoshi@jp.panasonic.com 502 M. Sugiura 503 Panasonic Mobile Communications 504 600, Saedo-cho 505 Tsuzuki-ku 506 Yokohama 224-8539 507 Japan 509 Phone: +81 45 938 3789 510 EMail: sugiura.mikihito@jp.panasonic.com 512 Intellectual Property Statement 514 The IETF takes no position regarding the validity or scope of any 515 Intellectual Property Rights or other rights that might be claimed to 516 pertain to the implementation or use of the technology described in 517 this document or the extent to which any license under such rights 518 might or might not be available; nor does it represent that it has 519 made any independent effort to identify any such rights. Information 520 on the procedures with respect to rights in RFC documents can be 521 found in BCP 78 and BCP 79. 523 Copies of IPR disclosures made to the IETF Secretariat and any 524 assurances of licenses to be made available, or the result of an 525 attempt made to obtain a general license or permission for the use of 526 such proprietary rights by implementers or users of this 527 specification can be obtained from the IETF on-line IPR repository at 528 http://www.ietf.org/ipr. 530 The IETF invites any interested party to bring to its attention any 531 copyrights, patents or patent applications, or other proprietary 532 rights that may cover technology that may be required to implement 533 this standard. Please address the information to the IETF at 534 ietf-ipr@ietf.org. 536 Disclaimer of Validity 538 This document and the information contained herein are provided on an 539 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 540 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 541 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 542 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 543 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 544 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 546 Copyright Statement 548 Copyright (C) The Internet Society (2004). This document is subject 549 to the rights, licenses and restrictions contained in BCP 78, and 550 except as set forth therein, the authors retain all their rights. 552 Acknowledgment 554 Funding for the RFC Editor function is currently provided by the 555 Internet Society.