Network Working Group J. Arkko (Editor) Internet-Draft Ericsson Intended status: Informational March 5, 2007 Expires: September 6, 2007 Guidance on Area Director Sponsoring of Documents draft-iesg-sponsoring-guidelines-02 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 6, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This note discusses the process related to "individual submissions", publication of RFCs by finding a sponsoring Area Director to take it through IETF and Internet Engineering Steering Group (IESG) review. This note covers both the the processing in the IESG as well as guidance on when such sponsoring is appropriate. Arkko (Editor) Expires September 6, 2007 [Page 1] Internet-Draft AD Sponsoring Guidelines March 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements language . . . . . . . . . . . . . . . . . . . . 3 3. Submission . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Processing Rules . . . . . . . . . . . . . . . . . . . . . . . 4 5. Choosing Documents to Sponsor . . . . . . . . . . . . . . . . 5 6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Summary of Changes to Existing Procedures . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 11 Appendix B. Secretariat Response to Submissions . . . . . . . . . 12 Appendix C. PROTO Write-Up . . . . . . . . . . . . . . . . . . . 13 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Arkko (Editor) Expires September 6, 2007 [Page 2] Internet-Draft AD Sponsoring Guidelines March 2007 1. Introduction "Individual submissions" are documents intended to become RFCs through the IETF, without being submitted by a Working Group (WG). The publication of these documents requires the authors to find sponsoring Area Director (AD) to take it through IETF and Internet Engineering Steering Group (IESG) review. Accordingly, this publication method is sometimes called the "AD Sponsored" method. The note is concerned with the IESG processing by the AD Sponsored method. This note also provides guidance for choosing between individual submissions and independent submissions through the RFC Editor. This note describes procedures and working methods. It does not change any underlying rules such as those in RFC 2026 [RFC2026] or the operation of the RFC Editor as defined in [I-D.iab-rfc-editor]. The note also does not change the procedures related to independent submissions or other RFC streams [I-D.iab-rfc-editor] [I-D.klensin-rfc-independent]. 2. Requirements language In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 3. Submission Individual submissions enter the process through an agreement with an AD. Such agreements are usually the result of the AD tracking the work earlier, or discussions between the authors and the AD. And sometimes the AD agrees with a WG that a particular document should be progressed as an individual submission. Similar to the process for WG submissions, the authors may find a willing external Shepherd [I-D.ietf-proto-wgchair-doc-shepherding]. The task of the Shepherd is to manage the discussions relating to the document's process through the system. The Shepherd will also provide a write-up similar to Document Shepherd Write-ups for WG documents. Appendix C explains how to interpret the normal write-up template for individual submissions. If no Shepherd can be identified, the tasks of the Shepherd fall on the AD. In that case the authors should, however, provide the write up so that the AD has the necessary background information about the proposal. When the AD has the write-up he or she can insert the document into the data Arkko (Editor) Expires September 6, 2007 [Page 3] Internet-Draft AD Sponsoring Guidelines March 2007 tracker and set its parameters correctly (e.g., the area, intended status and ballot information). If for some reason the authors cannot identify the most relevant Area Director, they should contact to the General Area Director first. This replaces the previous practice of writing to the IESG as a whole. Messages sent to iesg-secretary@ietf.org prompt the secretariat to send a response that suggests the authors should follow the appropriate submission procedure for their desired method, such as finding an AD to sponsor an individual submission. The response can also suggest that the authors should also consider the normal IETF publication path through an existing working group, or consider proposing a BoF at a future IETF meeting. An example note is shown in Appendix B. Finally, authors who consider making either an individual submission through the IETF or an independent submission via the RFC Editor should be aware that some documents either have to be from the IETF or would benefit from being from the IETF. For instance, the document may request an IANA allocation from a space that has a Standards Action IANA rule (see RFC 2434 [RFC2434]). Such actions can not come from independent submissions. For a discussion of when a document can not be processed as an independent submission, see RFC 3932 [RFC3932]. One possibility for such documents is to process them as AD Sponsored submissions. Other alternatives include finding or creating a suitable WG to process the document or abandoning the document altogether. The authors are responsible for the decision to proceed with a particular approach among the set of allowed options. The authors are also responsible for the effort of proposing a Birds-of- a-Feather (BoF) session, convincing the IESG or one of the ADs that the document needs to be sponsored, etc. 4. Processing Rules AD Sponsored documents to Standards Track require review in the IETF, IETF Last Call, and IESG approval. AD Sponsored documents to Experimental/Informational require some form of review in the IETF and IESG approval. While RFC 2026 does not require the latter type of documents to go through an IETF Last Call, this note suggests that it is always performed. It is needed to ensure adequate review and transparency in a situation where the pending publication of the document may not be known by any Working Group or the IETF community at large. Arkko (Editor) Expires September 6, 2007 [Page 4] Internet-Draft AD Sponsoring Guidelines March 2007 As RFC 2026 states, when a proposed standards action comes from outside Working Groups, the IETF Last Call period is at least four weeks. If the IESG believes that the community interest would be served by allowing more time for comment, it may decide on a longer Last-Call period or to explicitly lengthen a current Last-Call period. The exact nature of the review within the IETF is not specified, but it is expected that documents be posted for review in the relevant WG mailing lists. Often no relevant mailing list exists, in which case area-specific or IETF main discussion list can be used. Individual reviewers, review teams, and review boards for specific topics can also be used. If no sufficient review has been obtained, the AD should solicit it explicitly. Note that discussing topics outside the charter of a WG can cause loss of focus in a WG, if a WG list is chosen for discussion. This should be considered when seeking review and when deciding to adopt documents for sponsoring. On the other hand, work closely related to a WG but strictly outside its charter should always be brought to the WG's attention during review. Sponsored submissions are treated in the same manner with other submissions in the actual IESG evaluation process. Existing discuss, appeal, recusing, etc. rules apply also to sponsored submissions. 5. Choosing Documents to Sponsor This section provides some guidelines for the use of the AD Sponsoring method. Such guidelines are useful when authors contact the AD and suggest that their document be sponsored. The rules are also useful in controlling the load on the IESG, and to ensure fairness. AD Sponsored documents are the only way to publish Standards Track documents outside WGs. IETF documents may also have a higher priority at the RFC Editor processing queue than independent submissions. When considering the choice between a sponsored document and an RFC Editor submission, the RFC 3932 rules play a role [RFC3932]. If it is likely that the document would generate a 3 (harmful to IETF work), 4 (violates IETF procedures) or 5 (extension requires IETF review) response based on RFC 3932 it is not appropriate for an independent submission. Sometimes such documents are suitable candidates for being sponsored, however. It would be useful to add, say, IANA rules or IPv6 considerations to an old specification that did not have them and for which no WG can be found. Such additions to standards track RFCs need to be on the standards track themselves, Arkko (Editor) Expires September 6, 2007 [Page 5] Internet-Draft AD Sponsoring Guidelines March 2007 preventing the use of independent submissions. In general, the decision to sponsor a document involves AD discretion. It is necessary for the AD to be willing to spend effort on the document. The following considerations should be applied: Document Track Documents that need to be on the Standards Track can only be published via WGs or the AD Sponsored method. Documents that fall under this class should either be handled by the IETF in some manner or be dropped. This ultimate decision depends on, among other things, on the value of the document's contribution and whether it fits within the mission of the IETF. The AD should also consider whether the normal IETF WG/BoF process should be employed instead. Some situations where this is impractical have been noted in Section 6. IANA Rules Documents that request "IETF Consensus" or "Standards Action" IANA allocations also need to be WG submissions or AD Sponsored documents. On the other, documents intended to satisfy "Specification required" could be processed as independent submissions. Benefit from IETF Review All AD sponsored documents go through IETF Last Call, and also receive additional review from the sponsoring AD, the IESG, and may also be reviewed by solicited experts and WGs. Does the document need such IETF-wide review, or is RFC Editor's Independent Submission Review (ISR) sufficient? For instance, the AD can decide that while a particular document could be an independent submission, the added review would be useful and would benefit the community. As an example, the AD may expect that a particular protocol will be widely deployed, and that providing additional IETF review makes the protocol more likely to be useful for the community and less likely to cause problems. Arkko (Editor) Expires September 6, 2007 [Page 6] Internet-Draft AD Sponsoring Guidelines March 2007 Availability of Reviewer Resources Are there persons that can help with the review of the document during, for instance, the IETF Last Call? Is there a risk that such persons become distracted from their chartered work at the IETF because of the extra reviews being requested? Fairness ADs should be fair in choosing the documents that they decide to sponsor. For instance, they should not give priority in accepting or processing documents on company or personal criteria; the content of the document and its relevance to the Internet community should be the guiding factor. Where an AD is one of the authors or significant contributors in a document, he or she can not be the sponsoring AD. Relevance The above process issues need to be considered together with the relevance the document has for the Internet community. Does it solve an important problem? Does it describe an issue that affects a significant number of users in the Internet? Does it create an interface or convention where widespread interoperability would be necessary? For instance, a document that describes a serious vulnerability or an architectural issue in protocols in the AD's area is a good candidate for being sponsored. Clarifications and small updates of protocols in the AD's area are also good candidates when no suitable working working group exists, and the scale of the change does not warrant the creation of one. A document specifying a particular vendor's proprietary protocol is typically more suitable as an independent submission than being sponsored by an AD. A document specifying an alternate approach to an existing Standards Track solution is typically not a likely candidate either. But this is a judgment call. For instance, if there is general agreement in a WG for publishing a "road not followed" document for the record, but the WG itself considers it out of scope, AD sponsoring might be appropriate. Quality As with relevance, the quality of the document and the expected outcome of the IETF review process affect the decision. In general, the AD should only sponsor documents that he or she Arkko (Editor) Expires September 6, 2007 [Page 7] Internet-Draft AD Sponsoring Guidelines March 2007 believes in; the decision to sponsor should only be taken after at least as detailed review as the AD performs for regular WG submissions. As with BoFs, it is possible that the IETF community is divided or unable to agree on a proposal, even if the proposal itself is of high quality and relevant. The AD should consider the likelihood of achieving consensus in IETF review, if relevant for the type of document in question. History Sometimes the IETF, IESG, and the WG has more information about the history of the document than the RFC Editor. This is the case with the "road not followed" documents mentioned above as well as with other documents recently seriously considered in the IETF. If the publication of these documents is appropriate, they are likely more suitable as individual submissions than as independent submissions. ADs can always decline to sponsor a given document. It may take a while to find the right AD. Sometimes the contacted AD may suggest that the document fits better in another AD's area of expertise. Or the author may realize that a more suitable AD exists. Legitimate search for the right AD should not be confused with authors going through several ADs trying to find one that will sponsor their document. For BOF requests, this practice has been termed "AD shopping." To identify cases of AD shopping, it is recommended that ADs send a brief note to the IESG when they have turned down a sponsoring request, accompanied by an indication if this was due to unsuitable topic for the AD or some other reason. This allows the other ADs to recognize that they are being asked for the same document again. This should not necessarily cause the second AD to automatically turn down the request. However, it is recommended that he or she query the ADs that have turned down sponsorship in the past and incorporate this information into their own decision. 6. Discussion AD Sponsored submissions represent a significant workload to the IESG. Reasons for the popularity of these submissions include the interest of the ADs to progress work in their fields, the difference in time-to-RFC-publication IETF documents enjoy over independent submissions, the ability to avoid the IESG notes that independent Arkko (Editor) Expires September 6, 2007 [Page 8] Internet-Draft AD Sponsoring Guidelines March 2007 submissions get, and the wider review IETF documents get. Improvements in the efficiency of the RFC Editor processing are likely to increase the popularity of the independent submissions, which represent a smaller load for the IESG. Similarly, ongoing work [I-D.klensin-rfc-independent] may change the tone of the IESG notes. However, the speed of the independent submissions channel depends to a large extent on its review stage, and it has generally been easier to find reviewers for IETF documents. In any case, the IESG can handle some amount of sponsored documents. The system is self-regulating in the sense that if the IESG becomes too busy, the ADs are less likely to adopt sponsored documents; there is no requirement for them to sponsor any submissions. The interesting question is why there was no WG to deal with the issue in the proposal, if it is so important and useful. One reason for this can be that our BoF process tends works better for large efforts than small. The process also favors focused efforts which may make it hard to report issues that cross multiple WGs or areas. Running a BoF and creating a WG takes time and requires a significant number of persons to be involved in the effort. Some of the situations where this can be problematic include: o Corrections and small updates of existing RFCs when the WG that created the original RFCs no longer exists. o Draft Standard revisions of Proposed Standard RFCs when the WG no longer exists. o IANA considerations updates for old protocol specifications to bring them up to today's requirements. Many old protocol specifications had no IANA considerations, for instance. o Architectural issues that cross multiple WGs or areas, but are not being handled currently by the IAB. o Registration of values and formats in frameworks, such as media type registrations. Some areas employ area-specific WGs that can be used to process some of these. For instance, TSVWG in the Transport area produces documents as a real WG, resulting in less need for AD sponsoring. Other areas such as Internet and Security have area-specific discussion forums that do not act like WGs. The Routing area employs both models with their RTGAREA group for discussion and RTGWG for WG- like operation for "catchall" documents. In the Operations and Management Area the MIB Doctors team discusses procedural and Arkko (Editor) Expires September 6, 2007 [Page 9] Internet-Draft AD Sponsoring Guidelines March 2007 technical issues, reviews documents, and sometimes issues documents related to the MIB quality review process. 7. Summary of Changes to Existing Procedures The "talk to the appropriate AD" and "submit via RFC Editor" approaches are promoted over submitting documents via the secretariat. This allows the ADs to discuss the appropriate submission method with the authors, and does not require the secretariat to think about policy issues such as whether a document is worthwhile for being sponsored. Submissions sent to iesg@ietf.org are not considered. New text is adopted for the secretariat's response to submissions. It should also be noted that Section 4.2.3 of RFC 2026 states "Unless they are the result of IETF Working Group action, documents intended to be published with Experimental or Informational status should be submitted directly to the RFC Editor." This has not been operational practice for some time, however. A number of Informational and Experimental documents have been submitted as AD Sponsored documents. The rationale behind this is the wider review that can be achieved, but this is one area where current procedures have deviated from RFC 2026. However, RFC 2026 is not technically violated, since in these cases the IESG serves as the submitter to the RFC Editor in place of the author. 8. Security Considerations There are no security considerations beyond those normally involved in the IETF processing of proposals for new RFCs. 9. IANA Considerations There are no IANA considerations. 10. References 10.1. Normative References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. Arkko (Editor) Expires September 6, 2007 [Page 10] Internet-Draft AD Sponsoring Guidelines March 2007 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3932] Alvestrand, H., "The IESG and RFC Editor Documents: Procedures", BCP 92, RFC 3932, October 2004. [I-D.ietf-proto-wgchair-doc-shepherding] Levkowetz, H., "Document Shepherding From Working Group Last Call to IESG Approval", draft-ietf-proto-wgchair-doc-shepherding-07 (work in progress), June 2006. 10.2. Informative References [RFC3967] Bush, R. and T. Narten, "Clarifying when Standards Track Documents may Refer Normatively to Documents at a Lower Level", BCP 97, RFC 3967, December 2004. [I-D.iab-rfc-editor] Daigle, L., "The RFC Series and RFC Editor", draft-iab-rfc-editor-01 (work in progress), July 2006. [I-D.klensin-rfc-independent] Klensin, J., "Independent Submissions to the RFC Editor", draft-klensin-rfc-independent-02 (work in progress), May 2006. Appendix A. Acknowledgements This note has been prepared as a result of discussions in the IESG. The members of the IESG at the time this was written were: Bill Fenner Brian Carpenter Cullen Jennings Dan Romascanu David Kessens Arkko (Editor) Expires September 6, 2007 [Page 11] Internet-Draft AD Sponsoring Guidelines March 2007 Jari Arkko Jon Peterson Lars Eggert Lisa Dusseault Magnus Westerlund Mark Townsley Ross Callon Russ Housley Sam Hartman Ted Hardie In addition, the editor would like to thank Leslie Daigle, John Klensin, and Pekka Savola for input. Appendix B. Secretariat Response to Submissions Individual submission requests sent to iesg-secretary@ietf.org prompt the secretariat to send a response suggesting an alternative submission process. Example response note is shown below. Arkko (Editor) Expires September 6, 2007 [Page 12] Internet-Draft AD Sponsoring Guidelines March 2007 "We cannot process your request. Please make an independent submission through the RFC Editor, or find an IETF Area Director to sponsor your draft as an individual submission to the IETF. Also, please consider the normal IETF publication path through an existing working group, or consider proposing a BoF at a future IETF meeting. Please see RFC 3932 for guidance on which documents may be suitable as independent submission through the RFC Editor. If you choose this option, please send your publication request to If you wish to seek Area Director sponsorship for an individual submission, the best solution is to contact the most relevant Area Director directly, with an explanation of why the draft is appropriate for IETF publication. The Area Director is also the best source of advice about whether an existing WG, or a BoF, may be applicable. The Area Directors and WGs are listed at: http://www.ietf.org/html.charters/wg-dir.html If for some reason you cannot identify the most relevant Area Director, please talk to the General Area Director first. The IETF Secretariat" Appendix C. PROTO Write-Up A write-up should accompany any request for sponsoring. This write-up should follow the the Document Shepherd Write-up template given in Section 3.1 of [I-D.ietf-proto-wgchair-doc-shepherding]. However, as there is no working group, questions that relate to the the working group need to be interpreted in the context of the interested community instead. It is assumed that an interested community exists in all cases, and that individual submissions are not prepared in complete isolation. In addition, under item 1.k the authors should indicate if the document been considered in any existing or past WG, and if yes, describe why the work was not adopted as a work item there. The initial template of the edited write-up is included below for ease of copying pasting the questions elsewhere. But changes are expected over time. Any future changes to [I-D.ietf-proto-wgchair-doc-shepherding] need to be applied, for instance. The latest version of this template is available from the Arkko (Editor) Expires September 6, 2007 [Page 13] Internet-Draft AD Sponsoring Guidelines March 2007 IESG section of the IETF web site. (1.a) Who is the Document Shepherd for this document? Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? (1.b) Has the document had adequate review both from key members of the interested community and others? Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the interested community has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. (1.e) How solid is the consensus of the interested community behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the interested community as a whole understand and agree with it? (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? (1.h) Has the document split its references into normative and informative? Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their Arkko (Editor) Expires September 6, 2007 [Page 14] Internet-Draft AD Sponsoring Guidelines March 2007 completion? Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggested a reasonable name for the new registry? See [I-D.narten-iana-considerations-rfc2434bis]. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Writeup? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary Relevant content can frequently be found in the abstract and/or introduction of the document. If not, this may be an indication that there are deficiencies in the abstract or introduction. Working Group Summary Was there anything in the discussion in the interested community that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? Was the document considered in any WG, and if so, why was it not adopted as a work item there? Arkko (Editor) Expires September 6, 2007 [Page 15] Internet-Draft AD Sponsoring Guidelines March 2007 Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? Personnel Who is the Document Shepherd for this document? Who is the Responsible Area Director? The write-up is entered into the ID Tracker in the "Comment" field. Author's Address Jari Arkko Ericsson Jorvas 02420 Finland Email: jari.arkko@ericsson.com Arkko (Editor) Expires September 6, 2007 [Page 16] Internet-Draft AD Sponsoring Guidelines March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Arkko (Editor) Expires September 6, 2007 [Page 17]