September 2006 - ogsa-wg

Inderpal Narang is out of the office.
by Inderpal Narang 09 Sep '06

09 Sep '06

I will be out of the office starting 09/08/2006 and will not return until 09/21/2006. I'm on a business trip to Korea/China

1 0

Re: [ogsa-wg] [ogsa-naming-wg] New Version of OGSA Naming
by Frank Siebenlist 08 Sep '06

08 Sep '06

Excellent - we're almost there! Just a couple of small issues: 1) Section 4 Endpoint Identifier Profile <quote> The EndpointIdentifier element MUST be included in the ENDPOINTREFERENCE wsa:Metadata element. The schema for an EndpointIdentifier is included in Appendix A." </quote> This is a little confusing because we could also have an EPI through the wsa:Address of a Web Service Endpoint Address Profile or we could add one in the reference properties. Maybe it should be something like "When an EPI is added to the Metadata element, then it MUST be according..." 2) Section 4 Endpoint Identifier Profile We should be able to have 0,1 or more EPIs added to the metadata element. 3) section 5.1.3 Fault Types <quote> /naming:referral-epr An EndpointReference, provided by the resolver INSTANCE, that references an alternative resolution service. The referral-epr element contains either a naming:EndpointIdentifierResolver and naming:ReferenceResolver element, as defined is section 5.2. </quote> This is a little confusing... I believe this implies that we use the exact same elements for the EndpointIdentifierResolver and ReferenceResolver EPRs as we use in the EPR's Metadata element... 4)section 5.1.3 Fault Types We should also add the option to return a referral EPI, i.e. an alias that in turn can be resolved to an application-EPR. In other words, the exact same EndpointIdentifier/EndpointIdentifierResolver/ReferenceResolver trio that we can add to a Metadata element could be returned as referral information (including multiples). 5) section 6. Web Service Endpoint Address Identifier Profile I don't believe it's clear enough that such an wsa:Address is a full-fledged EPI that can be used with the resolvers that we defined. Maybe we can change: This profile restricts the “Unambiguous Web Service Endpoint Profile” further, and defines the requirements placed on an EPR wsa:Address field (IRI) to ensure that it is unique in space and time, and that it by itself identifies the endpoint/resource. to: This profile restricts the “Unambiguous Web Service Endpoint Profile” further, and defines the requirements placed on an EPR wsa:Address field (IRI) to ensure that it is unique in space and time, and that it by itself identifies the endpoint/resource, and can therefor be used as an EPI with any of the defined resolver services. 6) Annotation of EPR with profile conformance claim URIs In some cases, we can infer the profile conformance claim from the EPR content, like: if the Metadata section includes an EndpointIdentifier, EndpointIdentifierResolver, or ReferenceResolver element, then it conforms at least to the "Unambiguous Web Service Endpoint Profile". However, we have no way yet to communicate any profile conformance claim in the EPR. I suggest to add another element to the EPR's Metadata section like: … <naming:profile-conformance-claim> xsd:anyURI </naming:profile-conformance-claim> ... such that we could have an EPR like: <wsa:EndpointReference xmlns:wsa=”http://www.w3.org/2005/03/addressing” xmlns:naming=”http://ggf.org/name”> <wsa:Address> http://tempuri.org/example_application/B94C4186-0923-4dbb-AD9C-39DFB8B54388 </wsa:Address> <wsa:Metadata> <naming:profile-conformance-claim> http://www.ogf.org/naming/2006/08/naming-wsepai-pf </naming:profile-conformance-claim> </wsa:Metadata> </wsa:EndpointReference> That's all! See you all in DC. Regards, Frank. David Snelling wrote: > Folks, > > Sorry for the large posting. The OGSA-Naming site is not allowing me > to post - maybe I just need to sign up as a GF member. > > Joel, Can you post both these documents in "Documents > Root Folder > > Current Drafts"? > > What I have done: > > 1) Accepted all previous changes. > > 2) Rewrote major sections (lots of out of date stuff about > WS-Addressing being pre standard etc.) > > 3) Reorganized the sections around the 4 specs outlined in the use > cases document, > > 4) Added the missing sections that were my action items. > > 5) Separated normative and non-normative parts of each section, see > subsections "Non Normative Discussion". These sections could probably > be extended. > > 6) I removed the SOAP message examples. These could go back in an > appendix, but they would be non normative (I don't like having too > much of this is a spec) and I wanted to get this out sooner. > > 7) Asked Michel Drescher to do a new set of schema and WSDL. > > There are two documents attached: > > 1) draft-ws-naming-August-2006-1-ct.doc: This has all my changes > tracked. This is provided for process reasons. I really expect folks > top start with the clean copy. > > 2) draft-ws-naming-August-2006-1.doc: I have accepted all my own > changes, since it is virtually a new document. People should start > with this, and use the above to identify things they thought were > there and went away. > > Enjoy! > > -- > Take care: > > Dr. David Snelling < David . Snelling . UK . Fujitsu . com > > Fujitsu Laboratories of Europe > Hayes Park Central > Hayes End Road > Hayes, Middlesex UB4 8FE > > +44-208-606-4649 (Office) > +44-208-606-4539 (Fax) > +44-7768-807526 (Mobile) > > > -- Frank Siebenlist franks(a)mcs.anl.gov The Globus Alliance - Argonne National Laboratory

1 0

Teleconference minutes - 7 September 2006
by Andreas Savva 08 Sep '06

08 Sep '06

Minutes attached. https://forge.gridforum.org/sf/go/doc13796?nav=1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference minutes - 7 September 2006 ============================================== * Participants Donal Fellows (UoM) Chris Jordan (SDSC) Hiro Kishimoto (Fujitsu) Tom Maguire (EMC) Mark Morgan (UVa) Takuya Mori (NEC) Andreas Savva (Fujitsu) Ellen Stokes (IBM) Jem Treadwell (HP) Jay Unger (IBM) Minutes: Andreas Savva * Summary of new actions AI-0907a: Hiro to add Chris Jordan to the list of people attending the F2F at the IBM facility. AI-0907b: Takuya will search for an external reliable source of strong (or deprecated) ciphers to reference. AI-0907c: Andreas will revise the explanatory text and send the new version to Takuya. AI-0907d: Takuya will update the documents and issue a final call on the list. (Probably during GGF18.) AI-0907e: Hiro to send an email to Greg requesting that the 'obsoletes' information be added to the document template. AI-0907f: Hiro to add an agenda item for the F2F to discuss a revision of statement R0711. * Aug 10 minutes approved with no changes * Aug 31 minutes approved with minor changes - AI-0831g is incorrect in the list of actions. The correct text is in the body of the minutes. * Action Items review [Only actions with updates are listed.] - AI-0831a: Done - AI-0831b: Done - AI-0831h: Mark is working on a document and will mail it out when finished; perhaps next week. - AI-0828b: Done * GGF18 & F2F update - The schedule on the wiki is up to date - Ellen Stokes is not available Friday afternoon. If there is a need for additional Information Model discussion the schedule might have to change. - Tentative day for the second dinner is Tuesday (after the OGF reception). Hiro will put details on the wiki. - Chris Jordan is also planning to attend the F2F. AI-0907a: Hiro to add Chris Jordan to the list of people attending the F2F at the IBM facility. * Security Profile review Reviewed revised versions uploaded by Takuya before the call. ** Secure channel review - l.232: "discourage" does not sound correct. - Agreed to Hiro's proposed revised text "Appendix D lists suites not meeting criteria of R0319 and R0320." - l.225: States that secure ciphers are 'mandated' but the compliance statements only say "SHOULD NOT". - Agreed that the compliance statements should be changed to "MUST NOT" - What is the definition of a secure cipher? Discussed whether it is appropriate to include a list in the Appendix given that this is likely to be obsolete. - Agreed to reference an external source, if a reliable one can be found. It is good to have a dynamic list. - If no such source can be found then the Appendix should be included (or even perhaps spawning another short document). AI-0907b: Takuya will search for an external reliable source of strong (or deprecated) ciphers to reference. - Title: Takuya proposed changing the title to remove 'basic'. The term "Basic Security Profile" has been defined in the OGSA WSRF BP but this profile does not expose the BSP claim as defined in the WSRF BP. 'Basic' in the title is not correct. - Introduction: Revised text to clearly state that this profile is not required by all ogsa services; it is recommended for those services requiring a secure transport. - l.135: Takuya reviewed the terms defined and confirmed their consistent usage. Also added citations at every usage. ** Core profile review - l.173: Added R0302 to restrict occurrence of keyinfo to exactly one - The explanatory text above the compliance statements is not correct. It should state that it "mandates that keyinfo appears exactly once" - Also the text has a few minor english mistakes. AI-0907c: Andreas will revise the explanatory text and send the new version to Takuya. ** Other comments - With the change to OGF there is a new template. The documents should be updated to this new template before re-submission. The new template includes the new OGF copyright. - There is a new namespaces document in public comment that changes the namespace uri to use ogf. It is not formally published yet so it is up to the Authors to decide what to do at this time. - For the references section see OGSA 1.5 for how to cite published GGF documents. Also some citations need update (e.g., WSRF BP has been published.) - Any remaining change requests (e.g., update the citations of these since they are cited by each other) should be marked in the document and noted during submission to the tracker. - Title change should also be noted in the submission to the tracker. AI-0907d: Takuya will update the documents and issue a final call on the list. (Probably during GGF18.) * Roadmap document review - Chris Jordan gave a status overview - Roadmap is close to completion - Received updated information on most documents; some data document entries have not been updated yet. - Integrating information about WS standards from Michael Behrens - Discussed disposition of published documents. Should these be in the Appendix? - It was noted that there many be many documents that will not be updated. It will end up re-doing document type structure in the back as well. - Published documents can't be deleted. The dependency information included in each entry is still needed, and also how they fits with other documents. - One idea is to exploit the ordering within each of the 4 sections. Keep published documents in the same section and ordering entries by hierarchy and completion status - What about newer versions? There should be only one entry that includes older version information. - There is still an issue if the newer version obsoletes a previous one (or other documents). Each document should say which documents it obsoletes. There are many examples of this in W3C or IETF. - This is not done with OGF documents because authors have not been asked to do so and the OGF document template does not point that such information should be added. AI-0907e: Hiro to send an email to Greg requesting that the 'obsoletes' information be added to the document template. * WS-BaseFault discussion Tom Maguire sent an email about this issue to the list: http://www.ogf.org/pipermail/ogsa-wg/2006-August/002037.html It is not clear what the meaning of the compliance statement in Sec.7.1.1 R0711 [WSRF BP]. Tom gave a recap of the 3 different interpretations listed in the email. The proposal is to revise the statement along the lines of proposed interpretation 3. (Make additional statements about the relation between BaseFaults and SOAP faults and under which circumstances BaseFaults should be used.) There was no quorum to reach a decision at this meeting. AI-0907f: Hiro to add an agenda item for the F2F to discuss a revision of statement R0711.

1 0

Re: [ogsa-wg] [OGSA-BES-WG] Tracker Resolution Descriptions
by Marvin Theimer 08 Sep '06

08 Sep '06

Hi; This topic got discussed at today's BES conference call and the reasoning for having a GetAttributesDocument operation in the core BES interface was re-derived from the previous time(s) that the topic was discussed. The argument goes like this: * Clients will want to retrieve some or all of the attributes that a BES exposes. If GetAttributesDocument is in a separate "rendering" port type that composes with the BES-Factory and BES-Management port types then clients will need to determine which rendering port type is actually available from any given BES. * In order to determine which renderings a BES implements you have to query it. That requires that there be some operation in the core client BES interface (i.e. BES-Factory) that will retrieve the attribute that describes which renderings are available by some means or another. (I can't actually find an attribute in the spec that exports that information, by-the-way.) * If that operation just returns the attribute that describes which renderings are available then the normal case behavior for a client querying multiple BESes in order to see what state they are in (e.g. to decide which is most lightly loaded) will involve two message round trips: one to retrieve the rendering information and one to then retrieve the desired attributes. That seems like a bad design from a software and systems engineering point-of-view. One might argue that clients will be written to amortize the cost of the rendering query over multiple attribute retrievals, but that presumes a fairly heavy-weight client model that may not be appropriate in all cases. Note also that BES service implementers will be implementing a retrieval operation of some sort that is rendering-independent in any case. So from an implementation complexity point-of-view, they have to pay the development cost of implementing some sort of retrieval operation in the BES-Factory port type in any case. * The only way to make this common case into a single message exchange is to have a single rendering that is universally implemented. Tom Maguire has pointed out that WS-ResourceTransfer has now been published and could be considered a candidate for such a universal rendering interface. But using this rendering interface implies that BES implementers must implement ALL of that interface in order to be able to employ its Get operation. Furthermore, they must do so in a manner that complies with the standard and its compliance requirements and tests (have those been published yet?). So, in order to get a simple Get operation, a BES implementer must also implement Put and Create operations, whose semantics are potentially controversial (I haven't read the new spec to see how they deal with atomicity questions of creating/updating multiple properties) and, in general, a spec that is 30 pages long - 46 pages if you count the appendices. That's arguably substantially more work than simply implementing a single GetAttributesDocument operation that is unencumbered by any other spec's requirements. * So, in order to enable BES clients to efficiently (i.e. using only a single message exchange) retrieve all the attributes of a BES without having to require BES service implementers to implement a non-trivially sized second spec, most of which is not necessary for BES, it was decided to include a GetAttributesDocument operation in the BES-Factory port type. * Inclusion of this operation makes the BES specification inherently resource model-free, but it does not preclude a BES from redundantly exporting its attribute information by means of other (composed) rendering port types, such as WSRF, WS-Transfer, or WS-ResourceTransfer as well. This would allow clients that wish to exploit the reuse possibilities of such renderings to do so while imposing only a very minor additional service implementation burden for BES implementers - namely to implement the GetAttributesDocument operation instead of a GetRenderingAttribute operation. Marvin. -----Original Message----- From: ogsa-bes-wg-bounces(a)ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Peter G. Lane Sent: Wednesday, September 06, 2006 10:51 AM To: Mail list for ogsa-bes-wg working group Cc: ogsa-bes-wg(a)ggf.org Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions Christopher Smith wrote: > Characterizing this issue as WS-RF vs WS-Transfer is misleading. I can't > recall any discussions within this group where anybody advocated doing a > WS-Transfer rendering for the BES interface. Well ... other than the WS-RF > proponents who wrongly assumed that because some (like myself) were against > the use of WS-RF, that must mean we were in favour of WS-Transfer. I also > don't recall anybody advocating operations for modification, etc such as > defined within WS-Transfer. To me this is a discussion of a resource > modelling approach (built on WS-RF) vs a non resource modelling approach. Just for the record, I wasn't trying to make this into a fairness issue between WSRF and WS-Transfer just because WSRF isn't being equally represented and I'm from the WSRF camp. If some WSRF-like operation was included I would have asked the same question. I also did bring this up before the tracker existed, but nobody seemed interested in discussing it then. That said, whether a discussion was had or not, having this operation makes WS-Transfer partly redundant. That's my main point in all of this. It seemed silly to have two operations doing the exact same thing when minimal interop IMHO doesn't warrant it. In other words, it was a cosmetic gripe. > > My main reason for not wanting to make use of one of the resource modelling > approaches has to do with the burden of implementation. If Platform buys > into one of these resource models, we no longer have to implement one simple > spec and test compliance of that specification, but we need to implement and > test compliance on a suite of specifications, for (in my opinion) no extra > benefit. You might say that once you've implemented a resource modelling > suite of specifications, you can use it over and over and thus amortize the > cost of this implementation. But even at a small cost, it's not one that I'm > willing to take, as the implementation of standards specifications is one > feature in a sea of features that we implement from product release to > product release. Fair enough. Out of curiosity, though, if WSRF and WS-Transfer get reconciled, does this mean Platform will still opt not to implement a second spec? If on the other hand they would be willing to implement such a spec, would they be ok with deprecating the GetAttributesDocument operation at that time? Peter > > -- Chris > > > > On 06/9/06 07:56, "Peter G. Lane" <lane(a)mcs.anl.gov> wrote: > >> If it's about fear of reopening the dialog, then I'd appreciate if someone >> could at least add >> comments to the two trackers addressing the issues raised. >> >> Ian can push for reopening this particular issue if he wants; but I just want >> to know why we're >> advocating WS-Transfer in spirit if not in name, and why aggregation of >> resource attributes is not a >> concern to anyone else. As long as someone has a reason for these issues that >> I raised in the >> tracker, I'm fine. I don't expect to get everything to go my way, and I'm open >> to being convinced of >> alternate points of view. I just don't like being ignorant, especially when >> I'll have to implement >> the spec someday. >> >> On the other hand, if nobody has a good answer for the issues, I think Ian is >> perfectly valid in >> asking for it to be reopened as apparently the issues weren't actually >> addressed as they should have >> been. >> >> Peter >> >> Mark Morgan wrote: >>> Well, I guess the thing that confuses me is whether or not it is SOP to >>> re-open an issue that was discussed previously because a new person has >>> re-raised that issue. I'll bow to whatever the majority thinks is best of >>> course, but it seems to me that you can't reopen an issue everytime a new >>> person re-raises it or you risk the possibility of continuously cycling on >>> it. New information should always be considered, but if an issue gets >>> re-raised that has already been discussed fully and voted on, then it >>> doesn't make sense to re-discuss it. Just my 2 cents worth... >>> >>> -Mark >>> >>>> -----Original Message----- >>>> From: ogsa-bes-wg-bounces(a)ogf.org >>>> [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster >>>> Sent: Tuesday, September 05, 2006 9:39 PM >>>> To: Mail list for ogsa-bes-wg working group; 'Mail list for >>>> ogsa-bes-wg working group'; ogsa-bes-wg(a)ggf.org >>>> Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions >>>> >>>> Mark: >>>> >>>> I guess that I am asking that we re-open the issue, then. >>>> >>>> Ian. >>>> >>>> At 07:47 PM 9/5/2006 -0400, Mark Morgan wrote: >>>> >>>> >>>> I'm not sure what level of "addressing" is meant here, but my >>>> recollection/belief was that it was addressed in the >>>> group in so much as the >>>> topic was discussed at the last face-to-face and that >>>> the appearance of the >>>> GetAttributesDocument was the result of that >>>> discussion. We haven't as a >>>> group discussed the email that Peter sent out yet but >>>> it is my belief that >>>> doing so is essentially a rehash of discussions previously had. >>>> >>>> -Mark >>>> >>>>> -----Original Message----- >>>>> From: ogsa-bes-wg-bounces(a)ogf.org >>>>> [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster >>>>> Sent: Tuesday, September 05, 2006 1:42 PM >>>>> To: Mail list for ogsa-bes-wg working group; >>>> ogsa-bes-wg(a)ggf.org >>>>> Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions >>>>> >>>>> Has Peter's comment been discussed? >>>>> >>>>> He advocates (I believe) that we should not include the >>>>> GetAttributesDocument operation. Instead, any particular BES >>>>> should choose (if they wish) to provide access to attributes >>>>> via an appropriate resource model-specific operations. >>>>> >>>>> * A WS-Transfer-based BES would use GET >>>>> * A WSRF-based BES would use WS-ResourceProperties >>>>> * A resource-model-free BES might define a >>>>> GetAttributesDocument operation >>>>> * etc. >>>>> >>>>> This seems a good proposal to me. >>>>> >>>>> Ian. >>>>> >>>>> At 03:09 PM 9/2/2006 -0600, Peter G. Lane wrote: >>>>> >>>>> >>>>> 2) Why are we still essentially advocating >>>>> WS-Transfer's attribute model by having the >>>>> GetAttributesDocument operation? In my opinion it is not >>>>> necessary for minimal interop, and makes WS-Transfer's Get >>>>> operation redundant. Is part of the problem that we haven't >>>>> defined any interop standards yet? >>>>> >>>>> >>>> _______________________________________________________________ >>>>> Ian Foster -- Weblog: http://ianfoster.typepad.com >>>> <http://ianfoster.typepad.com/> >>>>> <http://ianfoster.typepad.com/> Computation Institute: >>>>> www.ci.uchicago.edu <http://www.ci.uchicago.edu/> >>>> <http://www.ci.uchicago.edu/> & >>>>> www.ci.anl.gov <http://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/> >>>>> <http://www.globus.org/> >>>>> >>>>> >>>>> >>>>> >>>> -- >>>> ogsa-bes-wg mailing list >>>> ogsa-bes-wg(a)ogf.org >>>> http://www.ogf.org/mailman/listinfo/ogsa-bes-wg >>>> >>>> _______________________________________________________________ >>>> 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/> >>>> >>>> >>>> >>>> >>> -- >>> ogsa-bes-wg mailing list >>> ogsa-bes-wg(a)ogf.org >>> http://www.ogf.org/mailman/listinfo/ogsa-bes-wg >>> >> -- >> ogsa-bes-wg mailing list >> ogsa-bes-wg(a)ogf.org >> http://www.ogf.org/mailman/listinfo/ogsa-bes-wg > > -- > ogsa-bes-wg mailing list > ogsa-bes-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/ogsa-bes-wg >

