[acs-wg] Re: Feedback from review of requirements spreadsheet

[pete at ziu.net]

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 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:

> 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 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:
> > 
> >>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
> > 
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/acs-wg/attachments/20050131/5822c4f1/attachment.html