August 2006 - ogsa-wg - lists.ogf.org

Proposed agenda for Aug. 31st call
by Hiro Kishimoto 30 Aug '06

30 Aug '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on Aug. 31st Thursday from 8:30am - 10:30am (CDT). Dial-in numbers for Thursday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0831 See more explanation: https://forge.gridforum.org/sf/go/wiki1584?nav=1 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (if available) Action Items status review (see the bottom of this email) Agenda bashing 2) OGSA F2F meeting agenda update (20 min) F2F agenda on Sep. 14 (Thur) and 15 (Fri) https://forge.gridforum.org/sf/go/wiki1555?nav=1 3) EMS scenarios (Andreas and Steven, 30 min) EMS architecture scenario document review - https://forge.gridforum.org/sf/go/doc12749?nav=1 4) EMS & Data joint scenario (30 min) > Agreed that a good first candidate scenario is simple job execution > with data staging. In particular the combination of JSDL, BES, Data > transfer service (DMI based?). > > AI-0817b: Stephen Davey will do a cut down parameter sweep scenario > focusing on the JSDL+BES+Data Transfer/Staging service > > The aim is to discuss it at least within Data at the Data F2F (Aug > 28-30 @Edinburgh) and with EMS at GGF18. Since many Data members > will be leaving on Thursday it would be good to arrange some time > early on Thursday (OGSA F2F). 5) Wrap up (10 min) AOB <*NEXT CALL*> https://forge.gridforum.org/sf/go/wiki1477?nav=1 Sep. 4 (Mon): No call (Labor Day) Sep. 7 (Thu): Roadmap (Chris), GGF18 prep (Tom and Hiro) <*ACTION ITEMS*> https://forge.gridforum.org/sf/go/wiki1569?nav=1 > From Aug. 17 call AI-0817a: Dave Berry and Jay Unger will approach groups (GIN, Globus, etc) that have implemented practical grids and start a discussion on how they handle data: - how data is treated as a resource that can be scheduled - how transfers are modeled - how files are advertised - how applications find files (query, by knowledge,?) AI-0817b: Stephen Davey will do a cut down parameter sweep scenario focusing on the JSDL+BES+Data Transfer/Staging service > From Aug. 10 call AI-0810a: Donal to look into the relation of the EPS and CDL (retrieval, update, etc). (Eventually this should probably become a separate scenario.) > From Aug. 3 call AI-0803e: Jun will provide an example of the CDL mechanism and why using ID/IDREF is not a good idea. AI-0803f: Jun will update the CDL document to remove the Environment variables > > From July 20 F2F - EGR-WG (Ravi) will contact Geoffrey Fox and invites him to contribute use cases. - Andreas to go through the minutes and formulate a reply mail to Geoffrey on each artifact covered in these minutes. <postponed> - Steve McGough & Andreas to do a mapping from the current JSDL elements / terminology into the new information model structure (Proposed split into Description and Requirements) (from July 18th F2F, By GGF18 as original discussed.) ---- Hiro Kishimoto

1 0

RE: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg
by Maguire_Tom＠emc.com 30 Aug '06

30 Aug '06

Apologies for the cross post but some of this discussion is relevant to the OGSA-WG I would agree that WS-BaseFaults are not required for BES. In WS-ResourceProperties the use of BaseFaults is optional (SHOULD). The OGSA Basic Profile for WSRF has mandatory (MUST) use of BaseFaults for WS-Resources. 7.1.1 BaseFault Structure R0711 A MESSAGE for a fault from a WS-Resource MUST conform to the structure specified in Web Services Base Faults Section 2, "Base Fault Type." As I re-read this section it is not nearly clear enough about the scope of 'WS-Resource'ness. I could interpret this requirement several ways: * ALL faults from a WS-Resource MUST be extensions of BaseFaults * ALL faults from a WS-Resource based portType MUST be extensions of BaseFaults * ALL faults from a WS-Resource base portType that match the semantics of existing BaseFaults MUST use the BaseFault extension type that is defined for that portType (basically what this does is turn the SHOULD in WSRF specs for faults into MUSTs) Clearly, point 1 is a non-starter; no implementation will be able to guarantee that all faults are extension of BaseFaults. Point 2 is also extremely difficult as there are significant numbers of interceptors between the consumer and the provider implementation all of which are likely to not fault with WS-BaseFaults. Which leads us to point 3, I think this is the only reasonable interpretation of the requirement; that faults that are defined in WSRF specs MUST be used (as opposed to the SHOULD requirement in WSRF). Perhaps we should clarify this requirement in the Basic Profile. w.r.t the subject at hand I think that any consumer will need to deal both SOAP faults and BaseFaults and as such I don't see much of a need to fuss about the fault definitions in BES. I do however, agree with Ian that there is value in having a common base type for faults. Tom _______________________________________________ Tom Maguire +1(845) 729-4806 _____ From: owner-ogsa-bes-wg(a)ggf.org [mailto:owner-ogsa-bes-wg@ggf.org] On Behalf Of Ian Foster Sent: Friday, August 18, 2006 11:27 AM To: Marvin Theimer; ogsa-bes-wg(a)ggf.org Subject: RE: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg Marvin: David's proposal, which is realized in the current draft, is that we define BES to just have "GetStatus" and "GetProperties" operations (as well as CreateActivity etc.). We can then compose WS-Transfer operations or WSRF operations, if desired, in a particular BES implementation. This seems to me to be a really nice solution to the "problem" that we thought we had, in that it avoids the need for multiple renderings. The one tricky issue is the rendering of faults. In the current BES document, we use WS-BaseFaults. You report that the Microsoft WS team has problems with that. I don't think we should let this be a show stopper, as I don't think it is essential that we use WS-BaseFaults in BES. At the same time, WS-BaseFaults was introduced for a reason. Thus I'd like to propose that we proceed as follows: a) We set up a phone call with the Microsoft WS team and the WS-BaseFaults guys to talk this over, in case it turns out that we can in fact all agree that WS-BaseFaults is useful. b) In the (likely) case that the Microsoft WS team still doesn't want to see WS-BaseFaults included, we check with the BES team that it is ok to use a different fault model for the BES core vs. the specs that might be composed with the BES core, such as WSRF. Thoughts? Ian. At 05:17 PM 8/16/2006 -0700, Marvin Theimer wrote: Hi; Another comment/question on Dave Snellings proposal: I dont really understand how it avoids distinct renderings since it is still the case that we have at least 3 different WSDLs, one per rendering option: * WSRF version that employs WS-ResourceProperties, etc. * WS-Transfer version that employs WS-Transfer, etc. * Resource model-free version that employs an explicit QueryStatus operation (and potentially additional QueryFoo operations). It is certainly the case that there is a coreset of operations that is common to all 3 interface choices and we should certainly write the spec that way. But dont we still end up with 3 different rendering versions? Marvin. _____ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: Friday, August 04, 2006 2:20 PM To: Marvin Theimer; ogsa-bes-wg(a)ggf.org Subject: Re: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg Marvin: I've claimed the pen on the document, but have been finding it hard to find time to make a lot of progress. I will try to do some work on it tomorrow morning. That said, I want to mention an important development that Dave Snelling may or may not have mentioned on calls. Dave argues that we can avoid the need for distinct renderings by defining our interfaces carefully. The basic idea, as I understand it, is that: a) the "core interface" has the basic operations for creating jobs, modifying their status, etc., and an operation for grabbing all of the factory state; b) then, if desired, a WSRF service (for example) can also implement the WS-ResourceProperties, WS-ResourceLifetime, WS-BaseNotification, operations; c) while a WS-Resource service would implement the WS-Resource equivalents of those. So we exploit the power of interface composition to avoid the need for separate bindings. The only problematic issue, as I understand it, is that of faults. The question is how we render faults. The WSRF binding must (by the spec) use WS-BaseFaults. If we can all agree to use that, then we are ok. If not, then we still have problems. Ian. At 01:29 PM 8/4/2006 -0700, Marvin Theimer wrote: x-ms-exchange-organization-recipient-p2-type: To Content-Type: text/plain; charset="us-ascii" Hi; The HPC Profile (HPCP) work depends critically on BES. The recent face-to-face meeting at Argonne made substantial progress in terms of reshaping the proposed BES specification in a way that would make it suitable for supporting the HPCP on top of it. Are there plans to generate a new revision of the BES specification draft in the near future? As soon as the revised version comes into existence we'll be able to seriously start doing the actual HPCP work (which will take place on the hpcp-ogsa-wg mailing list and in weekly telecom calls that will be starting shortly). Since the HPCP WG is effectively gated on this revised spec, having a draft of a revised spec sometime in the next week or so would be really helpful. I would be willing to help rewrite the BES spec if that would be useful to the BES WG. Marvin. _______________________________________________________________ Ian Foster, Director, Computation Institute Argonne National Laboratory & University of Chicago Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619. Web: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> . Globus Alliance: www.globus.org <http://www.globus.org/> . _______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/>

