October 2005 - ogsa-wg - lists.ogf.org

[ogsa-wg | Secure Channel 1.0 - 1658] R0301 Requiring support for both TLS and MLS is too much.
by Sourceforge Tracker Monitor 17 Oct '05

17 Oct '05

A new artifact has been added: 1658 Submitted by: Takuya Mori Submitted date: 2005-10-18 02:34:02 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1658&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1658&group_id…) Summary: R0301 Requiring support for both TLS and MLS is too much. Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1658 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-10-18 02:34:02 Submitted By: Takuya Mori Submit Date: 2005-10-18 02:34:02 Assigned To: &lt;None&gt; File(s): <None> Description: Requiring support for both TLS and MLS is too much. The consensus is: ---- Proposed and accepted to focus the secure channel profile on just TLS in the interests of making quick progress. Leave MLS out until the requirements for it are made clear. MLS may be included in a later version; or a separate profile for it may be defined. Action: Takuya and Frank to re-check the WS-I BSP for the MLS choices and which portions of those might be refined in an OGSA security profile. from the Sep28th call minuts ---- View the Secure Channel 1.0 : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Secure Channel 1.0 - 1657] Missing extensibility points?
by Sourceforge Tracker Monitor 17 Oct '05

17 Oct '05

A new artifact has been added: 1657 Submitted by: Takuya Mori Submitted date: 2005-10-18 02:31:07 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1657&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1657&group_id…) Summary: Missing extensibility points? Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1657 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-10-18 02:31:07 Submitted By: Takuya Mori Submit Date: 2005-10-18 02:31:07 Assigned To: &lt;None&gt; File(s): <None> Description: WS-I BSP 1.0 has seven extensibility points. Now the v005 draft has five. Check if the missing ones need not to be included. View the Secure Channel 1.0 : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

[ogsa-wg | Secure Channel 1.0 - 1656] Claiming Conformance
by Sourceforge Tracker Monitor 17 Oct '05

17 Oct '05

