doc: Add RFC documents

1 files changed, 171 insertions, 0 deletions

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