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

[Keisuke Fukui]

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
>