2 2

OGSA F2F meeting agenda on Sept. 14 & 15
by Hiro Kishimoto 29 Aug '06

29 Aug '06

Hi all, GGF18 and back-to-back OGSA meeting are just around the corner and we need to finalize meeting agenda very soon. The following is current proposal and if you have any request or comment, please let me know ASAP. We will review and finalize meeting agenda at the upcoming Thursday call. Also, if you plan to come (or dial-in) but your name is not on the attendee list, please let me know. You should be on the list to enter facility. https://forge.gridforum.org/sf/go/wiki1555?nav=1 Thursday afternoon (2:30-6pm) * A joint EMS/Data session (Dave and Andreas, 1-2hr depending on people's availability) o Since many Data members will be leaving on Thursday it would be good to arrange some time early on Thursday. * Info Model (Ellen and Fred, 2H or half day) o agenda is overflow from work that will not get done during the 2 GGF sessions o first draft of base model objects for HPC/BES/JSDL o probably XQuery examples. Friday morning (8am-noon) * OGSA general session (Tom and Hiro, 2H) o OGSA direction and priority o document status review o winter F2F schedule o telecon schedule * JSDL session (Steve McGough, 1-2 hr) o Bashing out ideas for JSDL 2.0 Friday afternoon (1-4pm) * OGSA-DMI Update (Michel Drescher, 1hr) o This session is to update the OGSA-WG and all interested parties on the status of the OGSA-DMI work. It is expected that a first draft of the functional interface is drafted at GGF18. * OGSA-RSS (Donal Fellows, ??) o discuss the EPS and its relation to the rest of the EMS arch -- Hiro Kishimoto

3 8

Proposed agenda for Aug. 28th call
by Hiro Kishimoto 28 Aug '06

28 Aug '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on Aug. 28th Monday from 5pm to 7pm (CDT). The dial-in number for Monday; US: +1 718 3541071 (New York) or +1 408 9616509 (San Jose) UK: +44 (0)207 3655269 (London) Japan: +81 (0)3 3570 8225 (Tokyo) PIN: 4371991 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0828 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (Aug. 21st) - https://forge.gridforum.org/sf/go/doc13750?nav=1 Action Items status review (see the bottom of this email) Agenda bashing 2) OGSA F2F meeting agenda update (20 min) F2F agenda on Sep. 14 (Thur) and 15 (Fri) https://forge.gridforum.org/sf/go/wiki1555?nav=1 3) OGSA authorization call-out proposal review (Frank, 20 min) > - Frank is now consulting with people in GGF (David Chadwick, Von > Welch) on whether his approach can be defined within the AuthZ > group. If there is no agreement then he will accept the XACML > group's decision. David's "Functional Components of Grid Service Provider Authorisation Service Middleware" document - https://forge.gridforum.org/sf/go/doc13724?nav=1 4) Basic Security Profile PC review (Takuya, 30 min) Review Takuya's proposal. 5) Wrap up (10 min) AOB <*NEXT CALL*> https://forge.gridforum.org/sf/go/wiki1477?nav=1 Aug. 31 (Thu): EMS scenarios (Andreas and Steven) EMS & Data joint scenario (Allen, Dave Barry, Steven, and Andreas) Sep. 4 (Mon): No call (Labor Day) Sep. 7 (Thu): Roadmap (Chris), GGF18 prep (Tom and Hiro) <*ACTION ITEMS*> https://forge.gridforum.org/sf/go/wiki1569?nav=1 > From Aug. 21 call AI-0821a: Hiro to talk to Jun and CDDLM group about EGA & CDDLM comparison proposal. AI-0821b: Hiro to talk to Jem about EGA & OGSA glossary comparison > From Aug. 17 call AI-0817a: Dave Berry and Jay Unger will approach groups (GIN, Globus, etc) that have implemented practical grids and start a discussion on how they handle data: - how data is treated as a resource that can be scheduled - how transfers are modeled - how files are advertised - how applications find files (query, by knowledge,?) AI-0817b: Stephen Davey will do a cut down parameter sweep scenario focusing on the JSDL+BES+Data Transfer/Staging service > From Aug. 10 call AI-0810a: Donal to look into the relation of the EPS and CDL (retrieval, update, etc). (Eventually this should probably become a separate scenario.) > From Aug. 3 call AI-0803e: Jun will provide an example of the CDL mechanism and why using ID/IDREF is not a good idea. AI-0803f: Jun will update the CDL document to remove the Environment variables > > From July 20 F2F - EGR-WG (Ravi) will contact Geoffrey Fox and invites him to contribute use cases. - Andreas to go through the minutes and formulate a reply mail to Geoffrey on each artifact covered in these minutes. <postponed> - Steve McGough & Andreas to do a mapping from the current JSDL elements / terminology into the new information model structure (Proposed split into Description and Requirements) (from July 18th F2F, By GGF18 as original discussed.) ---- Hiro Kishimoto

2 1

draft minutes for OGSA-Authz call-out proposal review (Aug 11)
by Hiro Kishimoto 28 Aug '06

