As per Relevance of the word decision, we have this rfc below:
Network Working Group D.
Request for Comments: 1670
Category: Informational August 1994
Input to IPng Engineering
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 IETF IPng area in response to
1550. Publication of this document does not imply acceptance by
IPng area of any ideas expressed within. Comments should
submitted to the big-internet@munnari.oz.au mailing list
This white paper expresses some personal opinions on IPng
considerations, based on experience with DECnet Phase V transition
It suggests breaking down the IPng decisions and transition
into smaller parts so they can be tackled early by the
experts
In order to allow key decisions to be taken early, I would like
see IPng decisions and timescales broken down into into
parts, for example
- address structure and allocation
- name service
- host software and programming interface
- routing protocol
Although interrelated, not all details need to be defined by the
date. Identify which decisions will be hard to change and which
be allowed to evolve. All changes should be worked on in parallel
but the above list indicates a feeling for urgency of a decision
Our experience has been that administrative changes (as may
required for addressing changes) need the greatest elapse time
implementation, whereas routing protocol changes need the least
Heagerty [Page 1]
RFC 1670 Input to IPng Engineering Considerations August 1994
I would like to see an early decision on address structure and
information for service managers to start planning their transition
Some hosts will never be upgraded and will need to be phased out
configured with reduced connectivity. A lead time of 10 years (
more) will help to take good long term technical decisions and
financial and organisational constraints
Transition and
Transition requires intimate knowledge of the environment (financial
political as well as technical). The task needs to be broken down
that service managers close to their clients can take decisions
make them happen
Let the service managers adapt the solutions for their environment
providing them with a transition toolbox and scenarios of their
based on real examples. Clearly state the merits and limitations
different transition strategies
Provide for transition autonomy. Let systems and sites transition
different times, as convenient for them
Identify what software needs to be changed and keep an up-to-
list
Identify what is essential to have in place so that service
can transition at their own pace
Allow for a feedback loop to improve software based on experience
Configuration, Administration,
We run IP on a wide range of equipment and operating systems.
need an easy way to (re-)configure all our IP capable systems.
systems need to be sent their IP parameters (e.g., their address
address of their default router, address of their local name servers
and we need to obtain data from the system (e.g., contact
for owner, location and name of system). We also need an easy way
update DNS
In our environment systems are regularly moved between buildings
we therefore find the tight coupling of IP address to physical
over restrictive. Automatic configuration could help overcome this
We would like to efficiently load balance users of various IP
services (e.g., telnet, ftp, locally written applications) across
number of systems
Heagerty [Page 2]
RFC 1670 Input to IPng Engineering Considerations August 1994
The ability to break down addresses and routing into several
of hierarchy is important to allow the delegation of
management into subdomains. As the network grows so does the
to increase the number of levels of hierarchy
Disclaimer and
This is a personal view and does not necessarily represent that of
employer. I have benefited from many transition discussions with
colleagues at CERN, other High Energy Physics DECnet managers
Digital Equipment Corporation engineers
Security
Security issues are not discussed in this memo
Author's
Denise
Communications Systems
Computing and Networks
European Laboratory for Particle
1211 Geneva 23,
Phone: +41 22 767-4975
Fax: +41 22 767-7155
EMail: denise@dxcoms.cern.
Heagerty [Page 3]
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