A new artifact has been added: 1656 Submitted by: Takuya Mori Submitted date: 2005-10-18 02:27:58 Respond by visiting: https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1656&group_id… (https://forge.gridforum.org/tracker/?func=detail&atid=820&aid=1656&group_id…) Summary: Claiming Conformance Project: Open Grid Services Architecture Tracker: Secure Channel 1.0 Artifact ID: 1656 Category: <None> Group: <None> Status: Open Priority: - Last Modified By: Takuya Mori Last Modified: 2005-10-18 02:27:58 Submitted By: Takuya Mori Submit Date: 2005-10-18 02:27:58 Assigned To: &lt;None&gt; File(s): <None> Description: Hiro pointed out that the previous draft of the profile missed a conformance claim URI, OGSABasicProfile-1.0. Now the v.005 of the profile has some text for the conformance claim URI. Check if the description is good or not. View the Secure Channel 1.0 : https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… (https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=…)

1 0

Minutes: Teleconf, GGF15, F2F
by Andreas Savva 17 Oct '05

17 Oct '05

Teleconf: https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20050928/en/1 https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051012/en/1 GGF15: https://forge.gridforum.org/projects/ogsa-wg/document/ggf15-ogsa-session-1/… https://forge.gridforum.org/projects/ogsa-wg/document/ggf15-ogsa-session-2/… F2F: https://forge.gridforum.org/projects/ogsa-wg/document/ggf15-f2f-minutes-200… https://forge.gridforum.org/projects/ogsa-wg/document/ggf15-f2f-minutes-200… -- Andreas Savva

1 0

New charter draft final call
by Hiro Kishimoto 17 Oct '05

17 Oct '05

Hi all, I've upload revised charter draft to GridForge. It covers all comments we got at the F2F review. https://forge.gridforum.org/projects/ogsa-wg/document/OGSA-WG-Charter-2005 I would make a final call for this draft. Please send any comments you may have on this. If there is no major one by Friday, I will ask our Area Director, Andrew Grimshaw, to bring it forward for GFSG approval. Thanks, -- Hiro Kishimoto

1 2

telecon schedule
by Hiro Kishimoto 15 Oct '05

15 Oct '05

Hi all, Based on the F2F discussion, I've written up and attached OGSA-WG telecon schedule until January F2F. As usual, it is uploaded to the GridForge, too. https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ Please give your comments or suggestions by email or at Monday call. Thanks, -- Hiro Kishimoto

1 0

Proposed agenda for Oct. 17th call
by Hiro Kishimoto 15 Oct '05

15 Oct '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Oct. 17th Monday from 5pm to 7pm (CDT). The dial-in number for Monday; Free: +1-866-639-4741 Toll: +1-574-935-6703 PIN: 8980700 Screen share service will be provided. URL: http://ogsa.glance.net Session key: 1017 See more explanation: http://www-unix.gridforum.org/mail_archive/ogsa-wg/2004/06/msg00077.html 1) Early discussion (10 min) Note taker assignment Roll call Telecon minutes approval (if available) WSRF RMD spec ownership info - Dan Jemiolo from ibm/wsdm tc is to take over ownership Agenda bashing 2) GGF15 and F2F meeting minutes approval (10 min if available) https://forge.gridforum.org/docman2/ViewCategory.php?group_id=42&category_i… 3) Management Developer Conference (10 min) MDC 2005 will be held from Dec. 5 to 8 at Santa Clara Marriott Hotel and GGF is one of their Organization Sponsors for this conference (http://www.mandevcon.com/index.html) We are asked to give OGSA introduction presentation on Wednesday Dec. 7. Audience is enterprise management hardware / software experts and may be new to Grid technology. Any volunteer? 4) Basic Security Profile discussion (60 min) Open issue discussion. Takuya will file all open issues to new GridForge trackers. https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… https://forge.gridforum.org/tracker/index.php?func=browse&group_id=42&atid=… 5) Architecture & Glossary 1.5 discussion (30 min) Andreas and Jem will lead 6) Wrap-up AOB <NEXT CALL> Oct. 19 (Wed) EMS architecture, information model & CIM profile Oct. 24 (Mon) Basic Security Profile document review, Architecture & Glossary 1.5 (data section review) Oct. 26 (Wed) EMS architecture, information model & CIM profile Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 0

Joining 1 hour late this evening (7PM ET)
by Maguire_Tom＠emc.com 12 Oct '05

12 Oct '05

Thanks, Tom Senior Technologist, CTO Office EMC²|SMARTS 44 South Broadway 7th Floor White Plains, NY 10601 Office: +1-914-508-3477 Mobile: +1-845-729-4806 Email: maguire_tom(a)emc.com <mailto:maguire_tom@emc.com> If you want to build a ship, don't drum up people to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea. Antoine de Saint-Exupery

1 0

Meeting notes from the CDDLM meeting, Wed 10/12/2006, at 6am PST
by Milojicic, Dejan S 12 Oct '05

12 Oct '05

Attendees: Keisuke Fukui, Jun Tatemura, Ayla De Souza, and Dejan Milojicic. Note taker: Dejan Milojicic > At the F2F meeting with OGSA, CDDLM had a couple of homework assignments. > > The first one was to sort out how does CDDLM interact with > ACS. We had some preliminary hallway discussions between > CDDLM people, Mike Behrens and Sachiko, but they suggested > that they would like to sync up with Keisuke prior to making > any decision. The options have been documented in a > presentation that Stuart prepared and gave at the F2F meeting > (either direct CDDLM-ACS interactions; through data services; > or through information services. I expect that someone from > ACS-WG can join us either tomorrow at our meeting or at some > other meeting in the near future. Keisuke presented the slides he posted earlier to the mailing list. Then we discussed which of the options of should work best for ACS, CDDLM, and other groups, such as CSG and RSS. The conclusion was that we do not need to be specific which information or services need to be combined. We defined interfaces for each services (ACS and CDDLM). As it is, the CDDLM and ACS relationship is appropriate. Options 1 and 2 does not make much difference (each spec doesn't explicitly specify I/F to be used for that). In a summary, we plan to leave the things as is, with the current specs on both sides unchanged. At the moment, they are closest to the option 2 (communication through data services). However, see also discussion below, which implies the interactions between ACS and CSG, even though it only relates to the data/information path between ACS and CSG and instead it is really about future services that CDDLM may offer. CSG interaction with ACS has not been discussed within ACS group, it is ambiguous and we believe that this was really the core of this whole controversy about the relationship between ACS, CDDLM, and CGS. It is about how CSG can obtain the information about the resource requirements and deployment time from the deployment descriptions, which is the topic of the next two items. > The second task item we had from the F2F was how can we help > provisioning services by providing an estimate of the deployment time. It is not possible, it could only be a hint. History is better source of this information. We could potentially, (from hints) resolve CDL by obtaining for each component the predicted deployment time, then from component graph calculate compound estimate (e.g. add times where components are serialized, return max where components are parallel, etc.). We will continue to explore these options. We do not plan to support this sort of functionality in the existing specs; we may want to support it in versions 2.0, or if it is urgently required, we can address it in a separate spec. This could be something called "Deployment Estimates Services" (DES). This will heavily depend on this information provided as a part of the CDL. These Deployment Estimates Services can also address the resource requirements, by having a similar run through the tree and adding up the resource required. . In addition to these offline services, we can provide the statistics about the run-time deployment time, by collecting time of the deployment of each component as well as overall time. These times can then be matched against the estimate times. Again, we do not plan to support this in the current versions of specs, but rather in the second versions or in separate specs. > The third task assignment was where do we stop in expanding > the tree (e.g. at the OS provisioning?) and how do we mark this. CDDLM (and CDL) are transparent to this. This is more matter of the policy and best practices. If further required, we can take this offline with Jay and come up with a proposal. > The last assignment was to see how we fit into Andrew > Grimshaw's view of provisioning. Andrew promised that he will > write-up a paragraph or so on his view and we will use that > to answer his concerns. We are still waiting for Andrew to provide one (or more) paragraph(s) description of how he sees deployment and we'll provide a feedback to his proposal how we match his expectations. > I expect to make progress on the first three topics tomorrow > morning PST (as well as the fourth if we receive Andrew's > paragraph in a timely fashion) and if we get some opportunity > we can present the outcome at the OGSA meeting tomorrow > afternoon (PST) or we can communicate the outcomes by email. We welcome an opportunity to go into more details on all these matters with the OGSA group. It is my understanding that we are not on the agenda for today. nor for the following meeting. Finally, we raised the issue of interoperability. It remains to be a major concern that the underlying specs that we depend on are not stable (WS-Addressing) or themselves do not have a full interoperability story in order for us to be able to demonstrate full degrees of interoperability. We expect feedback from Hiro on how IETF demonstrates interoperability so that we can best meet our target for interoperability demonstrations which is June 2006. Best regards, Dejan.

1 0

RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSD L Binding
by Maguire_Tom＠emc.com 12 Oct '05

12 Oct '05

That may be true at the moment. But when the WS-Addressing - WSDL Binding spec is done (or shortly there after) that should not be true. Let me put it this way; if we have an EPR per protocol address we have failed miserably. I am sure you are not implying that the Naming architecture should be bounded by the current toolings limitations. Tom -----Original Message----- From: Mark Morgan [mailto:mmm2a@virginia.edu] Sent: Tuesday, October 11, 2005 12:57 PM To: Maguire, Tom; ogsa-wg(a)ggf.org Cc: ogsa-naming-wg(a)ggf.org; tuecke(a)univa.com; David.Snelling(a)uk.fujitsu.com Subject: RE: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding My experience has been that available tooling (Microsoft and Java) doesn't support Address lines that aren't URLs. Am I wrong about this? -Mark > -----Original Message----- > From: owner-ogsa-wg(a)ggf.org [mailto:owner-ogsa-wg@ggf.org] On Behalf > Of Maguire_Tom(a)emc.com > Sent: Tuesday, October 11, 2005 12:49 PM > To: ogsa-wg(a)ggf.org > Cc: ogsa-naming-wg(a)ggf.org; tuecke(a)univa.com; > David.Snelling(a)uk.fujitsu.com > Subject: [ogsa-wg] RE: [ogsa-naming-wg] WS-Names and WS-Addressing > WSDL Binding > > > As promised at the F2F in Boston I have started a thread of discussion > on the subject line. I have reposted the thread to the this mailing > list > (ogsa-wg) in the hope that broader distribution will spur debate and > discussion. > > Tom > > -----Original Message----- > From: Maguire, Tom > Sent: Sunday, October 09, 2005 4:51 PM > To: Maguire, Tom; David.Snelling(a)UK.Fujitsu.com > Cc: ogsa-naming-wg(a)ggf.org; tuecke(a)univa.com > Subject: RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding > > Dave you mentioned in one of your question: > > >>It appears that in the example that either the was:Address and the > >>soap:address must be the same or that the wsa:Addess is irrelevant. > >> I can't really believe the former so let's assume the later. > > It's not that the wsa:adddress is irrelevant it is that the > wsa:address is logical as opposed to physical. This is precisely why > I think we can use it.... > > Tom > > -----Original Message----- > From: owner-ogsa-naming-wg(a)ggf.org > [mailto:owner-ogsa-naming-wg@ggf.org] On Behalf Of Maguire, Tom > Sent: Sunday, October 09, 2005 8:35 AM > To: David.Snelling(a)UK.Fujitsu.com > Cc: ogsa-naming-wg(a)ggf.org; tuecke(a)univa.com > Subject: RE: [ogsa-naming-wg] WS-Names and WS-Addressing WSDL Binding > > Dave, > > I'll do my best to answer your questions inline below. Let me caution > this thread a bit. The WSDL Binding specification is not complete and > is clearly still evolving... > > >>It appears that in the example that either the was:Address and the > soap:address must > >>be the same or that the wsa:Addess is irrelevant. I can't really > >>believe > the > >>former so let's assume the later. > > Yes, I believe that is the intent. As I mentioned in my note it is > 'interesting' that they are the same. My guess is that makes > implementations that are not <wsa:metadata> aware able to cope. I > would expect that would be a 'best practice'. > Not sure what the implications would be for us if that were the > case... > > >>With a wsdl11:definitions section present, the wsa:Address > field must > >>be > superseded > >>by the soap:address chosen by the client. I assume that the > >>soap:address gets copied to the was:To field in the soap header. > > Ultimately you are correct however I expect that the specification of > that > linkage would not be quite as explicit as that. > > >>There is no linkage in the wsdl11:definitions to connect the > >>wsa:Address > to it. > > No > > >>Q1) What happens with more than one wsdl11:definitions > section in the > >>was:Metadata? > > I have no idea what that would even mean. I presume they would limit > that in the spec. As I said it is still evolving. > > >>Q2) In this case can we put any old junk in the wsa:Address? > >>i.e. leave it out (except that the scheme saus [1..]. > > <wsa:address> is required and I would assume that at a minimum there > would be a statement of 'best practice' where the <wsa:address> is the > 'default' > address. > > >>Q3) If we use the wsa:Address as an Abstract Name, how do > we know that > >>is > what > >>we are doing? We could subtype the EPR to create a WS-Name > as we do > >>now, and bind the usage of the was:Address to type of the WS-Name. > > I would use a wsi conformance claim on both the wsdl and the EPR. The > wsdl claim would be that the service is capable of generating > WS-Names. The EPR claim would be that this EPR adheres to the > additional semantics of a WS-Name. > > >>Q4) I thought WS-Addressing was NOT about naming or identity. > >>How will this use (abuse) of the wsa:Address go down with > the W3C folks? > > I think this is a misread on your part W3C objected to identity being > encoded in something OTHER than a URI (IRI); in the WS-Addressing case > they objected to ReferenceProperties. Ultimately ReferenceProperties > were merged with ReferenceParameters which weakened (removed) the > identity semantic. I think they would be extremely happy with the use > of a URI as an identifier :-). > > > Tom > > > On 7 Oct 2005, at 12:41, Maguire_Tom(a)emc.com wrote: > > > This will be a fairly long note to discuss the current > incarnation of > > WS-Naming Abstract Names. An Abstract Name has the following > > properties: > > > > * The name MUST be globally unique in both space and time. > > * The name conforms to URI syntax ("Uniform Resource Identifiers > > (IRI): Generic Syntax", RFC 3987). > > > > Let's leave aside the first point, for the time being, and focus on > > the second point. The abstract name is an IRI which is an > > internationalized URI. Currently this means that a WS-Name > abstract > > name would look like > > this: > > > > <wsa:EndpointReference > > xmlns:wsa="http://www.w3.org/2005/03/addressing" > > xmlns:name="http://ggf.org/name"> > > <wsa:Address>http://tempuri.org/example</wsa:Address> > > > > <name:AbstractName>urn:guid:B94C4186-0923-4dbb-AD9C-39DFB8B54388</ > > name:Abstr > > actName> > > </wsa:EndpointReference> > > > > There are several built in assumptions in this particular > rendering of > > an > > abstract name. First, there is an assumption that the > <wsa:Address> > > is the > > [destination] MAP of the EPR. Second, the AbstractName > does not need > > to flow on the wire when 'dereferencing' this EPR. > > > > It may be ok for the AbstractName to not flow on the wire. I will > > leave that discussion to others. Let's focus on the first > > assumption... > > If you assume that the <wsa:Address> is NOT necessarily a physical > > address > > (URL) then it is essentially the same as an AbstractName minus the > > "MUST be globally unique in both space and time" property described > > above. > > > > This is essentially how 'Web Services Addressing 1.0 - WSDL > Binding' > > defines > > a <wsa:Address>. An example from that specfication: > > > > <wsa:EndpointReference > > xmlns:wsa="http://www.w3.org/2005/03/addressing"> > > <wsa:Address>http://example.com/fabrikam/acct</wsa:Address> > > <wsa:Metadata> > > <wsdl11:definitions > targetNamespace="http://example.com/fabrikam" > > xmlns:fabrikam="http://example.com/fabrikam" > > xmlns:abc="http://www.abccorp.com/" > > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" > > xmlns:iiop="http://www.iiop.org/" > > xmlns:wsdl11="http://schemas.xmlsoap.org/wsdl/"> > > <wsdl11:import namespace="http://example.com/fabrikam" > > location="http://example.com/fabrikam/fabrikam.wsdl"/> > > <wsdl11:import namespace="http://www.abccorp.com/" > > location="http://www.abccorp.com/abc.wsdl"/> > > <wsdl11:service name="InventoryService"> > > <wsdl11:port name="ep1" binding="abc:soap-http-binding"> > > <soap:address > location="http://example.com/fabrikam/acct"/> > > </wsdl11:port> > > <wsdl11:port name="ep2" binding="abc:iiop"> > > <iiop:address location="..."/> > > </wsdl11:port> > > </wsdl11:service> > > </wsdl11:definitions> > > </wsa:Metadata> > > </wsd:EndpointReference> > > > > And also from 'Web Services Addressing 1.0 - WSDL Binding' > > > > In particular, embedding a WSDL service component > description MAY be > > > used by EPR issuers to indicate the presence of alternative > addresses > > and protocol bindings to access the referenced endpoint. The > > alternatives are provided by the different endpoints of the > embedded > > service. > > > > It is interesting to note that in the above example that the > > <wsa:address> matches the soap:address location. > > So this says to me that the <wsa:address> is essentially equivalent > > (or at least could be) to an abstract name. > > > > Thoughts? > > > > > > Thanks, > > Tom > > > > Senior Technologist, CTO Office > > EMC²|SMARTS > > 44 South Broadway > > 7th Floor > > White Plains, NY 10601 > > Office: +1-914-508-3477 > > Mobile: +1-845-729-4806 > > Email: maguire_tom(a)emc.com <mailto:maguire_tom@emc.com> > > > > If you want to build a ship, don't drum up people to > collect wood and > > don't assign them tasks and work, but rather teach them to long for > > the endless immensity of the sea. > > > > Antoine de Saint-Exupery > > > > > -- > > 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) >

4 6