idnits 2.17.1 draft-iab-liaison-guidelines-01.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 545. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 552. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 558. ** 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119], [RFC4052]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (January 23, 2006) is 6661 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 (-08) exists of draft-andersson-rtg-gmpls-change-02 -- Obsolete informational reference (is this intentional?): RFC 3356 (Obsoleted by RFC 6756) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Andersson 3 Internet-Draft Acreo AB 4 Expires: July 27, 2006 January 23, 2006 6 Guidelines for Acting as an IETF Liaison to Another Organization 7 draft-iab-liaison-guidelines-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 27, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 Whenever IETF decides to enter into a liaison relationship with 41 another organization, such as a Standards Development Organization 42 (SDO), a consortium, or an industrial forum, a liaison manager is 43 appointed. The procedures used by the IAB to establish and maintain 44 liaison relationships between the IETF and other organizations are 45 described in RFC 4052 [RFC4052]. This document gives guidelines on 46 expectations, tasks, responsibilities and mandate of the liaison 47 managers. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC 2119 [RFC2119]. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. IETF Liaison Relationships . . . . . . . . . . . . . . . . . . 4 59 2.1. Related documents . . . . . . . . . . . . . . . . . . . . 4 60 2.2. Written information . . . . . . . . . . . . . . . . . . . 4 61 2.3. A Person Acting As a Liaison Manager . . . . . . . . . . . 5 62 2.4. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. Liaison Guidelines . . . . . . . . . . . . . . . . . . . . . . 6 64 3.1. Expectations . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.2. Responsibilities . . . . . . . . . . . . . . . . . . . . . 7 66 3.3. Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.4. Mandate . . . . . . . . . . . . . . . . . . . . . . . . . 9 68 3.4.1. Speaking for the IETF . . . . . . . . . . . . . . . . 9 69 3.5. Relationship management . . . . . . . . . . . . . . . . . 9 70 3.5.1. IETF consensus process on liaison statements . . . . . 9 71 3.5.2. Incoming Liaison Statements . . . . . . . . . . . . . 10 72 3.5.3. Ambigous incoming Liaison Statements . . . . . . . . . 10 73 3.5.4. Liaison managers representing other SDOs . . . . . . . 10 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 13 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 78 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 79 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 Intellectual Property and Copyright Statements . . . . . . . . . . 17 83 1. Introduction 85 The IETF communicates extensively with other organizations on issues 86 relating to the development of Internet standards. Part of this 87 communication occurs in written form, known as "liaison statements". 88 In order to ensure the delivery of liaison statements, as well as to 89 enable other forms of communication, the IETF appoints a liaison 90 manager to be responsible for the relationship with the other 91 organization. We normally speak of such a person as "the liaison" 92 from the IETF to the other organization. 94 The organizations IETF establishes liaison relationships with include 95 Standards Developing Organizations (SDOs) such as ITU-T or IEEE 802, 96 consortia, and industrial forums such as Global Grid Forum. Usually 97 IETF liaisons are concerned with groups that develop standards and 98 technical specifications. 100 Whenever the IETF decides to enter into a liaison relationship, a 101 liaison manager is appointed. The procedures used by the IAB to 102 establish and maintain liaison relationships between the IETF and 103 other organizations are described in RFC 4052 [RFC4052]. 105 The role of the liaison manager has grown in importance to the IETF. 106 This document supplements [RFC4052] by providing guidelines for 107 liaison managers and liaison representatives to other organizations. 109 2. IETF Liaison Relationships 111 A major goal of the IETF is to develop standards for the Internet, 112 enabling the development of interoperable implementations. In order 113 to develop Internet standards, it is sometimes necessary for the IETF 114 to communicate with other organizations which develop standards for 115 other types of networks, for Internet applications or for 116 technologies that the Internet uses. 118 Sometimes the IETF and other organizations consider it mutually 119 beneficial to have certain rules governing the relationship. The 120 organizations then enter into a "liaison relationship". At a high 121 level, both sides agree to undertake certain responsibilities with 122 respect to each other. The most basic liaison responsibility is to 123 communicate information as necessary, and to respond to requests from 124 liaison organizations. 126 2.1. Related documents 128 The IETF liaison process is specified in several documents. RFC 4052 129 [RFC4052] specifies how the IAB manages the IETF liaison 130 relationship; RFC 4053 [RFC4053] specifies how liaison statements 131 should be treated; RFC 3356 [RFC3356] describes the collaboration 132 between the IETF and ITU-T. 134 2.2. Written information 136 Extensive communication may occur between the IETF and the 137 organizations it has liaison relationships with. Much of this 138 information is sent in liaison statements and typically contains 139 plans, new developments and time schedules that one party believes 140 that the other party should be aware of. 142 For example, when a liaison organization needs to reference an IETF 143 Internet-Draft within a specification that is under development, a 144 liaison statement is often sent to the IETF requesting that an RFC 145 number be assigned within the required timeframe. In response, the 146 IETF can provide the RFC number or explain why it is not possible to 147 provide this within the timeframe requested. 149 Requests for expedited action on RFCs by organizations other than 150 ITU-T have not typically come in the form of liaison statements. For 151 example, 3GPP/PP2 and OMA provide the IETF with an updated list of 152 dependencies on a monthly basis, indicating what documents are needed 153 and the required timeframe. The liaison manager tracks the 154 dependency list and conveys the request for expedited publication to 155 the appropriate AD. 157 2.3. A Person Acting As a Liaison Manager 159 Whenever the IETF enters into a liaison relationship with another 160 organization, a liaison manager (often referred to as "the IETF 161 liaison") is appointed. This document describes the expectations, 162 tasks and responsibilities of the liaison manager. 164 Decisions on IETF liaison relationships are the responsibility of the 165 IAB. This includes whether the IETF should have a liaison 166 relationship with a particular organization or not. The IAB is also 167 responsible for appointing both liaison managers and liaison 168 representatives. 170 In some cases, it may be necessary to have more than one person 171 handling the liaison relationship with a given organization. For 172 example, the time commitment required may be too substantial, or the 173 technical scope of the liaison relationship may be too broad to be 174 handled by a single individual. 176 In such cases the IAB may appoint a liaison representative to manage 177 one aspect of the liaison relationship between the IETF and the other 178 organization. 180 2.4. Terminology 182 Terminology relating to IETF liaison procedures is found in 183 [RFC4052]. Terms defined below are valid for this document only. 185 Liaison manager 187 A person appointed to manage an IETF liaison relationship with 188 another organization. 190 Liaison representative 192 A person appointed to manage a certain (sub-)aspect of an IETF 193 liaison relationship with another organization. Since it is only the 194 scale of the responsibilities, mandate and tasks that is different, 195 the rest of this document only explicitly mentions liaison managers. 197 IETF consensus 199 RFC 2026 [RFC2026] and RFC 2418 [RFC2418] discuss the IETF consensus 200 process. In this document the term "IETF consensus" is used to 201 indicate either consensus of the IETF as an organization, an Area 202 within IETF or a working group. There the term "IETF consensus" 203 needs to be interpreted in the context in which it is used. 205 3. Liaison Guidelines 207 Since liaison relationships are intended to be mutually beneficial, 208 the IETF liaison to another organization must act as a bi-directional 209 communication link between the IETF and the other organization. 210 Since the liaison manager has been appointed by the IETF, the liaison 211 manager is accountable to the IETF. 213 RFC 4052 lists some of the tasks and expectations relating to liaison 214 managers. This document provides more detailed discussion and 215 describes how the role is executed. 217 3.1. Expectations 219 There are certain expectations placed on liaison managers appointed 220 by the IETF. Examples of these expectations are listed below. 222 Competence 224 A person appointed to act as a liaison manager on behalf of the IETF 225 is expected to have a thorough technical understanding of the key 226 issues in the subject area, as well as an understanding of the 227 concerns important to stakeholders in both organizations. 229 An IETF liaison manager needs to have knowledge of the IETF's 230 consensus process in general, as well as the consensus process(es) 231 applying to the key issues within the liaison relationship. 233 The technical competence of the liaison manager is important, but the 234 essence of the liaison manager role is management of the liaison 235 process according to the rules that have been agreed upon. In the 236 liaison manager role, the liaison manager acts as a representative of 237 the IETF and not an independent voice with respect to topics of 238 discussion in the liaison relationship. The liaison manager must 239 therefore be careful to distinguish their own views from documented 240 IETF consensus in his or her dealings with the liaison organization. 242 Perspective 244 Liaison relationships are designed for the mutual benefit of the 245 organizations participating in the liaison. As such, swift 246 information flow in both directions is a firm requirement. The role 247 of an IETF liaison manager is to promote the interests of the IETF 248 with respect to all topics within the scope of the liaison 249 relationship. Since the liaison manager "wears an IETF hat", it is 250 NOT the task of a liaison manager to promote the interests of the 251 liaised organization within the IETF. 253 Distance 255 When appointing an appropriate person to manage a liaison 256 relationship, the IAB needs to take into account any conflicts of 257 interest that the individual being considered might have. Before a 258 person is appointed to manage a liaison relationship he or she will 259 be asked to explicitly state any conflicts of interest. The IAB will 260 not appoint a person to a liaison manager position if there is a 261 strong conflict of interest. For example, an individual with an 262 industry or organizational leadership position in an organization 263 would typically not be suitable for appointment as an IETF liaison to 264 that organization. 266 Commitment and opportunity 268 A liaison manager needs to be committed to addressing the issues 269 relevant to the liaison relationship. To handle the job properly, it 270 is necessary for the liaison be able to allocate sufficient time to 271 the task. 273 Timeliness 275 It is expected that a liaison manger will make the IETF aware of new 276 developments in the subject area in a timely fashion. 278 3.2. Responsibilities 280 The liaison manager provides information to the IETF community in 281 order to enable the IETF to make decisions based on the best possible 282 information. Information communicated by the IETF liaison to the 283 liased organization is based on IETF consensus. The liaison manager 284 works with the liaised organization to ensure that communication is 285 clear. As part of this, the liaison manager must clearly 286 differentiate their own independent positions from those which 287 represent IETF consensus. 289 It is the responsibility of the liaison manager to ensure that the 290 liaised organization provides its requirements to the IETF and that 291 the IETF consensus is clearly understood. This is particularly 292 important in situations where the IETF and the liased organization 293 differ substantially in their positions. In this situation the 294 liaison manager needs to facilitate prompt communication so that the 295 IETF the the liased organization can stay in close communication. 297 The liaison managers are responsible for clearly and correctly 298 communicating the IETF consensus position to the liased organization. 299 This includes, when specifically instructed, to carry any messages 300 from the IETF to the peer organization. Generally, these 301 communications "represent the IETF", and therefore due care and 302 consensus must be applied in their construction. 304 The liaison managers are responsible for ensuring that relevant 305 information originating from the liaised organization, or other 306 information coming to the attention of the liaison manager, reaches 307 the correct destination within the IETF, in a timely and correct way. 309 3.3. Tasks 311 Examples of tasks performed by the liaison manager are provided 312 below. Depending on the nature of liaised organization the task may 313 vary in frequency and relative importance. 315 1. Attend relevant meetings and participate in conference calls and 316 mailing lists within the liased organization. Report back to the 317 IETF on the developments of interest. 319 2. A liaison manager is encouraged to communicate; sometimes this 320 involves holding frequent update meetings with a team of IETFers 321 involved in the liaised organization and other interested parties 322 within the IETF, e.g. working group chairs and ADs. A 323 significant result of holding such meetings is an increased 324 understanding, and eventually IETF support, for the other 325 organizations goals. 327 3. Prepare updates as requested. The target for these updates 328 (e.g., the IAB, an AD, a WG) will typically be identified upon 329 establishment of the liaison relationship and/or the appointment 330 of the liaison manager. 332 4. Oversee delivery of liaison statements addressed to the IETF. 333 This includes ensuring that liaison statements are delivered to 334 the appropriate destination within the IETF, as well as 335 sheparding the timely creation of responses by the IETF. 337 5. Work with the liaised organization to ensure that the IETF's 338 liaison statements are appropriately directed and responded to in 339 a timely fashion. To accomplish this, the liaison needs to build 340 a contact network. 342 6. Communicate and coordinate with other IETF liaison managers where 343 the activities of two or more liaised organizations overlap. 345 7. Assist with the preparation of IETF liaison statements based on 346 IETF consensus. 348 8. Liaison mangers and liaison representatives shall report to the 349 IETF on the status of the liaison relationship and keep track of 350 outstanding issues on behalf of the IETF. The frequency of the 351 reports and the recipients of the reports within the IETF will be 352 decided when the liaison relationship is set up and may be 353 changed at any time by an IAB decision. IAB or other parties 354 within the IETF may probe for liaison reports as needed or at 355 reegular intervals. 357 3.4. Mandate 359 In Section Section 3.2 and in Section Section 3.3, tasks and 360 responsibilities are listed which enable the IETF to obtain the 361 information to correctly interact with the liased organizations and 362 to develop and clearly communicate IETF consensus. 364 The mandate for IETF liaison managers is strictly limited to 365 conveying IETF consensus to the liaised organization. The liaison 366 manager MUST NOT on their own initiative, send liaison statements to 367 a liaised organization on behalf of IETF, its areas and working 368 groups. Liaison statements are only sent following the process 369 specified in [RFC4052]. Liaison statements are only sent on the 370 initiative of the IETF chair, the IAB chair, IETF Area Directors or 371 IETF working group chairs. 373 3.4.1. Speaking for the IETF 375 The IETF functions based on rough consensus, which means that the 376 right to speak for the IETF cannot be delegated. The liaison manager 377 speaks on behalf of the IETF on the subject matter of the liaison, 378 but only after making sure that the IETF consensus is understood. 379 Some guidelines for understanding IETF consensus are provided above; 380 however, the most important requirement is close and detailed 381 coordination/consultation with the IETF community. 383 3.5. Relationship management 385 Liaison managers will be involved in activities for which they are 386 not directly responsible, but that might greatly benefit from their 387 expertise. Some of these activities are outlined below. 389 3.5.1. IETF consensus process on liaison statements 391 Liaison statements and other messages sent to a liaised organization 392 should be based on rough consensus within IETF or one of its working 393 groups or areas. Though the liaison manager is not responsible for 394 determining consensus, it is important that the liaison manager 395 participate in the process and makes his/her expertise and knowledge 396 available. 398 How consensus is arrived at may vary according to the circumstnaces. 399 Some issues are new and in these cases an open discussion on a 400 mailing list should be undertaken. For some issues consensus has 401 already been arrived at and in these cases the liaison statement can 402 be written and sent (such as by a working group chair), possibly 403 involving the liaison manager 405 3.5.2. Incoming Liaison Statements 407 When the IETF receives a liaison statement or other communication 408 from an organization with which it has an liaison relationship, the 409 IETF is committed to providing a timely response. This means that 410 IETF will respond within the time requested, and provide information 411 as accurately as possible. This commitment has been one of the key 412 discussion points in the past, such as within the (g)mpls change 413 process [I-D.andersson-rtg-gmpls-change]. 415 This commitment does not mean that the IETF will uncritically accept 416 the content in the incoming liaison statement. To the extent the 417 liaison contains requirements on IETF technology or protocols they 418 will be taken into consideration based on their technical merit. 420 3.5.3. Ambigous incoming Liaison Statements 422 Sometimes the IETF, IETF areas or IETF working groups receives 423 liaison statements from a liaised organisation that is sent to the 424 wrong destination. At other times the liaision statement is sent to 425 working groups that is not chartered to do the work that the liaison 426 statement addresses. In some cases it might be the situation that no 427 working group is chartered to do the work. 429 In such cases the liaison manager should assist in finding the 430 appropriate recipient within the IETF that might respond to the 431 incoming liaison statement. Sometimes this might require that the 432 intended response is made available for review on one of the IETF 433 mailing lists. 435 3.5.4. Liaison managers representing other SDOs 437 Liased organizations may appoint a person to act as a liaison manager 438 for "their side" of the relationship. This is the person that will 439 speak for the other organization within the IETF. The other 440 organization needs to make this person known to the IETF. This 441 person might request a slot on a working group agenda to discuss 442 developments and plans of the liaised organization. 444 The mandate of liaison managers from other organizations are 445 recognized by the IETF to the extent needed to understand the 446 information received from the liaison manager. In all other respects 447 he/she participates in IETF activities under the same conditions and 448 rules as any other IETF participant. 450 IETF liaison managers should work to include the liaison manager from 451 the liaised organization within their contact network. 453 4. Security Considerations 455 This document does not specify any protocol or "bits on the wire". 456 However, since interaction with other standards-making organizations 457 often relates to security, the liaison manager can assist with 458 security related issues, resulting in improved security for Internet 459 protocols. 461 5. IANA considerations 463 There are no requests to the IANA herein. Note that the liaison 464 manager very often has to understand and bridge questions regarding 465 IETF namespace. 467 6. Acknowledgements 469 This document was developed as part of a conversation regarding the 470 requirements on IETF liaison managers and representatives. Several 471 IAB members have significantly contributed to the document. Also, 472 the document has been improved thanks to suggestions and review from 473 Allison Mankin, Dave Meyer and Leslie Daigle. 475 A special thanks to Bernard Aboba who apart from drawing on his 476 experience as a liaison manager has made many useful comments on the 477 subjet matter, also have spent time on correcting language and 478 grammar. 480 Members of the IAB at the time of approval of this document were: 482 Bernard Aboba 483 Loa Andersson 484 Brian Carpenter 485 Leslie Daigle 486 Patrik Falstrom 487 Bob Hinden 488 Kurtis Lindqvist 489 David Meyer 490 Pekka Nikander 491 Eric Rescorla 492 Pete Resnick 493 Jonathan Rosenberg 494 Lixia Zhang 496 7. References 498 7.1. Normative References 500 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 501 3", BCP 9, RFC 2026, October 1996. 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, March 1997. 506 [RFC2418] Bradner, S., "IETF Working Group Guidelines and 507 Procedures", BCP 25, RFC 2418, September 1998. 509 [RFC4052] Daigle, L. and Internet Architecture Board, "IAB Processes 510 for Management of IETF Liaison Relationships", BCP 102, 511 RFC 4052, April 2005. 513 7.2. Informative References 515 [I-D.andersson-rtg-gmpls-change] 516 Andersson, L., "MPLS and GMPLS Change Process", 517 draft-andersson-rtg-gmpls-change-02 (work in progress), 518 December 2005. 520 [RFC3356] Fishman, G. and S. Bradner, "Internet Engineering Task 521 Force and International Telecommunication Union - 522 Telecommunications Standardization Sector Collaboration 523 Guidelines", RFC 3356, August 2002. 525 [RFC4053] Trowbridge, S., Bradner, S., and F. Baker, "Procedures for 526 Handling Liaison Statements to and from the IETF", 527 BCP 103, RFC 4053, April 2005. 529 Author's Address 531 Loa Andersson 532 Acreo AB 534 Email: loa@pi.se 536 Intellectual Property Statement 538 The IETF takes no position regarding the validity or scope of any 539 Intellectual Property Rights or other rights that might be claimed to 540 pertain to the implementation or use of the technology described in 541 this document or the extent to which any license under such rights 542 might or might not be available; nor does it represent that it has 543 made any independent effort to identify any such rights. Information 544 on the procedures with respect to rights in RFC documents can be 545 found in BCP 78 and BCP 79. 547 Copies of IPR disclosures made to the IETF Secretariat and any 548 assurances of licenses to be made available, or the result of an 549 attempt made to obtain a general license or permission for the use of 550 such proprietary rights by implementers or users of this 551 specification can be obtained from the IETF on-line IPR repository at 552 http://www.ietf.org/ipr. 554 The IETF invites any interested party to bring to its attention any 555 copyrights, patents or patent applications, or other proprietary 556 rights that may cover technology that may be required to implement 557 this standard. Please address the information to the IETF at 558 ietf-ipr@ietf.org. 560 Disclaimer of Validity 562 This document and the information contained herein are provided on an 563 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 564 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 565 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 566 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 567 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 568 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 570 Copyright Statement 572 Copyright (C) The Internet Society (2006). This document is subject 573 to the rights, licenses and restrictions contained in BCP 78, and 574 except as set forth therein, the authors retain all their rights. 576 Acknowledgment 578 Funding for the RFC Editor function is currently provided by the 579 Internet Society.