doc: Add RFC documents

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