Feedback from review of requirements spreadsheet

[pete at ziu.net]

Keisuke, 

This is a good start.  I could only find some minor appearances of 
conflicts between items.  I also threw in some potential items to think 
about:

 - These two items appear to be at odds, or contradictory.  Items 1.1-a 
and 2.4-a.  The first states everything must be in one archive (file), and 
the latter states external references are legal.  Perhaps we could reword 
somehow to say the "notion of one logical archive (with version stamp and 
signature) must be maintained"?

- 2.4-e states that any protocol must be allowed, but 4.a states that 
SOAP/WS must be used.   Is there an issue here if one wishes to implement 
a multi-protocol ACS solution (say SOAP/WS and RMI and CORBA  [for legacy 
support, since this archive system could serve other paradigms as well])?


I was wondering if there was more to add to the list:

 - Perhaps there should be different classes of archives that can be 
linked together, internally or externally from the package, such as 
"foundational/infrastructure bundles" (PK DN descriptions, OS, drivers, 
etc.),  Application bundles, and data bundles?

 - Seems like there must be the ability to replicate/synchronize, in part 
of whole, the archive server/storage, since some of the binaries are bound 
to large or very large (packaged OS stuff and data), and may be 
inefficient to transmit across long hauls.  Many times, an enterprise 
system may wish to distributed non-transactional/non-realtime or 
infrequently updated data to many locations for WAN load distribution, 
different physical site redundancy, and reducing routes/long hauls.  ACS 
data is a good fit for this type of behavior.

 - Is there any idea of, or existing software unit and unique identity, to 
deploy across an enterprise on all devices to remotely enable the usage of 
the device to become part of a grid?  This could access ACS to obtain 
needed software.  Also, is there a bootp-like service to deploy this 
software unit/kernel? (may be out of scope of ACS, but should allow for 
the possiblity to accept client connections from this type of software 
unit in our use-cases).

Peter D Ziu
703.883.5168 (o)
571.235.0208 (c)
peter.ziu at ngc.com (o)
pete at ziu.net (h)
5712350208 at tmomail.net (sms)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/acs-wg/attachments/20050130/c4751eb5/attachment.html