rfc1291.txt

RFC 的详细文档！


RFC 1291             Potential Technical Services          December 1991


   to its connected news sites, and so on. There is no preset norm for
   finding a site willing to provide a news feed, and it usually ends up
   being a site with whom the site administrator happens to be
   acquainted. However, this could easily result in some sites not being
   able to get an economical news feed from within the mid-level network
   and actually having to derive the feed from a site located on another
   mid-level network.

   A mid-level network could alleviate such occurrences by being able to
   provide a newsfeed to any or all of its directly connected end sites.
   Though an expensive resource, some of the costs can be moderated by
   acting as a transit news feeder so that the news needn't be stored
   for a long time on disk. The software for providing the news feed is
   not specific and depends entirely on the newsfeed provider.

3.5 Mailing Lists

   Internet mailing lists are another popular source of information in
   parallel to Network News. However, like public software, there is no
   central repository of all the possible mailing lists available on the
   Internet, and it would require considerable effort to compile one (at
   the time of writing this document, a fairly comprehensive list is
   available on the Internet and mentioned in appendix A.

   At this time, there is no clear strategy for distributing or
   maintaining mailing lists. However, it can be very expensive for a
   site to distribute mail to all individual end users directly, and if
   a clear strategy for maintaining a list of mailing-lists can be
   devised, then mail exploders can be set up at the mid-level networks,
   each of which forwards the mail to exploders at the end sites. This
   mechanism would reduce the load on the originating systems, and
   provides a clean path for tracking down mailer problems. Also, in
   order to prevent bounced mail from propagating back to the originator
   of the message, the mailing lists should be set up in a way so that
   bounced mail goes to the the "owner" of the list and not to the
   originator of the mail message.

   A list of major mailing lists for the services discussed in this
   document are listed in appendix A.

4. Experimental Testbeds

   Due to the working relationships that they have with their end sites
   and peer networks, the mid-level networks are very good media for
   distribution of new ideas and technology. Examples of this function
   are the White Pages pilot project [RS90] established by NYSERnet, the
   NSAP routing schema for OSI transitioning [CGC91], etc.




Aggarwal                                                        [Page 6]

RFC 1291             Potential Technical Services          December 1991


   The mid-level networks could establish cooperative experimental
   testbeds for testing and deployment of new technologies similar to
   the ones mentioned above. Besides deployment and testing of new
   technology, this could also serve to provide a "help" service to the
   end-sites and to get them started with the new software.

   The exact interaction between the mid-level networks in this area is
   not very clear. It is complicated by competition for members between
   the mid-level networks and needs to be discussed further.

5. Network Information Services

   There are a variety of new and useful user services available on the
   Internet that are difficult to document and provide a comprehensive
   list of. Some attempt has been made at documenting such resources
   [NNS] and a mid-level network can be the initial point of contact for
   distribution of such information on a wide basis. The information can
   be disseminated in a more controlled and complete manner using this
   hierarchical approach if each mid-level network maintains up-to-date
   information about its directly connected sites. Network Information
   services (NIC) also make the network easier and more attractive to
   end users. Examples of these services are:

     o  provide information resources

          -  security advisory messages

          -  list of library catalogs [GL91]

          -  geographical information servers

          -  password generators

     o  resolve end user problems (user support)

   These services are NIC related and discussed in detail elsewhere
   [SSM91]. For accessibility information, an entry for "nic" could
   exist in the DNS for the domain (this could be a TXT entry listing
   email or phone number information for users or other NIC's).

6. Network Operations

   The Network Operation Center's (NOC's) at the mid-level networks need
   to cooperate with each other to resolve network problems.  In the
   event of a network problem between two mid-level networks or if an
   end-site has trouble getting to any host, the mid-level network NOCs
   can serve to be the initial point of contact. The procedures for
   interaction among NOCs and the formats for exchange of trouble-



Aggarwal                                                        [Page 7]

RFC 1291             Potential Technical Services          December 1991


   tickets between the NOCs are described elsewhere [JOH91, ML91].

   It is important for cooperating NOCs to have contact information for
   their directly connected campus/organizational sites and also about
   their peer mid-level networks. A distributed mechanism for
   maintaining contact information could be implemented by using a
   nameserver TXT entry for "noc" or by maintaining "finger" information
   for user "noc@domain" or "[e-mail]". A NOC "phonebook" listing
   the contact information for the various NOCs can be used as a static
   non-distributed mechanism (it is understood that the phonebook can
   contain outdated information, but the distributed mechanisms can
   provide correct and updated NOC information provided that the hosts
   are reachable at the desired time).  If it is undesirable to publish
   the phone number or email address of the NOC for any reason, an entry
   saying "unpublished" (or words to that effect) could exist in the
   nameserver or "finger" entry instead.

7. References

   [BOG]     Dunlap, K., and M. Karels, "Nameserver Operations Guide
             for Bind Release 4.8", CSRG, Department of Electrical
             Engineering and Computer Sciences, University of
             California, Berkeley, California.

   [CCI88]   CCITT Blue Book, "X.500 Series Recommendations", ITU,
             1989.

   [CGC91]   Collela, R., Gardner, E., and R. Callon, "Guidelines for
             OSI NSAP Allocation in the Internet'', RFC 1237,
             NIST, Mitre, DEC, July 1991.

   [SSM91]   Sitzler, D., Smith, P., and A. Marine, "Building a Network
             Information Services Infrastructure", RFC in
             preparation.

   [GL91]    George, A., and R. Larsen, "Internet Accessible Library
             Catalogs & Databases", Aug 1991.
             Available via anonymous FTP from ariel.unm.edu.

   [JOH91]   Johnson, D., "NOC TT Requirements", RFC in
             preparation.

   [MAN]     Mandelbaum, R., and P. Mandelbaum, "The Strategic Future
             of the Mid-Level Networks", University of Rochester,
             NY, 1991.

   [MOC87a]  Mockapetris, P., "Domain Names - Implementation and
             Specification", RFC 1035, USC Information Sciences



Aggarwal                                                        [Page 8]

RFC 1291             Potential Technical Services          December 1991


             Institute, November 1987.

   [MOC87b]  Mockapetris, P., "Domain Names - Concepts and
             Facilities", RFC 1034, USC Information Sciences
             Institute, November 1987.

   [MIL89]   Mills, D., "Network Time Protocol", RFC 1129, UDel,
             October 1989.

   [ML91]    Mathis, M., and D. Long, "User Connectivity Problems
             Working Group", RFC in preparation.

   [NEU]     Neuman, B., "The Virtual System Model: A Scalable
             Approach to Organizing Large Systems", Department of
             Computer Science, University of Washington, FR-35,
             Seattle, WA, May 1990.

   [NNS]     NSF Network Service Center, "Internet Resource Guide",
             Cambridge, MA.
             Available via anonymous FTP from nnsc.nsf.net.

   [RS90]    Rose, M., and M. Schoffstall, "The NYSERnet White Pages
             Pilot Project", NYSERnet, Inc., Mar 1990.

   [SHHH90]  Schwartz, M., Hardy, D., Heinzman, W., and G.
             Hirschowitz, "Supporting Resource Discovery Among
             Public Internet Archives", Department of Computer
             Science, University of Colorado, Boulder, CO.,
             September 1990.

8. Security Considerations

   Security issues are not discussed in this memo.

9. Author's Address

   Vikas Aggarwal
   JvNCnet
   6 von Neumann Hall
   Princeton University
   Princeton, NJ 08544

   Phone: [phone]
   Email: [e-mail]







Aggarwal                                                        [Page 9]

RFC 1291             Potential Technical Services          December 1991


Appendix A - Mailing Lists

   The following is a list of popular mailing lists for the services
   listed in this document. To subscribe to a particular mailing list,
   send a request to "mailing-list-request" (do not send a request to
   the entire mailing list).

  o  [e-mail]: The general mailing list for the Internet
     Engineering Task Force. This group is concerned with the evolution
     and development of Internet related protocols and standards. Old
     mail is archived at "venera.isi.edu" in directory ftp/irg/ietf.

  o  [e-mail]: For discussions on the Network Time
     Protocol (NTP).

  o  [e-mail]: Mailing list for discussions on DNS
     topics. Old mail is archived at "nic.ddn.mil".

   At the time of writing this document, a list of mailing lists on the
   Internet is available via anonymous FTP from host "ftp.nisc.sri.com"
   in the file "netinfo/interest-groups".

Appendix B - DNS Architecture Strategy

   This section discusses practical strategies for implementing a
   nameserver architecture within a mid-level network, so that it can
   resolve nameserver queries for all domains directly attached to it.

   In order to resolve queries for all directly connected networks, a
   host that is authoritative for all directly attached domains will
   need to exist within the mid-level network. Nameservers at the end
   sites would then treat this "group-of-domains" nameserver as a
   forwarding server to resolve all non-local queries.

   This can be done by adding a line to the named.boot file on the end
   site nameservers such as:

              forwarders 128.121.50.7 128.32.0.4

   This method has the added advantage that the forwarding server builds
   up a very rich cache of data [BOG] and acts like a metacache that all
   hosts can benefit from. Note that the forwarding server is queried
   only if the end-site server cannot service a query locally -- hence
   the "meta-domain" server is not overloaded with queries for all
   nameserver lookups.






Aggarwal                                                       [Page 10]