2 1

Will be dialing in late around 10PM ET <EOM>
by Maguire_Tom＠emc.com 07 Sep '06

07 Sep '06

0 *H÷ 010 +0 *H÷ $ëContent-Type: multipart/mixed; boundary="----=_NextPart_000_0003_01C6D25E.CF526480" X-MS-TNEF-Correlator: E07D625680D2C601 This is a multi-part message in MIME format. ------=_NextPart_000_0003_01C6D25E.CF526480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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_0003_01C6D25E.CF526480 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IgcNAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgBcFQAAHwAAAAsAHw4BABIAAgH4DwEAAAAQAAAAGTFs0enA QU+TG+xdGMv50gIB+g8BAAAAEAAAAEcAeBfHkKxKr+8LploFF7ADAP4PBQAAAAMADTT9PwUAAwAP NP0/BQACARQ0AQAAABAAAABUlKHAKX8QG6WHCAArKiUXHgD6PwEAAAANAAAATWFndWlyZSwgVG9t AAAAAAsABIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAAAwARgAggBgAAAAAAwAAAAAAAAEYA AAAAAYUAAAAAAABAABOACCAGAAAAAADAAAAAAAAARgAAAABghQAAAAjW6CkAAAALABCACCAGAAAA AADAAAAAAAAARgAAAAADhQAAAAAAAAsABoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAD gAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAGqACCAGAAAAAADAAAAAAAAARgAAAAAYhQAA AAAAAAsAcIAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAAAgEJEAEAAAA+EgAAOhIAAIgoAABM WkZ1DYPqTQcABgEBC2BuZzEwMmY1AGQAcmNwDdAOADIdDGBjDUQBNAExc3Rz4mgFcGJjaBA1CQAQ x2ZoDrAQ1mJpAUMNpDPyMxLmZmUTYgH3AqQDY0cCABDACsBzZXQC0XAocnEyAAAqCqFuby0WICAN 8BdxNhNwMDWcMDQX8QHQF+A0fQdt3wKDAFAD1BXPFttiF7EYIJ8XghzEGKAHEwKDMzcaH18bLxw3 F+QcohigVgSQZNUAcGEd1DgVXjIich9yoiAHbSBDRR3UOSKfpxgQI88k1XlyAoM0GgG5FXwxNhoB Jx8DgkcJ0X5rKJQPICkfLFEqXwOCVM8IcCiUE5ASoWRpAzYpeA43HjEtvwOCKEhlYvkJcHcpKJQm 4S/PMNQjv38yRgcQAaAOsDMlDhAsfjjWNjVPJNRCB0B0DrAolF84wSkuL5E4/zJzVgiQdPsiAAeB ZTMlIoEebCOYBxN9JSY0JbE/DSbXQIUodTX/Gg8qCECEK6gPEUQvLYZAhH0vBjUvmEQ9MSdAhDK7 Ne8zmEoOQAw2uzU3kUQ9OLf7QIQ6STU4wUQ+PDZLhT3P3jA+3yOYIbVA1zBBbybI/1fnKHdEDyoI V+YrqQ7wW9/3LXdX5i8HMVAvOKhX5jpKfyoAYZ88J1fmVQwCkQjmO9UJbzBoT2UOADVpemqR/2pP a1lpZGuCae9tv219bP/nay9pfxQwMjhzSnRhdB//dSlpZHVSc793j3dNds90//14xDkPIHwUfXF1 k31wAoKpEFB5bAeQaAngdAAAenEDIWwSwQUQAUAD8GS4Y3RsCrGAUDbQcAEB7GF1OmAAYHMKsICw HuBRgbJudW0CAGGBcHQybw1RanUQUAUQZ2hfgaAFEAoBf+AKAWkBkHA2MAMwACBsEMAesXMx/QMw YQExhcAL8CbgB0ANtf9/wYOAhTSE0YYTEycT6AjQ5wnAM9CIE25wiGmKBAMw8HNuZXgfMAewBbAA wH8CcxbghXGE0Q1gM+A6cHbnF1AQQB8QbWkSAIzwCfCkIESBVCBQCsBhCcDxgSBoIEYCIYwkEGBb sTsQYANgdwswg4ABgHNX8TPQdGhCE5CDgAqwjPDubA3gIoCRlHKSCA2QkXYrAYCTd2KTd3KRcmNi /wqwKfCVYh9glcMCYAuACZEzlpR+8HBlkXEE8GVs3myAYZFAkOGW8XONQAAg/zpRj/Ey4JKQmVYJ UJl0DLHnmYOA4Jl0ZGeaVpvQm1b7hUCZdHYDMH+vgL+Bz4Lf/4PvhP+GAqLxhx2iQQ20iAT/FCKG MYlspgenhIs1W7CNbP+LxDygAaB/EIwnhuGM6KMtt6R8n6AI0GY8kBBAYp/gfwmAAiCMon7hHwAz 0DrwMOI3LXA2IEiXgZpAC4D/K+OMY7Agq5+sr625ryKur/+vt49gmBCQgAmAsE8xELF//4VXAFGk PxnkDAG0P42KEEA9sGFzAiBAsRBABaBtcNsXMq9ORQDAAxBTfvIxEPdncxbgC2B0CfAQYH7znfDM c2QQUAdwYXhhcDjA28FxEVFrCYABATCMM2hgYnYCUSB7VbCwFyB3/xmhwxSvkcOSxLMjkDrwHjBZ xVM2Njixr4I4N4Ax/ybgr4LHAEPwLXHFU7AQDvC7E5DH5DcPEABQr4IzSVDHxwDIdMmANjk2DhCv g38N4A3wxnQ68AHQDxHLVTfmOSWwr4M4OMmgyoQBwHfJoDigzVU4NSCeIc1yM/vJEMyFOMcAOLDF 1H1wr+D/yODQFVAQy9UN4M5RKOHHM/8B0MhRxxXQccmgyHQO8BfA+8pw06Y3ywDOcMckzxHI4N/R ZSJwF+DNENU1OcmAXqHfxzQ8ID7A06XJkTlS4dhE7Dk0r/HY9jhQEMyUKgD3E3BBUNOlNi+AQ/Da ZTUg93XgHiHcBDkYEK/w3LbKYP/cYMck3SDcYccV0GEXsNOl/8pgxcDY1t3x1wHFRBfw2LH/4SfM gNaVyRCSAcpQ4rXXIP9BUMkkyCAX4sZ0zbGv4NvV/SOQN9lwN4HFUy+AzpDk1v83gMeRxxQOANNx OvHF9ElQ/8sAyHXlgCoQ6VfFwOJRxUT/xtATgM3ldeDMgM8QxnQX4N/MgNlgyoTNIcbQMsyUyaD/ KhAloO3lF+HMcMXUE4DKcP868OxlL4AvgMpgyTTMUe/B/8k05iA3gIYx8cXPAe9lyPD/yFHzJjwg ynDHxCJwOLDURv8icNcizfRWEc8hy+Xawe3Q/8XULEDlgDeA96fgQcqF3HH/2LHKlBgg7ZH2JRgg KhDHtf8zgK/wF9HLRa/jy0XbkOZG/8Wx1mHL5sbSzJUBwCxA6JX/8uLJoMvl2jAN8cqF2jE1IP/J JD7ANSAXwPYl5BDGQNog/wL22MAMAa+CGAAB8dlwBHX/25DZUAUm3FHkFQ8QylDPAP/GdElQDADs EAalzxDNEPJV/0lQ2WB14AalDxAJQch0UuD/QVCv4MyU6FDeocZQBHTNEP8TgDEhDAQGQdLVDQH/ gcqE/9lQxcAjkAslzIATcPnVKhD/zRBS4MfELXDaINcgxnTbkP/IINlgxxTbkAgB+FUK0dOQ/9Tg D7QB4tXVynD3YQ4VxkD/yOAsQMh06qEqAN0gFbXgIf/N5d4B54IXNfCAzGEPtN0g/1jgInHNY4hw 05Cv4Bl17BD/zQHNVDEQ8IDXVQdBy8HNRf8o4A+BHGbI8BcG5iDvUDEQ/86lAsEtcM1FKhB9Yc31 zpD/L4DTlc6BylBMsSBEivA4oP/NRc/hykEgNdcgViAhpcyA/88A5iDGhNCB71DOpODxzxD/0KXc YMsAyPDIdPahViDNNf8LsTEgCxULstogJKXhEPwB/yYlBwEcIcaEFIEkh8pw9FL/xoTNoH1g5YDG hM6Q3fEnpf/jQf5GzQDMcO8BxoTXIMxw/wFV7BHksNyV3SHbkccUMGL/iIAxZ88A2NXdINuQ26HQ FP/UAQWhM7XJoAyQzfTkEM/h/xHVfXAR0B2R0BXbkNQAMWX/AGEPhu0BxlDsENAUynDTkP/4VR5h 7xLQFA6R62HRdYhw/+YgXOHRhNQA2IHaZSIx5lD/ycUiI1/Q0WZikAuRzfSGsf9sAfnVhrEMcfJV peLaEUDX/wTApfLRhDTh1NFChrsgyDH/QoYyseZVivDtwO2hOybbof81gdF1CsEhYdF27zJABsbR /4hwPzVIghHQ0iWK8NlgXOD/QAVbsP7B1RY8ce/QxmVLwf/2ofGVW7Dv0DKxScYwgdpH/2FwIZAm Bluw+/AEEdOlA2P/W7FPldjB8BVbsK/xEyFJBf/P åsBDBxxVikCIRzIVT4vsQ/0DGU/EhgT81B+F1 4D8mS+H/BkHS5scA71AFFTxzGqHSNf8HEVD3yNKSAllVz7DekVrn/wyQPLY34UTB0WU34S4hXHb/ +xEEwV4m7aBYSP+B8IBe5v/G8BVx0ib2AQrhYJbYwMsA/9Lm2hEW0dO205AR0F1GEkH/whDSJspw 1mLUduSh7aDUdv9MIOwQ0uYgkdjHaEECkmfm/z1hVEbOYcWhXHbaIDERQ0X/GgHksBHVNNHPMdOW NOHhEP8s1TTRDFEhlTTR1yFvFymR/8bh1TXG8OGicNYKIOqBcNb/DUE7FsmAY5Hs0HDW0RHcQP/V Nd+Q2MFr5s2gcJFxls2g/9fhdAYxAjOV1wHZkMWh1rb/r/A4xtcBGFHXV+zQRwLHJf9WUorwe2ba QTUVe7HgIdIW/yCwr+DlgHtWOYFHN9uhz+H/f2fGQIrw2OVkcRVxxxbP0f/ZcNUlEdDektOlSLEg EMp1/8dyAfGBBnihGRGFJ+2318H/0hCCYdd2J4HflofyC5HXdv9jgUTWgoHs0IAn2WACsXtW/9jA 3EF9xtjAg1GDdspg1oH/Q0UEwDWS1SUEwA6R6VVxUf/LEEvBj7bnkWIWyQEW0pFW/+/R2BcHEeJx kVYaoUdGBED/0RH+VUqA9oH2gZVm3QFXhv9PMdlR2CYwgYXH0TEQEZSG/xbB9tCZZzjBUQZy4vah mxb/jBF4Bu2gPUFTQJy2VAE75v/iYe/R2ybiUehQ1SXLoezB/z5l35BegT2GynAQ4aF39IF/2uDY 5VHBPuDLJX1yKOE5YarzeG1sbsEAxRF96FxwYbBhd1mRe0Gl045o7ZJDQL+AcmdsPuBrhdGnUnKn p3SBYac0YtGo42d1dMDAckNAuhHpvkBjdLnwdztgtnCqoMOwgLrAdG5iarLgwNArwsDCgFzEEHjA oXRvAnnA0FxleHBzaH+yMK0AxBC0AKtBvTCsQGTHwODFEKVQYmRirFG9MGRhY8Lgb3K0Aa+BbaOt ULgAZVxor5B6rCLcZGenUrcQsPForzOnoe2w8XaxybCBabFRHoG64P+yUbNFKQKxkrCApiCyQ7UT +mqtIWGsAK5QwoC/0L1AwT5gdmlld2uxYASwX7bzveC9oMAAhdFwqWByOmSm0GWwQLhlr4BvdPG9 IWx5dMQwsWCwYKuB+bn3aHS/gKngvTCsUa6gy7tAsEBqxQFcdb5AreD+YrgArQC9AcUBt1HCMLoA 97fxqqDFEHe9w8UBrXCoIPPCMKugcmuvobBgxBC/gch3cnC8YnNupqCswG+oIDtgs4CvYGyvwLgA bPXEIGa3EGywUKwAvLGq0NnAYHB1wXC5sGHRkLYwu7+GO0JyuZH8hrpQd6Vx9aVgea+hc6xRqCCr ELtxhm/CIKqxZmV0MKTiwneoIGZmbXTCIK3g5aYAINKgM2alsMgQuYDPqTC38L4ArqB1cKozppD3 yFC5wKqRZKrAqlWqQLpB/nhDQKvxvACmALBgqoLLQv/BIhwRykSvcLtwreDJYLnANauDIKTicKVQ qpBsdvOnkM7BdWOwAM7CvCCtcHfPUrdRrPB0diHOwbAwbiZnzoHO0HR4vCAgLv59pNPO1j5gz3Kt 4c/f0O//0f/PMDsgztCwUKxA08/U3/3V72xA0M7QvjDTj9hf2WU+KdJMQADXL9wf2UViIP4opNHd T88DTDDa79+/4M//4d/PIXTQ4zLPv+Sf5a/dvf8/MOM/6M/p3+rvzyE8wOfP/+1v7n/vhaXBuKCl wKyQs4DzyqPKAVxxpZDLMUNB9gH/quHMYfVywFCmoM2Fw2GmkP/2wLAw98LJgPEgzaDGgqvQv7xA vKCrQLNgu0D2IW6qMXf6EsbQpqAwqsCtcL4waJGv0GNzMarAYWZDQP370HNAwbgA2QFCAsqj+0R/ +uH8I/yEOxH8gscQ/nNj88Ei/iNucP55ABTOgfsc/7XQ/BL64f0rtdACgv9g++F9s4BzO0LExvtA p2AEmSD8DQr0cgZG9GT1L/Y/90f/+NX6DgFeMJECf8bxMJED11/8hf4U/wJAwaxgcMSBZkMEXc6D Ymtta/FjIKRfTfTwbEHGkVOzYPx9VMkApNEBf/wgU0ACz78UsgQRSoEO7w//Bc5fGc//Gt8bqhN/ +6EVHQ6vF38Yj/8HAhzPFJ8Vrx8/IE8F1hNBtiASgKnQacwQBlVTrPBuaa+QKBCqkGi70cEQaVGl YCwgT8fAaa9gIOHGsCBDVE8iTx3PHt//Jj8g/yIPIx8kLyU/Lq8Qy/hFTUMw/zIPMx80L0DB3nPJ kKYANV8F5TI3Dyx/vy2PNO8vrzC1wiOk4mbCUH8EYaqwPW8+fz+PQJ8Qy0gAWVBFUkxJTkvMICKp MMgRbzqpMCiDAl+swG1AZW1jLvpjyQAiPV9FL0Y/R08Ef98Fg4ghUpALkqUAZKyg+9AbwjKqwGKz gKSwIADQAMnqefm6zhGMAIIAqgBLqQsCqgBUEANUEeBTHTZUEQBtAGEAaQBsACB0AG8AOlWzZwCC dVXxcgBlAF9WM41VwEBXUVXAYwAuWFH/V8JUENJAQuLCUFrwreBEH/84Hzkqr7E5707PELxKXxNR /9JCS89M303vXj9BzzDvWu+POR9jr2S/ZcgrMSi0oMg1KSB28Dkti1B/QH8GXWbvZ/9pDGn/aw9l yCLuVLjQKvC6oSDBUMfAzAFJwXEgYscgd2Ws8CAv2bCvoKqwtjEgqCBhdnMq4CpAIHR0gbBQwHBo QC4iIC0gUvgCIK5XuACrADbAbaYAc3Sw/26fYl9xb3J/ZY8G/wgMrGD/CO8J/wsPAb96nw5ffG99 f/9+j3+fCN/3f/iP+Z+DT/uk//0MBCmmMP9AlHCZUBGHq/ETEmyJZn0AlXAAAB4AcAABAAAALQAA AFdpbGwgYmUgZGlhbGluZyBpbiBsYXRlIGFyb3VuZCAxMFBNIEVUIDxFT00+AAAAAAIBcQABAAAA FgAAAAHG0oBWRyGIqEGovUCyt5p5ug5MZ0wAAAMAJgAAAAAACwACAAEAAAALAAEOAAAAAAIBCg4B AAAALgAAAAAAAABHAHgXx5CsSq/vC6ZaBRewAQD8FU3Y73V5SocrBssEOJevAAAAA6wFAAAAAAMA CVkDAAAAAwDeP59OAAACAX8AAQAAABEAAABFMDdENjI1NjgwRDJDNjAxAAAAAAMABhDVPjhZAwAH EJEAAAADABAQAAAAAAMAERAAAAAAHgAIEAEAAABlAAAAVE9NVE9NTUFHVUlSRVNFTklPUlRFQ0hO T0xPR0lTVCxPRkZJQ0VPRkNUT0VNQzJNQUdVSVJFVE9NQEVNQ0NPTSsxKDg0NSk3MjktNDgwNiJU SEVPTkxZRElGRkVSRU5DRUJFVAAAAABWXg== ------=_NextPart_000_0003_01C6D25E.CF526480-- Ê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 060907132007Z0# *H÷ 1" Qæ÷bJ¬z2 ÊåYþ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÷ _F0³Ó63RÄ]lï(÷Þ|Š\ß8íÉuC=jÀ³³+H·|b÷'[€C)F*YŠßö#Q(MUM TÛ Ù¶µ4ÿ7pU²Hu ÂSÖÇ¶Æ ]öè HpaCäßÐAñR=é(€IÄÀ

