- acs-wg - lists.ogf.org

Agenda for the Call on Aug 10 Wed 20:00 EDT/Aug 11 Thu 9:00 JST
by Keisuke Fukui 11 Aug '05

11 Aug '05

Folks, Here is an agenda for the call tomorrow. See you there! * Watch out for the irregular call number. Dial-in Number: **** 1-949-373-0345 (Irvine, CA) **** ### Proposed Agenda 1. Role call, note taker & time keeper, agenda bashing. (5 min) 2. Review of the minutes of day 2 for F2F. (5 min) - Correction and approval for the minutes. 3. Security updates from Aug 3 meeting by Mike (10 min) - We will conclude what needed to be specified as a normative part in ACS. See more detail in my previous post on this. Date: Wed, 10 Aug 2005 19:01:59 +0900 (Japan time) - Does it confirm our understanding at Aug F2F? 4. Data replication use case (10 min) - Does the use case presented by OGSA-DATA WG go with our specifications? If it does, what is potentially missing in our specification? Please refer to my previous post on this in reply to Pete's message. Date: Wed, 10 Aug 2005 18:13:50 +0900 (Japan time) - Review the data replication diagram to be posted by Sachiko. 5. Schedule for drafting a specification (10 min) - Proposed schedule attached. - Who can contribute to what part in drafting? 6. Updates (10 min) Questions and Answer for the NAREGI PSE diagram (posted by KF on Aug. 3 JST). If any others,... 7. Wrap up, Next meeting(5 min) Sachiko and I cannot make it for next week. Can we skip the one for next week? Total: 55 min ### Logistics for the call Date & Time: Aug 10 Wed 20:00 EDT/Aug 11 Thu 9:00 JST Dial-in Number: 1-949-373-0345 (Irvine, CA) Participant Access Code: 7771111 -Keisuke

1 1

invalid access code for meeting?
by pete＠ziu.net 11 Aug '05

11 Aug '05

I am attempting to dial in, but getting an invalid access code. Mike sends his regrets, as he is unable to attend tonights meeting. Pete Ziu 571.235.0208 (c) mailto:pete@ziu.net (h) mailto:5712350208@tmomail.net (sms)

2 1

Meta information for AA
by Keisuke Fukui 10 Aug '05

10 Aug '05

Folks, We discussed about the "Administrative information" to be with Creation of the "AA instance". After discussed with Sachiko, we believe AA instance should have two class of meta information; one that is supplied by client and described in AAD and the one that is augmented by ACS on creation and thereafter. The latter will include creation time and owner information. Owner information will come from the security token or user identity information contained in each ARI request, probably in a SOAP header part. That information may be created by system security entity on prior user authentication and may be an opaque data structure that can be fully interpreted by only the security entity. We will additionally discuss this in today's call. -Keisuke

1 0

RE: [acs-wg] Replication discussion material
by Ziu, Peter 10 Aug '05

10 Aug '05

