[ogsa-naming-wg] GGF/OGSA standards for hierarchical namespaces

[Christopher Jordan]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


All,

Forgive the wide distribution on this e-mail, but this issue seems to  
be to be both extraordinarily important to the future of GGF/OGSA  
standards efforts and also in a state of either limbo or paralysis.  
The topic I'm addressing here, both in my capacity as the secretary  
of GFS-WG and as a generally interested participant on a few  
different GGF working groups, is the question of adopting a single,  
possibly minimal, standard for creating hierarchically organized  
collections of pointers (WS-Names? GSR/GSHs, to date myself?) to   
"resources", where the term "resource" could denote a service  
providing access to a collection of files, computational resources,  
or database records (that's a non-exclusive list), and where some  
items in the hierarchy could actually represent directory-like  
structures, i.e. containers for other collections of resources.

The way I got involved in this discussion through the Grid File  
Systems-WG, which at the time was bringing the RNS specification  
forward for final approval as a GFD. Subsequently, there have been  
numerous discussions outside of the GFS-WG context about the  
suitability of the RNS standard for more general applications, as  
well as the (perceived) complexity of the standard as a barrier to  
entry. There have also been alternative directory construction  
standards proposed by members of the OGSA-Naming-WG.

The following are the activities/proposals I know of:

RNS: I know the GGF editors have returned the final(?) RNS draft to  
GFS-WG, with the suggestion that it is too specific to filesystem  
needs, and the suggestion that it either be limited in scope to GFS  
applications only (a non-optimal solution for obvious reasons) or  
that the authors work with the OGSA-Naming people to help develop a  
universal standard for hierarchical resource namespaces. If we are to  
move forward with RNS, one of these options will clearly be a  
necessity, given the points Greg Newby made in his responses on  
behalf of the GFSG.

WS-Directory: This is the hierarchical namespace standard developed  
at UVa in response to their difficulty in implementing the  
complexities and ambiguities in RNS. I like the simplicity of WS- 
Directory, however it seems to be missing significant requirements  
for general use such as attributes, both attributed which should be  
required such as time-to-live, and the ability to add extensibility  
attributes such as resource type, QoS, etc. This ability to add  
arbitrary attributes is present in RNS but it still lacks some  
obviously fundamental required attributes.

Finally, Dave Berry sent an e-mail immediately after GGF16 in which  
he mentioned the suggestion that we separate this functionality into  
two logical functions, and therefore standards - a Directory  
Interface and an Iterator interface, in which Directory interfaces  
were essentially just pointers to Iterators, which would be  
standardized. However, there would be no restriction that a Directory  
point to a particular type of iterator interface. One point I wasn't  
clear on from the e-mail was whether an entry in an interator could  
be another directory, although I suspect it can.

This short list is what I've got within easy reach. As I said  
previously, I believe this is an important issue to resolve quickly,  
and I'm sending this note in the hopes of initiating the conversation  
among as many of the relevant parties as I can. Please feel free to  
forward at will, respond with agreement, anger, or even unconcealed  
rage.

Possible ways forward would be for us to have a conference call (GFS- 
WG meets rarely, and we could quite easily give up our call for a  
more focused discussion of these issues), an extended e-mail  
discussion, or a meeting at the next GGF (assuming we get a chance).

Let me know how you feel about the options presented above, or feel  
free to propose new ones if you like. The important thing is that we  
begin to gain momentum, and then keep it going forward.

Thanks.

N.B. For anyone who may have missed any of the discussions reference  
above, please let me know and I'll be happy to forward them to you  
from my archives.

- ----------------------------------------------------
Chris Jordan
HPC Systems Engineer
High End Computing Systems Group
San Diego Supercomputer Center
ctjordan at sdsc.edu
858.534.8347

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFEKJEyPCVtcXn6kg8RArL6AJwIxZfjr0tUdIVRX8bYgYyBel+yMACgujp4
BI4Q1i9d06gheHr1028BPuk=
=hj2R
-----END PGP SIGNATURE-----