As per Relevance of the word direction, we have this rfc below:
Network Working Group P.
Request for Comments: 1719
Category: Informational December 1994
A Direction for
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
This document was submitted to the IPng Area in response to RFC 1550.
Publication of this document does not imply acceptance by the
Area of any ideas expressed within. Comments should be submitted
the big-internet@munnari.oz.au mailing list. This RFC
criteria related to mobility for consideration in design
selection of the Next Generation of IP
Table of
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 1
2. A Direction for IPng . . . . . . . . . . . . . . . . . . . . 2
3. Issues Toward IPng Resolution. . . . . . . . . . . . . . . . 3
4. Security Considerations. . . . . . . . . . . . . . . . . . . 5
5. Author's Address . . . . . . . . . . . . . . . . . . . . . . 5
1.
At the Amsterdam IETF meeting, we held a BOF, entitled the "
BOF", on the process and progress of the IPng activities
("IPng" stands for "IP, the next generation". The IPDecide BOF
chaired by Brian Carpenter. Minutes are available in the
directories, with the file name
93jul.txt>.)
The IPDecide BOF explored several facets of the IPng process,
as
"What is the basis for choosing the next generation IP (i.e.,
are the technical requirements and decision criteria)."
Gross [Page 1]
RFC 1719 A Direction for IPng December 1994
"With the advent of CIDR and new, more stringent
assignment policies, are we comfortable that we truly
the level of urgency?"
"Should the IETF or the marketplace make the final IPng decision".
The BOF was held in a productive atmosphere, but did not achieve
could be called a clear consensus among the assembled attendees.
fact, despite its generally productive spirit, it did more
highlight the lack of a firm direction than to create it
The IPDecide BOF was followed the next evening by the open
plenary. During this session, the IESG and the assembled
discussed the IPng issues and seemed to arrive at a consensus
on the following set of bullets presented by the IETF chair
"The IETF needs to move toward closure on IPng." That is,
IETF should take active steps toward a technical decision,
than waiting for the "marketplace" to decide
"The IESG has the responsibility for developing an
recommendation for the Internet community." That is, the
should provide leadership and take specific actions to help
the IETF toward a technical decision
"The procedures of the recommendation-making process should
open and published well in advance by the IESG."
"As a part of the process, the IPng WGs may be given
milestones and other guidance to aid the IESG."
"There should be ample opportunity for community comment prior
final IESG recommendation (e.g., there will be an extended
Call)."
2. A Direction For
Building on this consensus, I'd like to announce a set of
directions in the IESG that I hope will move us toward
resolution of many of the key IPng issues
The IESG will establish a temporary, ad hoc, "area" to
specifically with IPng issues. The charter for this new IESG
is to develop a recommendation on which, if any, of the
proposals should be adopted as the "next IP". This
will be submitted to the IESG and to the Internet community
review. Following an adequate period of review to surface
community concerns, the IESG will issue a final IPng recommendation
Gross [Page 2]
RFC 1719 A Direction for IPng December 1994
All of the current IPng-related working groups will be
immediately into this new area
This new area will be headed by two co-Area Directors from within
IESG. I have asked Allison Mankin (NRL), current Transport
AD, and Scott Bradner (Harvard), current Operational Requirements AD
to serve as co-AD's for this temporary area. I am very pleased
report that they have agreed to take this important assignment
(Because this is expected to be a temporary assignment, Scott
Allison will also continue to serve in their current IESG
during this period.)
All IETF Areas are now expected to have Area Directorates. For
IPng Area, a Directorate will be especially important to
additional viewpoints into the process. Therefore, I am asking that
as their first action, Scott and Allison form a specific
Directorate to act as a direction-setting and preliminary
body. The IPng process will continue to be completely open,
therefore reports and meeting notes from any IPng
meetings will be published in timely fashion
3. Issues Toward IPng
Two important issues need resolution immediately before we can
progress toward an IPng recommendation
- What is the scope of the effort
That is, should IPng be limited to solving the well known
and address exhaustion issues; or should IPng also
advanced features such as resource reservation for real-
traffic
The argument in favor of considering advanced features is
migration to a new IP is (hopefully, only!) a once-in-a-
occurrence, and therefore all advanced features should at least
considered
Arguments opposed to considering advanced features include
fact that we may not have time for this level of effort before
scaling and address exhaustion problems confront us, and that
may not have the necessary understanding and experience to
all the correct choices at this time
Gross [Page 3]
RFC 1719 A Direction for IPng December 1994
- What is the available timeframe
That is, before we can even begin to make an informed
about the scope, we need a better understanding of the urgency
time constraints facing us
Factors that affect the available time include the current rate
address assignments (which can give us an estimate of when we
currently projected to run out of addresses), the current
governing address assignment (which can give us an
of how policies affect the assignment and utilization rates),
impact of CIDR aggregation, the development time for IPng, and
time needed to field and migrate to the new IPng
Therefore, I am asking the new AD's and the Directorate to
immediately the following specific activities to help guide
ultimate IPng recommendation
1. Develop an understanding of the available timeframe,
at least the following issues
- Review Internet growth metrics, such as the current
assignment and utilization rates. Develop an understanding
how the new address assignment policies impact the
and utilization rates
- Review the expected impact of CIDR address aggregation
Develop an understanding of the expected savings due to
aggregation
- Develop new technical guidelines for classless
addressing. Specific examples include guidelines for how
utilize variable length subnet masks, and how to
currently unused Class A and B addresses in a classless
in hosts and routers
- Develop a strong understanding of the time required for
development, fielding, and migration for a new IP
- Based on all the above issues
(a) develop an estimate for how long we have to
and deploy an IPng. This could be a set of
based on best/worst case estimates for how each of
above factors will affect the available timeframe
Gross [Page 4]
RFC 1719 A Direction for IPng December 1994
(b) Consider whether more stringent assignment
might provide additional time. If so, recommend
policies
(c) make a recommendation on whether it is worthwhile
mount a serious effort to reclaim addresses and/or
renumber significant portions of the Internet
2. Based on an informed judgment of the time constraints above
make a recommendation regarding the scope for IPng, i.e.,
IPng consider scaling issues only or advanced topics also
3. Based on the scope and time constraints, develop a clear
concise set of technical requirements and decision criteria
IPng. These should include, but not be limited to, the
outlined in the IESG statement (RFC1380).
4. Based on the decision criteria, scope, and time constraints
make a recommendation on which of the current IPng candidates
accept, if any
Finally, I am asking Scott and Allison to make a detailed
at the opening plenary of the next IETF meeting in November on
status of setting up their new area, and on their progress
organizing the above work items. In particular, the status of
work items on timeframe should be fully reported. This will
followed by regular progress reports to the Internet community,
IETF meetings and in other appropriate forums
Please join me in giving Scott and Allison our full cooperation,
in thanking them for accepting this daunting assignment. I
confident that we will now make significant progress on the
IPng issues facing the Internet community
4. Security
Security issues are not discussed in this memo
5. Author's
Phill
Director of Internet
MCI Data Services
2100 Reston Parkway FL 6
Reston, VA 22091
Phone: 703-715-7431
EMail: phill_gross@mcimail.
Gross [Page 5]
RFC 1719 A Direction for IPng December 1994
Gross [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
