idnits 2.17.1 draft-iab-iana-04.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 602. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 586. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 2008) is 5664 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'CORR' is defined on line 519, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 1700 (Obsoleted by RFC 3232) -- Obsolete informational reference (is this intentional?): RFC 4071 (Obsoleted by RFC 8711) -- Obsolete informational reference (is this intentional?): RFC 4748 (Obsoleted by RFC 5378) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Danny McPherson, Ed. 2 Geoff Huston, Ed. 4 Internet Architecture Board 5 Expires: April 2009 October 2008 6 Intended Status: Best Current Practice 8 Defining the Role and Function of IETF Protocol 9 Parameter Registry Operators 10 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 Many IETF protocols make use of commonly defined values that are 42 passed within protocol objects. To ensure consistent interpretation 43 of these values between independent implementations, there is a need 44 to ensure that the values and associated semantic intent are uniquely 45 defined. The IETF uses registry functions to record assigned 46 protocol parameter values and their associated semantic intent. For 47 each IETF protocol parameter it is current practice for the IETF to 48 delegate the role of protocol parameter registry operator to a 49 nominated entity. This document provides a description of and the 50 requirements for these delegated functions. 52 Table of Contents 54 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Definition of an IETF Protocol Parameter 56 Registry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 3. Publication of Protocol Parameter Registry 58 Assignments . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. The Procedures related to IETF Protocol Parameter 60 Management. . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. The Operation of IETF Protocol Parameter Reg- 62 istries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Current IETF Protocol Parameter Assignments . . . . . . . . . 7 64 7. Roles and Responsibilities concerning IETF Proto- 65 col Registries. . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 7.1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . 8 67 7.2. Protocol Parameter Registry Operator Role . . . . . . . . . 8 68 7.3. IAB Role. . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 7.4. IESG Role . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 7.5. Role of the IETF Trust. . . . . . . . . . . . . . . . . . . 12 71 8. Miscellaneous Considerations . . . . . . . . . . . . . . . . . 12 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 73 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 74 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 75 12. References. . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 77 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 78 13. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 14 79 14. Appendix A: IAB Members . . . . . . . . . . . . . . . . . . . 15 81 1. Overview 83 Many IETF protocols make use of commonly defined values that are 84 passed within protocol objects. To ensure consistent interpretation 85 of these values between independent implementations, there is a need 86 to ensure that the values and associated semantic intent are uniquely 87 defined. The IETF uses registries to record each of the possible 88 values of a protocol parameter and their associated semantic intent. 89 The document describes the function of these registries as they apply 90 to individual protocol parameters defined by the IETF Internet 91 Standards Process [RFC 2026]. 93 At the time of writing this document (October 2008) the operation of 94 the majority of the protocol parameter registries is delegated to the 95 Internet Corporation for Assigned Names and Numbers (ICANN) according 96 to the terms and conditions described in RFC 2860 [RFC 2860] and 97 supplements developed thereafter. Not all IETF protocol parameter 98 registries are delegated to ICANN, and at present the operation of 99 the 'e164.arpa' registry has been delegated to the RIPE Network 100 Coordination Center (RIPE NCC) [RIPE NCC]. 102 The term "Internet Assigned Numbers Authority" (IANA), has been used 103 historically to refer to the entire collection of protocol parameter 104 registries. It is noted that there is current general use of this 105 term to refer specifically to the set of registries operated by ICANN 106 under terms of this delegation of function. While IETF documents 107 continue to use the term "IANA Considerations" when referring to 108 specific functions to be performed with respect to a protocol 109 parameter registry [RFC 5226], it is noted that the use of the term 110 'IANA' in this context does not necessarily imply the delegation of 111 the parameter registry operation to the body managed by ICANN. 113 This IETF - IANA organizational separation is one that appears to be 114 a relatively unique arrangement in the context of standards 115 development organizations (SDOs), and similar arrangements of 116 structural separation are not generally used by SDOs. Other SDOs that 117 undertake a similar protocol parameter registration function 118 generally do so as part of their secretariat service functions or 119 their equivalent, thereby avoiding the overheads of detailed 120 coordination of activity across multiple distinct organizations. 121 However, as already noted, this structural separation of roles exists 122 within several places in the IETF framework (e.g., to include the RFC 123 Editor function) and the IETF has the responsibility to define and 124 manage the relationship with the IANA role. This IETF responsibility 125 includes the selection and management of the protocol parameter 126 registry operator(s), as well as management of the parameter 127 registration process and the guidelines for parameter allocation. 129 Furthermore, as with other SDO's, the IETF asserts full authority 130 over the management of all the IETF protocol parameter registries. 132 2. Definition of an IETF Protocol Parameter Registry 134 Using the term 'IANA' in the sense of the entire set of IETF protocol 135 parameter registries, the Internet Standards document, STD 2, 136 published in October 1994, defined the role of the IANA as follows: 138 The Internet Assigned Numbers Authority (IANA) is the central 139 coordinator for the assignment of unique parameter values for 140 Internet protocols. The IANA is chartered by the Internet 141 Society (ISOC) and the Federal Network Council (FNC) to act as 142 the clearinghouse to assign and coordinate the use of numerous 143 Internet protocol parameters. 145 The Internet protocol suite, as defined by the Internet 146 Engineering Task Force (IETF) and its steering group (the IESG), 147 contains numerous parameters, such as Internet protocol addresses, 148 domain names, autonomous system numbers (used in some routing 149 protocols), protocol numbers, port numbers, management information 150 base object identifiers, including private enterprise numbers, and 151 many others. 153 The common use of the Internet protocols by the Internet 154 community requires that the particular values used in these 155 parameter fields be assigned uniquely. It is the task of the 156 IANA to make those unique assignments as requested and to maintain 157 a registry of the currently assigned values [RFC 1700]. 159 Again using the term 'IANA' in the sense of the entire set of IETF 160 protocol parameter registries, the definition of the protocol 161 parameter registry role is provided in [RFC 5226]: 163 Many protocols make use of identifiers consisting of constants 164 and other well-known values. Even after a protocol has been 165 defined and deployment has begun, new values may need to be 166 assigned (e.g., for a new option type in DHCP, or a new encryption 167 or authentication transform for IPsec). To ensure that such 168 quantities have consistent values and interpretations across all 169 implementations, their assignment must be administered by a 170 central authority. For IETF protocols, that role is provided by 171 the Internet Assigned Numbers Authority (IANA). 173 3. Publication of Protocol Parameter Registry Assignments 175 The current mode of publication of protocol parameter registry 176 assignments undertaken within registries whose operation is currently 177 delegated to ICANN is described in the Informational Document [RFC 178 3232], published in January 2002: 180 From November 1977 through October 1994, the Internet 181 Assigned Numbers Authority (IANA) periodically published 182 tables of the Internet protocol parameter assignments in 183 RFCs entitled, "Assigned Numbers". The most current of these 184 Assigned Numbers RFCs had Standard status and carried the 185 designation: STD 2. At this time, the latest STD 2 is 186 RFC 1700. 188 Since 1994, this sequence of RFCs have been replaced 189 by an online database accessible through a web page 190 (currently, www.iana.org). The purpose of the present RFC 191 is to note this fact and to officially obsolete RFC 1700, 192 whose status changes to Historic. RFC 1700 is obsolete, and 193 its values are incomplete and in some cases may be wrong 194 [RFC 3232]. 196 The mode of publication of the e164.arpa protocol parameter registry 197 operated by the RIPE NCC is documented in reference [RIPE ENUM]. 199 4. The Procedures related to IETF Protocol Parameter Management 201 IETF Protocol Parameter registry actions are defined through the 202 inclusion of an "IANA Considerations" section in Internet Standards 203 documents, as described in [RFC 5226]. There are also RFCs that 204 specifically address IETF protocol parameter considerations for 205 particular protocols, such as [RFC 2780], [RFC 2939], and [RFC 2978]. 207 5. The Operation of IETF Protocol Parameter Registries 209 As documented in the IAB Charter [RFC 2850], the role of the Internet 210 Architecture Board includes responsibility for the IETF Protocol 211 Parameter registration function (referred to in the charter as 212 'IANA'). The IAB, acting on behalf of the IETF, approves the 213 appointment of an organization to act as a protocol parameter 214 registry operator on behalf of the IETF, and also approves the terms 215 and conditions of this delegation of this function. 217 The technical direction of the IETF Protocol Parameter registry 218 function is provided by the Internet Engineering Steering Group 219 (IESG) [RFC 2850]. 221 6. Current IETF Protocol Parameter Assignments 223 The list of current IETF protocol parameters for which parameter 224 value assignments are registered within registries whose operation is 225 currently delegated to ICANN is listed in reference [IANA]. In 226 addition there is the e164.arpa registry function, which is listed in 227 reference [RIPE ENUM]. 229 As provided in the list list contained in [IANA], those protocol 230 parameter registries that refer to registrations related to the 231 allocation of public unicast IPv4 addresses, public unicast IPv6 232 addresses, public use Autonomous System Numbers (ASNs) and the top 233 level delegations within the Domain Name System, have associated 234 registration mechanisms that have been delegated to the IANA function 235 operated under the auspices of ICANN, as defined in [RFC 2860]. In 236 these cases other bodies are responsible for the development of 237 policies to manage the registrations of allocations performed as part 238 this aspect of the registration function. Registrations that refer to 239 reservations (e.g., IP address blocks for documentation purposes or 240 ASNs defined for documentation purposes) and all other use cases 241 within those registries must be prescribed by the IETF. 243 7. Roles and Responsibilities concerning IETF Protocol Registries 245 This section describes the operation and role of a delegated IETF 246 Protocol Parameter Registry Operator, to be selected and administered 247 by the IETF Administrative Support Activity (IASA) [RFC 4071]. This 248 section also includes a description of the roles of related bodies 249 with reference to this function. 251 This generic description is being provided for clarity, in order to 252 document the protocol parameter registry administrative function that 253 has evolved over time as intrinsic aspects of the IANA culture. 255 7.1. Introduction 257 Many protocols make use of identifiers consisting of constants and 258 other well-known values. Even after a protocol has been defined and 259 deployment has begun, new values may need to be assigned (e.g., for a 260 new option type in DHCP, or a new encryption or authentication 261 algorithm for IPSec). To insure that such quantities have consistent 262 values and interpretations in different implementations, their 263 assignment must be administered by a central authority. For IETF 264 protocols, that role is provided by a delegated Protocol Parameter 265 Registry operator. For any particular protocol parameter there is a 266 single delegated registry operator. 268 7.2. Protocol Parameter Registry Operator Role 270 A IETF Protocol Parameter registry function is undertaken under the 271 auspices of the Internet Architecture Board. 273 The roles of the Protocol Parameter registry operator are as follows: 275 o Review and Advise 277 * The registry operator may be requested to review 278 Internet-Drafts that are being considered by the Internet 279 Engineering Task Force Steering Group (IESG), with the 280 objective of offering advice to the IESG regarding the 281 need for an "IANA Considerations" section, whether such 282 a section, when required, is clear in terms of direction 283 to the registry operator and whether the section is 284 consistent with the current published registry operator 285 guidelines. 287 o Registry 289 * To operate a registry of protocol parameter assignments. 291 * The delegated registry operator registers values for 292 Internet protocol parameters only as directed by the 293 criteria and procedures specified in RFCs, including 294 Proposed, Draft and full Internet Standards, Best Current 295 Practice documents, and other RFCs that call for protocol 296 parameter assignment, and only for those protocol parameters 297 specified by the IETF. If they are not so specified, or in 298 case of ambiguity, the registry operator will continue to 299 assign and register only those protocol parameters that have 300 already been delegated to the operator, following past and 301 current practice for such assignments, unless otherwise 302 directed in terms of operating practice by the IESG. In 303 the case of the current IANA operation, requirements are 304 provided in the MoU with ICANN [RFC 2860] and associated 305 supplements outlining service level agreements for IETF 306 protocol parameter registry functions. 308 * For each protocol parameter, the associated registry 309 includes: 311 + a reference to the RFC document that describes the 312 parameter and the associated "IANA Considerations" 313 concerning the parameter, and 315 + for each registration of a protocol parameter value, 316 the source of the registration and the date of the 317 registration, if the date of registration is known. 319 * If in doubt or in case of a technical dispute, the registry 320 operator will seek and follow technical guidance exclusively from 321 the IESG. Where appropriate the IESG will appoint an expert to 322 advise the registry operator. 324 * The registry operator will work with the IETF to develop any 325 missing criteria and procedures over time, which the registry 326 operator will adopt when so instructed by the IESG. 328 * Each protocol parameter registry operates as a public registry, 329 and the contents of the registry are openly available to the 330 public, on-line and free of charge. Any related intellectual 331 property rights associated with the registry and its contents 332 are held by the IETF Trust [RFC 4748]. 334 * The registry operator assigns protocol parameter values in 335 accordance with the policy associated with the protocol 336 parameter. Some policies are listed in [RFC 5226]. 338 o Mailing Lists 340 * The registry operator maintains public mailing lists as 341 specified in IANA Considerations [RFC 5226]. Such lists are 342 designated for the purpose of review of assignment proposals 343 in conjunction with a designated expert review function. In 344 addition, each protocol parameter registry operator should 345 maintain a mailing list that enables the registry staff of 346 each registry operator to be contacted by email. For example, 347 iana@iana.org currently provides this function for IANA. 349 o Liaison Activity 351 * The registry operator will nominate a liaison point of contact. 352 The registry operator, though this liaison, may be requested to 353 provide advice to the IESG on IETF protocol parameters as well 354 as the IANA Considerations section of Internet-drafts that are 355 being reviewed for publication as an RFC. Where appropriate the 356 IESG will appoint an expert to advise IANA. 358 o Reporting 360 * The registry operator will submit periodic reports to the IAB 361 concerning the operational performance of the registry function. 362 As an exmaple of the requirements for such reports the reader is 363 referred to a supplement to the MoU outlined in [RFC 2860], which 364 was established by the IASA [RFC 4071] and provides SLA 365 guidelines under which IANA, as implemented by ICANN, must 366 operate. 368 * At the request of the chair of the IETF, the registry operator 369 will undertake periodic reports to the IETF Plenary concerning 370 the status of the registry function. 372 * The registry operator will publish an annual report describing 373 the status of the function and a summary of performance 374 indicators. 376 o Intellectual Property Rights and the Registry Operator 378 * All assigned values are to be published and made available free 379 of any charges and free of any constraints relating to further 380 redistribution, with the caveat that the assignment information 381 may not be modified in any redistributed copy. 383 * Any intellectual property rights of the IETF Protocol Parameter 384 assignment information, including the IETF Protocol Parameter 385 registry and its contents, are to be held by the IETF Trust 386 [RFC 4748], and all IETF Protocol Parameter registry publications 387 relating to assignment information are to be published under the 388 terms of Section 10 of [RFC 2026], and are to include the 389 copyright notice as documented in Section 10.4 (C) of [RFC 2026]. 391 7.3. IAB Role 393 An operator of an IETF Protocol Parameter registry undertakes the 394 role as a delegated function under the auspices of the Internet 395 Architecture Board (IAB). 397 The IAB has the responsibility to, from time to time, review the 398 current description of the registry function and direct the registry 399 operator to adopt amendments relating to its role and mode of 400 operation of the registry according to the best interests of the 401 IETF. 403 The IAB has the responsibility to select an organization to undertake 404 the delegated functions of the Protocol Parameter registry for each 405 IETF protocol parameter. 407 The IAB has the responsibility to determine the terms and conditions 408 of this delegated role. Such terms and conditions should ensure that 409 the registry operates in a manner that is fully conformant to the 410 functions described in this document. In addition, such terms and 411 conditions must not restrict the rights and interests of the IETF 412 with respect to the registry function. 414 7.4. IESG Role 416 The IESG is responsible for the technical direction of the IETF 417 Protocol Parameter registries. Such technical direction is provided 418 through the adoption of IETF RFC documents within the "IANA 419 Considerations" section of such documents, or as stand-alone "IANA 420 Considerations" RFC documents. 422 The IESG shall ensure that the review of Internet-Drafts that are 423 offered for publications as RFCs ensures that IANA Considerations 424 sections are present when needed, and that IANA Considerations 425 sections conform to the current published guidelines. 427 At the discretion of the IESG, the registry operator may be required 428 to designate a non-voting liaison to the IESG to facilitate clear 429 communications and effective operation of the registry function. 431 7.5. Role of the IETF Trust 433 Any intellectual property rights of IETF Protocol Parameter 434 assignment information, including the registry and its contents, and 435 all registry publications, are to be held by the IETF Trust on behalf 436 of the IETF. 438 The IETF Trust [RFC 4748] was recently formed to act as the 439 administrative custodian of all copyrights and other intellectual 440 property rights relating to the IETF Standards Process that had 441 previously been held by ISOC and the Corporation for National 442 Research Initiatives (CNRI). 444 8. Miscellaneous Considerations 446 The IESG provides technical guidance for IETF created registries. 447 For registries created by non-IETF stream documents the policies set 448 by the IESG apply unless there are solid arguments to follow a 449 different policy in which case the IAB has the final word. 451 9. Acknowledgements 453 This document is adapted from [RFC 5226], and has been modified to 454 include explicit reference to Intellectual Property Rights, and the 455 roles of the IAB and IESG in relation to the IETF Protocol Parameter 456 registry function. 458 The Internet Architecture Board acknowledges the assistance provided 459 by reviewers of earlier drafts of this document, including Scott 460 Bradner, Leslie Daigle and Thomas Narten. 462 10. Security Considerations 464 This document does not propose any new protocols, and therefore does 465 not involve any security considerations in that sense. 467 11. IANA Considerations 469 This document requires no direct IANA actions. 471 12. References 473 12.1. Normative References 475 12.2. Informative References 477 [RFC 1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, 478 STD 2, October 1994. 480 [RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 481 3", RFC 2026, BCP 9, October 1996. 483 [RFC 2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines 484 For Values In the Internet Protocol and Related Headers", 485 RFC 2780, BCP 37, March 2000. 487 [RFC 2850] Carpenter, B., "Charter of the Internet Architecture 488 Board", RFC 2850, BCP 39, May 2000. 490 [RFC 2860] Carpenter, B., Baker, F. and M. Roberts, "Memorandum of 491 Understanding Concerning the Technical Work of the 492 Internet 493 Assigned Numbers Authority", RFC 2860, June 2000. 495 [RFC 2939] Droms, R., "Procedures and IANA Guidelines for Definition 496 of New DHCP Options and Message Types", RFC 2939, BCP 43, 497 September 2000. 499 [RFC 2978] Freed, N. and J. Postel, "IANA Charset Registration 500 Procedures", RFC 2978, BCP 19, October 2000. 502 [RFC 3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by 503 an On-line Database", RFC 3232, January 2002. 505 [RFC 4071] Austein, R., Wijnen, B., "Structure of the IETF 506 Administrative Support Activity (IASA)", RFC 4071, 507 April 2005. 509 [RFC 4748] Bradner, S., "RFC 3978 Update to Recognize the IETF 510 Trust", RFC 4748, BCP 78, October 2006. 512 [RFC 5226] Narten, T., Alvestrand, H., "Guidelines for Writing 513 an IANA Considerations Section in RFCs", RFC 5226, 514 May 2008. 516 [IANA] Reynolds, J., "IANA Protocol Numbers and Assignment 517 Services", October 1994, . 519 [CORR] Dyson, E., "Correspondence from Esther Dyson, Interim 520 Chairman, ICANN to Scott Bradner, Brian Carpenter and 521 Fred Baker of the IETF", February 1999, 522 . 524 [RIPE NCC] IAB, "ENUM LIAISON ON IAB INSTRUCTIONS TO RIPE-NCC", 525 September 2002, 526 . 528 [RIPE ENUM] RIPE NCC, "ENUM Registry", September 2002, 529 . 531 13. Authors' Addresses 533 Danny McPherson, Editor 534 Arbor Networks, Inc. 535 Email: danny@arbor.net 537 Geoff Huston, Editor 538 APNIC 539 Email: gih@apnic.net 541 Internet Architecture Board 542 Email: iab@iab.org 544 14. Appendix A: IAB Members 546 Internet Architecture Board Members at the time this document was 547 published were: 549 Loa Andersson 550 Gonzalo Camarillo 551 Stuart Cheshire 552 Aaron Falk 553 Russ Housley 554 Olaf Kolkman 555 Gregory Lebovitz 556 Barry Leiba 557 Kurtis Lindqvist 558 Andrew Malis 559 Danny McPherson 560 David Oran 561 Dave Thaler 562 Lixia Zhang 564 Intellectual Property Statement 566 The IETF takes no position regarding the validity or scope of any 567 Intellectual Property Rights or other rights that might be claimed to 568 pertain to the implementation or use of the technology described in 569 this document or the extent to which any license under such rights 570 might or might not be available; nor does it represent that it has 571 made any independent effort to identify any such rights. Information 572 on the procedures with respect to rights in RFC documents can be 573 found in BCP 78 and BCP 79. 575 Copies of IPR disclosures made to the IETF Secretariat and any 576 assurances of licenses to be made available, or the result of an 577 attempt made to obtain a general license or permission for the use of 578 such proprietary rights by implementers or users of this 579 specification can be obtained from the IETF on-line IPR repository at 580 http://www.ietf.org/ipr. 582 The IETF invites any interested party to bring to its attention any 583 copyrights, patents or patent applications, or other proprietary 584 rights that may cover technology that may be required to implement 585 this standard. Please address the information to the IETF at 586 ietf-ipr@ietf.org. 588 Copyright Statement 589 Copyright (C) The IETF Trust (2008). 591 This document is subject to the rights, licenses and restrictions 592 contained in BCP 78, and except as set forth therein, the authors 593 retain all their rights. 595 This document and the information contained herein are provided on an 596 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 597 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 598 AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 599 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 600 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY 601 IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR 602 PURPOSE. 604 Acknowledgment 606 Funding for the RFC Editor function is provided by the IETF 607 Administrative Support Activity (IASA).