[acs-wg] Re: Feedback from review of requirements spreadsheet
pete at ziu.net
pete at ziu.net
Mon Jan 31 21:45:47 CST 2005
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
peter.ziu at ngc.com (o)
pete at ziu.net (h)
5712350208 at tmomail.net (sms)
owner-acs-wg at ggf.org wrote on 01/31/2005 10:24:36 PM:
> 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
> > standard) of an identity (string). I was suggesting that we might
> > make bindings of software/drivers to certain machine identities, not
> > classes of machine types. To do this, we will need some way to work
> > the security folks to use x509 identities to target software to them
> > 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
> > 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
> Does anyone have idea who we can ask?
> I'm aware of the vast compilation about the security requirements.
> 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.
> I think this might contain the most comprehensive description about
> the security.
> I found the below contains more concise overview about the aspect
> though it is dated 2001.
> > Pete.
> > -----Original Message-----
> > From: owner-acs-wg at ggf.org [mailto:owner-acs-wg at ggf.org]On Behalf Of
> > Keisuke Fukui
> > Sent: Monday, January 31, 2005 3:03 AM
> > To: pete at ziu.net
> > Cc: acs-wg at ggf.org
> > Subject: [acs-wg] Re: Feedback from review of requirements spreadsheet
> > Hi Pete,
> > Thanks. You gave me good points in your comments.
> > pete at ziu.net wrote:
> >>This is a good start. I could only find some minor appearances of
> >>conflicts between items. I also threw in some potential items to
> >> - These two items appear to be at odds, or contradictory. Items
> >>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
> > This would be more specific rather than introducing the term
> > since it is used everywhere in the world and we haven't had its
> > 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
> > word to talk about the protocol. I should have said:
> > [2.4-e] ARI: ACS should allow ARI implementers to select a
> > 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,
> >>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
> >> - 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
> >>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.
> >>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
> >> 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
> >>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
> >>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
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the acs-wg