diff options
Diffstat (limited to 'doc/rfc/rfc1550.txt')
-rw-r--r-- | doc/rfc/rfc1550.txt | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc1550.txt b/doc/rfc/rfc1550.txt new file mode 100644 index 0000000..eaee1a1 --- /dev/null +++ b/doc/rfc/rfc1550.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group S. Bradner +Request for Comments: 1550 Harvard University +Category: Informational A. Mankin + NRL + December 1993 + + + IP: Next Generation (IPng) White Paper Solicitation + +Status of this Memo + + This memo provides information for the Internet community. This memo + does not specify an Internet standard of any kind. Distribution of + this memo is unlimited. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1 + 2. Document Review Process . . . . . . . . . . . . . . . . . . 2 + 3. Document Format Requirement . . . . . . . . . . . . . . . . 2 + 4. Outline for IPng Requirements and Concerns White Papers . . 3 + 5. Engineering considerations . . . . . . . . . . . . . . . . . 3 + 6. Security Considerations . . . . . . . . . . . . . . . . . . 5 + 7. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 5 + Appendix A - Formatting Rules (from RFC 1543) . . . . . . . . . . 6 + +1. Introduction + + The IP: next generation (IPng) area in the IETF is soliciting white + papers on topics related to the IPng requirements and selection + criteria. + + All interested parties are invited to submit white papers detailing + any specific requirements that they feel an IPng must fulfill or any + factors that they feel might sway the IPng selection. An example of + the former might be a submission by a representative of a utility + company detailing the scaling and addressing features which would be + required to service future inclusion of utility meters on the + network. An example of the other case might be a paper outlining the + potential effect on IPng of some sections of the future network + connectivity being provided via wireless networks. + + At this time, we are not accepting white papers that evaluate + specific IPng proposals. This type of document will be accepted + after the various proposal documents are deemed to be clear and + complete. + + + + + +Bradner & Mankin [Page 1] + +RFC 1550 IPng White Paper Solicitation December 1993 + + + All white papers will be reviewed in a process described below. As a + result of these reviews, each white paper will receive the focused + attention of the IPng directorate and the community. The white + papers will be used as resource materials by the IPng Area working + groups, the directorate, the external review board and the area + directors, during the selection process. + + The deadline for the submission of these white papers is February 1, + 1994, though early submission is encouraged. + + Submit white papers, general or topic questions, and so on, to + ipng-wp@harvard.edu. + +2. Document Review Process + + All submitted documents will first be reviewed for clarity by members + of the IPng directorate and the external review board. This review + may produce suggestions to the author on areas of the document where + there may be some confusion as to the meaning. Authors are urged to + consider any such suggestions as constructive and to reexamine their + text in light of the suggestions. + + A separate technical review will then be done of the white paper. + This review will be conducted within the context of the document. + That is, the review still will not make value judgments on the white + papers, but will assess technical feasibility. This review may also + produce suggestions to the author. + + The document will be submitted as an Internet-Draft after these + reviews have been completed and after whatever (if any) revisions + that the author decides to make. After a suitable period of time + these documents will be submitted as informational RFCs unless + withdrawn by the author. These documents will comprise a part of the + historical record of the IPng process. + +3. Document Format Requirements + + All white papers must follow the format requirements listed in RFC + 1543 and must not exceed 10 pages in length. (The relevant portion of + RFC 1543 is included in this document as Appendix A.) They should + not include the "status of memo" section; this will be added when the + documents are posted as Internet Drafts. The reference version of + the document must be in ASCII as is current practice with all RFCs. + A PostScript version of the document may be submitted in addition to + the ASCII version. (See RFC 1543 for the formatting procedures to use + with PostScript documents.) + + + + + +Bradner & Mankin [Page 2] + +RFC 1550 IPng White Paper Solicitation December 1993 + + +4. Outline for IPng Requirements and Concerns White Papers + + This section details the white paper outline to be followed by + someone who would like to express an opinion about the various + factors involved in the IPng definition and selection process. Since + these documents will be used as resource material by the various IPng + working groups, the directorate, the external review board and the + area directors, they should be well-focused and give specific + references to data supporting their points. + + Each white paper should begin with an executive summary of the + important points of the document. This executive summary should not + exceed 1/2 page in length. + + The white paper should then address the issue or issues that the + author feels should be understood during the IPng process. The total + document should not exceed 10 pages in length. An author may submit + more than one white paper if he or she feels that the level of + detailed discussion on each topic warrants it. + +5. Engineering considerations + + In past discussions the following issues have been raised as relevant + to the IPng selection process. This list is in no particular order. + Any or all of these issues may be addressed as well as any other + topic that the author feels is germane, but do not exceed the 10 page + limit, please. + + 5.1 Scaling - What is a reasonable estimate for the scale of the + future data networking environment? The current common wisdom is + that IPng should be able to deal with 10 to the 12th nodes. + + 5.2 Timescale - What are reasonable time estimates for the IPng + selection, development and deployment process or what should the + timeframe requirements be? This topic is being evaluated by the + ALE working group and a copy of all white papers that express + opinions about these topics will be forwarded to that group. + + 5.3 Transition and deployment - Transition from the current version + to IPng will be a complex and difficult process. What are the + issues that should be considered The TACIT working group will be + discussing these issues and a copy of all white papers that + express opinions about these topics will be forwarded to that + group. + + 5.4 Security - What level and type of security will be required in + the future network environment? What features should be in an + IPng to facilitate security? + + + +Bradner & Mankin [Page 3] + +RFC 1550 IPng White Paper Solicitation December 1993 + + + 5.5 Configuration, administration and operation - As networks get + larger and more complex, the day to day operational aspects become + ever more important. What should an IPng include or avoid in + order to minimize the effect on the network operators? + + 5.6 Mobile hosts - How important is the proliferation of mobile + hosts to the IPng selection process? To what extent should + features be included in an IPng to assist in dealing with mobile + hosts? + + 5.7 Flows and resource reservation - As the data networks begin to + get used for an increasing number of time-critical processes, what + are the requirements or concerns that affect how IPng should + facilitate the use of resource reservations or flows? + + 5.8 Policy based routing - How important is policy based routing? + If it is important, what types of policies will be used? What + requirements do routing policies and potential future global + architectures of the Internet bring to IPng? How do policy + requirements interact with scaling? + + 5.9 Topological flexibility - What topology is anticipated for the + Internet? Will the current general topology model continue? Is + it acceptable (or even necessary) to place significant topological + restrictions on interconnectivity of networks? + + 5.10 Applicability - What environment / marketplace do you see for + the application of IPng? How much wider is it than the existing + IP market? + + 5.11 Datagram service - Existing IP service is "best effort" and + based on hop-by-hop routed datagrams. What requirements for this + paradigm influence the IPng selection? + + 5.12 Accounting - How important a consideration should the ability to + do accounting be in the selection of an IPng? What, if any, + features should be included in an IPng to support accounting + functions? + + 5.13 Support of communication media - IPv4 can be supported over most + known types of communications media. How important is this same + flexibility to an IPng? + + + + + + + + + +Bradner & Mankin [Page 4] + +RFC 1550 IPng White Paper Solicitation December 1993 + + + 5.14 Robustness and fault tolerance - To the extent that the Internet + built from IPv4 has been highly fault tolerant, what are ways that + IPng may avoid inadvertent decrease in the robustness (since some + things may work despite flaws that we do not understand well). + Comment on any other ways in which this requirement may affect the + IPng. + + 5.15 Technology pull - Are there technologies that will pull the + Internet in a way that should influence IPng? Can specific + strategies be developed to encompass these? + + 5.16 Action items - suggested charges to the directorate, working + groups or others to support the concerns or gather more + information needed for a decision. + +6. Security Considerations + + This RFC raises no security issues, but does invite comment on the + security requirements of IPng. + +7. Authors' Addresses + + Scott Bradner + Harvard University + 10 Ware St. + Cambridge, MA 02138 + + Phone: (617) 495-3864 + + EMail: sob@harvard.edu + + + Allison Mankin + Naval Research Laboratory + c/o Code 5591 + Washington D.C. 20375-5000 + + Phone: 202-404-7030 + + EMail: mankin@cmf.nrl.navy.mil + + + + + + + + + + + +Bradner & Mankin [Page 5] + +RFC 1550 IPng White Paper Solicitation December 1993 + + +Appendix A - Formatting Rules (from RFC 1543) + + Note: there are a set of NROFF formatting macros for the following + format. Please contact ipng-wp@harvard.edu if you would like to get + a copy. + + 3a. ASCII Format Rules + + The character codes are ASCII. + + Each page must be limited to 58 lines followed by a form feed on a + line by itself. + + Each line must be limited to 72 characters followed by carriage + return and line feed. + + No overstriking (or underlining) is allowed. + + These "height" and "width" constraints include any headers, + footers, page numbers, or left side indenting. + + Do not fill the text with extra spaces to provide a straight right + margin. + + Do not do hyphenation of words at the right margin. + + Do not use footnotes. If such notes are necessary, put them at + the end of a section, or at the end of the document. + + Use single spaced text within a paragraph, and one blank line + between paragraphs. + + Note that the number of pages in a document and the page numbers + on which various sections fall will likely change with + reformatting. Thus cross references in the text by section number + usually are easier to keep consistent than cross references by + page number. + + + + + + + + + + + + + + +Bradner & Mankin [Page 6] +
\ No newline at end of file |