February 2005 - acs-wg - lists.ogf.org

Teleconference minutes - 16/17 February 2005
by Sachiko Wada 07 Mar '05

07 Mar '05

Hi, Attached file is the minutes of our first teleconference. Please review it and point out where the record is not correct, if there is any. It is also available at Gridforge: https://forge.gridforum.org/projects/acs-wg/document/minutes-20050217/en/1 Regards, Sachiko Wada ====================================================================== ACS Teleconference ----------------------------------------------------------------------- Date and Time: Feb 16 19:00-20:15 EST 2005 / Feb 17 9:00-10:15 JST, 2005 Participants: Keisuke Fukui (Fujitsu) Thomas Studwell (IBM) Peter Ziu (Northrop) Michael Behrens (R2AD) Sachiko Wada (ASCADE) - minutes * Who will be present at the GGF13 ACS-WG session? - Tom, Pete and Mike can't make it and will join the sessions from the over the phone. - Tom will host the telephone bridge. * How many ACS-WG sessions will be at GGF13? - Two sessions including an introductory one and a detailed discussion is agreed with. * How many materials will be presented? first session : introductory presentation - A short overview of ACS by Keisuke and Sachiko - A CDC use case (Business Grid Project) by Keisuke and Sachiko - An introductory presentation "NaReGI PSE with ACS" by guest speaker. NAREGI(National Research GRID Initiative) http://www.naregi.org/index_e.html - Use case/example by Pete and Mike (over the phone) - Introduction to Solution Installation by Tom (over the phone) 15 min for presentation + 5 min for Q/A (question/answer) is suggested as presentation time. second session : detailed discussion - possible topics are: - scope - requirements - collaboration to other standardization, other WGs - Tom will send his proposal agenda for detailed discussion. * WGs to avoid time slot conflict to the ACS-WG session. The sessions for the below two WG/BOF are among the important ones that we need collaborate closely and thus we should avoid time conflict. OGSA's are also important but it's hard to avoid conflict to them. We should try to keep up with OGSA remotely. - Basic EMS Service (*) (*) Identified as "OGSA - Basic Execution Service" after the call. - CDDLM * Collaboration with Solution Installation activities - Solution Installation is very inclusive and has broader scope than ACS. Since it is expected to be a universal standard for software installation, ACS will follow its specification for the archive format. We should cooperate with them and join their activities. - Solution Installation intends to describe an enterprise level solution. In that sense, it goes well with ACS scope. * Miscellaneous: - Tom has kindly accepted hosting phone bridges for the next call and ACS-WG sessions at GGF13. - Thank you very much!! * Next call Date: Mar 2 Wed 19:00 EST/Mar 3 Thu 9:00 JST Theme: Review GGF presentation materials Call #: Same number, same pass code. * Action: Send out the materials to mailing list before next call

3 3

Session requests are submitted.
by Keisuke Fukui 25 Feb '05

25 Feb '05

Folks, FYI, I have registered two session requests for GGF13 on behalf of ACS-WG, based on the agreement made in the tele-conference held yesterday. https://forge.gridforum.org/tracker/index.php?aid=1304 https://forge.gridforum.org/tracker/index.php?aid=1306 The minute of the tele-conference will be posted for your review later today. -Keisuke P.S. A note on preferred session time slot: It turned out to be extra difficult to find proper time slots avoiding conflict with cddlm-wg/ogsa-wg/ogsa-*-bof sessions and within hours before the midnight in U.S East coast time, thus, I was forced to made compromises. It's up to the GGF office which time we will get eventually.

1 1

GGF13 session plan
by Keisuke Fukui 14 Feb '05

14 Feb '05

Folks, Since the ACS-WG is officially approved, I hope we can meet at the ACS sessions at GGF13 in Seoul! I'd like to discuss about our future plan. I think we need think about the below issues for GGF13: - Requirements refinement (including relationship to the Solution Installation) - Usecase collection - Verifing of the Milestones and Charter - Plenary session to recruit extra people to join - Prior recruiting for the ACS-WG session itself In addition, some logistics for GGF13 need to be found out, such as Session Plan, inviting the speakers; I guess we need expertise from security and data transport area to refine our requirements. Also, we'd like collect fair number of the usecases to justify our requirement analysis. Having a conference call about this may accelerate the discussion, though the comments on the mailing list are also welcomed. Please let me know your idea about these. And I expect all of you can meet at the GGF13! -Keisuke Fukui

4 9

RE: [acs-wg] Telephone conference for GGF13 preparation
by Ziu, Peter 14 Feb '05

14 Feb '05

