[92] in Zephyr_Comments
comments on August 9 draft
daemon@ATHENA.MIT.EDU (Jerome H. Saltzer)
Thu Sep 1 18:25:02 1988
Date: Thu, 1 Sep 88 18:24:04 EDT
To: zephyr-comments@ATHENA.MIT.EDU
From: Jerome H. Saltzer <Saltzer@ATHENA.MIT.EDU>
A file of comments follows. I didn't read section 7 in detail.
Jerry
----- ----- ----- ----- ----- ----- ----- ----- ----- ----- -----
Comments on August 9, 1988, draft of Zephyr, section E.4.1
1. Prerequisites. Ten pages in, one begins to draw the implicit
conclusion that Kerberos is a prerequisite for Zephyr, because it has
been mentioned so much. But it hasn't specifically been identified
as a prerequisite, so the reader isn't really sure. There should be
an up-front discussion of all prerequisites, and whether one could
mount a useful version of Zephyr if the prerequisite isn't available.
Some candidates:
- BSD 4.3
- UDP/IP
- Kerberos
- Hesiod
- Dedicated servers for Zephyr
- Network of the Ethernet class
- X windows
- workstations (can I use it with my time-sharing system?)
- SMS
- NFS
- etc.
2. Overview. "Zephyr" really has three distinct kinds of
components, but you have to read quite a bit to discover this fact,
and you have to deduce it yourself. The first page should point the
kinds of components out:
1. a notice transport mechanism.
2. some canned applications that use notice transport, e.g.,
zwrite, znol, etc.
3. a library that allows new applications to make use of the
transport mechanism.
3. Definitions: UID. Unfortunately, UNIX has captured this acronym (at
least in discourse that might apply to UNIX systems) to mean a
number, like 994. This document uses UID in a more general sense.
Since it also talks about ZID's, I think it may be possible to just
omit the concept of UID and replace it with English words in the one
or two places where it appears. (In addition, there is a packet
field called a "Multi UID" that brings in a still different specific
definition of UID. It might be better labeled "Unique Notice ID".)
4. Checksum; two issues. Is the byte order of the "checksum" field
well defined? The description as "four bytes" leads one to assume
that it is the raw output of the DES library. Is that output
guaranteed to be in the same byte order on every machine? Second
issue: despite the description implying four raw bytes, the example
suggests that the checksum is actually carried in the packet as an
ASCII hex-represented binary number. If the latter is actually what
is done, a bit more explanation is needed in the description.
5. Overall model. Section 2 (especially 2.4) lists messages that go
from a client to a server, from a client to a windowgram client, from
a server to another server, from a hostmanager to a server. But there
hasn't been any preceding description of the overall model that shows
those components or how they relate to one another. There ought to
be a picture in the overview and a few words explaining how the
overall responsibilities of Zephyr are split up and why.
6. The finite state machine in figure 1 is more puzzling than
helpful. What is input "e"? Although the text says otherwise, the
fsm diagram offers no way to leave the "Dying" state, except to
become "Dead". What are the square boxes, and the undirected lines
connecting them to the states?
7. 3.3.1 (timers) refers the reader to figure 1. But there isn't
anything in figure 1 about timers, or that supports 3.3.1.
8. I gather section 5 (client library) isn't finished?
9. What is the plan to update section 7? How about moving it to a
separate document entitled "Zephyr Implementation" and mentioned at
the bottom of page one? (Then it can be updated on its own
schedule.)
10. I haven't seen the other Zephyr documents mentioned at the
bottom of page one, but it seems surprising that there aren't any
design considerations mentioned here that cater to installation and
operations.
******* typos *******
p. 11 last sentence omits a cross-reference.
p. 13 sever -> server
p 45 intial -> initial
