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

Re: latest ws-naming draft (Re: [ogsa-naming-wg] One more thing)
by Mark McKeown 22 Nov '05

22 Nov '05

Hi Frank, I have made some comments inline... First to remove some confusion about IRIs that have appeared in previous mails in this thread. URNs and URLs are URIs[1], IRIs[2] are an extension of URIs to support extra charactors. A URI may or may not map to a real physical address. The WS-Addressing specification[3] defines a number of URIs that do not map to real network locations (eg http://www.w3.org/2005/08/addressing/anonymous) WS-Addressing mandates that the wsa:Address element is an absolute IRI. > > * include a profile for the use of the Address and ReferenceParameters > that ensure the proper uniqueness property in time and space of the > reference. Tom Maguire suggested to use the wsdl binding of the address > which sounded very promising. I am not sure I have understood Tom's argument correctly so I will try and repeat it here in order to be corrected... TomM suggested using the wsa::Address as the name, I understand his argument as being that with the WSDL binding for WS-Addressing you can include the service part of the WSDL into the wsa:Metadata of the EPR, the service part may contain a number of network endpoints indicating that the WS-Resource is available at a number of locations. >From 'Web Services Addressing 1.0 - WSDL Binding' [4]: "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." In this case the wsa:Address could be a URN (or URI that is not an actual network location) and the client could look to the wsa:Metadata to find the actual network location of the WS-Resource. Quoting Tom[5]: "Let me be very clear about this an EPR does not have a 1 to 1 correspondence with a protocol and binding address. It MUST be true that an EPR can support multiple protocols and their associated addresses." I am not sure I agree, the WS-Addressing WSDL binding uses "MAY" when discussing including WSDL components in the EPR, there is no obligation. I think most services will only use one transport protocol so I think this feature will not be used often - even if a service does use more than one transport/port there is no requirement to advertise this in the EPR. Also there is no transport bindings available for WS-Addressing - for example the SOAP bindings tells us to take the wsa:Address element and put it into the wsa:To element in the SOAP header but does not tell us what to do with it with regards to the transport protocol (eg most people use the wsa:Address element to create a RequestURI which they set as the POST HTTP Header when using HTTP - this issue has been raised with the W3C TAG[6]). Quoting WS-Addressing: "A Web service endpoint is a (referenceable) entity, processor, or resource to which Web service messages can be addressed. Endpoint references convey the information needed to address a Web service endpoint." To me there is a strong emphasis on singlar. > > * include a recipe for generation of a single IRI from the Address and > ReferenceParameters that can function as an identifier of the resource. > Mark Mc Keown pointed at the W3C Web Architecture description of the use > of URIs which we could borrow from. I am not sure about creating an IRI from the wsa:Address and the wsa:ReferenceParameters. Consider the following EPRs <wsa:EndPointReference> <wsa:Address>http://grid.org/jobs/4654</wsa:Address> <wsa:ReferenceParameters> <DateCreated>Thu Nov 17 16:05:43 UTC 2005</DateCreated> </wsa:ReferenceParameters> </wsa:EndPointReference> and <wsa:EndPointReference> <wsa:Address>http://grid.org/jobs/4654</wsa:Address> <wsa:ReferenceParameters> <DateCreated>Thu Nov 17 13:07:53 UTC 2005</DateCreated> </wsa:ReferenceParameters> </wsa:EndPointReference> If DateCreated is just to inform the service when the EPR was created and is not used by the service for anything else then the two EPRs are for the same WS-Resource. However if I create a name based on a combination of the wsa:Address and wsa:ReferenceParameters I will get two different names, ie I have created URI aliases and divided the network losing some of the goodness of Metcalfes law [7]. cheers Mark [1] http://www.ietf.org/rfc/rfc2396.txt [2] http://www.ietf.org/rfc/rfc3987.txt [3] http://www.w3.org/TR/2005/CR-ws-addr-core-20050817/ [4] http://www.w3.org/TR/2005/WD-ws-addr-wsdl-20050413/ [5] http://www-unix.gridforum.org/mail_archive/ogsa-naming-wg/2005/11/msg00021.… [6] http://www.w3.org/2001/tag/issues.html#endPointRefs-47 [7] http://www.w3.org/TR/webarch/

2 1

Proposal to split "Secure channel" profile
by Andreas Savva 22 Nov '05

22 Nov '05

During the review of the "Basic Security Profile - Secure Channel" today it was pointed out that Section 3.4 (Security Token), Section 4 (SAML Token Profile 1.0) and Appendix D (Key Information Exchange) are 'more basic' than the other parts of the profile and that it would be worth splitting them off in a separate document. Doing so would allow other future security profiles (e.g., an MLS profile) to use these sections without creating unnecessary dependencies with the Secure Channel (TLS) profile. Therefore the proposal is to separate these sections in an "OGSA Basic Security Profile" document. This document would expose the claim required to satisfy the WSRF BP security profile requirements (http://www.ggf.org/namespaces/2005/07/OGSABasicSecurity-1.0) but would have no normative dependency on the WSRF BP. In addition it was proposed that this profile would have explanatory text stating that it is defining an 'anonymous channel' (one requiring no security or authentication for service interaction) and would also expose the following claim: http://www.ggf.org/namespaces/2005/11/OGSABasicSecurityProfile-1.0-Anonymou… (This second proposal is optional and is primarily to reduce the number of security profiles we have to write.) The "Secure Channel" profile will then reference the "OGSA Basic Security Profile" and will expose in turn the following conformance claims: http://www.ggf.org/namespaces/2005/07/OGSABasicSecurity-1.0 (as required for composition with the WSRF BP) and http://www.ggf.org/namespaces/2005/08/OGSABasicSecurityProfile-1.0-SecureCh… Comments on the list, or please join next Monday's call where this proposal is scheduled to be discussed. Andreas >From the minutes: > - 1698: Strictly speaking the features described in section 3.4 and > section 4 are orthogonal to the rest of the profile. Tokens, and > the key exchange mini-specification would apply to both TLS and > MLS. > - If this text is left here then the MLS profile would have to > depend on this profile; or worse, duplicate the same text. > - Frank proposed that if these sections are needed in general then > it might be worth deleting these sections from the Secure > Channel Profiel and adding them to the WSRF Basic Profile. > - Agreed, in principle, to remove the sections from this spec. and > discuss how to make them apply to any profile. > - Andreas proposed that these sections should be part of a Basic > Security Profile and that Profile could then be combined with > the WSRF BP or be referenced by the Channel profiles. The Claim > URI mechanism defined in the WSRF BP allows multiple Security > profiles to be composed with it so there would be no problem > with this approach. > - Hiro proposed that such a Basic Security Profile could also > serve as an 'anonymous' channel profile (one that makes no > statements on channel security) and could also solve the problem > of having a separate, essentially empty, profile document with > no security statements. > - Andreas was tasked to write up the proposal for splitting up the > Secure Channel Profile and send it to the list to collect > feedback from stakeholders not on the call. -- Andreas Savva Fujitsu Laboratories Ltd

1 0

NO call on Wednesday (Nov. 23)
by Hiro Kishimoto 22 Nov '05

22 Nov '05

Hi all, Since Nov. 24 is Thanksgiving, we agreed to have *NO* call on Nov. 23 Wednesday. Next call is Nov. 28th. Nov. 28 (Mon) Architecture & Glossary 1.5 Basic Security Profile discussion MDC presentation review Nov. 30 (Wed) EMS architecture Information model & CIM profile Dec. 5 (Mon) Architecture & Glossary 1.5 Basic Security Profile review Dec. 7 (Wed) Two naming requirement docs review EMS architecture Information model & CIM profile Happy Thanksgiving, ---- Hiro Kishimoto

1 0

Teleconference minutes - 21 November 2005
by Andreas Savva 22 Nov '05

22 Nov '05

Minutes attached. Thanks to Alan Sill for his excellent notes of the AuthZ discussion. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051121/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconfererence - 21 November 2005 ======================================== * Participants Pete Ziu (Northrop Grumman) Von Welch (NCSA) Alan Sill (Texas Tech Univ.) Frank Siebenlist (ANL) Andreas Savva (Fujitsu) Takuya Mori (NEC) Mark Morgan (UVa) Tom Maguire (EMC) Fred Maciel (Hitachi) Hiro Kishimoto (Fujitsu Dave Berry (NeSC) Michael Behrens (R2AD, LLC) Apologies: Ellen Stokes Minutes: Andreas Savva, Alan Sill * November 16 minutes approved with no changes * OGSA AuthZ Joint Call ** Background Alan described OSG, EGEE and made mention of GridShib efforts, and the desire to support a more standards-based approach to attribute-based authorization. A strong desire exists both within the user communities and at the funding agency level, he believes, for a standards-based approach to authorization that can interoperate with and be complementary to the existing standards-based approach to CA operations being taken by the CAOps-WG and the PMA technical community. (cf. http://gridpma.org for the IGTF = International Grid Trust Federation and its member organizations.) He also noted that there is ongoing research and work being done to extend and supplement the "classic PKI" authentication profile, for example with the Short-Lived Credential Service (SLCS) profile being considered by TAG PMA (The Americas Grid PMA) and about to come up for voting there. ** Future directions (OGSA services, federated authentication) Frank said most important task is to come up with an improved authorization query interface. The present one is based on SAML 1.1 and lacks features needed to communicate easily such attributes as groups and roles. Version 2 of the OGSA AuthZ specification needs to define interfaces so such attributes can be communicated more easily. The hope is to leverage part of the work done in the OASIS XACML TC for the XACML 3.0 spec. (Frank is a member of the TC.) The TC has come to some agreement on how to proceed and is preparing to write up WSDL, etc. Ideally this could be used as is provided it fits the Grid requirements. At the last GGF, the two groups had separate face-to-face meetings at the same time, which interfered with progress. Alan noted that there was good attendance at the AuthZ GGF15 wrap-up meeting, nonetheless. Von Welch agreed with the above summary of priorities, but noted that there is a need for far more people and fresh blood. Alan added that he would like to see representation from at least 3 communities: the OSG Privilege Project authors, the LCG Joint Security Group, and members of the Shibboleth community who are interested in working in the direction of international standards. Hiro asked what would be required to use the XACML v3 query i/f with the OGSA WSRF BP. Frank and Tom agreed that the XACML i/f would be complementary to the BP and it should be possible to compose the two. There is no reason to have a WSRF-specific XACML i/f. Hiro asked whether standardizing on the schema or alternatively on a language for defining attribute characteristics is preferable. Alan responded that from his point of view, the latter (an attribute language) is preferable, as schema can become outdated and attribute spaces are by their nature extensible, and that a possible reason for failure of previous AuthZ efforts might be due to attempts to overly specify the schema. (Since it is not possible to do an exhaustive definition of the attributes.) ** OGSA-AuthZ WG status update (specs) - Is there a plan to produce a new version of the Attributes specification? It is important for people who are implementing this specification to come forward and join the discussion. The WG has to see what is being adopted and what needs to be done before moving forward. Alan volunteered to take this discussion to VOMS and try to get people to join. - What is the status of the submitted AuthZ documents? The Attributes document completed its public comment period and was returned back to the authors for revision. There was some uncertainty on the call whether this document was pulled out of the process altogether or whether it was going to move forward after changing its type to Experimental. There was also an issue with making it WSRF based, or combinable with the OGSA WSRF profile. Von will check the status of this document. ** Next steps Hiro suggested to have another joint call in Dec.; it was set for the OGSA call on Dec. 19 (Mon.). Hiro also asked whether AuthZ WG members can attend the next OGSA F2F in Sunnyvale in January (week of 16). - It was pointed out that the AuthZ specific discussion is likely to be occupy a very small slot (1-2 hours) during the 5 day meeting. - Frank will attend in person. - Von and Alan may join by phone if it is not possible to attend in-person. Agreed to advertise both the joint call and the F2F and try to get wider participation. * Profile Definition Review - Tom changed his Affiliation. - Consensus on the call not to add implementation status examples. - Agreed that the change from "In other words" to "For example" in the last sections and related changes in wording are appropriate. - Other minor wording changes. Tom will accept all changes, post a new draf and announce a final call to list, lasting to next week Wednesday. (This is to allow for people who may be on holiday this week.) Tom will also reply to comments on the public forum. * Security Profile - Secure Channel Review - Using version sent out by Hiro to the list. ** Tracker review (Numbers correspond to tracker artifacts) - 1657: added; close. - 1658: MLS is dropped; close. - 1659: No problem using SSL; close. - 1662: Checked that there are no significant changes that affect this profile; updated; fixed. - 1663: Updated to remove dependency; fixed. - 1685: Added secure channel definition: fixed - Does any part of this definition imply encryption? Yes, integrity does. - 1697: Revised the list but the explanatory text still needs work to make clearer what the profile is doing. It is ok to combine some of these items if it will make the explanation easier. - Takuya to draft some text and review with Andreas - 1698: Strictly speaking the features described in section 3.4 and section 4 are orthogonal to the rest of the profile. Tokens, and the key exchange mini-specification would apply to both TLS and MLS. - If this text is left here then the MLS profile would have to depend on this profile; or worse, duplicate the same text. - Frank proposed that if these sections are needed in general then it might be worth deleting these sections from the Secure Channel Profiel and adding them to the WSRF Basic Profile. - Agreed, in principle, to remove the sections from this spec. and discuss how to make them apply to any profile. - Andreas proposed that these sections should be part of a Basic Security Profile and that Profile could then be combined with the WSRF BP or be referenced by the Channel profiles. The Claim URI mechanism defined in the WSRF BP allows multiple Security profiles to be composed with it so there would be no problem with this approach. - Hiro proposed that such a Basic Security Profile could also serve as an 'anonymous' channel profile (one that makes no statements on channel security) and could also solve the problem of having a separate, essentially empty, profile document with no security statements. - Andreas was tasked to write up the proposal for splitting up the Secure Channel Profile and send it to the list to collect feedback from stakeholders not on the call. * UML Tool Choice - No opposition on the list or the call for the Rational choice. - Agreed that there are a couple of things that need to be cleared up, and until that time the choice is still tentative. - Hiro to follow up with Ellen on the IBM liaison and with the GGF Office and make sure that we can use the tool for GGF work. - Mike proposed that CDs should be made available at the next F2F. * OGSA 1.5 review - Postponed due to lack of time. * Next call - OGSA 1.5 review - Basic security profile discussion

1 0

[Fwd: latest ws-naming draft (Re: [ogsa-naming-wg] One more thing)]
by Frank Siebenlist 22 Nov '05

22 Nov '05

Sorry, forgot to cross-post... -Frank.

1 0

Teleconference minutes - 14 November 2005
by Andreas Savva 21 Nov '05

21 Nov '05

Minutes attached. * UML tool selection * Israel Workshop participant from OGSA-WG * Basic security profile review https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051114/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 14 November 2005 ====================================== * Participants Michael Behrens (R2AD, LLC) Hiro Kishimoto (Fujitsu) Takuya Mori (NEC) Andreas Savva (Fujitsu) Frank Siebenlist (ANL) Ellen Stokes (IBM) Jem Treadwell (HP) * Nov 9 minutes approved with no changes * UML tool selection Michael reviewed a number of UML tools and prepared a summary that was sent to the list before the call. http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/11/msg00053.html ** Requirements - Generating code is not a strong requirement for OGSA at this time. - Importing/exporting XMI from other tools probably falls in the nice-to-have category. (But Michael clarified that sometimes even importing portions of diagrams prepared by someone else using the same tool caused problems.) - Community or free editions of some commercial tools often add banner text on printouts. It should count against that tool. - Since the tools must be free other tools such as MS Visio are not reviewed. ** Tool summary - Poseidon: Very slow starting up---when clicking on a project icon it took about 45sec to start up. But after that is quite usable and the functionality is good. - Rose: A big download but the functionality and performance is good. A lot of features. But there are many editions and the RSM version may be sufficient. - It took about 1 week for a reply to the GGF license request. And Michael still has to talk with someone at IBM about receiving a license. - Jude: Also quite good, but would need the Pro version (not free) for import/export. - Visual Paradigm was also quite good. ** Discussion - Preference on the call for Rational. It is a full featured, unlimited, version. It has support for all the features needed and performance is good. Finally IBM's standards license should give all GGF participants access to same version at no extra cost. - In the case of DMTF there is a designated IBM representative within DMTF that participants can apply to and get a license. A similar arrangements should be possible within GGF. Action: Ellen will check who can be IBM's contact within GGF for Rational licenses. (It is probably going to be one of Dave Martin or Jay Unger.) Action: Hiro will send out a short memo on the rough consensus to the list. Ask for comments and make a final decision on the next call. * Israel Workshop participant from OGSA-WG OGSA-WG has had a similar request for participation to a workshop in Israel a few months ago but no one was able to go at that time. This time the proposal is to time the workshop before or after GGF16 since people are going to be nearby. The workshop organizers are flexible about the timing. - Since GGF16 runs from Monday to Thursday and OGSA-WG is planning a F2F on Friday the workshop is probably going to be the week before or the week after. - It would be a good idea to check whether the workshop organizers are willing to pay expenses. Many people have budget restrictions and many not be able to justify it to their companies otherwise. - No volunteer on the call - On a side note, Jem suggested that doing a webcast on OGSA and then providing access to the recording may also be a way to help interested parties engage with OGSA - WS-I has done something similar recently and it seems a good way to share information - OGSA, and in particular Ravi, is already preparing for the MDC presentation Action: Hiro to check with Steve Crumb whether expenses will be covered by the workshop organizers. Action: Hiro to ask Steve Crumb how far GGF can support an OGSA webcast. * Basic security profile review Draft uploaded by Takuya before the call. Reviewed trackers and other changes in the text. - Issue 1685: Added definition of secure channel. Agreed to modify to say 'mutual authentication' instead and also add a more specific word such as 'layer' to transport - Line 105: Add key info exchange to the list - Also since secure channel is defined further up try to use similar terminology here to make clearer what is being addressed by the profile. - Issue 1663: Deleted text on normative dependency to WSRF BP. - Should also delete the 'ogsa-bp' namespace from Table 1 (not used) - And the 'wsse' namespace; it is not used in main document and there is a separate table in the appendix that includes it. - On line 118 and also in the Abstract there is some text that still seems to imply sole use of this profile by the WSRF BP. Needs revision. Andreas volunteered to review the new text. - Issue 1662: Decided to use the latest version of the spec. - Issue 1660: Verified, closed. - R0321: Is this compliance statement needed? It seems MLS related and not needed by TLS. - Takuya will check whether it is needed; delete otherwise. - Plan: - Prepare a new draft by Wed - Do the final review next Monday - Make the final call after that and submit by Nov'30 - (Cannot do earlier given the Thanksgiving holiday) * Glossary review Jem has followed up on some issues with the submitters and confirmed that no action is needed. - Issue 1159 : no action; close - Issue 1333 : no action; close - Further review postponed. - Agreed that from now on a 10-15 minute slot must be reserved on *each call* for a brief glossary review. * Next call - Per agreed schedule. - Note: NO CALL on Wednesday, 11/23 (Thanksgiving holidays)

3 2

Proposed agenda for Nov. 21st call
by Hiro Kishimoto 21 Nov '05

21 Nov '05

Hi all, The following is a proposed agenda for OGSA-WG telecon on Nov. 21st Monday from 4pm to 6pm (CST). 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: 1121 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 (Nov. 16) https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051116/en/1 Agenda bashing 2) OGSA-AughZ WG joint call (20 min) OGSA-AughZ WG status update (proposed specs, re-charter) Future directions (OGSA services, federated authentication) 3) Basic Security Profile document *final* review (40 min) Takuya uploaded revised draft to GridForge https://forge.gridforum.org/projects/ogsa-wg/document/draft-ggf-ogsa-basic-… > <Basic security profile - secure channel - submission plan> > - Prepare a new draft by Wed (done) > - Do the final review next Monday (Nov. 21) > - Make the final call after that and submit by Nov'30 > (Cannot do earlier given the Thanksgiving holiday) 4) common UML tool selection (20 min) Make decision on common UML tool > - Preference on the call for Rational. It is a full featured, > unlimited, version. It has support for all the features needed and > performance is good. Finally IBM's standards license should give > all GGF participants access to same version at no extra cost. Mike's tool comparison summary http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/11/msg00053.html Hiro's proposal (Rational) http://www-unix.gridforum.org/mail_archive/ogsa-wg/2005/11/msg00068.html 5) OGSA architecture and glossary 1.5 (30 min) Infrastructure section review (minus Naming) Acronyms in Glossary 6) Profile definition public comments review (if time permits) Greg passed back "profile definition" to ogsa-wg accept or reject all public comments https://forge.gridforum.org/forum/forum.php?forum_id=568 Jem and Tom are working on the new draft 7) Wrap up AOB <NEXT CALL> Nov. 23 (Wed) NO call (Thanksgiving) Nov. 28 (Mon) Architecture & Glossary 1.5 Profile Definition Update Nov. 30 (Wed) EMS architecture information model & CIM profile Dec. 5 (Mon) Architecture & Glossary 1.5 Profile Definition *final* review Dec. 7 (Wed) two naming requirement docs review EMS architecture, information model & CIM profile Telecon schedule: https://forge.gridforum.org/projects/ogsa-wg/document/telecon_schedule/ -- Hiro Kishimoto

1 0

Once upon a time or two ...
by David Snelling 18 Nov '05

18 Nov '05

Folks, Once up on a time or two Frank wrote: > Without the proper uniqueness guarantees for the wsa:Address, the use > of ws-naming's AbstractName is meaningless. > > The EPR with an embedded AbstractName essentially describes a binding > between the Address and the AbstractName. > One could argue that this binding is a bit of a flaky assertion > without any way to specify time-validity or issuer. > As a result, one can not see from an EPR alone when it was issued or > whether it is still valid or not. > > An EPR-minter can decide to create a new EPR for a resource and reuse > an Address that was used for an other resource before. > This would yield the undesirable situation that you would have two > EPRs with identical Addresses and two different AbstractNames > associated with different resources, and the client would have no way > to see which one of the EPRs is valid... > > For example, if I have two EPRs with the same Address, where one EPR > includes an AbstractName that identifies MyBankAccount and the other > includes an AbstractName identifying YourBankAccount, then one of us > will not be happy with that situation... > > In order to avoid this ambiguity, we need the guarantee from the > EPR-minter that Address values will not be reused for different > resources: for all times, the Address should either refer to that one > and only resource, or it should be invalid (and it is allowed to > change between those two states). > Furthermore, the EPR-minters should ensure that globally unique > Addresses are used for a resource such that different EPR-minters do > not (accidentally) use the same Address for different resources. > The described uniqueness properties of the Address constitutes a > required EPR-minter profile for the use of AbstractNames. > This issue has yet to be addressed to my satisfaction. There have been a number of email exchanges in response to it on several occasions, but none of these threads actually deal with the issue. Put simply, if you don't put globally-unique-in-space-time requirements on your address (GSR in OGSI speak*) then any similar requirements you put on an Abstract Name (GSH in OGSI speak) are wasted. I believe that answering this issue will help clarify many of the other threads (miss) associated with this issue. In particular, I believe Frank is right. Therefore, if an EPR is going to be a WS-Name, the wsa:Address MUST have the same uniqueness properties as the Abstract Name. Then if the answer to the question, "Why do this uniqueness stuff twice?", is "I don't know!", then it seems logical to me that a WS-Name is a profiled EPR along the lines proposed by Tom M. Thoughts? Historical Footnote: * Note: OGSI addressed this issue in GSRs by requiring that clients could detect when the GSRs were stale and that services reject them if a client attempted to use them. GSHs had uniqueness constraints placed on them. -- 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)

1 0

RE: naming issues resolution process discussion (Re: [ogsa-wg] Proposed agenda for Nov. 16 call)
by Ian Foster 17 Nov '05

17 Nov '05

Andrew: I'm not ignoring you: either I hadn't heard you express the use cases below (I haven't been on all the calls) or I hadn't internalized you doing so. I appreciate you taking the time to write them down: this information is very helpful. Three comments on the use cases: 1) These use cases, like Chris Smith's, do not imply a need for names that are "globally unique in time and space." The only requirement is that names be unique with respect to the scope of the activities that the user wants to monitor or track. This might seem a minor point, but I think it's an important one: as Chris pointed out, a sensible key to use as a name in #1 could be, in some circumstances, e.g. the LSF jobid. That choice of key is prohibited by the current WS-Name definition. 2) In use case #1, I think you assume that a notification has the form "job with epr E has status S." Certainly, if that was the case, then you'd face the problem of determining which job that EPR referred to, something that you can't do without the ability to compare EPRs. But in WS-Notification, at least, when a client subscribes to notifications it can supply, as the callback address, an EPR to a unique WS-Resource. So the notification delivers the message "status S" to the subscription for job with epr E. Thus, there is no need to include a key in the EPR for the purpose of disambiguation. 3) Use case #2 makes sense to me. I could also do this without an AbstractName, by passing around an XML structure containing an application-specific key and the EPR--or, more likely, embedding the EPR in a larger application-specific structure that I have created for other purposes. But clearly an AbstractName could usefully be applied here. Ian. At 12:03 PM 11/16/2005 -0500, Andrew Grimshaw wrote: >Ian, > >I did give a scenario you just chose to ignore it. Here are two: > >1) As a client of BES I want to be able to keep track of the activities I >start. Suppose I have one hundred going. I want to build a data structure >that keys off of the activity. Id like the handle I get back from the BES >container (which is basically acting like a factory) to have a keyin it I >can use so that when I get notifications about the activity, or some other >services wants to talk about the activity I have some way to associate and >search for the activity information I am keeping. > >2) Using the WS-name (specifically the abstract name) to correlate >information flows about an activity. (This is the example I have used >several times.) > > > >The requirement in both cases is to be able to identify when two EPRs >refer to the same activity. > > > >Andrew > > > >---------- >From: Ian Foster [mailto:foster@mcs.anl.gov] >Sent: Wednesday, November 16, 2005 9:33 AM >To: Hiro Kishimoto; Andrew Grimshaw; Tom Maguire; Frank Siebenlist; Smith >Chris; Mark Morgan >Cc: Savva Andreas >Subject: Re: naming issues resolution process discussion (Re: [ogsa-wg] >Proposed agenda for Nov. 16 call) > > > >Hiro: > >Ahead of the call, I'd like to raise the question again of what >application requirements motivate the use of WS-Names in BES. I asked this >on the last call, and my question wasn't answered. I asked the question >again via email, and Chris replied with what turned out to be a >requirement for something different than WS-Names. I think it would be >really helpful to have a list of requirements as a basis for discussion. > >Ian.

1 0

Teleconference minutes - 16 November 2005
by Andreas Savva 17 Nov '05

17 Nov '05

Minutes attached. https://forge.gridforum.org/projects/ogsa-wg/document/minutes-20051116/en/1 -- Andreas Savva Fujitsu Laboratories Ltd OGSA Teleconference - 16 November 2005 ====================================== * Participants Andrew Grimshaw (UVa) Hiro Kishimoto (Fujitsu) Allen Luniewski (IBM) Fred Maciel (Hitachi) Tom Maguire (IBM) Mark Morgan (UVa) Takuya Mori (NEC) Andreas Savva (Fujitsu) Frank Siebenlist (ANL) Jem Treadwell (HP) Apologies: Steven Newhouse, Ellen Stokes, Michael Behrens Minutes: Andreas Savva * November 15 minutes approved with no changes * January 2005 F2F Update Reminder: Scheduled for week of Jan 16 at Sunnyvale (Fujitsu) Agenda discussion: - ByteIO: A one hour slot should be sufficient to give an update on group activities. - The specification documents have already been submitted and it is expected that by January the main focus will be on interoperability testing. - Naming session - Not sure if it should include RNS. Andrew will check Manuel's plan and the status of the RNS specification. - Allocate a WS-Management BP slot? - There has been no update---delayed due to other developments. - An MS volunteer to lead this effort is the main requirement. - Tom will ask Dave Snelling and Tony Hey for an update. - Allocate OGSA & Glossary 1.5 slot? - It should not be necessary. Other actions: - Andreas to re-check network setup at Fujitsu * GGF16 F2F Update - Planning a F2F on Friday after GGF16 - No confirmation from Athens University for a room yet. - Confirmed room at IBM. It is a 10 minutes ride from the hotel. - No discussion on how many sessions to have yet. Andrew suggested doing an "OGSA town hall" meeting to get more feedback from the community. [This would be in addition to or in place of Outreach.] * Naming issue resolution process ** Review of status - The BES-WG has not had a chance to discuss the naming issue on a teleconference yet. Given that this week is SC05 and next week is Thanksgiving it will take a few weeks. - The OGSA Naming WG will also have to discuss the related issue of the AbstractName definition. - The wider discussion within OGSA on Naming policy is more related to BES and not so much to the WS-Naming definition. Agreed that it will likely take about 3 weeks to reach a decision due to the various schedule issues, and given that some people prefer to discuss the issues on teleconfs rather than using e-mail. ** Next steps - Accepted Hiro's proposal to create a document (two in fact) on the requirements and issues and use it to drive the consensus process - Get a shared understanding of issues, requirements and people's positions. 1. Andrew and Mark for the OGSA-Naming WG will summarize Naming requirements and issues - Including issues from the list discussion and also including a separate set of OGSA-DAI Naming requirements 2. Tom will add issues from the list discussion to the policy document, including BES related issues. * EMS discussion - Postponed technical discussion; no quorum. - Hiro and Andreas are working on refining the scenario list in section 3. They will send a proposal to list. * Information Model discussion - Postponed technical discussion; no quorum. - Andrew will talk with Ellen and Fred on how best to continue. * Glossary review - Messaging service: keep as is - Metadata: check the OGSA document. If there has not been any change then leave as is. (Andreas and Jem) - portType: delete WSDL 2.0 definition. Check the OGSA document and delete any mention to WSDL 2.0, if it exists. (Andreas and Jem) - Provisioning: keep as is. Maybe not the only definition but it is the way it is used in the OGSA document. - Task: Review the OGSA document and delete if not used - UUID: leave as is - WSDL: Accepted Jem's proposal - Acronyms: Need to review separately. In principle add the ones defined in OGSA or grid specific ones. No need to add the general ones. - IRI: May be added if it ends up being used in the OGSA document. A reference to the appropriate RFC number should be sufficient. * UML Tool choice - Rational is the choice from the last call. - Review and finalize decision next call. * Next call ** Monday - UML tool - Basic Security Profile - AuthZ joint call - Profile Definition public comment revision - OGSA 1.5 Infrastructure section review (minus Naming) ** Wednesday (No call)

1 0