28 Aug '06

OGSA Teleconference - 11 August 2006 ==================================== * This is first half of Aug. 11 call * * Participants Andrew Grimshaw (UVa) Jay Unger (IBM) Frank Seibenlist (ANL) Steven Newhouse (OMII) Takuya Mori (NEC) Marvin Theimer (Microsoft) Jem Treadwell (HP) Duane Merrill (UVa) David Chadwick (U of Kent) Andreas Savva (Fujitsu) Donal Fellows (Uom) Minutes: Takuya Mori * OGSA authorization call-out proposal review (Frank, 20 min) Reference: "Functional Components of Grid Service Provider Authorisation Service Middleware" https://forge.gridforum.org/sf/go/doc13724?nav=1 David presented a draft document, "Functional Components of Grid Service Provider Authorisation Service Middleware", which was sent to the OGSA-AuthZ and OGSA-WG list on Aug 9. (The document was based on discussions between Von, Frank and David.) David introduced functional components, Policy Enforcement Point (PEP), Credential Validation Service (CVS) and PDP (Policy Decision Point) and showed four types of interactions between the components (See Fig.1 to Fig.4 in the document). David proposed to define two protocols, one for CVS and the other for PDP. The followings are the points of his proposal. - CVS is used to validate credentials and to issue valid attributes of Access Requestors. - CVS is passed authenticated name and credentials. - CVS determines if the credential is trust worthy and returns valid attributes. - An administrator manages two types of rules, auhtz decision rules and rules to resolve trust relationships - CVS makes use of XACML policy query interface, but it is not necessarily be an XACML policy engine behind the interface. - CVS is needed to separate authentication and authorization. Various questions and answers arouse during the presentation and some major points made clear in the discussion were: - The two protocols are intended to support all the configuration shown in the figures - Revisions of the two "OGSI" profiles are also in the scope of current activities of the OGSA-AuthZ-WG. - Defining attributes values (terms and semantics) is not in the scope of current activities of the OGSA-AuthZ-WG, but in its future scope. The discussion were suspended until Aug 28 due to the running out of the meeting time. The followings are some interactions during the discussion. * The scope of the work (1) Q: Does the two protocols cover all the configurations shown in the figures? The protocols shown in the figures look different. A: Yes, the both protocols can cover all the configuration. The current OGSA-Authz profiles can handle this kind of interactions. Q: The current profiles are not "OGSA" profiles. These are "OGSI" profiles. A: The difference between "OGSI" and "OGSA" is small for OGSA-Authz profiles. Revisions of these two profiles are also on the table. * How to define service I/F of applications Q: As an application desginer, do I need to choose appropriate one? * long interactions were taken place which Takuya couldn't perfectly follow, but if Takuya understood well, the answer from the authz wg is: * A: Interafces of applications will not be affected. It is the middleware which speaks the protocols. Authorization is taken place behind the infrastructure. * The scope of the work (2) Q: The architecture for authorization has not clearly been defined. What the OGSA-AuthZ-WG are going to define? Do we need to define all the comopnents? Various terms and semantics also needs to be defined for attributes and policies. These also should be standardized. A: The OGSA-AuthZ-WG did the similar things in the past, the credential formats and terms over the SAML Attribute Assertion and the X.509 Attribute Certs. Q: It covers a different interop level - only attribute name or type level - not the values. A: The OGSA-AuthZ-WG focuses only on the interface level. David doesn't have a need to define values. (at this moment?) The WG needs to define them later in the future. -- Hiro Kishimoto

1 0

Telecon minutes for Thursday Aug 24
by Treadwell, Jem 24 Aug '06

24 Aug '06

Hi, we didn't have the necessary people on the call for today's scheduled CDDLM discussion, so we didn't have a real meeting. But I've uploaded the minutes, and as they're extremely short I've embedded them below. - Jem OGSA Teleconference - 24 August 2006 ==================================== * Participants Hiro Kishimoto (Fujitsu) Jay Unger (IBM) Mark Morgan (UVa) Andrew Grimshaw (UVa) Jem Treadwell (HP) Michel Drescher (Fujitsu) Minutes: Jem Treadwell * As there were insufficient people for the scheduled business, no formal meeting was held. Hiro will reschedule the planned agenda items. ________________________________ Jem Treadwell Hewlett-Packard Company 6000 Irwin Road Mount Laurel, NJ 08054 Phone: 856-638-6021 Fax: 856-638-6190 E-mail: Jem.Treadwell(a)hp.com <mailto:Jem.Treadwell@hp.com>

1 0

FW: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg
by Maguire_Tom＠emc.com 22 Aug '06

22 Aug '06

