Alternative #2.5 This plan for meeting the problem stmt is that we proceed in 2 steps. 1. Create a top level design document which describes the framework for specific SCSI subsystem mods. It should give broad rules of thumb and include at least the port-class interface and some statements about data structures as well as the more generic rules of thumb about design principles. It should not be constrained to describing the top level design of the Zeta implementation only, but should describe a design which is implementable incrementally from Zeta. 2. Create a series of modules which will replace pieces of the Zeta SCSI implementation incrementally. As part of this creation, LOP statements of need and design would be needed and it is left till those investigation reports to decide whether functions (e.g. flow control) or code modules (e.g. MKdriver) get replaced. The design documents for these modules will become later chapters in the ultimate SCSI design handbook (or whatever it gets called) Advantages: 1. A framework document exists early in the cycle. (Indeed, we can and should crib it from the architecture document & studies that are now wholly or partly done with a few additions to fill in port-class detail and maybe some more words about data structures.) 2. The principle of getting to an incremental solution is preserved. 3. The possibility of including new functions or improving lower level details is wide open subject to the one constraint that really matters. 4. Some ("obsolescent") parts of the SCSI code base may be carried pretty much "as is" indefinitely. Disadvantages: 1. Any really revolutionary mods may be excluded. 2. More changes may be included than would happen if one stuck with the Zeta code, as more ideas may be included. The ideas may be good, but the changes will be larger and deeper. How it addresses problems: This provides documentation for the SCSI subsystem, and allows for growth of the documents so that design detail from "real world" coding experience will be preserved in the documents. The design constraint provides a path forward. What does it involve: The umbrella document part can be achieved most simply if the entire group gets involved in a wordsmithing pass over the existing document and locates areas to be added. Some words exist for most of the topics in Rick's note (53.1) in there, and it can be used to ensure that rules of thumb about each of them exist. The detail documents need LOP for each, and perhaps it would be wisest to start discussing whether functions or entire components should be replaced. I have not too many prejudices except that ultimately all of a component will need to conform, not 50-60%, so that a pass over components will eventually be necessary for at least those components which are intended to be developed further.