idnits 2.17.1 draft-ietf-mboned-multiaaa-framework-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 657. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 668. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 675. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 681. ** 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. 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 (October 23, 2006) is 6394 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) == Outdated reference: A later version (-10) exists of draft-ietf-mboned-maccnt-req-04 ** Downref: Normative reference to an Informational draft: draft-ietf-mboned-maccnt-req (ref. '1') Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft AAA Framework for Multicasting October 2006 4 Hiroaki Satou, NTT 5 Internet Draft Hiroshi Ohta, NTT 6 Expires: April 26, 2007 Christian Jacquenet, France Telecom 7 Tsunemasa Hayashi, NTT 8 Haixiang He, Nortel Networks 10 October 23, 2006 12 AAA Framework for Multicasting 13 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 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 Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other documents 29 at any time. It is inappropriate to use Internet-Drafts as 30 reference 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 26, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006) 44 Abstract 45 IP multicast-based services, such as TV broadcasting or 46 videoconferencing raise the issue of making sure that potential 47 customers are fully entitled to access the corresponding contents. 48 There is indeed a need for service and content providers to identify 49 (if not authenticate, especially within the context of enforcing 50 electronic payment schemes) and to invoice such customers in a 51 reliable and efficient manner. This memo describes the framework for 52 specifying the Authorization, Authentication and Accounting (AAA) 53 capabilities that could be activated within the context of the 54 deployment and the operation of IP multicast-based services. This 55 framework addresses the requirements presented in draft-ietf-mboned- 56 maccnt-req-04.txt, "Requirements for Accounting, Authentication and 57 Authorization in Well Managed IP Multicasting Services". 59 1. Introduction 61 1.1 Purpose and Background 62 IP multicasting is designed to serve cases of group communication 63 schemes of any kind, such as 1-to-n (case of TV broadcasting 64 services for example) or n-to-p (case of videoconferencing services, 65 for example). 66 In these environments, IP multicast provides a better resource 67 optimization than using a unicast transmission scheme, where data 68 need to be replicated as many times as there are receivers. 69 Activation of IP multicast capabilities in networks yields the 70 establishment and the maintenance of multicast distribution trees 71 that are receiver-initiated by nature: multicast-formatted data are 72 forwarded to receivers who explicitly request them. 74 IP multicast-based services, such as TV broadcasting or 75 videoconferencing raise the issue of making sure that potential 76 customers are fully entitled to access the corresponding contents. 77 There is indeed a need for service and content providers to identify 78 (if not authenticate, especially within the context of enforcing 79 electronic payment schemes) and to invoice such customers in a 80 reliable and efficient manner. This memo describes the framework for 81 specifying the Authorization, Authentication and Accounting (AAA) 82 capabilities that could be activated within the context of the 83 deployment and the operation of IP multicast-based services. 84 Specifically, this framework addresses the requirements 85 presented in draft-ietf-mboned-maccnt-req-04.txt, "Requirements for 86 Accounting, Authentication and Authorization in Well Managed IP 87 Multicasting Services" MACCNT-REQ-draft describes the requirements 88 in CDN services using IP multicast[1]. The requirements are derived 89 from: 90 - need for user tracking and billing capabilities 91 - need for network access control to satisfy the requirements 92 of the Network Service Provider (NSP) and/or content access control 93 to satisfy the requirements of the Content Provider (CP) 94 - methods for sharing information between the network service 95 provider and content provider to make it possible to fulfill the 96 above two requirements. 98 Detailed requirements are presented in MACCNT-REQ-draft. These 99 requirements include mechanisms for recording end-user requests and 100 provider responses for content-delivery, sharing user information 101 (possibly anonymously depending on the trust model) between content 102 provider and network service provider, and protecting resources 103 through the prevention of network and content access by unauthorized 104 users, as well as other AAA related requirements. 106 The purpose of this memo is to provide a generalized framework for 107 specifying multicast-inferred AAA capabilities that can meet these 108 requirements. This framework is to provide a basis for future work 109 of investigating the applicability of existing AAA protocols to 110 provide these AAA capabilities in IP multicast specific context 111 and/or if deemed necessary, the refining or defining of protocols to 112 provide these capabilities. 114 This draft's scope is limited to discussing SSM, 1-to-n IP 115 multicasting exclusively. 117 2. Definitions and Abbreviations 119 2.1 Definitions 121 For the purpose of this memo the following definitions apply: 123 Accounting: The set of capabilities that allow the retrieval of a 124 set of statistical data that can be defined on a per customer and/or 125 a per service basis, within the context of the deployment of 126 multicast-based services. Such data are retrieved for billing 127 purposes, and can be retrieved on a regular basis or upon 128 unsolicited requests. Such data include (but are not necessarily 129 limited to) the volume of multicast-formatted data that have been 130 forwarded to the receiver over a given period of time, the volume of 131 multicast-formatted data that have been exchanged between a receiver 132 (or set of) and a given source over a given period of time (e.g. the 133 duration of a multicast session), etc. 135 Authentication: action for identifying a user as a genuine one. 137 Authorization: The set of capabilities that need to be activated to 138 make sure a given requesting customer is (1) what he claims to be 139 (identification purposes), and (2) is fully entitled to access a set 140 of services (authentication purposes). 142 Receiver: an end-host or end-client which receives content. A 143 receiver may be identified by a network ID such as MAC address or IP 144 address. 146 User: a human with a user account. A user may possibly use multiple 147 reception devices. Multiple users may use the same reception device. 149 Note: The definition of a receiver (device) and a user (human) 150 should not be confused. 152 2.2 Abbreviations 154 For the purpose of this draft the following abbreviations apply: 156 ACL: Access Control List 158 CDN: Content Delivery Network 160 CDS: Content Delivery Services 162 CP: Content Provider 164 NSP: Network Service Provider 166 TP: Transit Provider 168 3. Common use models and network architecture implications 170 In some cases a single entity may design and be responsible for a 171 system that covers the various common high-level requirements of a 172 multicasting system such as 1) content serving, 2) the 173 infrastructure to multicast it, 3) network and content access 174 control mechanisms. In many cases however the content provision and 175 network provision roles are divided between separate entities. The 176 MACCNT-REQ-draft provides more detail of the multiple versus single 177 entity CDS network model. 179 As such it should not be assumed that the entity responsible for the 180 multicasting structure and the entity responsible for content 181 serving are the same. Indeed because the infrastructure for 182 multicasting is expensive and many content holders are not likely to 183 be competent at building and maintaining complicated infrastructures 184 necessary for multicasting, many content holders would prefer to 185 purchase transport and management services from a network service 186 provider and thus share the infrastructure costs with other content 187 holders. 189 Similarly network service providers in many cases do not specialize 190 in providing content and are unlikely to build and maintain such a 191 resource-intensive system without a certain level of demand from 192 content holders. 194 The use model of a single NSP providing multicasting services to 195 multiple CPs the following general requirements from MACCNT-REQ- 196 draft apply: 198 -Need for user tracking and billing capabilities 199 -Need for network access control and/or content access control 200 satisfactory to the requirements of the CP 201 -Methods for sharing information between the NSP and CP to make 202 the above two possible 204 When the NSP and CP are the same single entity the general 205 requirements are as follows. 207 -Need for user tracking and user-billing capabilities 208 -Need for access control and/or content protection at level the 209 entity deems appropriate 211 4. Framework and Roles of Entities 213 4.1 Framework for multicast AAA 214 A general high-level framework can be represented as follows. 216 +------------------------------+ 217 | user | 218 | | 219 +------------------------------+ 220 | Access ^ Response 221 | Request | & Multicast Data 222 V | 223 +------------------------------+ 224 | NSP | 225 | | 226 +------------------------------+ 227 | Access ^ Response 228 | Request | (Success) 229 v | 230 +------------------------------+ 231 | CP | 232 | | 233 +------------------------------+ 235 For the sake of simplicity, the above diagram portrays a case where 236 there is a single NSP entity and a single CP entity, but multiple 237 CPs can be connected to the same NSP. It is also possible for the 238 same CP to be connected to multiple NSP networks (e.g. network 239 selection). In other words the relationship of NSP:CP can be 240 described as 1:1, 1:N or M:N. Furthermore it is possible that the 241 NSP and CP could be the same entity. 243 Description of Roles: 245 The user (or the user's device) selects a CP and a NSP when the user 246 requests content. The NSP may be automatically selected by a user 247 terminal: e.g. a fixed line NSP for STB or a mobile NSP for mobile 248 phone. In some usage cases it is possible that the NSP used by the 249 user terminal will not always be the same. For example a user may 250 have contracted with different NSPs for fixed line or mobile roaming 251 access. 253 The CP is responsible for Authentication and Authorization of users' 254 access to content that the CP manages. The CP hopes to collect 255 accounting information related to the access of their content. The 256 CP may choose to authenticate and authorize NSPs which are eligible 257 to provide users access to its contents. When the CP cannot (e.g. 258 error or resource issues) or decides not (e.g. policy issues) to 259 deliver content, the CP is responsible for notifying the NSP of the 260 reason. It is up to the NSP how to relay or translate the messages 261 to the user. 263 The NSP is responsible for managing its network resources. The NSP 264 may perform admission control. It is also responsible for relaying 265 the AAA messages from the CP whether the user is eligible to receive 266 content (authentication by proxy), and the NSPs relevant AAA server 267 will make the final decision of whether the connection can be 268 established. When the NSP cannot or decides not to multicast to 269 users, the NSP is responsible for notifying the users of the reason. 271 4.2 Multiple User IDs 273 Users may hold multiple user IDs: IDs which have been separately 274 assigned for each subscription they may have for various NSPs and 275 CPs. When the user wants to access content or otherwise use the 276 network, the user registers the corresponding user ID with a request 277 for content, etc: web authentication is one possible method. 279 Terminal portability can be realized if the NSP authenticates a user 280 using a user ID. This allows the user to access the content from 281 various network access points. 283 Each CP may identify users by the user IDs that it has issued to 284 them. 286 The NSP and CP do not need to know the corresponding user id for the 287 same user in the other provider's domain, and it is not necessary 288 that there is a one to one relationship. It is quite possible for 289 one person to hold multiple user ids for the same provider. 291 4.3 Accounting 293 MACCNT-REQ-draft defines requirements for Accounting and Billing. 294 These include the requirement for the NSP to log user behavior such 295 as the join action and the leave action, as well as the result of 296 the access-control decision. (MACCNT-REQ-draft, 4.5) MACCNT-REQ- 297 draft also specifies that there should be a standardized format for 298 sharing with the CP the user behavior and content reception 299 information which the NSP is logging.(MACCNT-REQ-draft, 4.5.1) 301 In order to provide the granularity of user-behavior and actual 302 content reception information as specified in MACCNT-REQ-draft, the 303 NSP should not manage multicast states on a subnet basis, but on a 304 user basis (see in MACCNT-REQ-draft, 4.1 "User identification") 305 because the NSP needs to be able to notify the CP of a user's start 306 and stop times for accounting purposes. This means that the NSP 307 sends to the CP AAA an indication for Join and Leave on a user basis. 309 This framework specifies an accounting API provided by the NSP and 310 accessed by the CP to allow for sharing user-behavior and content- 311 reception information between the NSP AAA and CP AAA. This 312 accounting API should be configurable to allow the CP to request 313 only the logging information it actually requires. Such an API 314 would allow for realtime accounting information sharing by the NSP 315 to the CP. When logging information is shared through the accounting 316 API, it is important that the CP be able to match the user as 317 described in the database operated by the NSP to the user as 318 described in the database operated by the CP. 320 The NSP requires the capability to log both user and host 321 information for each join and leave, indicating the corresponding 322 multicast source for each action. When either a CP source stops 323 sending, or the NSP stops multicasting, in an unsolicited manner, 324 there is also a need to notify the AAA servers accordingly about the 325 users who are impacted by this event. 327 Also, intermittent logs between the join and leave would allow for 328 finer diagnostics and therefore could serve useful in billing 329 discrepancies, and provide for a better estimation of the time span 330 that content was multicasted in the even that users disconnect 331 without sending leave messages. 333 4.4 Access Control and CP selection by NSP 335 When a NSP receives an access request from a user, it is necessary 336 for the NSP to determine to which CP the request is to be directed. 337 It is necessary for the NSP to ensure that it is not spoofed by an 338 inappropriate CP or user. 340 4.5 API for Admission Control Information by NSP 342 After authorizing a user request, the NSP may have further 343 conditions for determining its admission control decision. MACCNT- 344 REQ-draft defines requirements for providing the network capability 345 to conduct admission control based on the network bandwidth usage 346 status and bandwidth management policy. (MACCNT-REQ-draft, 4.2.2, 347 4.2.3 & 4.9) Such QoS measurement and policy mechanisms themselves 348 are out of the scope of this memo. However the NSP's AAA Server 349 should be provided with an Admission control API that allows for 350 interfacing so that additional conditions can be added to the 351 admission control decision. 353 4.6 Access Control and Distinguishing of Users by CP 355 The user ID and authentication information are forwarded 356 transparently by the NSP so that the CP can distinguish the user, as 357 well as authenticate and authorize the request. 359 4.7 Caching of AAA results 361 An NSP should be able to cache AAA results based upon an agreement 362 between the NSP and a CP. The AAA cache would store information 363 about permissions of a specific user to receive multicast data from 364 specified channel(s) up to specified expiration date(s) and time(s). 365 If such caching is implemented, a method must exist for the CP to 366 communicate this permission information to the NSP. The NSP refers 367 to the AAA cache and if the cache indicates that the user has 368 permission to receive multicast data from a specific channel at that 369 time, the NSP may forward the data without querying the CP. 371 It should be possible for a CP to send unsolicited requests to the 372 NSP to refresh or change the permissions for a user for specific 373 channel(s). 375 When a user is receiving multicast content and the permission is 376 about to expire, the NSP may send a notification to the user client 377 that his session is about to expire, and that he will need to re- 378 connect. The user will have to reestablish a connection. In the 379 case that the user still has permission to the content, they should 380 be able to continue to receive the content without interruption. 382 5. Network Connection Model and Functional Components 384 Section 3.1 introduces the high-level AAA framework for multicasting. 385 This section provides more detail on the network connection model 386 and constituent functional components. 388 5.1 Basic Connection Model 390 +-------------+ 391 | user | 392 | | 393 +-------------+ 394 ^ Access & Resource 395 | Request 396 v 397 +-------------+ 398 | NSP | 399 | | 400 +-------------+ 401 ^ Access 402 | Request 403 v 404 +-------------+ 405 | CP | 406 | | 407 +-------------+ 409 First a user that requests content sends an Access request to an NSP 410 which then forwards it on to the appropriate CP for Authentication 411 and Authorization purposes. The CP responds with either "success" or 412 "failure". If "success", the NSP may forward a success response and 413 stream multicast data to the user. 415 In this model the user selects the NSP to which to send its content 416 request. Based on this request the NSP selects an appropriate CP to 417 which it forwards the request. The CP responds to the NSP's request: 418 it may not respond to another NSP in regards to the request. 420 In this model, as described in section 3.1, the relationship between 421 NSP and CP can be 1:1, 1:N or M:N. Users may connect to multiple 422 networks, and networks have multiple users. 424 5.2 Transit Provision 426 The diagram below shows that a Transit Provider(hereafter, TP) may 427 relay requests between NSPs and CPs. 429 +-------------+ 430 | user | 431 | | 432 +-------------+ 433 ^ Access & Resource 434 | Request 435 v 436 +-------------+ 437 | NSP | 438 | | 439 +-------------+ 440 ^ Access & Resource 441 | Request 442 v 443 +-------------+ 444 | TP | 445 | | 446 +-------------+ 447 ^ Access 448 | Request 449 v 450 +-------------+ 451 | CP | 452 | | 453 +-------------+ 455 For the sake of simplification the above diagram shows a 1-1 456 relationship between an NSP and a TP. However it is also possible 457 for a single NSP to connect to multiple TPs, and a single TP to 458 multiple NSPs. 460 A single TP may connect to one or more CPs. Similarly just as a 461 single CP may connect to multiple NSPs (as described in the general 462 high-level framework, section 3.1), a single CP may connect to one 463 or more TPs. 465 A solution will include a mechanism through which the NSPs know 466 which TP(s) are to be used to communicate with which CP(s), and CPs 467 know which TP(s) to use for which NSP(s). When a TP receives an 468 access or resource request from an NSP or CP, it must relay the 469 request to the correct CP or NSP, respectively. Minimally, this 470 means that it must reconstruct the request with translated address 471 information. In this model therefore a TP must understand the 472 format and meaning of the requests. 474 There may be multiple TPs between a NSP and CP so that a TP is 475 actually receiving from and/or sending requests to another TP and 476 not directly from/to a NSP or CP. 478 5.3 Transit with Tunnels 480 In addition to the above model of request relaying, a TP may 481 communicate requests through tunneling based on the contract between 482 the TP and the NSP and/or between the TP and the CP. So in this 483 case the TP will not directly need to process the contents of the 484 access and resource request (such as, header information), but 485 instead pass the request directly to the correct NSP or CP, using a 486 separate protocol to wrap the original requests. 488 Below is a diagram, representing how a TP can provide tunneling 489 between NSP(s) and CP(s). 491 +-----------------+ 492 | user | 493 | | 494 +-----------------+ 495 ^ Access & Resource 496 | Request 497 v 498 +------------------+ 499 | NSP | 500 | | 501 +------------------+ 502 |^| 503 |:| 504 |:| 505 +-|:|--------------+ 506 | |:| TP | 507 | |:| | 508 +-|:|--------------+ 509 |:| 510 |:| Tunnel 511 |:| 512 |V| 513 +------------------+ 514 | CP | 515 | | 516 +------------------+ 518 In this model too, the relationship between NSP and TP and between 519 transit provider and CP can be 1:1, 1:N or M:N. 521 5.4 Constituent Logical Functional Components of the fully enabled AAA 522 Framework 524 Section 3.1 introduces the high-level AAA framework for multicasting. 525 Below is a diagram of a fully enabled multicasting network with AAA, 526 including the logical components within the various entities. 528 +-------------------------------+ 529 | user | 530 | | 531 +-------------------------------+ 532 ^ 533 | Access & resource request 534 v 535 +-------------------------------+ 536 | NSP | 537 | | 538 |+--------------+ +---------+| 539 ||NR Management |<-->|AAA Proxy|| (NR= network resource) 540 |+--------------+ RR +---------+| (RR= resource request) 541 +-------------------------------+ 542 ^ 543 | Access request 544 v 545 +------------------------------+ 546 | CP | 547 | | 548 | +---------+ | 549 | | AAA | | 550 | +---------+ | 551 +------------------------------+ 553 In the fully enabled model the NSP provides proxying of 554 authentication and authorization between the NSP and CP, as well as 555 user-based accounting. The AAA proxy server of the NSP communicates 556 with the CP's AAA server. Although not shown in the above diagram 557 for the sake of simplicity, in addition to direct proxying between a 558 NSP and CP, this proxying may be done through a TP. This means that 559 the transit provider is also cable of supporting AAA proxying. 561 In the fully enabled model the NSP also includes a component that 562 provides network resource management (e.g. QoS management), as 563 described in section 3.4, "Network Resource Management by NSP". 564 When a transit provider is used it may also provide Network Resource 565 management of its own resources. 567 5.5 Modularity of the framework 568 In the interest of flexibility, this framework is modular so that it 569 is possible that partially enabled versions of the models are 570 supported. A AAA-enabled version provides AAA functionality without 571 Network Resource management. A Network-Resource-Management-enabled 572 (QoS-enabled) version provides Network Resource management without 573 AAA functionality. Similarly, the possibility of one or more layers 574 of transit provision between an NSP and CP is in the interest of 575 modularity and extendibility. 577 6. IANA considerations 579 This memo does not raise any IANA consideration issues. 581 7. Security considerations 583 Refer to section 3.3. Also the user information related to 584 authentication with the CP must be protected in some way. Otherwise, 585 this memo does not raise any new security issues which are not 586 already addressed by the original protocols. Enhancement of 587 multicast access control capabilities should enhance security 588 performance. 590 8. Conclusion 592 This memo provides a generalized framework for solution standards to 593 meet the requirements presented in MACCNT-REQ-draft. Further work 594 should be done to break down the content provider and network 595 service provider entities into their functional objects such as edge 596 devices, AAA servers, etc. 598 Normative References 600 [1] Hayashi, et. al., "Accounting, Authentication and Authorization 601 Issues in Well Managed IP Multicasting Services", draft-ietf- 602 mboned-maccnt-req-04.txt, February 2006, Work in Progress. 604 Authors' Addresses 606 Hiroaki Satou 607 NTT Network Service Systems Laboratories 608 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 609 Phone : +81 422 59 4683 610 Email : satou.hiroaki@lab.ntt.co.jp 612 Hiroshi Ohta 613 NTT Network Service Systems Laboratories 614 3-9-11 Midoricho, Musashino-shi, Tokyo, 180-8585 Japan 615 Phone : +81 422 59 3617 616 Email: ohta.hiroshi@lab.ntt.co.jp 618 Christian Jacquenet 619 France Telecom 620 3, avenue Francois Chateau 621 CS 36901, 35069 Rennes Cedex, France 622 Phone: +33 2 99 87 63 31 623 Email: christian.jacquenet@francetelecom.com 625 Tsunemasa Hayashi 626 NTT Network Innovation Laboratories 627 1-1 Hikari-no-oka, Yokosuka-shi, Kanagawa, 239-0847 Japan 628 Phone: +81 46 859 8790 629 Email: tsunemasa@gmail.com 631 Haixiang He 632 Nortel 633 600 Technology Park Drive 634 Billerica, MA 01801, USA 635 Phone: +1 978 288 7482 636 Email: haixiang@nortel.com 638 Comments 640 Comments are solicited and should be addressed to the mboned working 641 group's mailing list at mboned@lists.uoregon.edu_and/or the authors. 643 Full Copyright Statement 645 Copyright (C) The Internet Society (2006). 647 This document is subject to the rights, licenses and restrictions 648 contained in BCP 78, and except as set forth therein, the authors 649 retain all their rights. 651 This document and the information contained herein are provided on 652 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 653 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 654 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 655 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 656 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 657 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 659 Intellectual Property 661 The IETF takes no position regarding the validity or scope of any 662 Intellectual Property Rights or other rights that might be claimed 663 to pertain to the implementation or use of the technology described 664 in this document or the extent to which any license under such 665 rights might or might not be available; nor does it represent that 666 it has made any independent effort to identify any such rights. 667 Information on the procedures with respect to rights in RFC 668 documents can be found in BCP 78 and BCP 79. 670 Copies of IPR disclosures made to the IETF Secretariat and any 671 assurances of licenses to be made available, or the result of an 672 attempt made to obtain a general license or permission for the use 673 of such proprietary rights by implementers or users of this 674 specification can be obtained from the IETF on-line IPR repository 675 at http://www.ietf.org/ipr. 677 The IETF invites any interested party to bring to its attention any 678 copyrights, patents or patent applications, or other proprietary 679 rights that may cover technology that may be required to implement 680 this standard. Please address the information to the IETF at ietf- 681 ipr@ietf.org. 683 Expiration 685 This Internet-Draft will expire on April 26, 2007. 687 Acknowledgement 689 Funding for the RFC Editor function is currently provided by the 690 Internet Society.