1 0

Proposed agenda for Sept. 7th call
by Hiro Kishimoto 07 Sep '06

07 Sep '06

Hi all, The following is a proposed agenda for OGSA-WG telecon on Sept. 7th 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: 0907 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 (Aug. 10 and 31) - https://forge.gridforum.org/sf/go/doc13785?nav=1 - http://forge.gridforum.org/sf/go/doc13776?nav=1 Action Items status review (see the bottom of this email) Agenda bashing 2) GGF18 and F2F meeting update (if any) 3) Basic Security Profile Public Comment Review (Takuya, 30 min) Takuya will update the documents before the call. Review ciphersuites list Takuya already sent out. 4) Roadmap document discussion (Chris Jordan, 30 min) Status update and discussion. 5) WS-BaseFault discussion (Tom, 30 min) Tom will send out open issue summary. Related Marvin's email http://www.ogf.org/pipermail/ogsa-bes-wg/2006-August/000353.html 6) Wrap up (10 min) AOB <*NEXT CALL*> https://forge.gridforum.org/sf/go/wiki1477?nav=1 Sept. 11-14 GGF18 Sept. 14-15 F2F <*ACTION ITEMS*> https://forge.gridforum.org/sf/go/wiki1569?nav=1 > From Aug. 31 call AI-0831a: (A Savva) Merge and publish minutes for the call on 10 August 2006 AI-0831b: (H Kishimoto) Send CDDLM & CDL working copies to Andreas as they are slightly different from the versions in this draft AI-0831c: (A Savva) Update/rewrite secction 4.1 of the EMS Architecture scenarios AI-0831d: (A Savva) Add the Application Version in section 4.2, paragraph 4, of the EMS Arch Scenarios AI-0831e: (A Savva) Talk to ACS working group for refining this scenario. AI-0831f: (A Savvva) Research RNS and probably update the EMS Arch Scenarios document AI-0831g: (A Savva) List of open issues, scenarios and refinements for the EMS Arch Scenarios document AI-0831h: (M Morgan, A Grimshaw) Provide an outline sequence how BES, ByteIO, RNS, etc. are combined together at University of Virginia > From Aug. 28 call Action AI-0828a: Frank will do more investigation, read the paper, and make a proposal. Action AI-0828b: Takuya to update the Auth-Z proposal minutes and pass them to Andreas. > 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,?) (Postponed until GGF18) > 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