Network Working Group A. Mankin Internet-Draft Shinkuro, Inc. Expires: April 26, 2006 S. Hayes Ericsson October 23, 2005 Requirements for IETF Technical Publication Service draft-mankin-pub-req-01 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 April 26, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract The work of the IETF is to discuss, develop and disseminate technical specifiations to support the Internet's operation. As the the IETF progresses, document and review of its requirements for the process and structure of its technical specification publication is increasingly important, in order to ensure continued support for the IETF's work. Mankin & Hayes Expires April 26, 2006 [Page 1] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Stages in the Technical Specification Publication Lifetime . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Requirements Discussion . . . . . . . . . . . . . . . . . . . 6 4. Requirements for IETF Technical Specifications Publication Process . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Beginning-to-end Status Tracking . . . . . . . . . . . . . 7 4.2. Post-approval timeframes . . . . . . . . . . . . . . . . . 7 4.3. Fast Tracking . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Non-Author Editing . . . . . . . . . . . . . . . . . . . . 9 4.5. Post-Approval, Pre-Publication Changes . . . . . . . . . . 11 4.6. Post-Publication Changes: Maintaining and Updating Errata . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.7. Mechanisms for Changes to Tech Spec Style . . . . . . . . 12 4.8. Indexing: Publisher Maintenance of the Catalog . . . . . . 12 4.9. What is the Permanent Stable Identifier? . . . . . . . . . 12 5. Two Experiments . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Early Copy Editing of WG Documents by the RFC Editor . . . 13 5.2. Stable Permanent Identifier at Approval . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 9. Informative References . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . . . 20 Mankin & Hayes Expires April 26, 2006 [Page 2] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 1. Introduction The work of the IETF is to discuss, develop and disseminate technical specifications to support the Internet's operation. An important output of the IETF, then, is published technical specifications. As the IETF progresses, documentation and review of its requirements for the process and structure of technical specification publication is increasingly important, in order to ensure continued support for the IETF's work. The term "technical specification" is used here purposefully to refer to the technical output of the IETF. This document does not engage in the debate about whether it is expressed as RFCs or ISDs, what "is" an RFCs, how to classify, etc. All of that is out of scope. The intention of this document is to clarify the IETF's consensus on its requirements for its technical publication service. Discussing these requirements in relation to the existing service carried out by the RFC Editor is not a goal of this document. However, short and mid-term experiments with newly understood requirements can be performed in collaborations by the IETF and RFC Editor. This is the subject of Section 5. Mankin & Hayes Expires April 26, 2006 [Page 3] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 2. Scope The scope of this document is very specifically on the requirements of the publication process for technical specifications, leaving aside many of the other important topics related to the contribution to and creation of Internet-Drafts. Examples of topics that are meaningful, but are consciously not addressed here, include: o Specifics about non-technical document contents about which the the IETF and the publisher both have preference (such as contents of acknowledgement sections, reference classifications) o Structure of the non-technical document contents (such as their order or formats), again about which the IETF and the publisher both have preferences. o The large meta-topic of document formats -- it is imperative to get a firm agreement on the entire technical specification publication process before zeroing in on formats for any part of it. Nevertheless, it is important that the requirements laid out here do not place undue restrictions on future document format possibilities. Though these three points are out of scope here, the following proposed requirement encompasses addressing them in future: Req-1 The IETF should approve, or if needed, create and approve, a document describing the features of its technical publications, both the contents and policies on non-technical features, and structural matters such as the acceptable orderings of sections. The IETF should eventually approve a proposal for meeting its technical document requirements in terms of document format and processing, through the lifecycle shown in Figure 1 below. This topic is deferred from discussion at this time in part because this topic probably must span the whole lifecycle rather concerning only technical publication requirements. 2.1. Stages in the Technical Specification Publication Lifetime Figure 1 below provides a useful summary of where technical publication falls in the current lifetime of a document in the IETF. This figure shows a working group document and the review includes an IETF Last Call (LC). The lifetime is very similar for AD-sponsored IETF documents, such as documents which update IETF protocols where there is no longer a working group, or documents on interdisciplinary Mankin & Hayes Expires April 26, 2006 [Page 4] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 topics. | Author | WGLC | IESG, | | Tech Actors | or | AD | Shepherd, | A | Publisher, | Editor | IETF LC | Editor, | P | input from | | IANA | WG | P | authors, et al | | IESG | | R | Actions | Creation | | Resolution | O | non-author | and | Formal | of all | V | editing, | Editing | Reviewing | reviews | A | other | | | | L | publication |_________________| |______________________| |_________________| In WG Out of WG - Post-Approval Pre-Approval Figure 1: Stages of a Working Group Document Mankin & Hayes Expires April 26, 2006 [Page 5] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 3. Requirements Discussion The rest of this document discusses a series of requirements or postulated requirements for the IETF on the post-approval technical publication of its documents. For two of them, in Section 5, the stance of the document is to describe an experiment for a directed change from the 2005 situation, but otherwise, as stated, the requirements are presented in the abstract. o Beginning-to-end status tracking - more view into publication o Post-approval timeframes o Fast tracking o Non-author editing (publisher editing) o Post-approval, pre-publication changes (by the IETF) o Mechanisms for changes to technical publication style o Errata o Beyond errata o Indexing: publisher maintenance of the catalog o What is the permanent stable identifier? The IETF will determine in reviewing these what services best support its technical publication needs, and the result should be the set of requirements in this document expressed as firm requirements based on consensus. Then when the IAB, the IETF Administrator Director (IAD) and the IETF Administrative Oversight Committee (IAOC) RFC 4071 [2]. administer the Technical Publisher relationship for the IETF, they have a clear picture of the IETF's expressed requirements. In addition, the IETF can use these requirements, if expressed clearly enough, as a baseline when new or extended services are implemented. Mankin & Hayes Expires April 26, 2006 [Page 6] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 4. Requirements for IETF Technical Specifications Publication Process This section lists the set of requirements for IETF technical specifications publication. In each case, the current status is described (in terms of the extent to which the requirement is met and/or the means in which it is handled). Illustrations are provided. 4.1. Beginning-to-end Status Tracking In order to function as a full publication process, enabling all participants to fully contribute to, review, revise and reference specifications, it is imperative that all members of the IETF community have current and accurate information about the status of a specification's publication. Req-2 IETF documents should be able to move seamlessly from the IETF tracking system into the technical publication tracking system. (This discussion sets a requirement, but would not set forth how it would be accomplished). Req-3 The community should be obtain detailed status information on the publication process of IETF documents; for instance, both the IETF tracker and the technical publication tracker should provide external visibiity of not only the fact that a document is in an extended waiting period, but the token-holder or circumstance the wait. As with Req-2, Req-3 would not try to discuss how the fuller detailing would be provided. On the IETF side, the PROTO team will consider requirements for marking the token-holder accurately during long waiting periods, and others are looking into improved notification tools The requirement set on the technical publisher could be met by collaborations with these efforts, or by providing public access to email logs regarding publications, or by some other proposal. 4.2. Post-approval timeframes The IETF does not work in a vacuum. Many organizations (SDOs and implementing entities) depend on the IETF's specifications. Therefore, the IETF needs to be able to provide permanent references for, and final text of, specifications within a fixed time from the IETF's approval. Currently, our agreement with our technical publisher (the RFC Editor) has called for final publication within 2 months of approval, with a stable permanent reference available a month before that. Mankin & Hayes Expires April 26, 2006 [Page 7] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 However, the RFC Editor has a policy of not issuing permanent references for any documents before final textual publication, and the baseline of publication within 2 months has proven elusive over recent years. In special circumstances, a Fast Track expedite service may be requested, for document publication. We discuss this requirement in Section 4.3. A consideration for the stable permanent reference is whether it should also be held out till the 2 month point. RFC 2026 RFC 2026 [1]. stipulates that a document approval may be appealed up till 2 months after its approval. Note that the technical publisher meeting a strict post-approval timeframe for publication would depend on good discipline by everyone associated with the document. It has implications for authors, editors, working group, and the IANA protocol parameter assignment staff: all of these must be committed to timely action for their followup on any final reviews, changes, and actions needed post- approval. (Small delays add up shockingly if one is looking for a month or two month turn-around; the Area Director and the working group shepherd shepherding [3] must be proactive as coordinators and managers to keep a document on track for a short publication timeframe - see also Section 4.5, Post-Approval, Pre-Publication Changes, for more about this. The purpose of this section is not to discuss the current post- approval time-frame, though in the Section 5.2 below, we provide a suggestion for decoupling the provision of the stable permanent reference from the technical publishers editing queue present and future. The purpose here is to understand is to propose two firm requirements, in the light of the above discussion, including the coordination issues: Req-4 Stable permanent reference one or two months after approval Req-5 Published document at a predictable time after approval 4.3. Fast Tracking The technical publication service has a publication priority. In the ideal case, the the IETF would produce documents less quickly than the publication service could publish them, but this cannot be guaranteed for all future circumstances, and is not the case at the present writing, so there is a (substantial) queue with categories of priority (IETF working group standards track have high priority currently, e.g.). Under special circumstances, with documentation, the IESG votes to Mankin & Hayes Expires April 26, 2006 [Page 8] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 ask IETF Secretariat to send a message requesting expedited publication for a newly approved document. These circumstances are usually the requirement that the approved document have a stable permanent reference for another standards body's shortly to be published standard. Our experience is that lacking the stable reference, other bodies often simply incorporate the text of the last snapshot internet-draft in an appendix to their document, which is highly undesirable. But whether or not the pressure is as great as that, the expediting of the stable reference, called fast-tracking, is often a requirement. It seems likely that providing a stable permanent identifier within one or two months of approval (see Section 5.2) would eliminate most requests for technical publication Fast Tracking. Req-6 The IETF continues to requires Fast Track service requests, but the goal is for them to return to being rare, rather than frequent, e.g. needed because an eligible document approval has been accomplished with only a week or two to spare before its external deadline. 4.4. Non-Author Editing In the post-approval period, the technical publisher performs an editing role. This use of the word "edit" is very different from "editing" in the pre-approval period. The WG's Editor manages language and consensus from the IETF working group, Last Call and review process. The technical publisher's non-author editor, in the publication editing process, is interested not in any aspects of the IETF development, but only in improving readability, correcting spelling and grammar errors, and so on. These are laudable goals in any piece of writing, and the IETF should always be attempting to give less onerous work to its technical publisher improving its texts and not "leaving that [known] writing for the publisher to fix". But there are tradeoffs in the degree of non-author editing that is done, and the IETF needs to discuss the requirements it wants for this. How much copy editing is enough? Here is a range of possibilities: o corrections to errors only o light rewriting o significant editing of documents with less skillful WG editors, and minimal editing when the WG editors were skilled o rewriting of all documents to the dictates of a style manual Mankin & Hayes Expires April 26, 2006 [Page 9] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 At times in the past year, stylistic editing has resulted in 40-100 substantive changes in many documents. A typical structure of Non- Author Editing is to make changes, and then ask all the authors separately to vet them, and go through rounds of author acceptance and re-vetting. If the Post-approval timeframe is expected to be short, slowness in this process can be a serious problem. There may be a tradeoff between the amount of consultation and improved communication that can be attained, and the amount of time that multiple documents will be waiting for work to progress. An issue for the IETF's assessment of non-author editing is that most individuals experience only a few publications a year at most, whereas WG Chair shepherds and Area Directors (and the technical publisher) view the throughput of larger number of publications. Can the IETF support individual experiences of writing being improved for the best while also maintaining a high throughput of documents as desired by users of our specifications? Pre-Req-7 The IETF needs to construct a requirement for non-author editing balancing the quality effects with timeliness and other issues. An example of balance is that the IETF could guide document shepherds to nominate one person in the author team to speak for all when a document is going to receive a heavier edit (and require the technical publisher to accept the document shepherd's leadership on this). A distinct issue from the convergence when there are many changes is the possibility of loss of technical meaning or loss of WG consensus wordings. The more extensive forms of stylistic editing can change agreed on technical information or agreed on language (sometimes wording that has been settled on as part of a review). At best, the loss in these cases is just time (and some tempers). But since this activity occurs when the document has left the WG, there can be problems of determining whether the WG must become involved in the new language for a former WG consensus or technical matter, or if they must stay in the dark. One is time-consuming and recycles the document, essentially, the other loses IETF transparency. Pre-Req-8 The IETF needs to construct a requirement for non-author editing regarding changes to technical and consensus wording. Is the early copy editing experiment (see Section 5.1) a good solution, since the document receives its thorough editing for style before it leaves the working group, while the WG is still reviewing the document? Mankin & Hayes Expires April 26, 2006 [Page 10] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 4.5. Post-Approval, Pre-Publication Changes Though occurring at the same time as the technical publisher's copy edits, the post-approval, pre-publicaton changes referred to in this section come from the IETF, and raise problems for us because they are often extensive and time-consuming. The document becomes ready for publication, the copy edit comes to the authors and editors, and the primary author or perhaps several of them, present the publisher, with a long list of their own changes. These fall into a number of categories, and it may be suggested that the IETF could agree that some of these are procedurally permitted (with appropriate steps) and some not: o Changes the author or editor wants he or she thinks because document will read better o Technical change WG has found and agreed on since approval o Small update needed to match another spec approved since approval o Serious technical bug found since approval The IETF has held that the author and editor are not the 'owners' of the document so that the first type is not viewed as an acceptable request (it would be acceptable during the time the editor is working on the document in the WG, but no longer during Post-Approval). The IETF should decide to accept the other types, but require them to be submitted only within a fixed time after approval, rather than having them submitted in the last few days before publication, when they contribute to delay. The last type, the serious bug, clearly needs to be reportable up to the last moment. Req-9 Authors/IETF Editors must not initiate stylistic changes during the Post-Approval period. Req-10 Authors/IETF Editors/WGs may request small technical changes or small updates to a document (to match another approved specification) in the Post-Approval, period, but the IETF will require these to be presented to the document shepherd (and processed) within a set time period after approval has elapsed (following that period, issues with the document will be handled by other means). 4.6. Post-Publication Changes: Maintaining and Updating Errata A technical publications service maintains errata for the publications. If a bug or error is found after the document is Mankin & Hayes Expires April 26, 2006 [Page 11] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 issued, rather than republishing a corrected copy, because of the stickiness of web copies, a specific error notice is placed on a web page. What does the IETF require for this service in terms of: o Public awareness o Review of the erratum (who reviews, transparency of review) o Timeliness of posting o Is this the right service? o How does this interact with limiting the submission time for changes and updates to post-approval documents? 4.7. Mechanisms for Changes to Tech Spec Style See Req-1 4.8. Indexing: Publisher Maintenance of the Catalog To Come 4.9. What is the Permanent Stable Identifier? The permanent stable identifiers of IETF documents are widely referenced (as the IETF technologies are widely used). The current policy of the IETF is to publish our documents in a series whose identifiers the IETF does not manage. Further we publish our standards and working group documents in this series, along with experimental drafts, documents receiving very light review such as those under the current URN policy, and so on. Proto-Req-11 The IETF should consider whether its own permanent stable identifier system would be of benefit, including being able to make clear the distinction in the identifier between IETF documents which have had more and less IETF review. Mankin & Hayes Expires April 26, 2006 [Page 12] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 5. Two Experiments The following are presented as experiments for a current IETF/RFC Editor collaboration. One is running currently. The second could be proposed if this discussion results in interest; it is given a concrete form for that purpose. 5.1. Early Copy Editing of WG Documents by the RFC Editor Time: September 20005 - November 2005 Objectives: Improve document quality early on Experiment to perform as much of the editorial work as possible early in the process, e.g., before working group last call. This note describes a very limited initial experiment that should begin to sort out the issues. We can then decide whether further experimentation is warranted. Expected impact: o positive impact on WG Last Call, AD review, IETF Last Call and IESG review. This is expected because of clearer/better text early on. o less copy-editing, so faster process after IESG approval. This hopefully reduces the time between IESG approval and RFC publication. o Reduction of time spend in status AUTH48. This is expected because there should be less changes (if any) between the approved text and the rfc-to-be-published. This seems to insert post-approval activity into the pre-approval period. But in fact it makes what was a serial process a partly parallel one. Part of the study is to determine if this parallelizing holds good, and there is not a long interlude on copy editing at the end of the publication period for these experiment documents. 5.2. Stable Permanent Identifier at Approval A large fraction of IETF documents have either SDOs or implementor consumers who require a stable permanent identifier as soon as the document is approved. This is a compliment to the value of the IETF's work. Although simply providing the technical publications right away seems desirable, there are operations research arguments Mankin & Hayes Expires April 26, 2006 [Page 13] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 to suggest that the IETF offer what the IETF can control, the output of the IETF's approval, not gated on a service we can only give requirements for. Here is an outline for steps in an experiment for the IETF providing the stable permanent identifier at approval, and how this would modify the requirements for the technical publication: o IESG approves document, which may include some text changes in the form of Notes to the Publisher o IANA performs IANA actions for the document as usual and places usual i-d placeholder o The two month timeout on appeals runs out (document approval is now final). (As discussed above, this period could be shortened based on the view that approval rescissions are rare). o The IESG assigns stable permanent identifer to the document and passes this to IANA and to the publisher. o IANA can now update registry with the stable permanent identifier o At this time the IETF's editor/author prepares a new draft with filename to be determined but which includes the stable permanent identifier o The internal headers must be modified so that they include the stable permanent identifier and convey the approval status and non-expiration of the document, for instance: OLD: INTERNET-DRAFT September 5, 2005 Expires: March 5, 2006 NEW: RFC-TO-BE #### Approved September 30, 2005 Expires at RFC Publication The new draft would not be as polished as the RFC publication, but it would incorporate the text changes and would be technically stable. Related to the section above on post-approval changes, if the timeframe for those is set in the same timeframe, this draft can be shepherded to include those and exclude all future, other than severe bugs that have been discovered. Mankin & Hayes Expires April 26, 2006 [Page 14] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 The shepherds for the document should ensure that normative references for the document have stable permanent references already, for the citations. OPEN ISSUE: how to manage documents which are brought forward with normative references which will be significantly delayed beyond the window of permanent stable identifier issuance. On first thought, it seems that such drafts need to be wait as before; the rationale for waiting for normative references is that the technology underlying the first approved work may change significantly by the time the later work comes to approval. It is not always possible to secure completion of all work on which one's specification is dependent, but this is an important task for the document shepherds as the document progresses, to try to coordinate with the other work's progress. Other open issues are likely, besides execution questions such as the best string name for the post-approval draft. However this experiment would pull together a number of the requirement threads. Mankin & Hayes Expires April 26, 2006 [Page 15] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 6. IANA Considerations Any requirements that result from this discussion need to be reviewed by IANA and the IETF to understand to what extent, if any, the work flow of the documents through IANA are affected. Mankin & Hayes Expires April 26, 2006 [Page 16] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 7. Security Considerations There is a tussle between the sought-for improvements in readability and the specific language that has often been negotiated carefully for the security content of IETF documents. In general, it seems that clarifying the technical publication requirements seems likely to make sure that the IETF's secure protocols get out more effectively and with better result. Mankin & Hayes Expires April 26, 2006 [Page 17] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 8. Acknowledgements The early copy edit experiment writeup is by Bert Wijnen, and he made a number of useful comments on the rest. Leslie Daigle has contributed strongly to this text throughout. Other acknowledgements to date: a discussion on the wg chairs mailing list, Henning Schulzrinne, Henrik Levkowetz. 9. Informative References [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. [2] Austein, R. and B. Wijnen, "Structure of the IETF Administrative Support Activity (IASA)", BCP 101, RFC 4071, April 2005. [3] Levkowetz, H. and D. Meyer, "The PROTO Process: Working Group Chair Document Shepherding", draft-ietf-proto-wgchair-doc-shepherding-05 (work in progress), March 2005. Mankin & Hayes Expires April 26, 2006 [Page 18] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 Authors' Addresses Allison Mankin Shinkuro, Inc. 1025 Vermont Avenue Washington, DC 20005 USA Phone: +1 301 728 7199 Email: mankin@psg.com URI: http://www.psg.com/~mankin/ Stephen Hayes Ericsson Phone: Email: stephen.hayes@ericsson.com URI: Mankin & Hayes Expires April 26, 2006 [Page 19] Internet-Draft draft-mankin-techspec-pubreq-01 October 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Mankin & Hayes Expires April 26, 2006 [Page 20]