[8853] in Commercialization & Privatization of the Internet
IPng White Paper Solicitation
daemon@ATHENA.MIT.EDU (Scott Bradner)
Tue Dec 7 22:28:57 1993
Date: Tue, 7 Dec 93 22:26:32 -0500
From: sob@hsdndev.harvard.edu (Scott Bradner)
To: com-priv@psi.com
IETF IP: next generation area (IPng)
chairs
Allison Mankin (NRL)
Scott Bradner (Harvard University)
IPng White Paper Solicitation
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.
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 RFC1543 and
must not exceed 10 pages in length. (The relevant portion of RFC1543 is
included in this document as Appendix A.) They should not include the
'status of memo' or 'distribution' sections; these 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.
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.
4.1 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.
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.
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.
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.
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?
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?
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?
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?
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?
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?
Applicability - What environment / marketplace do you see for the
application of IPng? How much wider is it than the existing IP market?
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?
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?
Support of communication media - IPv4 can be supported over most known
types of communications media. How important is this same flexibility to
an IPng?
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
inadvertant 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.
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?
Action items - suggested charges to the directorate, working groups or
others to support the concerns or gather more information needed for a decision.
Appendix A - Formatting Rules (from RFC1543)
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.