For some reason this did not make it to the OGSA-WG mailing list. In particular I think this points out the need for a bit more clarity in the Basic Profile. Tom _______________________________________________ Tom Maguire +1(845) 729-4806 _____ From: Maguire, Tom Sent: Monday, August 21, 2006 3:44 PM To: Maguire_Tom(a)emc.com; foster(a)mcs.anl.gov; theimer(a)microsoft.com; ogsa-bes-wg(a)ggf.org; ogsa-wg(a)ggf.org Subject: RE: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg As an aside I am not quite sure how BaseFaults breaks tooling. The BaseFault element is carried as an extensibility item in the s11:detail or s12:Detail elements. Isn't that what these items were designed for?? Tom _______________________________________________ Tom Maguire +1(845) 729-4806 _____ From: owner-ogsa-bes-wg(a)ggf.org [mailto:owner-ogsa-bes-wg@ggf.org] On Behalf Of Maguire_Tom(a)emc.com Sent: Monday, August 21, 2006 3:30 PM To: foster(a)mcs.anl.gov; theimer(a)microsoft.com; ogsa-bes-wg(a)ggf.org; ogsa-wg(a)ggf.org Subject: RE: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg Apologies for the cross post but some of this discussion is relevant to the OGSA-WG I would agree that WS-BaseFaults are not required for BES. In WS-ResourceProperties the use of BaseFaults is optional (SHOULD). The OGSA Basic Profile for WSRF has mandatory (MUST) use of BaseFaults for WS-Resources. 7.1.1 BaseFault Structure R0711 A MESSAGE for a fault from a WS-Resource MUST conform to the structure specified in Web Services Base Faults Section 2, "Base Fault Type." As I re-read this section it is not nearly clear enough about the scope of 'WS-Resource'ness. I could interpret this requirement several ways: * ALL faults from a WS-Resource MUST be extensions of BaseFaults * ALL faults from a WS-Resource based portType MUST be extensions of BaseFaults * ALL faults from a WS-Resource base portType that match the semantics of existing BaseFaults MUST use the BaseFault extension type that is defined for that portType (basically what this does is turn the SHOULD in WSRF specs for faults into MUSTs) Clearly, point 1 is a non-starter; no implementation will be able to guarantee that all faults are extension of BaseFaults. Point 2 is also extremely difficult as there are significant numbers of interceptors between the consumer and the provider implementation all of which are likely to not fault with WS-BaseFaults. Which leads us to point 3, I think this is the only reasonable interpretation of the requirement; that faults that are defined in WSRF specs MUST be used (as opposed to the SHOULD requirement in WSRF). Perhaps we should clarify this requirement in the Basic Profile. w.r.t the subject at hand I think that any consumer will need to deal both SOAP faults and BaseFaults and as such I don't see much of a need to fuss about the fault definitions in BES. I do however, agree with Ian that there is value in having a common base type for faults. Tom _______________________________________________ Tom Maguire +1(845) 729-4806 _____ From: owner-ogsa-bes-wg(a)ggf.org [mailto:owner-ogsa-bes-wg@ggf.org] On Behalf Of Ian Foster Sent: Friday, August 18, 2006 11:27 AM To: Marvin Theimer; ogsa-bes-wg(a)ggf.org Subject: RE: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg Marvin: David's proposal, which is realized in the current draft, is that we define BES to just have "GetStatus" and "GetProperties" operations (as well as CreateActivity etc.). We can then compose WS-Transfer operations or WSRF operations, if desired, in a particular BES implementation. This seems to me to be a really nice solution to the "problem" that we thought we had, in that it avoids the need for multiple renderings. The one tricky issue is the rendering of faults. In the current BES document, we use WS-BaseFaults. You report that the Microsoft WS team has problems with that. I don't think we should let this be a show stopper, as I don't think it is essential that we use WS-BaseFaults in BES. At the same time, WS-BaseFaults was introduced for a reason. Thus I'd like to propose that we proceed as follows: a) We set up a phone call with the Microsoft WS team and the WS-BaseFaults guys to talk this over, in case it turns out that we can in fact all agree that WS-BaseFaults is useful. b) In the (likely) case that the Microsoft WS team still doesn't want to see WS-BaseFaults included, we check with the BES team that it is ok to use a different fault model for the BES core vs. the specs that might be composed with the BES core, such as WSRF. Thoughts? Ian. At 05:17 PM 8/16/2006 -0700, Marvin Theimer wrote: Hi; Another comment/question on Dave Snellings proposal: I dont really understand how it avoids distinct renderings since it is still the case that we have at least 3 different WSDLs, one per rendering option: * WSRF version that employs WS-ResourceProperties, etc. * WS-Transfer version that employs WS-Transfer, etc. * Resource model-free version that employs an explicit QueryStatus operation (and potentially additional QueryFoo operations). It is certainly the case that there is a coreset of operations that is common to all 3 interface choices and we should certainly write the spec that way. But dont we still end up with 3 different rendering versions? Marvin. _____ From: Ian Foster [mailto:foster@mcs.anl.gov] Sent: Friday, August 04, 2006 2:20 PM To: Marvin Theimer; ogsa-bes-wg(a)ggf.org Subject: Re: [ogsa-bes-wg] Create a revised BES spec draft that reflects the decisions of the July F2F mtg Marvin: I've claimed the pen on the document, but have been finding it hard to find time to make a lot of progress. I will try to do some work on it tomorrow morning. That said, I want to mention an important development that Dave Snelling may or may not have mentioned on calls. Dave argues that we can avoid the need for distinct renderings by defining our interfaces carefully. The basic idea, as I understand it, is that: a) the "core interface" has the basic operations for creating jobs, modifying their status, etc., and an operation for grabbing all of the factory state; b) then, if desired, a WSRF service (for example) can also implement the WS-ResourceProperties, WS-ResourceLifetime, WS-BaseNotification, operations; c) while a WS-Resource service would implement the WS-Resource equivalents of those. So we exploit the power of interface composition to avoid the need for separate bindings. The only problematic issue, as I understand it, is that of faults. The question is how we render faults. The WSRF binding must (by the spec) use WS-BaseFaults. If we can all agree to use that, then we are ok. If not, then we still have problems. Ian. At 01:29 PM 8/4/2006 -0700, Marvin Theimer wrote: x-ms-exchange-organization-recipient-p2-type: To Content-Type: text/plain; charset="us-ascii" Hi; The HPC Profile (HPCP) work depends critically on BES. The recent face-to-face meeting at Argonne made substantial progress in terms of reshaping the proposed BES specification in a way that would make it suitable for supporting the HPCP on top of it. Are there plans to generate a new revision of the BES specification draft in the near future? As soon as the revised version comes into existence we'll be able to seriously start doing the actual HPCP work (which will take place on the hpcp-ogsa-wg mailing list and in weekly telecom calls that will be starting shortly). Since the HPCP WG is effectively gated on this revised spec, having a draft of a revised spec sometime in the next week or so would be really helpful. I would be willing to help rewrite the BES spec if that would be useful to the BES WG. Marvin. _______________________________________________________________ Ian Foster, Director, Computation Institute Argonne National Laboratory & University of Chicago Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619. Web: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> . Globus Alliance: www.globus.org <http://www.globus.org/> . _______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com <http://ianfoster.typepad.com/> Computation Institute: www.ci.uchicago.edu <http://www.ci.uchicago.edu/> & www.ci.anl.gov <http://www.ci.anl.gov/> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org <http://www.globus.org/>

1 0

Re: Action item list on wiki (was Re: [ogsa-wg] OGSA Teleconference (August 17))
by Subramaniam, Ravi 22 Aug '06

22 Aug '06

