Network Working Group RANL
Request for Comments: 50
Comments on the Meyer Proposal
We find the Meyer proposal (Note #46) to be the most acceptable
to dare, for exactly the reasons that he enumerates; viz., simple,
suffices for most planned uses of the Network, easy to implement,
can be extended. It does not encompass everything that has been
suggested recently, however, we do agree with the items that are
proposed and we feel that the missing features are probably not
worth doing battle over and thus delaying the specification.
We make the following comments on the seven issues rasied in
1) We agree with Steve that dynamic reconnection will later
be required for more sophisticated uses of the Network.
We also agree with the Project MAC people that it
unnecessary initially. A better job can be done of dynamic
reconnection given some Network experience and the specific
needs of its use.
2) INT is easy to implement and serves a useful purpose.
3) We favor including a sub-field for instance tag identifier.
We see the need for both cases; a) where multiple processes
should appear indistinguishable, and b) where a given
user owning multiple processes must distinguish among
them. Those program parts that should not distinguish
among processes should simply ignore the instance tag.
Tom's suggestion to use part of the user number sub-field
merely reduces the combined length of sub-fields from 32
bits to 24 bits; the problem remains.
4) We disagree with both Steve and MAC in that no special
structure should be imposed on the data transmitted. We
prefer the "message data type" mentioned by E. I. Ancona,
Note #42, page 1. An example of its use was cited in
Note #39, page 2, transmit vs broadcast.