Teleconference minutes - 20 July 2005

Minutes attached. - F2F update - Next step discussion - WSRF BP 1.0 review https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050720/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 20 July 2005 ================================== * Participants Mike Behrens (R2AD, LLC) Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Fred Maciel (Hitachi) Mark Morgan (UVa) Takuya Mori (NEC) Andreas Savva (Fujitsu) Pete Ziu (Northrop Grumman) Apologies: Tom Maguire Minutes: Andreas Savva * Minutes July 18 minutes approved with minor modifications: date is wrong, and should be corrected to July 18. * F2F Update - The Resource Management (RM) design team wants a slot during the F2F; preferably a full day. - They had a call, starting their discussion from the same point as the last OGSA call: the need for a document to make requirements concrete. The F2F seems to be the best time to start working out the contents of this document. - Andrea Westerinen will also be joining the OGSA F2F for this purpose. (She cannot make it before Wednesday, however) - Andrew is also needed for this effort. But he is leaving Thursday afternoon. - Schedule proposal is to use the OGSA session Wednesday afternoon and continue in the OGSA session Thursday morning. - Will look at BES, and EMS resource model (RSS will need something too). - EGA joint-session is also being planned for Wednesday afternoon. - Andrew is therefore double-booked. - Agreed to move the EGA session to Tuesday morning, either in parallel to or after ByteIO if it finishes early. - The EGA members may want to get involved on a specific issue. The RM work seems like a good candidate. In this meeting however it may be better to discuss procedural issues. - And start discussing what that common topic is. Suggest RM as a candidate. (And possibly ask them to join the RM work at a later point when it has more structure.) - Is the OGSA general session on Friday sufficient? Not sure. - Are ByteIO and Naming taking too much time on the schedule? (half-a-day each) - ByteIO: a couple of hours are probably enough (including spec review). No controversy so far. - Naming: there seems to be (tentative) consensus on the main issues. So a couple of hours might be enough. This excludes a discussion of RNS. If RNS is discussed then half-a-day in total may be needed. Action: Andrew to send an email to the EGA members and arrange the meeting for Tuesday morning. Action: Andreas to book an extra room for Tuesday morning - Marvin Theimer cannot join in person. Add to the list of people dialling in. * Next Step discussion Based on Hiro's draft sent out before the call: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/07/msg00064.html - OGSA-WG is already committed to the following activities: - OGSA 1.5 and Glossary 1.5 - OGSA Roadmap 1.0 - OGSA Profile definition (submitted; waiting to enter public comment) - WSRF BP 1.0 (working to complete; schedule has already slipped. Probably cannot publish before November.) - EMS area: - BES has already started and RSS is starting up. - CDDLM and ACS work has to be integrated (see next topic) - Provisioning - Priority is high; will be worked on at the next F2F in the joint session with CDDLM. - Basic EM Profile: revisit after GGF15 - Job Manager Interface: - Perceived overlap with BES as well as work from other groups. - Not high priority; revisit later. - EMS architecture document - As a separate document it may take longer than August. [Need to identify what changes in OGSA 1.5 though.] - Grid Resource model - This is now high priority; agreement is to start working on this soon. - Resource virtualization: This seems more of a by-product of OGSA work. Probably do not need it as a separate topic. - Information services: Abdeslem has indicated he needs help with this topic. Need to follow up with Abdeslem. (Not sure if he can attend the F2F. Hiro to confirm.) - OGSA Authz - They have submitted one document recently; it is probably going to public comment soon. - There is also another draft on using SAML and OGSI. It needs to be revised for WSRF. - They are trying to re-charter. - OGSA-WG would like to be more involved with this group. The target is to have the same level of interaction that OGSA-WG has with BES, RSS, etc. (Especially since this seems to be the only active security group and it carries the OGSA prefix.) - Therefore synchronizing with this group is high priority. The F2F may offer a good opportunity to do so. Maybe invite members of OGSA AuthZ to attend and have a discussion. - Some people are based in the Bay area. - Negotiate a place on the agenda based on their availability. Action: Takuya has contact with this group (OGSA liaison) and will invite them to attend. - Agreed to add Basic Profile 2.0 to the list. - BP 1.0 interop - this is going to be a lot of work. and noone has taken this activity on yet. Volunteers needed. - If it will happen in public at GGF16 it should be done before in a smaller circle. So as to make sure it will not fail. Action: Andrew will ask Marty if he would like to lead this activity on. - Roadmap document update - OGSA-WG has committed to updating this document. So it should be moved to the first section. - It is low priority. - Use case cross-check: low priority. No volunteers. - December F2F: consider La Jolla as a location. - Hiro's schedule proposal: - Andrew has sent out comments on RNS specification. Some time for the RNS review should be allocated in July/August - Roadmap public comment period is until July 29. - There are very few comments. Are those enough? - It is an informational document and so the bar is lower than Recommendation track. - Is there a way to check how many people have downloaded it? - All should try to invite more comments from colleagues. [An updated version of the work items list, based on this review, was sent to the list: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/07/msg00068.html] * WSRF BP 1.0 review There has not been a separate security call or discussion yet. Also Takuya is still reviewing the WS-I Basic Security Profile (WS-I BSP) on the header signing issue. Other related issues are also still unresolved. Review based on draft 29: https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-wsrf-ba... Did a page by page review until page 14 (l.493). Accepted all changes to that point with the following exceptions: - R0429: Takuya has comments on the Schema Centric Canonicalization specification. A summary follows: - The Schema Centric Canonicalication specification only covers serialization of nodesets. So there is still a need to define the schema for the content of reply messages when the return values that are strings, numbers, booleans. (XPath allows such return values.) - Even if selecting a fragment the whole document would be serialized; this might cause big performance problems with large documents, even if the returned fragment is small. Action: Takuya to send an email with his concerns on the Schema Centric Canonicalization to the list. - E0802: Is this extensibility point listed in WS-I BSP 1.0? - Takuya think it is. Action: Hiro to re-check the WS-I BSP 1.0 - A newer version of the WS-I BSP seems to be in the works. But there is no time to change from using the currently used version. Might be able to do so during public comment. - l.493: 'only' issue is still unresolved. Action: Takuya to propose new text to the list. * Other business - Andrew will miss the next call (Monday) due to other commitments.

