doc: Add RFC documents

1 files changed, 798 insertions, 0 deletions

diff --git a/doc/rfc/rfc920.txt b/doc/rfc/rfc920.txt
new file mode 100644
index 0000000..661b830
--- /dev/null
+++ b/doc/rfc/rfc920.txt
@@ -0,0 +1,798 @@
+
+
+Network Working Group                                          J. Postel
+Request for Comments: 920                                    J. Reynolds
+                                                                     ISI
+                                                            October 1984
+
+                          Domain Requirements
+
+
+Status of this Memo
+
+   This memo is a policy statement on the requirements of establishing a
+   new domain in the ARPA-Internet and the DARPA research community.
+   This is an official policy statement of the IAB and the DARPA.
+   Distribution of this memo is unlimited.
+
+Introduction
+
+   This memo restates and refines the requirements on establishing a
+   Domain first described in RFC-881 [1].  It adds considerable detail
+   to that discussion, and introduces the limited set of top level
+   domains.
+
+The Purpose of Domains
+
+   Domains are administrative entities.  The purpose and expected use of
+   domains is to divide the name management required of a central
+   administration and assign it to sub-administrations.  There are no
+   geographical, topological, or technological constraints on a domain.
+   The hosts in a domain need not have common hardware or software, nor
+   even common protocols.  Most of the requirements and limitations on
+   domains are designed to ensure responsible administration.
+
+   The domain system is a tree-structured global name space that has a
+   few top level domains.  The top level domains are subdivided into
+   second level domains.  The second level domains may be subdivided
+   into third level domains, and so on.
+
+   The administration of a domain requires controlling the assignment of
+   names within that domain and providing access to the names and name
+   related information (such as addresses) to users both inside and
+   outside the domain.
+
+
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                               [Page 1]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+General Purpose Domains
+
+   While the initial domain name "ARPA" arises from the history of the
+   development of this system and environment, in the future most of the
+   top level names will be very general categories like "government",
+   "education", or "commercial".  The motivation is to provide an
+   organization name that is free of undesirable semantics.
+
+   After a short period of initial experimentation, all current
+   ARPA-Internet hosts will select some domain other than ARPA for their
+   future use.  The use of ARPA as a top level domain will eventually
+   cease.
+
+Initial Set of Top Level Domains
+
+   The initial top level domain names are:
+
+      Temporary
+
+         ARPA  =  The current ARPA-Internet hosts.
+
+      Categories
+
+         GOV  =  Government, any government related domains meeting the
+                 second level requirements.
+
+         EDU  =  Education, any education related domains meeting the
+                 second level requirements.
+
+         COM  =  Commercial, any commercial related domains meeting the
+                 second level requirements.
+
+         MIL  =  Military, any military related domains meeting the
+                 second level requirements.
+
+         ORG  =  Organization, any other domains meeting the second
+                 level requirements.
+
+      Countries
+
+         The English two letter code (alpha-2) identifying a country
+         according the the ISO Standard for "Codes for the
+         Representation of Names of Countries" [5].
+
+
+
+
+
+
+Postel & Reynolds                                               [Page 2]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+      Multiorganizations
+
+         A multiorganization may be a top level domain if it is large,
+         and is composed of other organizations; particularly if the
+         multiorganization can not be easily classified into one of the
+         categories and is international in scope.
+
+Possible Examples of Domains
+
+   The following examples are fictions of the authors' creation, any
+   similarity to the real world is coincidental.
+
+   The UC Domain
+
+      It might be that a large state wide university with, say, nine
+      campuses and several laboratories may want to form a domain.  Each
+      campus or major off-campus laboratory might then be a subdomain,
+      and within each subdomain, each department could be further
+      distinguished.  This university might be a second level domain in
+      the education category.
+
+      One might see domain style names for hosts in this domain like
+      these:
+
+         LOCUS.CS.LA.UC.EDU
+         CCN.OAC.LA.UC.EDU
+         ERNIE.CS.CAL.UC.EDU
+         A.S1.LLNL.UC.EDU
+         A.LAND.LANL.UC.EDU
+         NMM.LBL.CAL.UC.EDU
+
+   The MIT Domain
+
+      Another large university may have many hosts using a variety of
+      machine types, some even using several families of protocols.
+      However, the administrators at this university may see no need for
+      the outside world to be aware of these internal differences.  This
+      university might be a second level domain in the education
+      category.
+
+      One might see domain style names for hosts in this domain like
+      these:
+
+         APIARY-1.MIT.EDU
+         BABY-BLUE.MIT.EDU
+         CEZANNE.MIT.EDU
+         DASH.MIT.EDU
+
+
+Postel & Reynolds                                               [Page 3]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+         MULTICS.MIT.EDU
+         TAC.MIT.EDU
+         XX.MIT.EDU
+
+   The CSNET Domain
+
+      There may be a consortium of universities and industry research
+      laboratories called, say, "CSNET".  This CSNET is not a network
+      per se, but rather a computer mail exchange using a variety of
+      protocols and network systems.  Therefore, CSNET is not a network
+      in the sense of the ARPANET, or an Ethernet, or even the
+      ARPA-Internet, but rather a community.  Yet it does, in fact, have
+      the key property needed to form a domain; it has a responsible
+      administration.  This consortium might be large enough and might
+      have membership that cuts across the categories in such a way that
+      it qualifies under the "multiorganization rule" to be a top level
+      domain.
+
+      One might see domain style names for hosts in this domain like
+      these:
+
+         CIC.CSNET
+         EMORY.CSNET
+         GATECH.CSNET
+         HP-LABS.CSNET
+         SJ.IBM.CSNET
+         UDEL.CSNET
+         UWISC.CSNET
+
+General Requirements on a Domain
+
+   There are several requirements that must be met to establish a
+   domain.  In general, it must be responsibly managed.  There must be a
+   responsible person to serve as an authoritative coordinator for
+   domain related questions.  There must be a robust domain name lookup
+   service, it must be of at least a minimum size, and the domain must
+   be registered with the central domain administrator (the Network
+   Information Center (NIC) Domain Registrar).
+
+   Responsible Person:
+
+      An individual must be identified who has authority for the
+      administration of the names within the domain, and who seriously
+      takes on the responsibility for the behavior of the hosts in the
+      domain, plus their interactions with hosts outside the domain.
+      This person must have some technical expertise and the authority
+      within the domain to see that problems are fixed.
+
+
+Postel & Reynolds                                               [Page 4]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+      If a host in a given domain somehow misbehaves in its interactions
+      with hosts outside the domain (e.g., consistently violates
+      protocols), the responsible person for the domain must be
+      competent and available to receive reports of problems, take
+      action on the reported problems, and follow through to eliminate
+      the problems.
+
+   Domain Servers:
+
+      A robust and reliable domain server must be provided.  One way of
+      meeting this requirement is to provide at least two independent
+      domain servers for the domain.  The database can, of course, be
+      the same.  The database can be prepared and copied to each domain
+      server.  But, the servers should be in separate machines on
+      independent power supplies, et cetera; basically as physically
+      independent as can be.  They should have no common point of
+      failure.
+
+      Some domains may find that providing a robust domain service can
+      most easily be done by cooperating with another domain where each
+      domain provides an additional server for the other.
+
+      In other situations, it may be desirable for a domain to arrange
+      for domain service to be provided by a third party, perhaps on
+      hosts located outside the domain.
+
+      One of the difficult problems in operating a domain server is the
+      acquisition and maintenance of the data.  In this case, the data
+      are the host names and addresses.  In some environments this
+      information changes fairly rapidly and keeping up-to-date data may
+      be difficult.  This is one motivation for sub-domains.  One may
+      wish to create sub-domains until the rate of change of the data in
+      a sub-domain domain server database is easily managed.
+
+      In the technical language of the domain server implementation the
+      data is divided into zones.  Domains and zones are not necessarily
+      one-to-one.  It may be reasonable for two or more domains to
+      combine their data in a single zone.
+
+      The responsible person or an identified technical assistant must
+      understand in detail the procedures for operating a domain server,
+      including the management of master files and zones.
+
+      The operation of a domain server should not be taken on lightly.
+      There are some difficult problems in providing an adequate
+      service, primarily the problems in keeping the database up to
+      date, and keeping the service operating.
+
+
+Postel & Reynolds                                               [Page 5]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+      The concepts and implementation details of the domain server are
+      given in RFC-882 [2] and RFC-883 [3].
+
+   Minimum Size:
+
+      The domain must be of at least a minimum size.  There is no
+      requirement to form a domain because some set of hosts is above
+      the minimum size.
+
+      Top level domains must be specially authorized.  In general, they
+      will only be authorized for domains expected to have over 500
+      hosts.
+
+      The general guideline for a second level domain is that it have
+      over 50 hosts.  This is a very soft "requirement".  It makes sense
+      that any major organization, such as a university or corporation,
+      be allowed as a second level domain -- even if it has just a few
+      hosts.
+
+   Registration:
+
+      Top level domains must be specially authorized and registered with
+      the NIC domain registrar.
+
+      The administrator of a level N domain must register with the
+      registrar (or responsible person) of the level N-1 domain.  This
+      upper level authority must be satisfied that the requirements are
+      met before authorization for the domain is granted.
+
+      The registration procedure involves answering specific questions
+      about the prospective domain.  A prototype of what the NIC Domain
+      Registrar may ask for the registration of a second level domain is
+      shown below.  These questions may change from time to time.  It is
+      the responsibility of domain administrators to keep this
+      information current.
+
+      The administrator of a domain is required to make sure that host
+      and sub-domain names within that jurisdiction conform to the
+      standard name conventions and are unique within that domain.
+
+      If sub-domains are set up, the administrator may wish to pass
+      along some of his authority and responsibility to a sub-domain
+      administrator.  Even if sub-domains are established, the
+      responsible person for the top-level domain is ultimately
+      responsible for the whole tree of sub-domains and hosts.
+
+      This does not mean that a domain administrator has to know the
+
+
+Postel & Reynolds                                               [Page 6]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+      details of all the sub-domains and hosts to the Nth degree, but
+      simply that if a problem occurs he can get it fixed by calling on
+      the administrator of the sub-domain containing the problem.
+
+Top Level Domain Requirements
+
+   There are very few top level domains, each of these may have many
+   second level domains.
+
+   An initial set of top level names has been identified.  Each of these
+   has an administrator and an agent.
+
+   The top level domains:
+
+      ARPA =  The ARPA-Internet   *** TEMPORARY ***
+
+         Administrator:  DARPA
+         Agent:          The Network Information Center
+         Mailbox:        HOSTMASTER@SRI-NIC.ARPA
+
+      GOV  =  Government
+
+         Administrator:  DARPA
+         Agent:          The Network Information Center
+         Mailbox:        HOSTMASTER@SRI-NIC.ARPA
+
+      EDU  =  Education
+
+         Administrator:  DARPA
+         Agent:          The Network Information Center
+         Mailbox:        HOSTMASTER@SRI-NIC.ARPA
+
+      COM  =  Commercial
+
+         Administrator:  DARPA
+         Agent:          The Network Information Center
+         Mailbox:        HOSTMASTER@SRI-NIC.ARPA
+
+      MIL  =  Military
+
+         Administrator:  DDN-PMO
+         Agent:          The Network Information Center
+         Mailbox:        HOSTMASTER@SRI-NIC.ARPA
+
+
+
+
+
+
+Postel & Reynolds                                               [Page 7]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+      ORG  =  Organization
+
+         Administrator:  DARPA
+         Agent:          The Network Information Center
+         Mailbox:        HOSTMASTER@SRI-NIC.ARPA
+
+      Countries
+
+         The English two letter code (alpha-2) identifying a country
+         according the the ISO Standard for "Codes for the
+         Representation of Names of Countries" [5].
+
+         As yet no country domains have been established.  As they are
+         established information about the administrators and agents
+         will be made public, and will be listed in subsequent editions
+         of this memo.
+
+      Multiorganizations
+
+         A multiorganization may be a top level domain if it is large,
+         and is composed of other organizations; particularly if the
+         multiorganization can not be easily classified into one of the
+         categories and is international in scope.
+
+         As yet no multiorganization domains have been established.  As
+         they are established information about the administrators and
+         agents will be made public, and will be listed in subsequent
+         editions of this memo.
+
+      Note:  The NIC is listed as the agent and registrar for all the
+      currently allowed top level domains.  If there are other entities
+      that would be more appropriate agents and registrars for some or
+      all of these domains then it would be desirable to reassign the
+      responsibility.
+
+Second Level Domain Requirements
+
+   Each top level domain may have many second level domains.  Every
+   second level domain must meet the general requirements on a domain
+   specified above, and be registered with a top level domain
+   administrator.
+
+
+
+
+
+
+
+
+Postel & Reynolds                                               [Page 8]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+Third through Nth Level Domain Requirements
+
+   Each second level domain may have many third level domains, etc.
+   Every third level domain (through Nth level domain) must meet the
+   requirements set by the administrator of the immediately higher level
+   domain.  Note that these may be more or less strict than the general
+   requirements.  One would expect the minimum size requirements to
+   decrease at each level.
+
+The ARPA Domain
+
+   At the time the implementation of the domain concept was begun it was
+   thought that the set of hosts under the administrative authority of
+   DARPA would make up a domain.  Thus the initial domain selected was
+   called ARPA.  Now it is seen that there is no strong motivation for
+   there to be a top level ARPA domain.  The plan is for the current
+   ARPA domain to go out of business as soon as possible.  Hosts that
+   are currently members of the ARPA domain should make arrangements to
+   join another domain.  It is likely that for experimental purposes
+   there will be a second level domain called ARPA in the ORG domain
+   (i.e., there will probably be an ARPA.ORG domain).
+
+The DDN Hosts
+
+   DDN hosts that do not desire to participate in this domain naming
+   system will continue to use the HOSTS.TXT data file maintained by the
+   NIC for name to address translations.  This file will be kept up to
+   date for the DDN hosts.  However, all DDN hosts will change their
+   names from "host.ARPA" to (for example) "host.DDN.MIL" some time in
+   the future.  The schedule for changes required in DDN hosts will be
+   established by the DDN-PMO.
+
+Impact on Hosts
+
+   What is a host administrator to do about all this?
+
+      For existing hosts already operating in the ARPA-Internet, the
+      best advice is to sit tight for now.  Take a few months to
+      consider the options, then select a domain to join.  Plan
+      carefully for the impact that changing your host name will have on
+      both your local users and on their remote correspondents.
+
+      For a new host, careful thought should be given (as discussed
+      below).  Some guidance can be obtained by comparing notes on what
+      other hosts with similar administrative properties have done.
+
+   The owner of a host may decide which domain to join, and the
+
+
+Postel & Reynolds                                               [Page 9]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+   administrator of a domain may decide which hosts to accept into his
+   domain.  Thus the owner of a host and a domain administrator must
+   come to an understanding about the host being in the domain.  This is
+   the foundation of responsible administration.
+
+      For example, a host "XYZ" at MIT might possible be considered as a
+      candidate for becoming any of XYZ.ARPA.ORG, XYZ.CSNET, or
+      XYZ.MIT.EDU.
+
+         The owner of host XYZ may choose which domain to join,
+         depending on which domain administrators are willing to have
+         him.
+
+   The domain is part of the host name.  Thus if USC-ISIA.ARPA changes
+   its domain affiliation to DDN.MIL to become USC-ISIA.DDN.MIL, it has
+   changed its name.  This means that any previous references to
+   USC-ISIA.ARPA are now out of date.  Such old references may include
+   private host name to address tables, and any recorded information
+   about mailboxes such as mailing lists, the headers of old messages,
+   printed directories, and peoples' memories.
+
+   The experience of the DARPA community suggests that changing the name
+   of a host is somewhat painful.  It is recommended that careful
+   thought be given to choosing a new name for a host - which includes
+   selecting its place in the domain hierarchy.
+
+The Roles of the Network Information Center
+
+   The NIC plays two types of roles in the administration of domains.
+   First,  the NIC is the registrar of all top level domains.  Second
+   the NIC is the administrator of several top level domains (and the
+   registrar for second level domains in these).
+
+   Top Level Domain Registrar
+
+      As the registrar for top level domains, the NIC is the contact
+      point for investigating the possibility of establishing a new top
+      level domain.
+
+   Top Level Domain Administrator
+
+      For the top level domains designated so far, the NIC is the
+      administrator of each of these domains.  This means the NIC is
+      responsible for the management of these domains and the
+      registration of the second level domains or hosts (if at the
+      second level) in these domains.
+
+
+
+Postel & Reynolds                                              [Page 10]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+      It may be reasonable for the administration of some of these
+      domains to be taken on by other authorities in the future.  It is
+      certainly not desired that the NIC be the administrator of all top
+      level domains forever.
+
+Prototypical Questions
+
+   To establish a domain, the following information must be provided to
+   the NIC Domain Registrar (HOSTMASTER@SRI-NIC.ARPA):
+
+      Note:  The key people must have computer mail mailboxes and
+      NIC-Idents.  If they do not at present, please remedy the
+      situation at once.  A NIC-Ident may be established by contacting
+      NIC@SRI-NIC.ARPA.
+
+   1)  The name of the top level domain to join.
+
+      For example:  EDU
+
+   2)  The name, title, mailing address, phone number, and organization
+   of the administrative head of the organization.  This is the contact
+   point for administrative and policy questions about the domain.  In
+   the case of a research project, this should be the Principal
+   Investigator.  The online mailbox and NIC-Ident of this person should
+   also be included.
+
+      For example:
+
+         Administrator
+
+            Organization  USC/Information Sciences Institute
+            Name          Keith Uncapher
+            Title         Executive Director
+            Mail Address  USC/ISI
+                          4676 Admiralty Way, Suite 1001
+                          Marina del Rey, CA. 90292-6695
+            Phone Number  213-822-1511
+            Net Mailbox   Uncapher@USC-ISIB.ARPA
+            NIC-Ident     KU
+
+   3)  The name, title, mailing address, phone number, and organization
+   of the domain technical contact.  The online mailbox and NIC-Ident of
+   the domain technical contact should also be included.  This is the
+   contact point for problems with the domain and for updating
+   information about the domain.  Also, the domain technical contact may
+   be responsible for hosts in this domain.
+
+
+
+Postel & Reynolds                                              [Page 11]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+      For example:
+
+         Technical Contact
+
+            Organization  USC/Information Sciences Institute
+            Name          Craig Milo Rogers
+            Title         Researcher
+            Mail Address  USC/ISI
+                          4676 Admiralty Way, Suite 1001
+                          Marina del Rey, CA. 90292-6695
+            Phone Number  213-822-1511
+            Net Mailbox   Rogers@USC-ISIB.ARPA
+            NIC-Ident     CMR
+
+   4)  The name, title, mailing address, phone number, and organization
+   of the zone technical contact.  The online mailbox and NIC-Ident of
+   the zone technical contact should also be included.  This is the
+   contact point for problems with the zone and for updating information
+   about the zone.  In many cases the zone technical contact and the
+   domain technical contact will be the same person.
+
+      For example:
+
+         Technical Contact
+
+            Organization  USC/Information Sciences Institute
+            Name          Craig Milo Rogers
+            Title         Researcher
+            Mail Address  USC/ISI
+                          4676 Admiralty Way, Suite 1001
+                          Marina del Rey, CA. 90292-6695
+            Phone Number  213-822-1511
+            Net Mailbox   Rogers@USC-ISIB.ARPA
+            NIC-Ident     CMR
+
+   5)  The name of the domain (up to 12 characters).  This is the name
+   that will be used in tables and lists associating the domain and the
+   domain server addresses.  [While technically domain names can be
+   quite long (programmers beware), shorter names are easier for people
+   to cope with.]
+
+      For example:  ALPHA-BETA
+
+   6)  A description of the servers that provides the domain service for
+   translating name to address for hosts in this domain, and the date
+   they will be operational.
+
+
+
+Postel & Reynolds                                              [Page 12]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+      A good way to answer this question is to say "Our server is
+      supplied by person or company X and does whatever their standard
+      issue server does".
+
+         For example:  Our server is a copy of the server operated by
+         the NIC, and will be installed and made operational on
+         1-November-84.
+
+   7)  A description of the server machines, including:
+
+      (a) hardware and software (using keywords from the Assigned
+      Numbers)
+
+      (b) addresses (what host on what net for each connected net)
+
+      For example:
+
+         (a) hardware and software
+
+            VAX-11/750  and  UNIX,    or
+            IBM-PC      and  MS-DOS,  or
+            DEC-1090    and  TOPS-20
+
+         (b) address
+
+            10.9.0.193 on ARPANET
+
+   8)  An estimate of the number of hosts that will be in the domain.
+
+      (a) initially,
+      (b) within one year,
+      (c) two years, and
+      (d) five years.
+
+      For example:
+
+         (a) initially  =   50
+         (b) one year   =  100
+         (c) two years  =  200
+         (d) five years =  500
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 13]
+
+
+
+RFC 920                                                     October 1984
+Domain Requirements
+
+
+Acknowledgment
+
+   We would like to thank the many people who contributed to this memo,
+   including the participants in the Namedroppers Group, the ICCB, the
+   PCCB, and especially the staff of the Network Information Center,
+   particularly J. Feinler and K. Harrenstien.
+
+References
+
+   [1]  Postel, J., "The Domain Names Plan and Schedule", RFC-881, USC
+        Information Sciences Institute, November 1983.
+
+   [2]  Mockapetris, P., "Domain Names - Concepts and Facilities",
+        RFC-882, USC Information Sciences Institute, November 1983.
+
+   [3]  Mockapetris, P., "Domain Names - Implementation and
+        Specification", RFC-883, USC Information Sciences Institute,
+        November 1983.
+
+   [4]  Postel, J., "Domain Name System Implementation Schedule",
+        RFC-897, USC Information Sciences Institute, February 1984.
+
+   [5]  ISO, "Codes for the Representation of Names of Countries",
+        ISO-3166, International Standards Organization, May 1981.
+
+   [6]  Postel, J., "Domain Name System Implementation Schedule -
+        Revised", RFC-921, USC Information Sciences Institute, October
+        1984.
+
+   [7]  Mockapetris, P., "The Domain Name System", Proceedings of the
+        IFIP 6.5 Working Conference on Computer Message Services,
+        Nottingham, England, May 1984.  Also as ISI/RS-84-133,
+        June 1984.
+
+   [8]  Mockapetris, P., J. Postel, and P. Kirton, "Name Server Design
+        for Distributed Systems", Proceedings of the Seventh
+        International Conference on Computer Communication, October 30
+        to November 3 1984, Sidney, Australia.  Also as ISI/RS-84-132,
+        June 1984.
+
+
+
+
+
+
+
+
+
+
+Postel & Reynolds                                              [Page 14]
+