Sachiko, to answer your questions (got carried away last email), see inserted comments... -----Original Message----- From: owner-acs-wg(a)ggf.org [mailto:owner-acs-wg@ggf.org] On Behalf Of Sachiko Wada Sent: Wednesday, August 10, 2005 12:58 PM To: acs-wg(a)ggf.org Subject: Re: [acs-wg] Replication discussion material Hi Pete, I read your document. Slide 3: This diagram seems to represent a generic replication concept. Concerning ACS replication, I assume that an ACS corresponds to a Replication Element. Am I correct? -- Not really. See previous email (it can be applied however). This content may be more appropriate for the ogsa-d team to comment on. If so, GUID is AA ID or AA EPR in ACS term, and ElementValue is Application Content. Yes, I agree that ACS should handle change history meta data. -- As I wrote in the previous mail, I prefer the replication specific information be maintained by an outer replication service rather than ACS itself, since those information varies according to the QoS of the replication service. For simplicity sake I agree, however, something will need to coordinate the control over distribution of ACS content. Where do you suggest this is accomplished? It does not seem natural to do this outside of the ACS interface. Perhaps some type of ACS management interface separate from ACS basic functions? Slide 4: Is this a scenario of replicating multiple AAs controled by a single policy? -- It is a structure and methodology ( described in last email) that is intended to support multiple ACS's replicating multiple AA's, to a level of granularity as small as ACS-WG desires. Sachiko At Wed, 10 Aug 2005 11:18:43 -0400, Ziu, Peter wrote: > > [1 <text/plain; us-ascii (quoted-printable)>] Sachiko, this is very > helpful, as usual, thanks so much for the valuable input. I have > attached a few new slides that I hope might serve to provide the > necessary data elements required by a replicative data storage > service. I had hoped to include all of the rules that would apply to > maintaining the element values for bi-directional replication (when > updating, when creating, when deleting), but they are fairly complex, > and I just haven't found adequate time so far. But, for what it's > worth, (see attached). > > Pete. > > -----Original Message----- > From: owner-acs-wg(a)ggf.org [mailto:owner-acs-wg@ggf.org] On Behalf Of > Sachiko Wada > Sent: Wednesday, August 10, 2005 11:07 AM > To: acs-wg(a)ggf.org > Subject: [acs-wg] Replication discussion material > > Pete and all, > > Here is the input material for the replication discussion. > > The purpose of this document is to examine the feasibility of > constructing a replication service on top of ACS. > There are the two scenarios: > Scenario 1: One-way synchronization, triggered by modification of > the master ACS. > Scenario 2: Two-way synchronization, triggered periodically. > > Conclusion: > The replication service can work with ACS if it supports the update > event notification as far as considering the two scenarios. > > My impression and proposal: > The replicator is supported to be highly sophisticated especially in > case of bi-directional synchronization. So I propose that ACS should > provide infrastructural functionalities such as notification mechanism > for the outer replication services instead of supporting replication > capability by itself. > This time I examined two scenarios to find out that the event > mechanism is required to realize them. There may be more replication > scenarios which have requirements for ACS spec. For example, the > capability to get change histories of an AA should be useful. > > Your comments are very much welcomed. > > Sachiko > > [2 ReplicaElement.ppt <application/vnd.ms-powerpoint (base64)>] >

1 0

RE: [acs-wg] Replication discussion material
by Ziu, Peter 10 Aug '05

10 Aug '05

The ReplicaElement is independent of any level of granularity of replication. For example, in your text below you see a one to one relationship between AA and ReplicaElement (AA as the value for DataElementValue[0] within a ReplicaElement). Since a ReplicaElement can only be added and deleted, and not partially edited, any modification to the AA would be an entire replacement. So, if for example we made the AA a collection of ReplicaElements, with each ReplicaElement being, say, a jar within the AA (many jars == many ReplicaElements), changes to just a jar within an AA can be replicated which would save replication time and bandwidth. So, you can start to image a process by which replication is a procedure in which two replicas (A and B) compare each others change lists: A sends adds to B B adds B sends adds to A A adds A sends deletes to B B deletes B sends deletes to A A deletes A sends mods to B B sends mods to A A and B identify any ReplicaElements modified on both sides A and B create duplicates and notify modifiers, force overwrite (he who saves last wins), or throw an error (whatever the conflict resolution policy is). B mods A mods There is a lot more to define in the way of how adds, mods and deletes are accomplished, and how the change or history lists are maintained and cleaned up. However, you can start to see that as long as the latency period between replication events is tolerable by the data use case, the timed or forced replication event (and even an event driven model) is a model that is lightweight on the network, and tolerable of network outages/intermittent connectivity, high traffic loads, and can be interrupted, halted and restarted. I think it is critical that the entire AA does not need to be replaced to keep replicas updated. Pete -----Original Message----- From: owner-acs-wg(a)ggf.org [mailto:owner-acs-wg@ggf.org] On Behalf Of Sachiko Wada Sent: Wednesday, August 10, 2005 12:58 PM To: acs-wg(a)ggf.org Subject: Re: [acs-wg] Replication discussion material Hi Pete, I read your document. Slide 3: This diagram seems to represent a generic replication concept. Concerning ACS replication, I assume that an ACS corresponds to a Replication Element. Am I correct? If so, GUID is AA ID or AA EPR in ACS term, and ElementValue is Application Content. Yes, I agree that ACS should handle change history meta data. As I wrote in the previous mail, I prefer the replication specific information be maintained by an outer replication service rather than ACS itself, since those information varies according to the QoS of the replication service. Slide 4: Is this a scenario of replicating multiple AAs controled by a single policy? Sachiko At Wed, 10 Aug 2005 11:18:43 -0400, Ziu, Peter wrote: > > [1 <text/plain; us-ascii (quoted-printable)>] Sachiko, this is very > helpful, as usual, thanks so much for the valuable input. I have > attached a few new slides that I hope might serve to provide the > necessary data elements required by a replicative data storage > service. I had hoped to include all of the rules that would apply to > maintaining the element values for bi-directional replication (when > updating, when creating, when deleting), but they are fairly complex, > and I just haven't found adequate time so far. But, for what it's > worth, (see attached). > > Pete. > > -----Original Message----- > From: owner-acs-wg(a)ggf.org [mailto:owner-acs-wg@ggf.org] On Behalf Of > Sachiko Wada > Sent: Wednesday, August 10, 2005 11:07 AM > To: acs-wg(a)ggf.org > Subject: [acs-wg] Replication discussion material > > Pete and all, > > Here is the input material for the replication discussion. > > The purpose of this document is to examine the feasibility of > constructing a replication service on top of ACS. > There are the two scenarios: > Scenario 1: One-way synchronization, triggered by modification of > the master ACS. > Scenario 2: Two-way synchronization, triggered periodically. > > Conclusion: > The replication service can work with ACS if it supports the update > event notification as far as considering the two scenarios. > > My impression and proposal: > The replicator is supported to be highly sophisticated especially in > case of bi-directional synchronization. So I propose that ACS should > provide infrastructural functionalities such as notification mechanism > for the outer replication services instead of supporting replication > capability by itself. > This time I examined two scenarios to find out that the event > mechanism is required to realize them. There may be more replication > scenarios which have requirements for ACS spec. For example, the > capability to get change histories of an AA should be useful. > > Your comments are very much welcomed. > > Sachiko > > [2 ReplicaElement.ppt <application/vnd.ms-powerpoint (base64)>] >

