Sarah Jelinek wrote: > Hi All, > > I have posted the first public draft of the proposed Caiman Unified > Engine Functional specification. It is located > at: > > http://opensolaris.org/os/project/caiman/CUD/CUE_docs/CUD_func_spec.pdf >
2.1: In general, I think most of requirements could use a bit more prose, they seem a bit too terse and leave lots of room for interpretation. A nit: "zpool datasets" -> "ZFS datasets" 2.1.3: Why is this specific to non-IPS installation? 2.1.4: Why is the engine responsible for validation of data that appears to be understood and interpreted by specific modules? Or are you suggesting that the engine will provide an infrastructure to enable modules to provide validation? 2.1.8: This one really needs clarification. My expectation was that the overall architecture provides it, not that there's a specific post installation framework. 2.1.9: Definitely need clarification on what "transport independent" means. 3.4: To me, a transition plan is more appropriate as something like an appendix; it's more a "how", not a "what", which is where I think the primary orientation of a functional spec belongs. 4.1.4.1.1 - it seems to me that there may be cases where limiting the scope of target discovery could be useful, if not necessary, (installadm is one that comes to mind), hence some inputs may be warranted. 4.1.5: As you have a number of references to the data collection object before this point, I'd suggest moving its description earlier in the section. I would tend to think of this as a service in the same vein as the items in 4.1.6 (as it has similar characteristics) but perhaps that's just me. 5.1: I'm curious as to the attributes of "R&R client" that led you to classify it as more different than like the installers, but perhaps I"m not understanding what you mean by R&R client here. 6.2: I'm not clear what is meant by a "network 'target'" that requires discovery for the text installer. Can you clarify? Dave
