idnits 2.17.1 draft-baker-liaisons-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 176 has weird spacing: '...nts may be un...' == Line 238 has weird spacing: '...equests the...' -- 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 (June 19, 2003) is 7616 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 537, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 540, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 545, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3356 (ref. '2') (Obsoleted by RFC 6756) -- Possible downref: Non-RFC (?) normative reference: ref. '3' Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Trowbridge 3 Internet-Draft Lucent Technologies 4 Expires: December 18, 2003 S. Bradner 5 Harvard University 6 F. Baker 7 Cisco Systems 8 June 19, 2003 10 Procedure for handling liaison statements from and to various 11 standards bodies 12 draft-baker-liaisons-00 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 18, 2003. 36 Copyright Notice 38 Copyright (C) The Internet Society (2003). All Rights Reserved. 40 Abstract 42 This document describes the procedure for proper handling of incoming 43 liaison statements from other standards development organizations 44 (SDOs), consortia, and industry fora, and for generating liaison 45 statements to be transmitted from IETF/ISOC to other SDOs, consortia 46 and industry fora. This procedure allows IETF to effectively 47 collaborate with other organizations in the international standards 48 community. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Liaison Statements . . . . . . . . . . . . . . . . . . . . . 4 54 2.1 Contents of a Liaison Statement . . . . . . . . . . . . . . 4 55 2.1.1 From: . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1.2 To: . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1.3 Title: . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1.4 Response Contact: . . . . . . . . . . . . . . . . . . . . . 4 59 2.1.5 Technical Contact: . . . . . . . . . . . . . . . . . . . . . 4 60 2.1.6 Purpose: . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1.7 Deadline: . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1.8 Body: . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2.1.9 Attachments: . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.2 Addressee Responsibilities . . . . . . . . . . . . . . . . . 5 65 3. Liaison Statements from other SDOs, Consortia, and Fora 66 to IETF . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.1 Liaison Statement Submission . . . . . . . . . . . . . . . . 7 68 3.2 Web Page for displaying Liaison Statements . . . . . . . . . 8 69 4. Communicating IETF information to other SDOs, consortia, 70 and fora . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.1 Spontaneously generating Liaisons to other organizations . . 9 72 4.1.1 Transmitting IETF documents to other organizations . . . . . 9 73 4.1.2 Requests for Information . . . . . . . . . . . . . . . . . . 9 74 4.1.3 Requesting comments on Work in Progress . . . . . . . . . . 10 75 4.1.4 Requests for Other Actions (besides comments on IETF 76 drafts) . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 4.2 Responding to Incoming Liaisons . . . . . . . . . . . . . . 10 78 4.2.1 Responding to Requests for Information . . . . . . . . . . . 11 79 4.2.2 Responding to Requests for Comments . . . . . . . . . . . . 11 80 4.2.3 Responding to Request for Action . . . . . . . . . . . . . . 11 81 4.2.4 Tool for generating liaisons . . . . . . . . . . . . . . . . 12 82 4.3 Approval and Transmission of Liaison Statements . . . . . . 12 83 4.4 Indication on Outgoing Liaison Statements about how to 84 Respond . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 5. Security Considerations . . . . . . . . . . . . . . . . . . 14 86 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 87 Normative References . . . . . . . . . . . . . . . . . . . . 16 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 16 89 Intellectual Property and Copyright Statements . . . . . . . 18 91 1. Introduction 93 This document describes the procedure for proper handling of incoming 94 liaison statements and for generating liaison statements to be 95 transmitted from IETF/ISOC so that IETF can effectively collaborate 96 with other organizations in the international standards community. 98 2. Liaison Statements 100 A Liaison Statement is a business letter sent by one standards 101 organization to another. These organizations may be at any level 102 (working group, area, etc); generally, the sender and receiver are 103 peer organizations. A liaison statement may have any purpose, but 104 generally the purpose is to solicit information, comment, or action. 106 2.1 Contents of a Liaison Statement 108 Liaison statements may be very formal or quite informal, depending on 109 the rules of the body generating them. Any liaison statement, 110 however, will always contain certain information, much as an business 111 letter does. This information will include the following, 113 2.1.1 From: 115 The statement will indicate what body it is from; it may be from, for 116 example, an IETF working group or area, An ITU-T Study Group, Working 117 Party, or Question, etc. In this document, this body is the "sender". 119 2.1.2 To: 121 The statement will indicate what body it is to. In this document, 122 this body is the "addressee". 124 2.1.3 Title: 126 The statement will contain a short (single line) statement of its 127 context and content. 129 2.1.4 Response Contact: 131 The sender will indicate the electronic mail address that any 132 response should be sent to. 134 2.1.5 Technical Contact: 136 The sender will indicate one or more electronic mail addresses 137 (persons or lists) that may be contacted for clarification of the 138 liaison. 140 2.1.6 Purpose: 142 While others are possible, a liaison generally has one of three 143 purposes, and will clearly state its purpose using one of these 144 labels: 146 For Information The liaison is to inform the addressee of something, 147 and expects no response. 149 For Comment The liaison requests commentary from the addressee, 150 usually within a stated time frame. 152 For Action The liaison requests that the addressee do something on 153 the sender's behalf. 155 In Reply The liaison replies to a previous liaison, usually one sent 156 for comment or for action. 158 2.1.7 Deadline: 160 Liaisons that request comment or action will indicate when the 161 comment or action is required. If the addressee cannot accomplish the 162 request within the stated period, courtesy calls for a response 163 offering a more doable deadline or an alternative course of action. 165 2.1.8 Body: 167 As with any business letter, the liaison contains appropriate 168 content. 170 2.1.9 Attachments: 172 Attachments, if enclosed, may be in the form of documents sent with 173 the liaison or may be URLs to similar documents including Intrenet 174 Drafts. If these are in formats not used in the Internet Draft 175 directory, the sending organization should assume that some IETF 176 participants may be unable to read them. 178 2.2 Addressee Responsibilities 180 The responsibilities of the addressee of a liaison statement are the 181 same as the responsibilities of any business letter. A liaison calls 182 for appropriate consideration of its contents, and if a reply is 183 requested, a courteous reply within the expected time frame. The 184 reply may be that the information was useful, that it was not useful, 185 that the requested action has been accomplished, it be accomplished 186 by a specified date, it will not be done for a specific reason, or 187 any other appropriate reply. 189 A liaison statement, like any other temporary document, must be 190 considered in terms of its relevance, importance, and its urgency. 192 One hopes that a liaison statement will be sent to the right 193 organization, but this cannot be assured; an SDO might send a liaison 194 to a specific IETF area which the area director deems is better 195 handled by one of the working groups, or it might be sent to one 196 working group when it should have gone to another. If a liaison 197 arrives which appears misdirected, the assignee should promptly 198 redirect it, by reassigning it in the ID Tracker and forwarding the 199 associated email appropriately. In some cases, a liaison may require 200 consideration by multiple bodies; in such cases, one takes the lead 201 and responsibility. 203 Liaisons are always important to the body that sent them. Having 204 arrived at the appropriate body, the liaison may be more or less 205 important to the addressee depending on the contents of the liaison 206 and the expertise of the sender. If the liaison seeks to influence 207 the direction of a working group's development, it should get the 208 same consideration that any temporary document receives. The working 209 group chair may request the sender's contacts to make their case to 210 the IETF working group in the same manner and on the same basis that 211 an internet draft author makes his case. 213 The urgency of a liaison is usually reflected in its deadline. A 214 liaison for informational purposes will have no deadline; a courteous 215 "thank you" is called for, after which the working group may inform 216 itself of the contents and close the document. A liaison specifying a 217 deadline, however, gives the addressee a finite opportunity to 218 influence the activity of another body; if it fails to react in a 219 timely fashion, it may miss this opportunity. 221 3. Liaison Statements from other SDOs, Consortia, and Fora to IETF 223 The process of handling a liaison statement is a little heavier than 224 the handling of a business letter, however, because the organizations 225 and issues are heavier. To manage liaison statements, the IETF will 226 offer three web-accessible facilities: a form for submission of 227 liaison statements, a web page organizing their contents and making 228 them accessible, and a tracking system. 230 3.1 Liaison Statement Submission 232 The IETF Secretariat will offer a liaison submission web page. This 233 web page is accessible if and only if the person accessing it is 234 authenticated by a specified certificate or cookie. The mechanism for 235 distributing the authentication information is outside the scope of 236 this document. 238 The liaison submission web page is a form that requests the 239 information listed in Section 2.1 from the authenticated user. 240 Additionally, it has a button marked "reply" and if a reply has been 241 generated, a pointer to the reply liaison page.. 243 Submission of that information results in the following automated 244 actions: 246 o the addition of a URL to the "outstanding liaisons" summary web 247 page, 249 o creation of a display web page, 251 o a tickler/status entry in the ID tracker, assigned to the relevant 252 chair or AD 254 o an email to the assignee, copying the liaison's technical contacts 255 and an alias associated with the target (WG/BOF or other open 256 mailing list, area directorate, IESG, IAB, etc.) that contains 257 the URL to said web page and indicates that the liaison has 258 arrived, requests appropriate consideration, and if a deadline is 259 specified, a reply by the deadline. 261 The assignee has the capability of interacting with the ID tracker, 262 including changing dates, reassignment, closing the liaison process, 263 etc. 265 The ID Tracker's "tickle" function periodically reminds assignee by 266 email that the liaison has not yet been closed. It copies all of the 267 above except the associated mailing list. 269 Since a liaison is a temporary document, it lives by the rules 270 similar to those for IETF temporary documents: the liaison remains 271 posted until six months after having been closed. 273 3.2 Web Page for displaying Liaison Statements 275 The IETF site contains a section for current liaison activity. This 276 consists of 278 o A summary web page, 280 o A status/summary web page for each active or recently closed 281 liaison, and 283 o zero or more associated files. 285 The summary web page contains a simple frame, showing the title of 286 the liaison, the URL for its web page, and the organizations it is 287 from and to. 289 The web page for the liaison contains the information entered during 290 liaison submission, plus URLs for the various associated files. It 291 also contains the current status of the liaison: who it is assigned 292 to, its due date, and its status. It also contains a pointer to the 293 ID Tracker entry for the liaison. [consideration: if the ID Tracker 294 primarily contains assignee, status, etc, it may be worthwhile to 295 leave the information found in the ID Tracker there and refer to it 296 using this URL] 298 4. Communicating IETF information to other SDOs, consortia, and fora 300 This includes liaisons sent in reply to liaisons sent by other 301 bodies, and liaisons being sent by the IETF. 303 4.1 Spontaneously generating Liaisons to other organizations 305 Liaisons can be generated at a WG, Area, or IETF level to another 306 organization. The respective (co)chair(s) are responsible for judging 307 the degree of consensus for sending the particular liaison and what 308 the content should be. The amount of consensus required to send a 309 liaison statement varies greatly depending on its content. This 310 section gives some rough guidance about how much consensus should be 311 sought before sending a liaison statement to another organization. 313 4.1.1 Transmitting IETF documents to other organizations 315 The simplest case of approving sending of a liaison from IETF is 316 where the information that is being transmitted consists of an IETF 317 document that has some level of agreement within the IETF. The 318 process that the document has already gone through to achieve its 319 current status assures the necessary level of consensus. Any 320 Standards Track RFC (Draft Standard, Proposed Standard, Internet 321 Standard, BCP), and any working group document expected to be placed 322 on the standards track, may be transmitted without concern. 324 Informational documents may also be exchanged readily when they 325 represent a working group position or consensus, such as a 326 requirements or architecture document. 328 In all cases, the document status must be appropriately noted. In the 329 case of a Working Group Internet Draft, it must be clear that the 330 existence of the draft only indicates that the Working Group has 331 accepted the work item and, as the standard disclaimer says, the 332 actual content can be treated as nothing more than Work in Progress. 334 Individual Internet Drafts, Experimental or Historical RFCs, and 335 non-working group informational documents should not be transmitted 336 without developing further consensus within the relevant group, as 337 these documents cannot be truthfully represented as any kind of IETF 338 position. 340 4.1.2 Requests for Information 342 Another type of liaison that can be generated without the need for 343 extensive consensus building on the email list is a request for 344 information. The (co)chairs(s) can generate such a liaison when they 345 recognize from the activities of the group that some additional 346 information would be helpful, for example, to resolve an impasse 347 (i.e., don't waste time arguing over what the real meaning or intent 348 of another SDOs document is, just ask the other SDO and base further 349 work on the "official" answer). 351 Other requests for information may be to request access to certain 352 documents of other organizations that are not publicly available. 354 4.1.3 Requesting comments on Work in Progress 356 There may be cases where people feel that a document under 357 development in the IETF would benefit from the input of experts in 358 another relevant SDO, consortium, or forum. Generally, this is done 359 before the text is "fully cooked" so that input from experts in 360 another organization can be included in the final result. Comments 361 would generally be solicited for a standards track working group 362 Internet Draft and some level of consensus should be reached on the 363 working group or other open mailing list that it is appropriate to 364 ask another organization for comments on an IETF draft. 366 4.1.4 Requests for Other Actions (besides comments on IETF drafts) 368 There are a number of other kinds of actions that might reasonably be 369 requested of another organization: 371 o In the case of overlapping or related work in another 372 organization, a request could be made that the other organization 373 change something to align with the IETF work. 375 o A request could be made for another organization to start a new 376 work item (on behalf of IETF). 378 o A request could be made for another organization to stop a work 379 item (presumably because it overlaps or conflicts with other work 380 in the IETF). 382 These sorts of requests are quite serious. They can certainly be made 383 where appropriate, but these kinds of requests should only be made 384 where there is the clearest possible consensus within the particular 385 Working Group, Area, or within the IETF at large. 387 4.2 Responding to Incoming Liaisons 389 Any incoming liaison that indicates that it is for "Comment" or for 390 "Action" requires a response by the deadline; other liaisons may also 391 be replied to, although a reply is generally optional. It is the 392 responsibility of the (co)chair(s) of the addressed organization to 393 make sure that a response is generated by the deadline. 395 4.2.1 Responding to Requests for Information 397 If another organization requests information that can be found in an 398 IETF document of the types indicated in Section 4.1.1, this can be 399 transmitted by the (co)chair(s) of the addressed group, indicating 400 the level of agreement for the relevant document. 402 4.2.2 Responding to Requests for Comments 404 If an incoming liaison requests comments on a document from another 405 organization, a discussion will occur on the mailing list where 406 participants can provide their comments. 408 If a clear consensus is evident from the pattern of comments made to 409 the mailing list, the (co)chair(s) can summarize the conclusions in a 410 reply liaison back to the originating organization. 412 If no clear consensus is evident from the pattern of comments on the 413 mailing list, a response is still due to the originator. A summary of 414 the email comments can be created and sent to the originator, and 415 represented as "collected comments" rather than as a consensus of the 416 IETF group to which the liaison was addressed. It is possible to send 417 this kind of a reply even if some of the comments are contradictory. 419 4.2.3 Responding to Request for Action 421 A request for Action is a fairly serious thing. Examples of the kinds 422 of actions that may be expected are: 424 o In the case of overlapping or related work in another 425 organization, another organization may request that the IETF align 426 its work with that of the other organization. 428 o A request could be made for IETF to undertake a new work item. 430 o A request could be made for IETF to stop a work item (presumably 431 because it overlaps or conflicts with other work in the 432 originating organization). 434 Consensus of the receiving group within IETF is clearly necessary to 435 be able to fulfill the request. Fulfilling the request may require a 436 great deal of time and multiple steps, for example, if initiating or 437 stopping a work item requires a charter change. 439 There is, of course, no requirement that IETF perform the action that 440 was requested. But the request should always be taken seriously, and 441 a response is required. The originating organization must always be 442 informed of what, if anything, the IETF has decided to do in response 443 to the request. If the IETF decides not to honor the request, or to 444 honor it with modifications, the response should include the reasons 445 and, if applicable, the alternate course of action. 447 For tasks that require a great deal of time, it may be necessary that 448 several liaisons be sent back to the originating organization to 449 report the status of the work and the anticipated completion time. 450 The first of these liaisons must be generated by the deadline 451 indicated in the incoming liaison. 453 4.2.4 Tool for generating liaisons 455 The liaison page described in Section 3 may be used to generate a 456 reply. If an authenticated person (usually a working group char or 457 AD) selects "reply", a new liaison page is generated from the 458 existing one, to send the reply using. The "reply-to" email address 459 is used as a target rather than the selection of working groups and 460 areas, and the selection of working groups and areas is displayed as 461 a "from" field. In the case that the IETF is originating the liaison, 462 the appropriate target must be. 464 4.3 Approval and Transmission of Liaison Statements 466 It is important that appropriate leadership review be made of 467 proposed IETF liaison statements and that those who write such 468 statements who claim to be speaking on behalf of IETF are truly 469 representing IETF views. 471 All outgoing liaison statements will be copied to IETF Secretariat by 472 the liaison page.Copying liaison statements to the Secretariat is to 473 ensure posting of the outgoing liaison statements as described in 474 section 5. 476 For a liaison statement generated on behalf of an IETF working group, 477 the working group chair(s) must have generated, or must agree with 478 the sending of the liaison statement, and must advise the Area 479 Director(s) that the liaison statement has been sent by copying the 480 appropriate Area Directors on the message. 482 For a liaison statement generated on behalf of an IETF Area, the Area 483 Director(s) must have generated or must agree with the sending of the 484 liaison statement. If the liaison statement is not sent by the Area 485 Directors then their agreement is indicated by copying the Area 486 Directors on the message. 488 For a liaison statement generated on behalf of the IETF as a whole, 489 the IETF Chair must have generated or must agree with the sending of 490 the liaison statement. If the liaison statement is not sent by the 491 IETF Chair then his or her agreement is indicated by copying the IETF 492 Chair on the message. 494 4.4 Indication on Outgoing Liaison Statements about how to Respond 496 All outgoing liaison statements should indicate how to respond. This 497 is standard text which can be appended by the secretariat when the 498 liaison statement is sent. This text should read: 500 Please send any responses to this liaison statement via email to 501 statements@ietf.org, indicating 503 Attention: (xxx Working Group)|(xxx Area)|IETF 505 5. Security Considerations 507 One of the key considerations in developing this process has been the 508 possibility of a denial of service attack on the IETF and its 509 processes. Historically, the IETF has not handled liaisons 510 effectively, resulting in people working in other organizations 511 becoming frustrated with it. Various organizations have also used the 512 liaison process to attempt to impose deadlines on IETF activities, 513 which has been frustrating for all concerned - the IETF because it 514 does not accept such, and the other organizations because they feel 515 ignored. 517 This is the reason that the submission process is automated, and 518 restricted to authenticated submitters. While the IETF cannot 519 rate-limit the submitters it authenticates, it can control who it 520 authenticates, and it can manage its internal pipelines. 522 6. Acknowledgements 524 This text has been prompted by discussions with numerous individuals 525 within IETF and other Standards Development Organizations and Fora, 526 including Gary Fishman and Bert Wijnen. Personal experiences and some 527 "miscues" in coordinating work across ITU-T Study Group 15 and the 528 IETF Sub-IP Area have also motivated this work. Some drafts 529 addressing individual problems (e.g., 530 draft-andersson-mpls-g-chng-proc-00.txt and RFC 3427) make it clear 531 that a more general, consistent solution is needed for dealing with 532 outside organizations. Certain ideas have been borrowed from these 533 texts. 535 Normative References 537 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 538 Levels", BCP 14, RFC 2119, March 1997. 540 [2] Fishman, G. and S. Bradner, "Internet Engineering Task Force and 541 International Telecommunication Union - Telecommunications 542 Standardization Sector Collaboration Guidelines", RFC 3356, 543 August 2002. 545 [3] International Telecommunications Union, "IETF and ITU-T 546 collaboration guidelines, Supplement 3, http://www.itu.int/ 547 dms_pub/itu-t/rec/a/T-REC-A.Sup3-200111-I!!PDF-E.pdf", ITU-T 548 SERIES A: ORGANIZATION OF THE WORK OF ITU-T, November 2001. 550 Authors' Addresses 552 Stephen J. Trowbridge 553 Lucent Technologies 554 1200 West 120th Avenue, Suite 232, Room 34W34 555 Westminster, Colorado 80234-2795 556 USA 558 Phone: +1 303 920 6545 559 Fax: +1 303 920 6553 560 EMail: sjtrowbridge@lucent.com 562 Scott Bradner 563 Harvard University 564 29 Oxford St. 565 Cambridge, Massachusetts 02138 566 USA 568 Phone: +1 617 495 3864 569 Fax: 570 EMail: sob@harvard.edu 571 Fred Baker 572 Cisco Systems 573 1121 Via Del Rey 574 Santa Barbara, California 93117 575 USA 577 Phone: +1-408-526-4257 578 Fax: +1-413-473-2403 579 EMail: fred@cisco.com 581 Intellectual Property Statement 583 The IETF takes no position regarding the validity or scope of any 584 intellectual property or other rights that might be claimed to 585 pertain to the implementation or use of the technology described in 586 this document or the extent to which any license under such rights 587 might or might not be available; neither does it represent that it 588 has made any effort to identify any such rights. Information on the 589 IETF's procedures with respect to rights in standards-track and 590 standards-related documentation can be found in BCP-11. Copies of 591 claims of rights made available for publication and any assurances of 592 licenses to be made available, or the result of an attempt made to 593 obtain a general license or permission for the use of such 594 proprietary rights by implementors or users of this specification can 595 be obtained from the IETF Secretariat. 597 The IETF invites any interested party to bring to its attention any 598 copyrights, patents or patent applications, or other proprietary 599 rights which may cover technology that may be required to practice 600 this standard. Please address the information to the IETF Executive 601 Director. 603 Full Copyright Statement 605 Copyright (C) The Internet Society (2003). All Rights Reserved. 607 This document and translations of it may be copied and furnished to 608 others, and derivative works that comment on or otherwise explain it 609 or assist in its implementation may be prepared, copied, published 610 and distributed, in whole or in part, without restriction of any 611 kind, provided that the above copyright notice and this paragraph are 612 included on all such copies and derivative works. However, this 613 document itself may not be modified in any way, such as by removing 614 the copyright notice or references to the Internet Society or other 615 Internet organizations, except as needed for the purpose of 616 developing Internet standards in which case the procedures for 617 copyrights defined in the Internet Standards process must be 618 followed, or as required to translate it into languages other than 619 English. 621 The limited permissions granted above are perpetual and will not be 622 revoked by the Internet Society or its successors or assignees. 624 This document and the information contained herein is provided on an 625 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 626 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 627 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 628 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 629 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 631 Acknowledgement 633 Funding for the RFC Editor function is currently provided by the 634 Internet Society.