The times work for me as well. -----Original Message----- From: owner-acs-wg(a)ggf.org [mailto:owner-acs-wg@ggf.org]On Behalf Of Thomas Studwell Sent: Monday, February 14, 2005 10:49 AM To: Keisuke Fukui Cc: acs-wg(a)ggf.org; owner-acs-wg(a)ggf.org Subject: Re: [acs-wg] Telephone conference for GGF13 preparation Fukui-san, all of these times are good for me and I can host the call. Since we have too little time to get agreement from everyone for a Monday call I suggest we limit to Wednesday or Thursday. For the moment I will assume we will have a Wed 19:00 EST/(Wed 16:00 PST)/Thu 9:00 JST call. Here is the call-in info: Toll Free: 1-800-497-2024 Toll: +1-719-457-3821 Tie Line: 650-3239 PC: 358182 Thomas W. Studwell Senior Technical Staff Member, Autonomic Computing Architecture IBM Software Group B140/Bldg 500 4205 S Miami Blvd, Durham, NC 27703 (919) 254-7574 Fax: (919) 254-7628 Mobile: (919) 619-1038 studwell(a)us.ibm.com "The optimist sees opportunity in every danger; the pessimist sees danger in every opportunity." Winston Churchill, Sir (1874-1965) Inactive hide details for Keisuke Fukui " src="cid:625495317@14022005-1c6c" width=16>Keisuke Fukui <kfukui(a)labs.fujitsu.com> Keisuke Fukui <kfukui(a)labs.fujitsu.com> Sent by: owner-acs-wg(a)ggf.org 02/14/2005 01:55 AM To Keisuke Fukui <kfukui(a)labs.fujitsu.com> cc acs-wg(a)ggf.org Subject [acs-wg] Telephone conference for GGF13 preparation Folks, As I suggested last week, we are planning preparation meetings over the phone for GGF13 preparation. Considering the announced deadline for session requests, February 18, I'm not sure if we can have one before that. But anyway, how many are attending it, except for Tom and Pete? Also, I have the following time slots in mind for the meeting: Mon 19:00 EST/(Mon 16:00 PST)/Tue 9:00 JST Wed 19:00 EST/(Wed 16:00 PST)/Thu 9:00 JST Thu 19:00 EST/(Thu 16:00 PST)/Fri 9:00 JST The first one may be too late to schedule for this week. Does these work for everyone? If not, please present your preference. If it works, we may have one before the deadline. One last thing, I'm now asking if Pete or Tom can host it, I think I can host the phone bridge in case they can't. However, it may result in more cost to join for most of the participants, since the dialing number will be in Japan. If someone on the list can host it, it would be appreciated very much. -Keisuke Keisuke Fukui wrote: > Tom, Pete, and folks, > > Here is my rough idea about what we'd like to have at GGF13. > > - Two sessions at GGF13. One for introduction to new comers > for ACS-WG, the other for detailed discussion and planning > towards the next step and next meeting. > - In the introductory one, we'd like to present short overview of > the ACS itself, and then use cases that will be enabled by ACS. > Among the candidates are the commercial data center grid, > targeted by Japanese business grid project, Science grid, > NaReGI Problem Solving Environment, the one that Pete and Mike > are pursuing. > - In the detailed discussion and planning session, we'd like to > examine current set of requirements for ACS, based on the list > I have posted here. Also, we'd like talk about the relationship > to the Solution Installation, including the synergy we can expect > and how we can join its standardization. I expect Tom will fill us > in the latest info in the area. I'd like cherish the collaboration > with this activity as a leverage to realize our vision. > > > We'd like to request phone line in the session room to have a bridge > to those cannot be present in the session. I hope participants from > other WG's such as the CDDLM-WG, OGSA EMS BOF. It would be nice > if they join our discussion or at least give us comments on ACS. > > What's your idea about this? Any comments? > > -Keisuke > > Keisuke Fukui wrote: > >> Folks, >> >> Since the ACS-WG is officially approved, I hope we can meet at the ACS >> sessions at GGF13 in Seoul! >> >> I'd like to discuss about our future plan. I think we need think about >> the below issues for GGF13: >> >> - Requirements refinement (including relationship to the Solution >> Installation) >> - Usecase collection >> - Verifing of the Milestones and Charter >> - Plenary session to recruit extra people to join >> - Prior recruiting for the ACS-WG session itself >> >> In addition, some logistics for GGF13 need to be found out, such as >> Session >> Plan, inviting the speakers; I guess we need expertise from security >> and data >> transport area to refine our requirements. Also, we'd like collect >> fair number >> of the usecases to justify our requirement analysis. >> >> Having a conference call about this may accelerate the discussion, >> though the >> comments on the mailing list are also welcomed. Please let me know >> your idea >> about these. And I expect all of you can meet at the GGF13! >> >> -Keisuke Fukui >> >

1 0

