rfc164.txt

RFC 的详细文档！


RFC 164         Minutes of Network Working Group Meeting        May 1971


IMLAC Users Group

   A quick survey was taken to determine which sites had or planned to
   get an IMLAC.  The plan is to form an IMLAC users group.  The
   following sites have or plan to get one:  UCLA-S7, AMES-67, BBN,
   SRI-ARC, Stanford, MIT-DM, MIT-MULTICS, Mitre, Case, Raytheon, U. of
   Illinois.

Official Document Formats

   The notion of a functional document was suggested, one of which would
   be the document of official protocols with divisions of levels of
   protocols.






































Heafner                                                        [Page 17]

RFC 164         Minutes of Network Working Group Meeting        May 1971


                   II.  MONDAY MORNING SESSION (5/17/71)

NETWORK INFORMATION CENTER

Plans for NIC

   Two activities are planned for this summer, off-line mail and on-line
   access.  The off-line service will continue after the on-line service
   has come into being.  Plans for getting on the Net via PDP-10
   (replaced XDS-940) are almost complete.  Response times for display
   use are marginal.

   The activities will be developed in stages.  Stage 0 (June 18) NIC
   will work with West Coast sites.  This will involve providing NLS
   facilities to allow people to create messages with initial delivery
   as hardcopy, etc., with automatic generation of catalog entry and NIC
   #.  This system has been used locally for about a month.  Stage 1
   (August 2) NIC will be open to the Net community as a whole.  Remote
   users will come in directly to the on-line system and will have on-
   line access to the catalog.  Users will be trained either at SRI or
   at their own sites before coming on.  Four to eight concurrent
   terminals will be supported.  Stage 2 will include file transfer
   protocol, on-line delivery of messages, remote editing of SRI-located
   text.  Prior to stage 0, a course will be offered (on June 16, 17)
   for UCLA, Rand, SDC, UCSB, Ames, and RADC for the use of Stage 0.
   The second group of users (after stage 0) will use NIC to do their
   own site documentation.

Concepts & Recommendations for Documentation

   The NIC # is a unique "name" for reference -- it has no other
   meaning. Other numbering schema such as RFC numbers will eventually
   go away.  However, the subgroups, such as RFCs, will remain.
   Appropriate set manipulators will be provided for assisting in
   storage and retrieval.

   The notion of functional documents was introduced (see RFC #115).
   This is to be a document whose purpose is reasonably stable over
   time.  It can have subdocuments that change more frequently.  A
   current list of functional documents includes the NIC Catalog,
   Directory of People, Resources Notebook, Protocols, and Site
   Facilities (one for each site).

   The mechanism of documentation is the responsibility of NIC; the
   document contents are the responsibility of the author.  There are
   two cases of document revision; replace part of the document and
   replace the entire document.  In general, NIC would like the document




Heafner                                                        [Page 18]

RFC 164         Minutes of Network Working Group Meeting        May 1971


   to be re-issued in its entirety with a new NIC # rather than issuing
   errata.  The functional documents are in looseleaf form, new pages
   can be issued with the same number and a revision date.

   Documents are reproduced and mailed to site liaisons 24-48 hours
   after receipt.  They are mailed to station agents on a weekly basis.
   When mailing is handled directly by a site, a copy of the document
   and a distribution list should also be sent to NIC.  In the past, NIC
   has supplied abstracts of documents for the catalog; NIC requests
   that the authors include an abstract.

TELNET

   The purpose of TELNET is to provide an immediate mechanism for
   communication between keyboard terminals and serving processes, with
   sufficient platform for later expansion and sophistication.

   Tom O'Sullivan described TELNET as delineated in RFC #137.  (Later in
   these NWG meetings, Tom issued RFC #158, a new TELNET protocol.)
   After the description, many issues and questions were raised, viz.,
   can TELNET expect "recovery" from NCP, 128 vs. 256 character set, DLE
   + 7-bit code vs. high-order bit on, should protocol extend service
   beyond what level consoles see, human factors, if information is
   available at second level should it be passed to TELNET, TWX-like
   service from NIC, mailbox protocol, etc.

   In large part, these issues were raised but not resolved.  It was
   agreed that an RFC would be forthcoming (RFC #158, published later at
   the meetings) followed by a functional document.






















Heafner                                                        [Page 19]

RFC 164         Minutes of Network Working Group Meeting        May 1971


                 III.  MONDAY AFTERNOON SESSION (5/17/71)

FILE TRANSFER PROTOCOL (RFC #114)

   The file transfer protocol (RFC #114) was described.  See also RFC
   #133 and RFC #141.

   A simplified version of RFC #114 is being implemented by MIT/DM and
   MIT/MULTICS in order to: 1) allow Dynamic Modeling access to MULTICS
   file storage facility and 2) conduct a pilot project to gain
   understanding of such protocols.

   It was noted that RFC #114 was not simple enough to implement for
   TIPs.

   A group was formed to meet Wednesday morning for more discussion and
   to exactly define the problems.  The group would include
   representatives from UCLA, UCSB, BBN, MIT, Rand, SRI, Harvard.

FILE PROTOCOL STATUS REPORT

   UCSB described the status of RFC #122, A Simple Minded File System,
   as an operational program; not a proposal.  The basic concepts of the
   file system were described; the design objective was to provide a
   simple service quickly.

   Currently one 2314 drive and pack is available.  At most four drives
   will be made available during the next year.  It is also not clear
   how long space will remain available.  The storage is currently free.

   Sites that will use the file system are Mitre, via BBN, UCLA, SRI,
   and Raytheon via one of the Boston hosts.

MISCELLANEOUS TOPICS

Sockets

   Socket name structure was briefly discussed.  Relevant RFCs that were
   mentioned were 1) RFC #129 whose purpose was to describe socket
   structures enumerated at the February NWG meetings, and 2) RFC #147,
   a recently proposed structure.

   It was pointed out that there was a definite need to reduce the
   socket length from 32 to 16 bits (a TIP storage problem) regardless
   of its structure.






