On last week's teleconference I took an action to look over the architecture document to see if there were places where we needed to consider storage more than the document currently does. I have just completed a quick scan of the document and we appear to be in good shape. I only detect the following places where we may need to say more: 1. In Naming (section 3.1) we may want to augment the table with some storage specific entities that need to be named. 2. Section 9 (Caching) needs to discuss where the data being cached is stored while on the caching server. It is not clear to me if this should be a file (system) or something from storage. If the cache is perceived to be short lived then one might argue that this is just temporary storage and nothing need be said to the cache service to tell it where to put such transient data. However, if the cache is perceived to be long lived, or even if the amount of cached data will be large, the owner of the cache may have a desire to control where the data goes. I am inclined to believe that the latter is the more likely case. So, I think that there is a clear hole here in the description. 3. In the Creation of Federations (section 11.1), we need, as for caching, a means to tell the federation service where it should keep any data that it generates in support of the federation. Since this data could be long lived, we will inevitably get into storage and storage concepts such as lifetime management. 4. Finally, the caching item above raises the whole question of temporary data used by any service in the environment. One could argue that the users of the grid system have a vested interest in understanding and controlling where this temporary data lives, especially if the data is either large or relatively long lived. If you go down this path, it is far from clear to me how one meets this need without either adding undue complexity to every factory(-like) operation or mandating a management interface to every service to allow control of the location of the service's temporary data. Personally, I have a slight tendency to not attempt to mandate something in this area. I am inclined to make a note in the architecture that there is an issue here that every service must address but that it is up to the service designer (?) to make the call about how to deal with the issue. Normal market forces would then determine if that decision was the proper one. I don't claim that these are all of the places but it is, hopefully, a good start. Allen