RE: [acs-wg] GGF13 session plan
by Ziu, Peter 09 Feb '05

09 Feb '05

Very interesting Mike. With respect to deployment of containers, (and OS's as containers for processes like service containers), there is a potential that we have to be sensitive to, that is, autonomy in conjunction with constraints verses specifying the deployed environment through exact description. Note that abstract constraints partially specify the environment, and leave the rest to algorithms. However, as long as the constraint specification within a job description can be extremely detailed as well as abstract, and the level of detail optional, the ability to control how much autonomy vs. direct instruction can be chosen by the job description. If the reverse is done (mandatory autonomy without detailed enough constraints), those wishing more control over where/how their jobs run (say for performance tuning or security reasons) may not be able to do so. Also, the job description is something which gets consumed by some job controlling mechanism service(s), but who deployed the job controlling service, securely and in autonomous fashion or exact fashion? Pete -----Original Message----- From: owner-acs-wg(a)ggf.org [mailto:owner-acs-wg@ggf.org]On Behalf Of behrens Sent: Wednesday, February 09, 2005 10:57 AM To: acs-wg(a)ggf.org Cc: franks(a)mcs.anl.gov Subject: Re: [acs-wg] GGF13 session plan Okay by me. Also - I have a few notes from Globus World which pertain to ACS: 1) Frank Siebenllist (security) mentioned in his brief a possible solution to some of the security risks: Dynamic deployment of a container (VM). This falls right in line with one of the requirements. As Frank put it: “Extremely cool stuff, I think” 2) GridPlan is an open source capability to support grid capacity and simulation. The speaker mentioned that they want to create an XML document to describe all the nodes required for an execution, so that it can perform the simulation, etc. I suggested to him to look into the ACS WG as there might be an opportunity for some synergy - if the simulate would then include an ACS component, that would be great. Also, perhaps a common XML document can be used. They might be able to provide a use case. Keisuke Fukui wrote: > Folks, > > The administration requires us to upload the session material by > February 18. > > I believe we can update them once uploaded the doc there. As such, I'm > going > to upload the current version of requirement documents a part of the > material > to the project document manager. Please check if it is ok to upload > the attached > one. I updated the doc w.r.t the comments from Pete, et al. > > -Keisuke > > > Keisuke Fukui wrote: > >> Folks, >> >> Since the ACS-WG is officially approved, I hope we can meet at the ACS >> sessions at GGF13 in Seoul! >> >> I'd like to discuss about our future plan. I think we need think about >> the below issues for GGF13: >> >> - Requirements refinement (including relationship to the Solution >> Installation) >> - Usecase collection >> - Verifing of the Milestones and Charter >> - Plenary session to recruit extra people to join >> - Prior recruiting for the ACS-WG session itself >> >> In addition, some logistics for GGF13 need to be found out, such as >> Session >> Plan, inviting the speakers; I guess we need expertise from security >> and data >> transport area to refine our requirements. Also, we'd like collect >> fair number >> of the usecases to justify our requirement analysis. >> >> Having a conference call about this may accelerate the discussion, >> though the >> comments on the mailing list are also welcomed. Please let me know >> your idea >> about these. And I expect all of you can meet at the GGF13! >> >> -Keisuke Fukui >> -- Michael Behrens R2AD, LLC (571) 594-3008 (cell) *new* (703) 714-0442 (land)

1 0

Re: [acs-wg] Re: Feedback from review of requirements spreadsheet
by pete＠ziu.net 31 Jan '05

31 Jan '05

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(a)ngc.com (o) pete(a)ziu.net (h) 5712350208(a)tmomail.net (sms) owner-acs-wg(a)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(a)ggf.org [mailto:owner-acs-wg@ggf.org]On Behalf Of > > Keisuke Fukui > > Sent: Monday, January 31, 2005 3:03 AM > > To: pete(a)ziu.net > > Cc: acs-wg(a)ggf.org > > Subject: [acs-wg] Re: Feedback from review of requirements spreadsheet > > > > > > Hi Pete, > > > > Thanks. You gave me good points in your comments. > > > > pete(a)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 > > > >

1 0

RE: [acs-wg] Re: Feedback from review of requirements spreadsheet
by Ziu, Peter 31 Jan '05

31 Jan '05

Agreed with all your responses. 2.4e is clarified. 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? Pete. -----Original Message----- From: owner-acs-wg(a)ggf.org [mailto:owner-acs-wg@ggf.org]On Behalf Of Keisuke Fukui Sent: Monday, January 31, 2005 3:03 AM To: pete(a)ziu.net Cc: acs-wg(a)ggf.org Subject: [acs-wg] Re: Feedback from review of requirements spreadsheet Hi Pete, Thanks. You gave me good points in your comments. pete(a)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

2 1