As per Relevance of the word solicitation, we have this rfc below:
Network Working Group S.
Request for Comments: 1550 Harvard
Category: Informational A.
December 1993
IP: Next Generation (IPng) White Paper
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
Table of
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.
The IP: next generation (IPng) area in the IETF is soliciting
papers on topics related to the IPng requirements and
criteria
All interested parties are invited to submit white papers
any specific requirements that they feel an IPng must fulfill or
factors that they feel might sway the IPng selection. An example
the former might be a submission by a representative of a
company detailing the scaling and addressing features which would
required to service future inclusion of utility meters on
network. An example of the other case might be a paper outlining
potential effect on IPng of some sections of the future
connectivity being provided via wireless networks
At this time, we are not accepting white papers that
specific IPng proposals. This type of document will be
after the various proposal documents are deemed to be clear
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
result of these reviews, each white paper will receive the
attention of the IPng directorate and the community. The
papers will be used as resource materials by the IPng Area
groups, the directorate, the external review board and the
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,
ipng-wp@harvard.edu
2. Document Review
All submitted documents will first be reviewed for clarity by
of the IPng directorate and the external review board. This
may produce suggestions to the author on areas of the document
there may be some confusion as to the meaning. Authors are urged
consider any such suggestions as constructive and to reexamine
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
papers, but will assess technical feasibility. This review may
produce suggestions to the author
The document will be submitted as an Internet-Draft after
reviews have been completed and after whatever (if any)
that the author decides to make. After a suitable period of
these documents will be submitted as informational RFCs
withdrawn by the author. These documents will comprise a part of
historical record of the IPng process
3. Document Format
All white papers must follow the format requirements listed in
1543 and must not exceed 10 pages in length. (The relevant portion
RFC 1543 is included in this document as Appendix A.) They
not include the "status of memo" section; this will be added when
documents are posted as Internet Drafts. The reference version
the document must be in ASCII as is current practice with all RFCs
A PostScript version of the document may be submitted in addition
the ASCII version. (See RFC 1543 for the formatting procedures to
with PostScript documents.)
Bradner & Mankin [Page 2]
RFC 1550 IPng White Paper Solicitation December 1993
4. Outline for IPng Requirements and Concerns White
This section details the white paper outline to be followed
someone who would like to express an opinion about the
factors involved in the IPng definition and selection process.
these documents will be used as resource material by the various
working groups, the directorate, the external review board and
area directors, they should be well-focused and give
references to data supporting their points
Each white paper should begin with an executive summary of
important points of the document. This executive summary should
exceed 1/2 page in length
The white paper should then address the issue or issues that
author feels should be understood during the IPng process. The
document should not exceed 10 pages in length. An author may
more than one white paper if he or she feels that the level
detailed discussion on each topic warrants it
5. Engineering
In past discussions the following issues have been raised as
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
topic that the author feels is germane, but do not exceed the 10
limit, please
5.1 Scaling - What is a reasonable estimate for the scale of
future data networking environment? The current common wisdom
that IPng should be able to deal with 10 to the 12th nodes
5.2 Timescale - What are reasonable time estimates for the
selection, development and deployment process or what should
timeframe requirements be? This topic is being evaluated by
ALE working group and a copy of all white papers that
opinions about these topics will be forwarded to that group
5.3 Transition and deployment - Transition from the current
to IPng will be a complex and difficult process. What are
issues that should be considered The TACIT working group will
discussing these issues and a copy of all white papers
express opinions about these topics will be forwarded to
group
5.4 Security - What level and type of security will be required
the future network environment? What features should be in
IPng to facilitate security
Bradner & Mankin [Page 3]
RFC 1550 IPng White Paper Solicitation December 1993
5.5 Configuration, administration and operation - As networks
larger and more complex, the day to day operational aspects
ever more important. What should an IPng include or avoid
order to minimize the effect on the network operators
5.6 Mobile hosts - How important is the proliferation of
hosts to the IPng selection process? To what extent
features be included in an IPng to assist in dealing with
hosts
5.7 Flows and resource reservation - As the data networks begin
get used for an increasing number of time-critical processes,
are the requirements or concerns that affect how IPng
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?
requirements do routing policies and potential future
architectures of the Internet bring to IPng? How do
requirements interact with scaling
5.9 Topological flexibility - What topology is anticipated for
Internet? Will the current general topology model continue?
it acceptable (or even necessary) to place significant
restrictions on interconnectivity of networks
5.10 Applicability - What environment / marketplace do you see
the application of IPng? How much wider is it than the
IP market
5.11 Datagram service - Existing IP service is "best effort"
based on hop-by-hop routed datagrams. What requirements for
paradigm influence the IPng selection
5.12 Accounting - How important a consideration should the ability
do accounting be in the selection of an IPng? What, if any
features should be included in an IPng to support
functions
5.13 Support of communication media - IPv4 can be supported over
known types of communications media. How important is this
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
built from IPv4 has been highly fault tolerant, what are ways
IPng may avoid inadvertent decrease in the robustness (since
things may work despite flaws that we do not understand well).
Comment on any other ways in which this requirement may affect
IPng
5.15 Technology pull - Are there technologies that will pull
Internet in a way that should influence IPng? Can
strategies be developed to encompass these
5.16 Action items - suggested charges to the directorate,
groups or others to support the concerns or gather
information needed for a decision
6. Security
This RFC raises no security issues, but does invite comment on
security requirements of IPng
7. Authors'
Scott
Harvard
10 Ware St
Cambridge, MA 02138
Phone: (617) 495-3864
EMail: sob@harvard.
Allison
Naval Research
c/o Code 5591
Washington D.C. 20375-5000
Phone: 202-404-7030
EMail: mankin@cmf.nrl.navy.
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
format. Please contact ipng-wp@harvard.edu if you would like to
a copy
3a. ASCII Format
The character codes are ASCII
Each page must be limited to 58 lines followed by a form feed on
line by itself
Each line must be limited to 72 characters followed by
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
margin
Do not do hyphenation of words at the right margin
Do not use footnotes. If such notes are necessary, put them
the end of a section, or at the end of the document
Use single spaced text within a paragraph, and one blank
between paragraphs
Note that the number of pages in a document and the page
on which various sections fall will likely change
reformatting. Thus cross references in the text by section
usually are easier to keep consistent than cross references
page number
Bradner & Mankin [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
