|
|
|
|
|
IETF RFC 131
Response to RFC 116: May NWG meeting
Last modified on Thursday, April 17th, 1997
Permanent link to RFC 131
Search GitHub Wiki for RFC 131
Show other RFCs mentioning RFC 131
Network Working Group E. Harslem - Rand
Request For Comments: 131 J. Heafner - Rand
April 1971
Response to RFC #116 (May NWG Meeting)
Phase One
Software Status of 360/65
1) Our software is currently being changed to reflect the new NCP
protocol delineated in RFC #107. These changes will be completed
before the end of May.
2) We are implementing a logger that, after an automatic ICP
dialog, can be driven from a local console. Any desirable messages
can be sent or received in EBCDIC, ASCII (8), or as binary streams.
The purpose of the logger is to allow sites to checkout remote log in
procedures. Since no production-oriented services will be offered on
the 360/65, the logger is for experimental purposes only. It will be
completed before the end of May.
3) We have not planned a TELNET. We will, however, implement both
server and user TELNETs once a specification is generally accepted.
Implementation time will be on the order of two weeks.
Transition from 360/65 to PDP-10
1) We plan to move from our 360/65 to a PDP-10. Rand will offer
Network services on the PDP-10. The hardware and software status of
the PDP-10 will be reported later.
2) The 360/65 Network connection will remain for some time due to
its production use by another ARPA-sponsored project at Rand.
Maintenance of the 360/65 Network software will be provided for the
lifetime of the connection but no new programs will be developed on
the 360/65 after September.
PAGE 1
Network Related Activities
1) The UCSB/Rand Network activities were recently reported in RFC
#113 and earlier in RFC #78. The Climate Dynamics Project (CDP) at
Rand will continue to use this facility (more heavily) in the future.
2) In conjunction with the above facility, the Rand Network team
has planned and implemented a front-end graphics program to allow the
reduced data from UCSB to be displayed and interacted with locally as
graphs, contours, plots, and lists. This will be used in about three
months after an intermediate program, being written by the CDP
personnel, is completed.
Phase Two
Experimental Data Reconfiguration Service (Form Machine)
1) A working session was held recently at Rand on the Data
reconfiguration Service (DRS), the results of which have been drafted
and are being edited by the participants. These data will be
published soon as an RFC. Eric Harslem will be prepared to make an
oral report at the NWG meeting on the DRS.
Protocol Manager
1) We plan to submit a positional paper on a proposed Protocol
Manager, which will allow flexibility in both experimental and
production use of connection protocols. This will be presented as a
Request for Comments on a software package that Rand intends to
implement for its use on the PDP-10. For example, it should obviate a
fixed logger on our forthcoming PDP-10.
PAGE 2
Phase Three
Comments on Goals and Organization of the NWG
1) We have been proponents of the collective NWG as a forum to
raise issues and as a general information transfer mechanism of what
sites are doing and thinking. More recently small working groups and
committees have been formed to generate particular specifications such
as TELNET, the new NCP protocol, etc. We favor continuance of these
methods as long as any site with a willingness, an interest, and
contribution is not excluded from any group or committee. We feel
that these groups will limit themselves to a small functional size a
priori because they are directed toward special interests.
The long lead time between the formation of such a group and
their final output (and subsequent implementation of the plan) has
been accepted by the NWG Technical Chairman and is rather
disconcerting. The NCP glitch cleaning committee is an example of
expedient work. UTAH, for example, has already implemented the new NCP
protocol. Other groups (including the DRS) have not been as
responsive. Perhaps the technical problems addressed by other groups
are more complex and the needs for their solutions are not as
immediate as the NCP glitches. We offer no nice solution except that
perhaps some guidelines should be established concerning timely
publication of reports.
2) Regarding long range goals of the NWG, we do not think that
the NWG is the right body to establish the long range goals. By long
range goals of the NWG, we are really concerned (in part) with long
range goals of the Network. We feel that the Principal Investigators
are in a position to have a better perspective of long range Network
goals than the NWG members. As a suggestion, one way of converting
their views into NWG tasks is to have the NWG Technical Chairman host
a one day opinion session of the Principal Investigators, then report
these views to the NWG for the generation of their implied tasks.
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Jim Thompson 4/97 ]
PAGE 3
Response to RFC 116: May NWG meeting
RFC TOTAL SIZE: 5375 bytes
PUBLICATION DATE: Thursday, April 17th, 1997
LEGAL RIGHTS: The IETF Trust (see BCP 78)
|