Minutes attached. Gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050406/en/1 aka http://tinyurl.com/5fxfd/minutes-20050406/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 6 April 2005 ================================== * Participants Mike Behrens (R2AD, LLC) Dave Berry (NeSC) Ian Foster (ANL) Soonwook Hwang (NII) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Tom Maguire (IBM) Mark Morgan (UVa) Takuya Mori (NEC, ANL) Kazushige Saga (NII) Andreas Savva (Fujitsu) Dave Snelling (Fujitsu) Ravi Subramaniam (Intel) Jem Treadwell (HP) Peter Ziu (Northrop Grumman) Minutes: Andreas Savva * Teleconference minutes April 4 Minutes approved with changes Corrections: (Mark) - May F2F: EMS was confirmed for Monday - Allen's name is mispelled * Byte IO charter During an earlier review it was proposed that since the OGSA Basic Profile 1.0 is not yet published the charter should mention that the WG will start work with a draft version of the Profile and move to the final version later on. To minimize synchronization work it was suggested to pick a draft version to work from and only when the WG's specification gets close to publication synchronize with a later or final version of the BP. There is no BoF ML set up yet. So it was agreed to mail a final draft charter to the ogsa-wg-ml and other interested parties and ask for comments. There is no problem with not setting up a call specifically to discuss the draft charter. Once that is done, incorporate any feedback and submit a final version of the charter to the AD. Since the GFSG call is on Tuesday it is important to get this to the AD fairly soon. (It was also suggested that important emails from the Byte IO WG should also be sent to ogsa-wg-ml as part of liaison work. Obviously there is no need to cross-post everything.) * OGSA evolution policy statement This is a new document written by Dave S for the GGF (GFSG). "Drawer statement": A (M.Linesch) term describing documents that may not be completely public (but not secret) and are used for reference when needed (kept in a drawer). The intention is, however, to send this document out to the ogsa-wg-ml for more comments. OGSA is high profile especially after GGF's adoption of OGSA as a "flagship architecture." There are some concerns raised with OGSA adopting one specific approach. This document tries address those concerns based on the consensus of the December OGSA F2F. Three levels of interoperability - At infrastructure layer (based on WS standards) - (OGSA version 1.0 (aka GFD.30) definition of infrastructure also includes WSRF and WSDM. This definition is inconsistent with the definition in this document. Needs clarification.) - At the highest level based on GFD.30 - (From a technical perspective it is not really meaningful to talk about interoperability at this level) - At the middle level based on profile definitions - Consistency between GFD.30 and profiles is mentioned but is this a vacuous statement at the moment? - Consistency is a work in progress. - There is a plan/desire to produce more detailed architectural documents per capability - Concerns that the way this document is written any profile can be ogsa so resulting in a tower of babel. - Is it possible that profiles can be inconsistent with each other? - Inconclusive discussion on the consensus of the Dec or Feb meeting. - From a technical point of view it is not meaningful to allow inconsistent profiles (so this statement seems to be politically motivated) - Technical vs branding issues - Who controls the OGSA name/brand and who can state that a profile is part of ogsa - If the OGSA 'brand' is important then it should not be 'diluted' by allowing anything to be OGSA. - E.g., is it possible to issue BP and then state that all other profiles should be consistent/build on top of this profile? - And a stronger statement could be that the higher profiles are unique for individual GFD.30 features/components - Might also need to work from top down to articulate the architecture further (something that could be done later) - Is there such a thing as a middle level profile (?architectural profile?) and what does it mean for interoperability - Profiles are concrete and talk about specific conformance targets so such a profile is not possible - Even though potentially this document allows for a tower of babel situation logistically it would be difficult to find the people to define the profiles/specifications currently being worked on. (So it seems like a small risk.) - Proposal for defining a process/policy by which only certain documents can use the OGSA name: - At the moment once a WG is formed it is accountable to the GFSG only; there is no formal mechanism for one WG to affect another except by individual member participation. - So some extra layer to allow OGSA-WG to 'control' such documents from other WGs would be needed. - The current process allows for feedback to documents during the public comment period and that could be the place to raise objections to inappropriate usage of the OGSA term. Action: - Send the document out to the list and continue this discussion there. (Hiro) - Dave S will feedback this discussion back to the GFSG * OGSA Profile definition (profile template) review - Existing issue with copyright affected text (text copied from WS-I basic profile): - Hiro has confirmed that it is not allowed to copy-paste this text. Even if GGF becomes a WS-I associate member, membership only provides early access to WS-I materials. Action: Delete the copyrighted text from the OGSA basic profile and template documents. (Dave S and Tom) - Reference the WS-I document instead - The status and adoption levels are the main contributions of the template document: - It is expected that profiles categorize specs used in this way - Level of adoption: for a profile it affects the transition from proposed recommendation to recommendation. Action: Make this kind of information for each referenced spec a required appendix for profiles and include an example in this document. (Dave S) - "Security considerations" is typically the last section in GGF documents. Action: Fix order of the "Profile type distinction" section and the "Security considerations" section. (Dave S) - Section 5.1: Should the term "informational profile" be changed to the more commonly used "candidate profile" - Dave S prefers "informational" but maybe "candidate" is already well established. No change for now. - Section 5.3: - It is incorrect to include "evolving standard" as an allowed status here. - "Published recommendation" should be "Grid recommendation" Action: Dave S to update the document with the above corrections - Section 5.2: - It was proposed to also delete 'Evolving standard' from this section. - A proposed recommendation becomes a recommendation after implementation and an experience report so the standards it is based on should not be 'evolving'. - The downside is that a lot of referred work may be in progress making this requirement too restrictive - No decision reached. Need to revisit in order to clarify which 'milestones' are being assumed. E.g., is it acceptable to use evolving specs up to submission but make sure they are updated before submission or not. - The adoption levels of section 5.2 and 5.3 should probably be the other way round. Dave S to correct. - Agreed that this document should be submitted as an information document by GGF14 Action: Andreas to create a tracker for the template document * AOB - Next call (Monday) is new WG status call - It is not clear if there is a Naming BoF list. - A BES BoF list seems to be setup (OGSA-BES-bof@ggf.org)