Minutes of the OGSA Data WG telcon, November 9th 2005

1) Early discussion 

* Roll call 
Dave Berry, NeSC (Note taker)
Stephen Davey, NeSC
Chris Jordan, SDSC
Ann Chervenak, ISI
Peter Kunzst, CERN
Allen Luniewski, IBM
Andrew Grimshaw, UVa

The minutes and agenda were approved.


2) Action report 

Completed actions:

- Dave to ask Hiro about a room at the Sunnyvale F2F and plans for Athens F2F. [Hiro has requested a room at Sunnyvale.  At Athens, OGSA will meet on Thursday pm and Friday after GGF16].
- Dave to chase Peter re progress. [Peter has sent a current draft.]  
- Allen to update the federation section in the light of comments.
- Dave to put reports from GGF on GridForge.
- Peter to rewrite storage management section to reflect changes from GSM-WG.
- Allen to write text about policy.
- Allen to write an overview section on security.

Ongoing actions:

- Ann to check the Access section for suitability for file replication.
- Mario to update the Access section and make text available for comment.
- Section authors to add security notes to their sections.
- Dave to revamp section 3 of the architecture document.
- Everyone to talk with your contacts to get more participation in this WG.
- Allen/Dave to contact David Martin & Hiro Kishimoto to get reviewers & expert participation (after internal reviews). 
  
New actions:

- Ann to update replication section.  
- Stephen to update replication scenarios.
- Allen to advise Stephen on how to address database replication in the scenarios document.

3) Progess & planning update.

Update on document writing, plans for telcons and F2F. 

Naming?


4) Review of replication section and associated scenarios

Ann noted that the first diagram in the scenario combines the replication service (that does the replication) and the catalog service.  The second diagram separates these, which better reflects the desired design.  Also, it is better to use the term "discovery service" rather than replica catalogue.

Dave asked whether the discovery service is different from a general discovery service>

Peter mentioned that RNS already deals with names, hierarchy and discovery.  So replica service is an instance of this.

Allen: replicas may have different attributes in a non-write-only service.

Second scenario reflects a certain model, where the replication service hides everything.  Ann notes that the architecture document doesn't address this.  IN the first scenario, the two services should sit side-by-side.  In the second scenario, the replica catalog should not call the data transfer service.

In the second scenario, the replica discovery service might not be a full discovery service.  This scenario may be keeping existence of replicas secret, so if its using a general discovery service there will be a security concern.  Alternatively, it might use a purely local data discovery service.  

What about a validation service; should this be reflected in the scenarios?  Ann suggests that his might be more general.  Peter thinks its a good place to put it, at least for now.  There is some work going on in Italy.  Validation means checksum in these cases.

What about consistency?  Should we add a third scenario?  How do we illustrate the consistency management in the diagram?

Dave suggested that the operations in the document should be expressed in more detail, to match the other sections.  

Andrew: replication could be done be resolving a renewable reference to get a list of replicas.  Does renewable references give you the ability to choose among the references, via specifying QoS policies?

Andrew raised the question of RNS, which specifies the translation from strings to EPRs.  It is a large specification: what does data think of it?  E.g. should iterators be removed?
Everyone to comment on draft RNS specification.

Replication is a tool by which graceful degradation can be implemented.  Allen to add a note to this effect in the data access section.

Ann to update replication section.  
Stephen to update replication scenarios.
Allen to advise Stephen on how to address database replication in the scenarios document.
Future questions to address:
- Identify where work is needed on metadata or on naming conventions  
- Graceful degradation  

5) Wrap up

Next meetings:

Nov 16th:	Storage
Nov 23rd: 	No call? (Thanksgiving, Dave travelling)
Nov 30th:	Scenarios document
Dec 7th:	RNS?  (Allen on holiday).