Hi Hiro, I agree with you that we need to make sure this is not a lot of work. Actually I was thinking that this would be recorded in the meeting minutes and them cut an pasted into a wiki or doc. This also like you indicate may be an extra effort on part of minutes keepers. I wish I could send out an example but the best example of minutes I have seen here is what Jim Hughes (HP) would keep for the Globus consortium. He had a neat scheme etc for recordiing AI and resolutions and other aspects of a meeting and from what I understood he had adapted this from some well known method. He would do this almost as a course of the meeting but in our case we could achieve something similar where we pause in the meeting to allow the note taker to record resolutions would help. Anyway, I am not suggesting we add more work so unless we can incorporate it into our current activity we could drop this for now. Ravi Ravi Subramaniam -----Original Message----- From: Hiro Kishimoto [mailto:hiro.kishimoto@jp.fujitsu.com] Sent: Friday, August 18, 2006 08:14 PM Pacific Standard Time To: Subramaniam, Ravi Cc: Andreas Savva; OGSA-WG ML Subject: Re: Action item list on wiki (was Re: [ogsa-wg] OGSA Teleconference (August 17)) Hi Ravi, "Summary resolutions compiled in one location" is very good idea. However, I worry about who is in charge. Our note taker(s) is doing very good job but I cannot ask him to do additional works. As an co-chair, I have started "telecon log" wiki page which has recorded discussed topics at each call instead of proposed agenda. Thus you can easily locate related minutes. https://forge.gridforum.org/sf/go/wiki1482?nav=1 Actually we need volunteers to maintain suggested resolution summary pages. Thanks, ---- Hiro Kishimoto Subramaniam, Ravi wrote: > Hi Andreas, > > I think intent and means are clashing in our discussion. I feel that we need to capture decisions and consensus that we reached at meetings. The items are spread into minutes (though not always recorded as a resolution) and other discussions including email. > > I think these also have two levels like action items. One level is recording the essence in a few lines (whether the topic is on of the domains or procedural like format ting) like we do with AIs and the other is an elaboration where necessary or possible like a document or in case of an AI the work product of that item. It is very likely that a collection of resolution/decisions/observations would lead to a single document elaboration and a resolution may not have any other elaboration. Maybe the disconnect is that I think you are referring to the latter level and I am indicating the need for the former level. (I think both levels are important and have their value propositions) > > Having the 'summary resolutions' compiled in one location (organised by domain if necessary) allows us to see where we have conflicts and, if as new members join or in course of discussion, we are revisiting earlier resolutions (we may change resolutions but we know that we are changing a previous one and not reinventing). Where we need more clarity on the earlier resolution we may refer to the 'Architectural notes' or other such related document. > > My experiential perception is that we have revisted a topic many > times and have reached the same conclusions. This is subjective (and I may be able to dig up a couple of recent examples). > > My one cent! > > Ravi > > > Ravi Subramaniam > > -----Original Message----- > From: Andreas Savva [mailto:andreas.savva@jp.fujitsu.com] > Sent: Friday, August 18, 2006 01:39 AM Pacific Standard Time > To: Subramaniam, Ravi > Cc: Hiro Kishimoto; OGSA-WG ML > Subject: Re: Action item list on wiki (was Re: [ogsa-wg] OGSA Teleconference (August 17)) > > Ravi, > > I still feel that what you are asking is too fine-grain and would not > work in the long run. What is really needed is to document what the > approach is on important topics. > > Taking the 'font' example below it would not be very useful on a general > list of resolutions if that list also included stuff on information > modeling, execution management, data access, security, etc. Instead if > someone thinks a topic is important and they want to maintain a short > (or long) document explaining what the group consensus is, and *keep it > up-to-date* I would be all for it. > > I'll just point out that I did set up an "Architecture Notes" forum some > time back and we still only have one note there. But it's a very good > note and I later used it to write up one subsection in OGSA 1.5. > > Andreas > > Subramaniam, Ravi wrote: >> Thanks. I am ok with Andreas' rationale too. >> >> Just a quick clarification though: The "resolution" I was referring to >> was not the resolution of the action item but noting any resolutions >> that were made/taken in the meeting, for example, if we decided that >> "All documents will be in 12 point font". It would be good to record >> such resolutions taken (or maybe there is a better word than >> 'resolution'). These will likely be around for a while and so the 'year' >> may be required here :-). >> >> Ravi >> > >

3 2

Proposed agenda for Aug. 24th call
by Hiro Kishimoto 22 Aug '06

22 Aug '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on <DATE> Thursday from 8:30am - 10:30am (CDT). Dial-in numbers for Thursday: Free: +1-888-452-0308 Intl/Toll: +1-484-644-0505 PIN: 71815 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 0824 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (20 min) Note taker assignment Roll call Telecon minutes approval (Aug. 21st) https://forge.gridforum.org/sf/go/doc13750?nav=1 Action Items status review (see the bottom of this email) Agenda bashing 2) OGSA F2F meeting agenda discussion (20 min) Establish F2F agenda on Sep. 14 (Thur) and 15 (Fri) https://forge.gridforum.org/sf/go/wiki1555?nav=1 3) CDDLM joint discussion #1 (40 min) Follow-up discussion on August 3rd. (3-1) >> PROPOSAL 1b: Use xsd:ID/xsd:IDREF to allow relations between elements in >> CDL documents > > - Jun thinks that this is not a good idea because ID must be unique > in the document and CDL inheritance may break this guarantee by > creating duplicate IDs in the resulting document. CDL has a > mechanism based on non-unique ids. > > AI-0803e: Jun will provide an example of the CDL mechanism and why > using ID/IDREF is not a good idea. (3-2) >> PROPOSAL 2: Eliminate the EnvironmentVariable concept from the >> PosixComponent (CDL plugin) >> >> * Proposal 2 is specific to the OGSA EMS scenarios document. > > Agreed that this is a reasonable resolution for resolving the > problem with the PosixComponent and is sufficient for the EMS > Scenarios document. > > AI-0803f: Jun will update the CDL document to remove the Environment > variables (3-3) > - A normative definition of PosixComponent > - At the moment there is no such definition; there are only some > examples. > - Agreed that a normative definition is necessary and that it is > not part of CDL version 1.0. Also it is probably too late to > leave it for CDL version 2.0---since it is not scheduled yet. > - Tentative agreement that this should be a work item for > CDDLM-WG between these two document release > - Dejan and Jun with discuss this in the CDDLM-WG and seek > approval as a work item after CDL 1.0. 4) CDDLM joint discussion #2 (20 min) OGSA-WG and EGA Reference Model WG started to identify similarities and differences between current works. EGA Ref Model's Dependency Graph and Life Cycle of Grid Components looks very relevant to CDDLM-WG's work. http://www.gridalliance.org/en/WorkGroups/ReferenceModel.asp OGSA-WG will have a GGF18 session on Tuesday 4-5:30pm for this discussion. https://forge.gridforum.org/sf/go/wiki1560?nav=1 5) Wrap up (10 min) AOB <*NEXT CALL*> https://forge.gridforum.org/sf/go/wiki1477?nav=1 Aug. 28 (Mon): Security (Takuya and Frank) Aug. 31 (Thu): EMS scenarios (Andreas and Steven) EMS & Data joint scenario (Allen, Dave Barry, Steven, and Andreas) Sep. 4 (Mon): No call (Labor Day) Sep. 7 (Thu): Roadmap (Chris), GGF18 prep (Tom and Hiro) <*ACTION ITEMS*> https://forge.gridforum.org/sf/go/wiki1569?nav=1 > From Aug. 21 call AI-0821a: Hiro to talk to Jun and CDDLM group about EGA & CDDLM comparison proposal. AI-0821b: Hiro to talk to Jem about EGA & OGSA glossary comparison > From Aug. 17 call AI-0817a: Dave Berry and Jay Unger will approach groups (GIN, Globus, etc) that have implemented practical grids and start a discussion on how they handle data: - how data is treated as a resource that can be scheduled - how transfers are modeled - how files are advertised - how applications find files (query, by knowledge,?) AI-0817b: Stephen Davey will do a cut down parameter sweep scenario focusing on the JSDL+BES+Data Transfer/Staging service > From Aug. 10 call AI-0810a: Donal to look into the relation of the EPS and CDL (retrieval, update, etc). (Eventually this should probably become a separate scenario.) > From Aug. 3 call AI-0803e: Jun will provide an example of the CDL mechanism and why using ID/IDREF is not a good idea. AI-0803f: Jun will update the CDL document to remove the Environment variables > > From July 20 F2F - EGR-WG (Ravi) will contact Geoffrey Fox and invites him to contribute use cases. - Andreas to go through the minutes and formulate a reply mail to Geoffrey on each artifact covered in these minutes. <postponed> - Steve McGough & Andreas to do a mapping from the current JSDL elements / terminology into the new information model structure (Proposed split into Description and Requirements) (from July 18th F2F, By GGF18 as original discussed.) ---- Hiro Kishimoto

