OGSA Teleconference - 2 March 2005 ================================== * Participants Mike Behrens (R2AD, LLC) Hiro Kishimoto (Fujitsu) Allen Luniewski (IBM) Fred Maciel (Hitachi) Tom Maguire (IBM) Takuya Mori (NEC, ANL) Steven Newhouse (OMII) Andreas Savva (Fujitsu) Latha Srinivasan (HP) Jem Treadwell (HP) Jay Unger (IBM) Peter Ziu (Northrop Grumman) Minutes: Andreas Savva * No minutes available * Minor change to the GGF13 schedule to add the teleconference information * Discussion generated from Tony Hey's article - Agreed to timebox (10 minutes) this discussion so that it would not take over the entire call. - Two stack interoperability problem? - It is a problem if we end up with different message protocols - Important to describe how the two stacks interroperate (one more analogy given: driving a car either on the left or the right side of the road) - It might be possible to write code that is agnostic but must make a choice about the wire format when running it on the grid. - Migration and co-existence are important issues. They should/could be addressed incrementally in later versions of the standards as they evolve (e.g., WSRF 2.0) - The article's point is that it is not possible to decide which is the right choice at the lower level at this moment; wait and see while defining things at a higher level in an independent manner; and follow the winner later. - Also possible to choose one approach and map to the other with some overhead - The suggested approach does not really solve the problem because it does not reach a common standard - Concern further clarified that building up an infrastructure by making the wrong choice (OGSI raised as an example) might end up messing up application code that is built specifically for it. - End of timebox; followup on the list. * Basic Profile review The latest draft is on gridforge: https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-profile/en/3 Aka: draft-ggf-ogsa-basic-profile-008 [Unassigned actions belong to Tom by default.] ** Front matter - Last line of "Status": This is a recommendation document so delete "...does not define any standards..." - Abstract: - l.4: There is a WS-I citation but no reference. Clarified that WS-1.1 is implied and will be referenced. (Tom to revise) - "Guided by these principlies" what does "these" refer to: > "interroperability, interaction" (Tom to revise) - Why is there no mention of WS-Resource? - In an earlier review agreed that the Profile is only discussing the WS-Addressing embodiment. - But there is a normative reference to WS-Resource. It should be removed (Tom to revise) - Also need to refer to Profile template document (Tom to revise) ** 1 Introduction - Pending action on WS-I copyright issues: - Tom & Hiro will follow up with their companies' representatives on whether the introductory text can be re-used as is or whether it has to be rewritten. - Suggestion to add a short (historical) paragraph on OGSI. - Rejected. No need to refer to OGSI. *** 1.2 Relationships - To add the relationship to Basic Security profile as well. *** 1.3 Notational conventions - UDDI namespace is not needed. Delete. - Other namespaces that are not used for normative statments should also be deleted (xsi, soap, ...) *** 1.4 Profile identification - Discussion on Profile 'name', versioning and what profile instance definition. - Note 'name' does not include the 'version' so the example given is correct. - Since a conformance URI (2.4) will also be defined consider doing the versioning definition just on the URI (or in conjunction) to avoid the need for similar versioning explanation appearing more than once. ** 2 Profile Conformance *** 2.2 Targets The new ones (introduced by this profile) are ENDPOINTREFERENCE and RESOURCE. The rest come from the WS-I BP 1.1. *** 2.3 Scope - It is stated that "extensions...when identified in the Profile..." - So what does it mean if an extension in a referenced spec is not identified in the profile? - There seems to be a minor gap in this explanation. [It is copied from the WS-I Profile explanation.] - The intention is, however, to list all relevant extensibility points from the referenced specs in the profile. ** 3 Addressing After the F2F Tom split off most of the text here to a separate document in anticipation of a separate Naming profile. - Discussed whether to move the remaining statement to the Naming profile or not. The consensus that those dealing with ServiceName and portType could be left here but the rest should go. - Tom will make this a tracker and revisit. ** 4 Resource Property - Description requirement on getmultipleproperties / query - This is already a recorded issue. ** 5 Resource Lifetime There has been some discussion but no firm conclusion on the destroy / resource destruction issue yet. It is recorded as an issue and will be revisited. ** ServiceGroup Tom has deleted this section as agreed at the F2F. ** 6 Notification No change. ** 7 Base Faults Tom added text that requires use of the structure, as agreed. ** 8 Security Dave S is not on the call. Postponed. * Basic Profile Tracker review ** Review of tracker setup Reviewed new tracker status values and discussed other configuration issues. It seems that only a person with OGSA-WG administrator rights can close an artifact on this tracker. Considered changing this but agreed it is good form in order to make sure that changes are properly verified before a tracker is closed. Use of priorities: To capture what to work on next; so it can (and should) be updated to boost the visibility of issues that become more important. ** Artifact review Spend about half an hour going through all artifacts updating them as necessary. For details refer to the BP tracker. Agreed that issues relating to Naming will be moved to a new tracker once the Naming profile draft becomes an independent (and publicly visible) document. > Andreas will take care of the transition.