Date: July 18th, 2006

Chris Jordan/GFS Working Group presentation of RNS and GFS

Participants:
Jay Unger, IBM
Ellen Stokes, IBM
Ian Foster, ANL
Ravi Subramiavan, Intel
Hiro Kishimoto, Fujitsu
Andreas Savva, Fujitsu
David Snelling, Fujitsu
Mark Morgan, UoV (via phone)
Dave Berry, NESC (via phone)
Chris Jordan, SDSC (via phone)

1. RNS presentation 

There is a question about return values of the remove operation - 
	We should allow for multiple returns, but the document doesn't necessarily make it explicit
	Probably add more explicit explanation of multiple returns from a remove, or require an exact regex match

Move operation semantics
	This is one of the major concerns expressed in the meeting - the issue is primarily related to the
	atomicity of the operations. The current document says that RNS implementations "SHOULD" make an effort to
	guarantee that move and delete operations will be atomic, but doesn't require it. From the general discussion,
	it seems clear that the specification may need to require atomicity instead of just suggesting it

Need better explanation of the overall hierarchy, including multiple RNS services
	There was some question about how the hierarchical organization of RNS services work, particularly with
	multiple embedded RNS services within a single hierarchy. It is probably a good idea to add more explicit
	explanation of how the use of RNS to federate other RNS hierarchies works in practice.

Hiro points out that we need a WSRF/Basic Profile rendering of the RNS service

Discussion of flexibility of RNS in addressing resources and in constructing multi-tier naming schemes - 
	WS-Naming includes the ability to do multi-tier naming with WS-Addresses, and RNS as a specification allows
	for any form of WS-Address, so it is possible to have abstract names or their equivalent within an RNS
	implementation 

Discussion of the use of RNS - RNS is intended to provide a basic service with flexible degrees of functionality,
	and is explicitly meant to be built upon for GFS and other purposes, via the use of "profiles" requiring
	more specific types of addresses and more specific types of information included in the attached XML.

2. GFS presentation:

Discussion of whether or not the GFS service should provide a Data Access service or whether it is just a 
	sophisticated kind of data-oriented resolution service. GFS group intends to provide some guidelines for
	the provision of simple data access via ByteIO or something similar, but it is not clear at this point
	exactly how far the GFS-WG will go in defining data access mechanisms for a Grid File System

Discussion of Information Model - Chris pointed out that the information model should be useful in helping GFS
	and OGSA-Data in general define how data resources are described within the GFS' underlying RNS components
	Will schedule a time to have further discussion of Information Model on OGSA-WG calls

Discussion regarding the use of GFS as it relates to job execution, possibly removing the need for explicit
	staging of data - Chris will get first version of EMS scenarios document from Hiro.