Heafner                                                        [Page 20]

RFC 164         Minutes of Network Working Group Meeting        May 1971


   A committee (Bob Metcalfe, Chairman with Abhay Bhushan and Joel
   Winett) was appointed to produce a report in two weeks.  The
   committee is to address the following three issues:

      1) is a socket structure needed
      2) are more than 16 bits needed
      3) what procedures are recommended for managing socket numbers.

Initial Connection Protocol

   Race conditions and time out problems were elucidated.  See RFC #123,
   127, and 151.

   A committee (chaired by Jon Postel and including Steve Wolfe, Eric
   Harslem, and Arie Shoshani) was appointed to clean up the ICP
   specification.

Testing and Validation

   Sites wishing a remote partner to exchange NCP, TELNET, and logger
   protocols can contact Rand.  Rand was to collect status information
   before and during these exercises.  Information was to be forwarded
   to Alex McKenzie to maintain and update status reports.  (NOTE:  A
   later steering committee decision reflects on the way in which this
   information is gathered, however.  Rand is still available for
   testing and validation.)

























Heafner                                                        [Page 21]

RFC 164         Minutes of Network Working Group Meeting        May 1971


                   IV.  MONDAY EVENING SESSION (5/17/71)

   NOTE: Minutes of this session were kindly prepared by Bob Walker,
   RADC.

