Re: [acs-wg] Re: Feedback from review of requirements spreadsheet
Pete,
Ziu, Peter wrote:
Agreed with all your responses. 2.4e is clarified.
Fine. I will update the doc.
I think I am mistaken concerning the PKI DN data. The PKI DN is the distinguished name (x509 standard) of an identity (string). I was suggesting that we might need to make bindings of software/drivers to certain machine identities, not just classes of machine types. To do this, we will need some way to work with the security folks to use x509 identities to target software to them (or a unique id that is bound to the DN). I was just suggesting that
some type of identity data will need to be stored/bound. Although,
right place for that is still probably in the job description/constraints, and has already been handled?
Agreed. We need more work on security requirements. Maybe we should ask consultation from security area folk or at least a review of the doc. Does anyone have idea who we can ask?
I'm aware of the vast compilation about the security requirements. However, we need a concise set of high level requirements. I hope the rest can be additionally considered after the framework of the spec. is clarified, with a minimal modification to what is described.
Note: I think this might contain the most comprehensive description about the security. http://niap.nist.gov/cc-scheme/cc_docs/index.html
I found the below contains more concise overview about the aspect though it is dated 2001.
http://www.bitsinfo.org/MSCv30sept03.pdf
-Keisuke
Pete.
-----Original Message----- From: owner-acs-wg@ggf.org [mailto:owner-acs-wg@ggf.org]On Behalf Of Keisuke Fukui Sent: Monday, January 31, 2005 3:03 AM To: pete@ziu.net Cc: acs-wg@ggf.org Subject: [acs-wg] Re: Feedback from review of requirements spreadsheet
Hi Pete,
Thanks. You gave me good points in your comments.
pete@ziu.net wrote:
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
Sounds Good Keisuke. I am not sure who to ask about the security aspects. I will refer to the links you posted below for now. Peter D Ziu 703.883.5168 (o) 571.235.0208 (c) peter.ziu@ngc.com (o) pete@ziu.net (h) 5712350208@tmomail.net (sms) owner-acs-wg@ggf.org wrote on 01/31/2005 10:24:36 PM: perhaps the 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"?
I got your point. Yes, it literally contradicts. I should have said:
[1.1-a] AAF/ARI: Application contents must be bundled in a single and consistent archive, either in a actual contents or in an external reference.
This would be more specific rather than introducing the term "logical", since it is used everywhere in the world and we haven't had its meaning narrowed down here.
- 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 believe the short description in the requirements text lacks restrictive word to talk about the protocol. I should have said:
[2.4-e] ARI: ACS should allow ARI implementers to select a communication protocol for transport of the bulk data transfer.
Doesn't it clarify the point yet?
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?
Yes, I would like to cover diversity of the application contents; it includes OS, drivers and middleware. What is "PK DN descriptors" here you mentioned?
- 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.
Yes, I believe the above describes what I meant for.
- 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).
I would call for expertise from the broader range of the people for this discussion. Maybe we can attract them at the GGF13 sessions.
P.S. Should we have some tele-conferences in February? We need decide the session plan by Feb. 18 according to the GGF office notice.
-Keisuke
participants (1)
-
pete＠ziu.net