OGSA Teleconference 20 December 2004 ==================================== * Participants Jay Unger (IBM) Steve Tuecke (Univa) Jem Treadwell (HP) Dave Snelling (Fujitsu) Chris Smith (Platform) Andreas Savva (Fujitsu) Steven Newhouse (OMII) Tom Maguire (IBM) Hiro Kishimoto (Fujitsu) Dave Berry (NeSC) Minutes: Andreas Savva * Summary of Actions Action: Hiro to confirm Andrew Grimshaw's availability for Jan 25, 26 @London. - A statement about conformance should probably be included in the Profile template document. - Tom has the pen on the document; add and re-post it - Next step: Work out a draft base profile template - Action: Hiro to produce new GGF13 session schedule and review again. - Action: Design team leads to list what WGs or other activities they do not want to conflict with at GGF13; Send to Hiro. * Next teleconference on Wednesday - This is the last call of the year. - Agenda: Introduce revised glossary and version 1.0 and invite people to review it by the first call of next year. * December 15 minutes approval (revised version) - Disagreement with some conclusions in the minutes. In particular "consensus ... widely adopted by industry ... " - Clarified that minutes are a record of last time's discussion and approval only relates to their accuracy. It is acceptable to raise topics for discussion again if there is disagreement. It should be possible to do so later in this call. - Revised minutes approved with no changes. * F2F meeting planning - Re-visited date and place decision. - Jan 26-28 (Chicago) - This was last call's consensus. - Jay and Steve T have a conflict and cannot make it. - Agreed that it is still a possibility given that Tom and Ian can make it instead of Jay and Steve T. - Jan 31 - 1 Feb (Chicago) - Steve T can make it; Ian cannot. - Conflict with UK E-Science meeting. Also not good for Dave S & Tom due to conflict with WSRF, WSN F2F. - Rejected. - Week of GlobusWorld (Feb 7-11) - Re-considered 7 & 8 Feb; arrange to have Globus team only on the 7th. - Rejected since Steve T had reservations on how much time he could commit. - Also re-considered and re-rejected the weekend before GlobusWorld. - Proposal for Jan 25 - 26, @London - No conflicts for people on the call. - Not sure about Andrew's availability given the PC meeting at Chicago later than week and the UK e-Science meeting the week after. - Current order of preference: 1. Jan 25, 26 @London 2. Jan 27, 28 @Chicago Action: Hiro to confirm Andrew Grimshaw's availability for Jan 25, 26 @London. * SAGA-WG F2F report - Simple API for Grid Applications - Distributed F2F using Access Grid. - Chris participated as OGSA-WG rep. - Planning language bindings for "usual suspects" - SAGA group is not trying to define an architecture; just a 'view' in the grid world - First step to look at what people have been doing so far. SAGA-WG members looked at OGSA-WG use cases since it is an existing document. - The OGSA use cases are more abstract than SAGA expects. Thought about putting them into SAGA format but gave up because of the EGR use case handover discussion. - SAGA focus - Files (physical & logical) - Job submission - Data streams - After the F2F people are working in smaller groups and will bring results by next SAGA call - Does file handling API include posix API? - Yes. There are two parts, metadata (directory) management & file access - Data team planning to have a look since it looks like there is an overlap. - Approved proposal for Chris to be formal liaison of OGSA-WG to SAGA-WG * Profile definition document review - Review of strawman produced by Dave S and Tom. http://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-profile-template/en/1 - WS-I style profiles with GGF flavor - Goal of profile definition? - No forward looking statements; Building on existing GGF work and exploiting the proposed recommendation/recommendation process. - Profile consists of references to specs that compose it - Normative references. Require a persistent url at an institutional site. Requirement that it is 'permanent.' - Reference might be only to a sub-section of other specs, including profiles. - Also need to state the current status of specification - Candidate profile vs profile - The difference is in the contents of the profile - Candidate profiles contain specifications that are not at a level that qualifies them as recommendation (ref: 2-d classification ) - Renamed "candidate profile" to "informational profile" for clarity. - Proposing 2-dimensional lifecycle of specs: 1. Status within standards process (Status); and 2. Standing within the community (Adoption) - Dimension 1: "Status" - Institutional standard - De facto standard - Evolving standard - Consortium specification - Evolving consortium specification - Draft specification - Dimension 2: "Adoption" - Ubiquitous - Adopted - Community - Interoperable - Implemented - Unimplemented - Motivation is to categorize specifications and make the criteria for inclusion or exclusion clear. In other words, define areas [status-adoption] that should be excluded and provide a guide to what kind of specs can be included. For example: - WSRF in this taxonomy would probably be 'evolving' since there is a stable specification that people are implementing to (but is not completed yet). - JSDL is at a more volatile state and does not have the same degree of widespread implementation (so despite its value might be not be eligible for inclusion in the Basic profile at this moment). - WS-Addressing as an example of a spec that was adopted first before being put in the standards process (so would have been ineligible earlier) - Required features: It is possible to include only part of a spec in a profile. - Restrictions: It is possible to place additional requirements, beyond those in an included spec. - Extensions: It is possible to allow more flexibility than defined in an included spec. (But it is not the intention to allow complete redefinition of a spec, e.g., change MUST to MAY.) - Security section: Required by GGF - Profile type distinction - Informational profile: can include anything since it is an informational document. Allows for inclusion of specifications that may be controversial/volatile etc - Recommended profile as proposed recommendation - Cannot include draft specs or specs not in standards track - MUST be institutional standard, evolving or de-facto - Examples put forward: WSDM, WSRF, WSDL, x509, also JSDL - But not WS-Federation (not submitted to a standards body) - MUST be Interoperable, Community, Adopted, Ubiquitous - Proposal to add 'Implemented' to this list (Dave B) - Recommended profile as published recommendation - All specs included must be beyond 'interoperable' and 'consortium specification' - And an experimental document required to move it through GGF process - Text looks good. It spells out a lot of the thinking that has been implicit so far. The document is not that long but it would be nice to have short 2-3 slide presentation to describe it. - Any disagreement about detailed definitions or is there any spec that cannot be covered? - Discussion focused around different specs and their likely classification: - OGSA-DAI raised as an example that is difficult to classify (and put in a recommended profile) using the definitions provided here. - WS-Agreement might also be difficult to justify at this point for inclusion in a proposed recommendation - WSRF as evolving standard; spec may be stable but also might change further: - Profile has to include a date by which the final version of the included specs are expected - And this is the main difference between evolving standard and institutional one. - GSI: Proxy certificates are an RFC draft - An evolving standard probably at 'community' level so it would be acceptable in a recommended profile - But it is still undecided whether to include it or not. - Consensus is that the direction and overall feeling of the document is fine. - There will be more opportunities to refine the classification proposed here as profile work progresses. - Note that this document itself is an informational document. - Open issue: How is compliance defined? - A statement about conformance should probably be included in the document. - Tom has the pen on the document; add and re-post it - Next step: Work out a draft Base profile template * GGF 13 schedule review - Based on Hiro's proposal: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/12/msg00033.html - Data profile discussion is on the agenda. Is it likely that there will be draft by then? - Should be able to make some statements about what specs to include but probably not to the level of talking about details, e.g., restrictions, etc. - Can there be discussion of a data profile before the base profile is out? Agreed that yes. - Concerns raised about embodiment of resource under OGSA-DAI and how it would fit together with the rest of the profiles. - Agreed to get Data team people to attend OGSA F2F, especially if it is going to be held in London. - Tom pointed out the need to have the EMS and Data teams vet the work done on Base profile. In particular need to make sure that what the Base profile defines is consistent and well understood by EMS and Data because profiles are additive and requirements should not be relaxed by higher profiles. - Hopefully there will be a fairly well formed draft of the Base profile by F2F; e.g., basic specs, conformance points, clarifications around the specs chosen, etc. - Agreed to re-order sessions. In particular - Move Naming before the EMS and Data - Interleave the Base profile, EMS, Data sessions so as to allow time to get more feedback from the different teams - Action: Hiro to produce new GGF13 session schedule and review again. - Action: Design team leads to list what WGs or other activities they do not want to conflict with at GGF13; Send to Hiro.