Hi,
- R0429: Takuya has comments on the Schema Centric Canonicalization specification. A summary follows: - The Schema Centric Canonicalication specification only covers serialization of nodesets. So there is still a need to define the schema for the content of reply messages when the return values that are strings, numbers, booleans. (XPath allows such return values.) - Even if selecting a fragment the whole document would be serialized; this might cause big performance problems with large documents, even if the returned fragment is small.
Action: Takuya to send an email with his concerns on the Schema Centric Canonicalization to the list.
I was wrong with this point. I overlooked its serialization step from an infoset to an octet stream. The serialization step omits info items which represent nodes that are not in the nodeset to be canonicalized. I'm sorry for making you confused. Thanks, Takuya
- E0802: Is this extensibility point listed in WS-I BSP 1.0? - Takuya think it is.
Action: Hiro to re-check the WS-I BSP 1.0
- A newer version of the WS-I BSP seems to be in the works. But there is no time to change from using the currently used version. Might be able to do so during public comment.
- l.493: 'only' issue is still unresolved.
Action: Takuya to propose new text to the list.
* Other business
- Andrew will miss the next call (Monday) due to other commitments.

Hi, I have some additional comments on the return type of the XPath evaluation for QueryResourceProperties.
Review based on draft 29: https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-wsrf-ba...
Did a page by page review until page 14 (l.493). Accepted all changes to that point with the following exceptions:
- R0429: Takuya has comments on the Schema Centric Canonicalization specification. A summary follows: - The Schema Centric Canonicalication specification only covers serialization of nodesets. So there is still a need to define the schema for the content of reply messages when the return values that are strings, numbers, booleans. (XPath allows such return values.)
The XPath specification allows four types of value as its return value. And, once an expression is given, its return value is also determined. But, in my opinion, because there may be a case where an XPath expression is not available at the design time, we still need a way to introspect the type of the return value dynamically at runtime. So, I think we need to define some structure in the content of the response message for the QueryResourceProperties operation. The structure could be an element which has an attribute to hold a type information of the result. And the content of the element could be one of four elements each of which can have a type of value defined in the XPath spec as its return value. The following is an example: <wsrf-rp:QueryResourcePropertiesResponse> <ogsa-bp:XPathResult type="ogsa-bp:string-type"> <ogsa-bp:StringValue>ReturnValue</ogsa-bp:StringValue> </ogsa-bp:XPathResult> </wsrf-rp:QueryResourcePropertiesResponse> Thanks, Takuya
- Even if selecting a fragment the whole document would be serialized; this might cause big performance problems with large documents, even if the returned fragment is small.
Action: Takuya to send an email with his concerns on the Schema Centric Canonicalization to the list.
- E0802: Is this extensibility point listed in WS-I BSP 1.0? - Takuya think it is.
Action: Hiro to re-check the WS-I BSP 1.0
- A newer version of the WS-I BSP seems to be in the works. But there is no time to change from using the currently used version. Might be able to do so during public comment.
- l.493: 'only' issue is still unresolved.
Action: Takuya to propose new text to the list.
* Other business
- Andrew will miss the next call (Monday) due to other commitments.