1 0

RE: [acs-wg] Replication discussion material
by Ziu, Peter 10 Aug '05

10 Aug '05

Sachiko, this is very helpful, as usual, thanks so much for the valuable input. I have attached a few new slides that I hope might serve to provide the necessary data elements required by a replicative data storage service. I had hoped to include all of the rules that would apply to maintaining the element values for bi-directional replication (when updating, when creating, when deleting), but they are fairly complex, and I just haven't found adequate time so far. But, for what it's worth, (see attached). Pete. -----Original Message----- From: owner-acs-wg(a)ggf.org [mailto:owner-acs-wg@ggf.org] On Behalf Of Sachiko Wada Sent: Wednesday, August 10, 2005 11:07 AM To: acs-wg(a)ggf.org Subject: [acs-wg] Replication discussion material Pete and all, Here is the input material for the replication discussion. The purpose of this document is to examine the feasibility of constructing a replication service on top of ACS. There are the two scenarios: Scenario 1: One-way synchronization, triggered by modification of the master ACS. Scenario 2: Two-way synchronization, triggered periodically. Conclusion: The replication service can work with ACS if it supports the update event notification as far as considering the two scenarios. My impression and proposal: The replicator is supported to be highly sophisticated especially in case of bi-directional synchronization. So I propose that ACS should provide infrastructural functionalities such as notification mechanism for the outer replication services instead of supporting replication capability by itself. This time I examined two scenarios to find out that the event mechanism is required to realize them. There may be more replication scenarios which have requirements for ACS spec. For example, the capability to get change histories of an AA should be useful. Your comments are very much welcomed. Sachiko

2 1

RE: [acs-wg] no one on call - (8/9 8pm EST)
by Ziu, Peter 10 Aug '05

10 Aug '05

No problem at all. Talk to everyone tonight :-) -----Original Message----- From: owner-acs-wg(a)ggf.org [mailto:owner-acs-wg@ggf.org] On Behalf Of Keisuke Fukui Sent: Tuesday, August 09, 2005 11:06 PM To: pete(a)ziu.net Cc: acs-wg(a)ggf.org Subject: Re: [acs-wg] no one on call - (8/9 8pm EST) Pete, I was to make a reservation on Wednesday your time. I was in another meeting today at that time and was not aware of it by now. I'm so sorry for my wrong arrangement and your time. (_o_) I will take more care next time. -Keisuke pete(a)ziu.net wrote: > Is the call tomorrow? > > Pete Ziu > 571.235.0208 (c) > mailto:pete@ziu.net (h) > mailto:5712350208@tmomail.net (sms) >

1 0

Security
by Michael Behrens 10 Aug '05

10 Aug '05

