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:

> 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 perhaps
> > some type of identity data will need to be stored/bound.  Although, the
> > 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 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
> >
>
>