1 0

Teleconference minutes - 21 August 2006
by Maguire_Tom＠emc.com 21 Aug '06

21 Aug '06

0 *H÷ 010 +0 *H÷ $Content-Type: multipart/mixed; boundary="----=_NextPart_000_002B_01C6C556.45071830" X-MS-TNEF-Correlator: C0E20DCC77C5C601 This is a multi-part message in MIME format. ------=_NextPart_000_002B_01C6C556.45071830 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit https://forge.gridforum.org/sf/go/doc13750?nav=1 Tom _______________________________________________ Tom Maguire Senior Technologist, Office of CTO EMC2 maguire_tom(a)emc.com +1(845) 729-4806 "The only difference between a rut and grave is the depth." - Ralph Waldo Emerson ------=_NextPart_000_002B_01C6C556.45071830 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+Ig4XAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgAQFAAAHwAAAAsAHw4BABIAAgH4DwEAAAAQAAAAGTFs0enA QU+TG+xdGMv50gIB+g8BAAAAEAAAAEcAeBfHkKxKr+8LploFF7ADAP4PBQAAAAMADTT9PwUAAwAP NP0/BQACARQ0AQAAABAAAABUlKHAKX8QG6WHCAArKiUXHgD6PwEAAAANAAAATWFndWlyZSwgVG9t AAAAAAsABIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwARgAggBgAAAAAAwAAAAAAAAEYA AAAAAYUAAAAAAABAABOACCAGAAAAAADAAAAAAAAARgAAAABghQAAAAjW6CkAAAALABCACCAGAAAA AADAAAAAAAAARgAAAAADhQAAAAAAAAsABoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAD gAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAGqACCAGAAAAAADAAAAAAAAARgAAAAAYhQAA AAAAAAsAcIAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAAAgEJEAEAAAD8EAAA+BAAABgmAABM WkZ1xkT3dgcABgEBC2BuZzEwMmY1AGQAcmNwDdAOADIdDGBjDUQBNAExc3Rz4mgFcGJjaBA1CQAQ x2ZoDrAQ1mJpAUMNpDPyMxLmZmUTYgH3AqQDY0cCABDACsBzZXQC0XAocnEyAAAqCqFuby0WICAN 8BdxNhNwMDWcMDQX8QHQF+A0fQdt3wKDAFAD1BXPFttiF7EYIP8XghzEGKAHEwKDGCAaHxsvrxw3 F+QcohigVgSQZABw4mECgzIzOBVeInMfcqIgB20gQ0UiJTkir6cYECPfJOV5ciIkNBoBuRV8MTYa ASc/A4JHCdF+ayi1DyApTyyRKo8DglTPCHAotROQEqFkaQM2KagMNzct3yTkKEhlYvkJcHcpKLUn ATAfMSQjz38ylgcQAaAOsDN2DhAsvjjWNjWvJORCB0B0DrAotV85MSleL+E5bzLDVgiQdPsiAAeB ZTN2IpEebCOoBxN9JTc0JdE/nSb3QRUoljX/Gg8qOEEUK9kPEUTfLcZBFH0vRzUv6ETtMXdBFDMM Ne8z+EreQJw3HDU4AUTtOSf7QRQ6ujU5MUTuPLZMVT5O/zygP28jqCG1JTY8oEIPJuj7WOcolTYp EkTvWH0r2Fyg/0ePLahY5i9GXKBRHzkYWOb/OrlcoFP/PJhY5lYMApEI5uo7CW8waU9lUPFqelDy /2tfbGhqZFDyau9uv259bf/nbC9qfxQwMjh0SnVhdR//dilqZHZSdL94j3hNd891//15xDkPIH0U fnF2k35wAoKpEFB5bAeQaAngdAAAenEDIWwSwQUQAUAD8GS4Y3RsCrGBUDcwcAEB7GF1OtAAYHMK sIGwHuBRgrJudW0CAGGCcHQybw1RanUQUAUQZ2hfgqAFEAoBgOAKAWkBkHA2MAMwACBsEMAesXMx /QMwYQExhsAL8CcAB0ANtf+AwYSAhjSF0YcTEycT6AjQ5wnANDCJE25wiWmLBAMw8HNuZXgfMAew BbAAwH8CcxbghnGF0Q1gNEA64HbnF1AQQB8QbWkSAI3wCfCkIESCVCBQCsBhCcBxgiBoIEYCIY0k EGAxdwBQEGADYHcLMISAAYBz4lc0MHRoQhOQhIAKsN2N8GwN4CKQkpRykwgNkFeSdgGAlHdilHdy knJj/mIKsCoglmIfYJbDAmALgGcJkZeUf/BwZZJxBPBlvGxsgWGSQJHhl/FzjkD/ACA6wZDxMzCT kJpWCVCadM8MsZqDgeCadGRnm1ac0PecVoZAmnR2AzCAr4G/gs//g9+E74X/hwKj8Ygdo0ENtP+J BBQihzGKbKcHqISMNZEg/45sjMQ9IAGggBCNJ4fhjei/pC2lfKCgCNAiYIwxYqDgPwmAAiCNon/h HwA0MDI25X5wN1ygIEiYgZtAC4D7LBONYzasj62frqqwIq+v/7C3kGCZEJGACYCxTzFgsn//hlcA UaU/GeQMAbU/jooQQD2xYXMCIEFBEEAFoG1w2xcysE5FAMADEFN/8jFg92hzFuALYHQJ8BBgf/Oe 8MxzZBBQB3BheKxgOTDbwnERUWsJgAEBMI0zaWBidgJRIHtVsbAXIHf/GaHEFLCRxJLFsyJwO3Ax gPWwgjg38DEnALCCx2BEoL8tsbCDsMAO8BOQyEQ3DxD7AFCwgjNKIMdgyNTJ4LDQ7jYOELCCKRAw DfA5MMsDzy2wF/DIJMvxNzkl0LCC7wHAygA5EM0FODWAnyHNIvYzyXDM5TjHYDkgxtR+cP4wAcDP tlEAzDUN4M4BKRH/x5MB0Mixx3XQIcoAyNQO8PcXwMrQ01Y3y2DOIMeEIoD3F+DVUNTlOcngDvDH hTygNz9Q01XJ8TlT4dc0OTT3sQDRFdhAOFEAzPQqMC/Q70Sg2VU1gHbgM9TVzNAYEP+xANrmysDa kMeE21Dakcd1/9ARF7DTVcrAxsDXxtwh1fH/xkSRIJMQsNDfZdYQQfDJhO/IgBfiy5QicDfYYDfx sIP/L9DOQOGGN/DH8cd0DgDTIX87cbCESiDLYMjVsNTGRDf/KjHlRrEA1JDZRdGhE4DNlV8X4Mzg 2FDK5MoANccwMv/M9MoAKkAlwOnVF+HM0MbU/xOAytA7cMuU68Cw8OuxyZT/4hA38Icx7PTWMdrF IoA5IP/T9iKA1hLNpCkQF8DpwMbU/yyA5oA38PCX3nHK5RggKkD/yBXr8eInO3DHMsz0P1BRAP81 gMmEP1A1gBfA79XgwN5Q/9kQ9ebXsAwBsIIYAPTh2GD/92ViYetFGADageDFDxCw0P/OsMuUSiDa oe2FSiDYUHbg//mVDxD7ccjUU+BB8NAwzPT/5EDc0dww92TVUBOAMXH+NP/5MdKF/zHYYA4B93PK wM1R//1VzOATcNewxbMqQNVQU+D/yCRfkenAM+ECtO+ArGDG1P/K0PThzVAEJfBRAEXeULDw/yyA yNTnUSow21AB5NqQ43L/ByXGoMzBAeTbUOjAIoHNE/+TENkQ1YXmgP9x1kX6Mcwh/8rk4hDrQDFg zlX1sS2wC5X/KkB+Yc2lzkAv0NNFzjGw0P9NkQ30i/A5EAuVz5HKoQ3l/9YQkxAPVczgzrDiEMbk 0DH/60DOVN8hzsDQVdqQy2DJUP/I1NqQkwGsYBPlxsAxcM8F/yXAF9HG1QUxEjfK0LEA7MX/7sDo wNwwFVXf8eFQyCTuwP/M0OrxxuTWEMzQB8XvgNtQ/+UQz7UOUNnBx3Qb0omAHNf/zrDXxeDAsMBi Yh50ygAxcP/NpH5wM+DYYB8VsMAKsRzV/87AiYABxQwR6wLPxADB6BH/0SWJcOIQKkHRNDkQN/DK Jf8P0y2w0RY5EP3BzaSHsf6h/+2FpuLZASen97Cm8tE0zsD/y3EkZtrAyeDiRYvw2dHgwP8m1vzx DxHRJusiKubHMYlw/ybVLbIz4NHVi/DYUF3gKuX/kSDz8dTG07DTQNww19V20f8xEi4168AeIS72 UQADATCW/wtQ9wHTVfZTkSEz9dex7AX/kSDYcR9xLjXuwC9h2VW8IP/akSbGMRH5MdKWx2DrQPgF /9OwsME1V8kykwI6dc9g3MH/PAf+wN9FyLHrwNYQN+YAIf8KoCrlRJEGIdHW77H9ET9G/9ewy2DS lgOxU+DR1vWR74D/0pYOQde3Q7H1gkNWJQE31//OIMahN+bZEByBQNUWseFg/wNFH4HO4dNGH5FZ 4OaASDb/1hEPRROB21Ey9tYh2fEq5f/J4ABAsPFLdv9xI4bJ4M4g/zRRS3bQwdpw1OVZ0QVB1OX/ zVBLMUw2zVDW0U6mysDGkv/VprEA7sBR5whB1kfowCwy/8eFM3HrQCbV8DEjUdHVJSD/0DDmgFUm TkHGwNlVJSDeUP+L8NfVA0AGEsd2/RHakNNV/y3hduDK1cfS9OFZNlJxCQH/XIfpp9axLuBjoMd2 3xEXUf9e+P3B1mbZEOI2x2D+wOjA/1hX2FD1oVUm17DacVbGysD/1XFA1fewAMHlRUvxy3Aw8f9l duOBQMbRAOvB1wewwczg/ybV0QAJ0Sx20QDQwRnFrGD/8oDHMDvmSoDbMTl2M5HYQf/XFhvxXSfD ELEAfnBpdlNS/zVm6yEy8Mng1yXPYNGx19f/1hDT9wtR17D+xcgBFqF+cf/ZdMrQcuHX1TYhJoDL hVZyhUMROY0zeG1sbsIA2cYRfVyf4LFhdzqxVRHddrNo6YKjkMCAcpzgJoB/XTF4MpOgeJaXYPJx eCNi7XnDZ6IQwcByo0GioL9Af5+wpjCfgZGAn7CbQZmAbrxiaqDQftCN8MOAXMUQVnjBoaIgeXzQ XIxwcP+AMLMwfeDFEKChm0Cg8H0gzmSQgKuwdjBiZJvQxRC7oPGY8GarMLUBgGFtfjDRlWBlXGir MHp9ApzQd3gyo3CB0WiAE3iBgdF2/4KpgWGiwKNwDDG74IMxhCW/KFKCcoFgdwCDI4Xzan4BH6aw kaB9AZhyJgB2aWX8d2uXwSrgh+KY4KEQp4F3d1F6QJ3iZZVgiUWAYG/joMCg8Gx5dMUwo3CBQP98 YYrXouDAgKIQoPB9MXYg/6LgolGXkbTwv0C7ELWQdiD/oNB2IJeUnvCK4IjRn7CrsH+RkYrRl5Gz MJ2BdiCakGvfgIGBQMUQkGGgIHCNQqnQf6PQoiCn8qNwmPKOEbdhZj2H8Gyq4cKQmQCgEXBwdnWS UKDCaaawkGYjsnL3inHltqngd5eRsFK1AMJQf8UQp/C3cKICkwB7kadwdAowxCJ3p/BmZm10l5MA uxC+UCDSUDNmdpC/wKCKYMCAiNCO4I3wdaPg77Qyn+GpsXtxZKVze2KjUv+p8KOQfNGM4L5QgUB7 Ypwi/6fyC0GbJKB0mkC/cHxjxMBnxDGhkHthbHZ4cJ+hdf5jgOCfoqPAszCgMogxwdG/UMGfoYEQ p1CfYZ+wdKoA+GEgLsFEn7YmAKBSuxH/oL+hz6LfoBAjkJ+wquB9IPekr6W/ps9slgCfsLnApG/7 qT+qRSmjLCrgqA+s/6ol+GIgKHWxri+f48Mgq8//sJ+xr7K/oAHU0LQSoJ+1f/+2j66dJtC0H7mv ur+7z6AB/yyAuK++T79fwGV2oYowdqDPfXCEYJuDmuFccXZwnBH/QNHG4XvBnUHGUpPAd4CeZf+U QYcAx6CBEMiimmDCAJ6A/5difLCNII2AfCCEQIzwxwHebpqRyvKXsHeAMJuAflBFvUBol+BjczGb gGH2ZpqQzLBzJ5GPAKnhKNL/m4PMJMvBzQPNZCOBzWKX8M3PU2OSAs8DbnDPWdD0/59hy/yGsMzy y8HOC4aw02L30EDMwYRgc+V6zCB6IOV5iiCM8HR+IDovL4BhmGdlLpICgGJtLtfBwi+fAC9nby99 AVChxfewP5Gwdj0xdbHSX8/Tb9R/1Y/WmA0KxVLfNv/FRMYPxx/IJ8m1yu7aTlUR/9tvl9FVEdzH zWXO9M/iJ5E1fUBwlWFm3U2fY2JrRG1rwkMgX03F0GzKQZdxU4RAfVSZ4No//9tD8rDbv+2i3QEV Qeff6O/93r5f8r/zz/Sa7G/Mge4N/+ef8G/xf9/y9b/tj+6f+C+3+T/exuwxIOtwerBpnPB130VT fNBpgNABAHtwaIuMsZHwacJALCBPmKAKaYOQIJeQIENUT//7P/a/98//L/nv+v/8D/0fx/4vB5/p u0VNQwnvCv/3DA8NHyeRc5pwduAOT97V/jIP/wVvBn8N3wifCaWTA/2YMmaTMN1Re5AWXxdvGH8D GY/pu0hZUEVSTGBJTksgInoQmPFvFjp6EAFzX5eAbUBl0G1jLmOZ4CIWTx4f7x8vID/db9ZjM13R LGDSEr2YUGSaIMywkxKbgGKEYAF1kCAA0MnqefkAus4RjIIAqgCgS6kLAgAtEAMtEQrgLB02LRFt AGEAAGkAbAB0AG8AIjous2cAdS7xcgDYZQBfLzMuwEAwUS7A+GMALjFRMMItEKMgG9L/kzAz8H7A HQ8RDxIagJES3/8nv+msI0/sQaMiJL8lzybf/zc/Gr8J3zPvEg88rz2/PsiIKzEohYA1KSBRkPw5 LWKwWSDfTT/vQP9CDOdC/0QPPsgiVImwA+CLgZ4gkjCYoJzhklEgYpgA9HdlfNAgqpCAgHuQhxGe IJIA2fAD0AMwIHRNgQOTQJFQaC4iIC0gclLI4iBXjwB74A+wbf124HNNsEefO19Kb0t/Po//3+/g /H1A4d/i7+P/2q9Tn//nT1VvVn9Xj1if4c/IX8lv/8p/XE/MhM3s3Rl3ENAglbA+MyvQ6oZ80etc YmZ9AAFucB4AcAABAAAAKAAAAFRlbGVjb25mZXJlbmNlIG1pbnV0ZXMgLSAyMSBBdWd1c3QgMjAw NgACAXEAAQAAABYAAAABxsV3y8DCEYPv4lhKO4lfWReqHE6yAAADACYAAAAAAAsAAgABAAAACwAB DgAAAAACAQoOAQAAAC4AAAAAAAAARwB4F8eQrEqv7wumWgUXsAEA/BVN2O91eUqHKwbLBDiXrwAA AAOsBQAAAAADAAlZAwAAAAMA3j+fTgAAAgF/AAEAAAARAAAAQzBFMjBEQ0M3N0M1QzYwMQAAAAAD AAYQJfv2pgMABxC/AAAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAEhUVFBTOi8vRk9SR0VH UklERk9SVU1PUkcvU0YvR08vRE9DMTM3NTA/TkFWPTFUT01UT01NQUdVSVJFU0VOSU9SVEVDSE5P TE9HSVNULE9GRklDRU9GQ1RPRU1DMk1BR1VJUkUAAAAAbeA= ------=_NextPart_000_002B_01C6C556.45071830-- Ê0=0ŠÍºVðßäŒTþ"¬³rªU0 *H÷ 0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0 960129000000Z 280801235959Z0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority00 *H÷ 0å¿m£Va-HqögÞ¹ë· ú8%¯Fåsš $] Ìen°ÐV¡sßŽX9knÁöÕšš?ª1¬°4×4g ÍâNEVixÚÜG)»6Éc\Åà×-{¡·2°{0º*/1ªî£gÚÛ0 *H÷ L?žÆhßîC3]éŠËMz3ÿô6Ø"6hl|BÌó.Ä?°OÿvùâŒJéÍ ÷Å)ñ"]ž±Ý#£{%F0yøêKÂÈã·ô@<Ã_SèHäŽ{¡5°{%ºžÓ«?84óÑq0b0Ë ÚÁ?« tzŽÎ.30 *H÷ 0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0 980512000000Z 080512235959Z0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated00 *H÷ 0»ZD»Uýz-Ox6ž J²oT¿Œèw*¹ðh»Ù1ApzK¹HV-ÇáB«À¢«D\ªBðé/ûÂ;»ŸÉ' ]¶°6B3µnTOJ¿Úùè¶ãÌÆj$ãüàeº§±~ïÉÛ7jÈJÈ ä£°00U0ÿ0GU @0>0<`HøE0-0++www.verisign.com/repository/RPA01U*0(0& $ " http://crl.verisign.com/pca1.crl0U0 `HøB0 *H÷ }oEK8 žÞéSd!ŒäL+þ@¬Ø 9j¡2!,«YþÒb}U8°7sÜôfcbœáSpRçšØRé[-ªáÞÏ¬1TÔÈØ#šï+2},È|š.wòDÑe MtµîÓst.;5rç@1Ó²Ä«çVŸãû00 aI±thÆãøSÈ¬1ÌÀ .0 *H÷ 0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated0 060419000000Z 070419235959Z010U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD(c)9810UPersona Not Validated1402U+Digital ID Class 1 - Microsoft Full Service10UThomas Maguire1"0 *H÷ maguire_tom@emc.com00 *H÷ 0«ŒåO!² cuû!ç_ãÚFÒWðçínøíy>ÏŒ³$"ÎñÜeq¶Úß©Çï«t úK?@K¬þ[REæâËH¶#»ÇS1w\¯lúèŸa7Š)ì_eÎËê66$±s²ùxT¿4×íËª/ç£µ0²0 U00DU =0;09`HøE0*0(+https://www.verisign.com/rpa0U 0U%0++03U,0*0( & $"http://crl.verisign.com/class1.crl0 *H÷ <¢A·ë¡ø'¿ÎáÜßTî$ñ<Ü{nDa6gWÛÈØ¿€«ÉšO³Eq!ÛÃnw) Žæ5ÜÊ£Á×eF¹Dö¬«úÄ()ÌLç£4œä×Å²AÿÅ,^56¥¢Ò°®oI÷ñ¿AÿæÅ1>0:0á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0 + ²0 *H÷ 1 *H÷ 0 *H÷ 1 060821231614Z0# *H÷ 1Kž{å¯ËÑÒêíÛÌ»ÊAê±Šé0g *H÷ 1Z0X0 *H÷ 0*H÷ 0 *H÷ @0+0 *H÷ (0+0 *H÷ 0ò +71ä0á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0ô*H÷ 1ä á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0 *H÷ aìtµÀÔv¢S×6fÇ7g¡hÅ ÙflNhÄ §Òu¡®Kí!M Ñï±3~èÐÑþ¬»øJ¯ežü¶'ŒaKÉpþ}êãËÚZÉJ>ùŸm}÷<hö2Ë¶~JXmSÊ+'&nè€{n

1 0