-1 to defining content wrappers for QRP Response. The consumer of the response is the same 'person' that defined the query xpath. They know what they should be getting in response. SC14N defines a concise serialization so that each xpath processor will know how to serialize that information. IMO that is all that is necessary for interop. Tom Frey’s Law: “Every 5 years the number of architecture components double and the ability to comprehend them halves” Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. – Antoine de Saint-Exupery T o m M a g u i r e STSM, On Demand Architecture Poughkeepsie, NY 12601 Takuya Mori <moritaku@bx.jp.n ec.com> To Sent by: ogsa-wg@gridforum.org owner-ogsa-wg@ggf cc .org Subject QueryResourceProperties (Re: 07/25/2005 01:43 [ogsa-wg] Teleconference minutes - PM 20 July 2005) Hi, I have some additional comments on the return type of the XPath evaluation for QueryResourceProperties.
Review based on draft 29:
https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-wsrf-ba...
Did a page by page review until page 14 (l.493). Accepted all changes to that point with the following exceptions:
- R0429: Takuya has comments on the Schema Centric Canonicalization specification. A summary follows: - The Schema Centric Canonicalication specification only covers serialization of nodesets. So there is still a need to define the schema for the content of reply messages when the return values that are strings, numbers, booleans. (XPath allows such return values.)
The XPath specification allows four types of value as its return value. And, once an expression is given, its return value is also determined. But, in my opinion, because there may be a case where an XPath expression is not available at the design time, we still need a way to introspect the type of the return value dynamically at runtime. So, I think we need to define some structure in the content of the response message for the QueryResourceProperties operation. The structure could be an element which has an attribute to hold a type information of the result. And the content of the element could be one of four elements each of which can have a type of value defined in the XPath spec as its return value. The following is an example: <wsrf-rp:QueryResourcePropertiesResponse> <ogsa-bp:XPathResult type="ogsa-bp:string-type"> <ogsa-bp:StringValue>ReturnValue</ogsa-bp:StringValue> </ogsa-bp:XPathResult> </wsrf-rp:QueryResourcePropertiesResponse> Thanks, Takuya
- Even if selecting a fragment the whole document would be serialized; this might cause big performance problems with large documents, even if the returned fragment is small.
Action: Takuya to send an email with his concerns on the Schema Centric Canonicalization to the list.
- E0802: Is this extensibility point listed in WS-I BSP 1.0? - Takuya think it is.
Action: Hiro to re-check the WS-I BSP 1.0
- A newer version of the WS-I BSP seems to be in the works. But there is no time to change from using the currently used version. Might be able to do so during public comment.
- l.493: 'only' issue is still unresolved.
Action: Takuya to propose new text to the list.
* Other business
- Andrew will miss the next call (Monday) due to other commitments.
participants (3)
-
Andreas Savva
-
Takuya Mori
-
Tom Maguire