<>I was able to talk with Rebekah last week. She is not currently involved with GGF however she worked on a security issue using grids for her Masters and was involved with the OGSA-Auth-WG at that time. She is an OASIS member and has participated in the security groups. The entire WS security architecture seems overly complex to me and is focused on static definitions or rules. There are some efforts to simplify the process with a new spec called WSPL - we'll need to research that. If a "service" wants to enforce access, then SAML+XACML can be used. Some services would most likely provide their own policy enforcement point (PEP), requiring that the service provide an auxillary service which would be SAML compliant. Therefore, it seems that an ACS implemetnation might need to implement one. <> It seems that "attributes" are more important than identity and roles in the WS Security mindset. I believe the thought is that roles are just other attributes and identity is a unique set of attributes. Someone please correct me here if this is wrong or overly simplified. This contrasts with the J2EE world where roles can be declared by the web.xml and then used externally to block requests or within the authenticated request processing internally for authorization decisions (isUserInRole() method). Whether or not an ACS implementations provides a PEP service might be irrelavant as long as the provided XACML can be passed along and processed - so perhaps it can be just an implemtation detail and our spec only needs to ensure that a security policy document (using a generic term) can be supplied and updated. References: http://research.sun.com/projects/xacml/wspl_intro.pdf http://sunxacml.sourceforge.net -- Michael Behrens R2AD, LLC (571) 594-3008 (cell) *new* (703) 714-0442 (land)

2 1

Re: [ogsa-d-wg] [acs-wg] Data Use Case Scenarios document
by pete＠ziu.net 10 Aug '05

10 Aug '05

Hi Keisuke and Mike, I read the current architecture draft ogsa-d-wg has up on their site, and there appears to be no conflicts. They do mention non-master replication in the context of "peer-to-peer". I refered to these a little differently in terms of "push", "pull", and "bi-directional". Mike, did you find the use cases up on ogsa-d or just through communications with Steven? I am working to continue to add detail to the replication presentation. I am attempting to define a "ReplicaElement" structure which will have properties of a unique instance id, replica id, the actual value of the data, modification and author history, and security constraint data. This one structure should be able to be used to represent a piece of data, a collection, a graph (tree), and a database, for a collection of replicas. Hopefully I can get this out before ogsa face2face to help stimulate the replication topics. Pete Ziu 571.235.0208 (c) mailto:pete@ziu.net (h) mailto:5712350208@tmomail.net (sms) To Michael Behrens <behrens(a)r2ad.com>, acs-wg(a)ggf.org cc bcc Subject Re: [ogsa-d-wg] [acs-wg] Data Use Case Scenarios document Keisuke Fukui <kfukui(a)labs.fujitsu.com> Sent by: owner-acs-wg(a)ggf.org 08/09/2005 04:28 PM ZE9 <font size=-1></font> Hi Mike # I removed ogsa-d-wg from recipients since non-subscriber post will # be rejected:-) Thanks for a heads up! So they include a data replication use case in their scope. Did you find any conflicts in their doc, especially between their requirements and our current specification? -Keisuke Michael Behrens wrote: > Albiet a bit late, I just read the use-case document - looks good. With > regard to replication, it seems that the ACS-WG might need to consider > that portion so I'm also CC'ing this to the ACS team. I presume the > use-case is available from the OGSA-D-WG site. > Thanks! > > Stephen Davey wrote: > >> Hi everyone, >> Attached is the beginnings of a list of Data Use Case Scenarios, which >> also includes the template sub-sections for each use case described. >> >> I have basically taken the original OGSA use case template and merged >> the "Use Case Situation Analysis" section into the "Summary" section 2.1 >> and renamed section 2.4 slightly. I have also deleted sections 2.5 & 2.6 >> since security and performance considerations will be part of the Data >> Architecture document and would probably have just led to repetition. >> This then leaves the sections: >> 2.1 Summary >> 2.2 Scenarios >> 2.3 Involved Resources >> 2.4 Functional Design >> 2.5 References >> >> Hopefully these sections will be all that is needed for the Data >> (infrastructure) Use Cases that we have. Any comments can be discussed >> on Wednesday 15th June. >> >> Cheers, >> Stephen. >> >> ------------------------------------------------------------------- >> Stephen Davey, NextGrid Software Architect, >> National e-Science Centre, >> 15 South College St., Edinburgh, EH8 9AA, UK >> Tel: +44 131 6 509820 >> >> >> >> > >

2 1

no one on call - (8/9 8pm EST)
by pete＠ziu.net 10 Aug '05

10 Aug '05

Is the call tomorrow? Pete Ziu 571.235.0208 (c) mailto:pete@ziu.net (h) mailto:5712350208@tmomail.net (sms)

2 1