OPERATING SYSTEMS AND NETWORKS

   An attempt was made to study the ARPA Networks from an academic point
   of view.  An analogy was drawn on the basis that the ARPA Network
   with its hosts and protocols is in a sense an "operating system" and
   that a study of what makes a good operating system might help define
   what makes a good ARPA Network.

   Professor Art J. Bernstein of Stony Brook gave a presentation
   abstracting what he considered to be the features of a flexible
   operating system, the techniques for obtaining such; and when
   appropriate, a discussion of those aspects where a difference in
   techniques is required between dealing with an internal operating
   system and dealing with a network.

   The features of a flexible operating system were cited as:  (1) a
   flexible file structure, (2) a process hierarchy, and (3) an
   interprocess communication facility (IPC).  The terminology and
   techniques described to obtain these three features were essentially
   those developed for the MULTICS system.

   A file structure capability was defined in terms of hierarchy of
   directories, tree names, active file table, hold count, known file
   table, and reference number.

   A process hierarchy was discussed in terms of father-son relationship
   and a father-node spawning a son node, creating an entry in the known
   file table and assigning resources, all embodied in the SPAWN
   primitive.  Implementation of primitives as time independent was
   stressed as being crucial to Network activity whereas not necessarily
   so for an internal operating system.  This lead into the concept
   subcontracting process, where executive type functions are treated on
   the same basis as user processes and as such are swappable.  The
   "link process" was then described as the interface mechanism between
   two cooperating machines.

   Interprocess communication was discussed in terms of channels, status
   return and software interrupts.  Appropriate primitives were defined
   in detail as well as control type problems.







Heafner                                                        [Page 22]

RFC 164         Minutes of Network Working Group Meeting        May 1971


   The discussion then went to file handling and a specification of the
   required primitives and thence to directory handling, specification
   of related primitives, and the mechanics of directory handling,
   specifically the outstanding operation entry table in the executive.

   After a short recess, Bob Metcalfe gave a presentation from the ARPA
   Network point of view with reference to various points of Professor
   Bernstein's presentation.  He noted the all pervasive tree structure
   in Bernstein's presentation which appears to be most efficient to
   internal operating systems (i.e., file system, process hierarchy,
   etc.), but that the ARPA Network is not a tree structure but rather a
   directed graph and that we should be careful not to impose tree
   structure thinking on a directed graph type situation.

   A number of questions and problem areas were elicited from the group
   and listed on the blackboard:
      1) How much does the operating system need to know about the
         Network to get how much and vice versa?
      2) Degree of transparency to the user?
      3) "Optimal" resource allocation on the Network?
      4) Autonomy versus centralization of control.
      5) Resiliency.

   The group discussed the need for a committee on Theory, how it should
   function, how often should they meet, requirements for attendance,
   etc.  Dave Walden was mentioned as a possible organizer of a related
   effort.  Bob Metcalfe agreed to chair such a committee.
























Heafner                                                        [Page 23]

RFC 164         Minutes of Network Working Group Meeting        May 1971


                   V.  TUESDAY MORNING SESSION (5/18/71)

DRS WORKING GROUP MEETING WITH OPEN ATTENDANCE

   The purpose of the Data Reconfiguration Service meeting was to
   resolve several lingering syntax and semantics issues and also to
   receive comments and discuss the DRS with the entire Net community.

   A brief overview of the DRS (see RFC #138) was given.

   Remaining technical issues were resolved.  An implementation
   specification (replacing RFC #138) will be issued soon.

   Initial implementers and users were polled for schedules and initial
   experiments, results are shown below.

   MIT        No dates currently provided
   U. of Ill. One or two months will be required to reformat from remote
              formats to GOULD printer; also conversion of ARDS to
              COMPUTEC strings.
   UCSB       Implementation of service in two months; will provide
              system forms for remote TTY-like devices to access UCSB
              on-line system.
   MITRE      Will compare performance of DRS to current software of
              UCSB file experiment.
   Rand       implement service by September; initial use to specify
              UCSB RJE/RJ0 and UCLA NETRJS formats for local users.
   UCLA       will have a compiler of forms within one month unless
              serious difficulties arise.

DATA MANAGEMENT ON COMPUTER NETWORKS

   SDC presented RFC #144 (see also RFC #146).  Arie Shoshani presented
   considerations and approaches that can be taken to achieve data
   sharing.  The considerations were common language, sharing of
   existing data, evolutionary/revolutionary, future and use facility,
   further development, implementation, and speed.

   Approaches given were:
         1)  centralized
             a) new data only
             b) existing data
         2)  standardized data
         3) integrated - common languages + interfaces
             a) interface on different nodes
             b) interface on service node
             c) Data Reconfiguration Service
         4) Unified



Heafner                                                        [Page 24]