Hi Andrea, Andrew Grimshaw (<<ASG>>) has been leading the OGSA-WG's work on naming, and he gave the following response. 
 We've made some changes in this area.

- Jem


4. In the definition of name, I would disagree that "human-oriented names" uniquely identify an entity (as the opening 
sentence of the defn states).  Human-oriented names MAY NOT be unique, but certainly are criteria by which an entity may
 be located.  Also in the definition of name, the following text is found: "Abstract names are bound to addresses."  
This seems very vague.  What is the intent?  Within an implementation, an abstract name is used to locate/address an 
instance/entity.  But, the binding may not be externally visible and may not relate to an "address" as defined in the 
subsequent bullet.  Lastly, as regards the definition of an address, what is a "concrete name"?  This is a new term that
 is not defined. [JT: Note that Heather Kreger recently (9/10/2004) proposed some definitions of name and related terms 
for WSDM.]

<< ASG: I agree completely. Human names may be many-to-one to abstract names, or perhaps one-to-many � that has not 
been agreed to yet but I believe so. As to the binding issue I am not sure I understand the comment.  The intent is that
 a name may be bound (resolved) to an address. The term "concrete name" was used as an equivalence to address  so we 
should remove the term "concrete name".>>

Hi Andrea, thanks very much for your comments on the OGSA Glossary.  We've now reviewed all the comments, and 
incorporated some of them; I hope to submit the updated draft to the editor within the next few days.  Below are the 
specific responses:

>1. Event - The definition is restricted to a "computer system" but 
> that seems too limiting.  Recommend saying "Anything that occurs in or 
> to a computer, storage or network system, or that is monitored by such a system, 
> that is potentially interesting ..." 

Reworded as "IT system".

> 2. Recommend including a definition of JSIM (the Job Submission Information 
> Model) from CGS, since JSDL is mentioned.  BTW, JSIM and JSDL need to be aligned 
> at the conceptual level. 

We decided not to include JSIM in the Glossary, as it isn't mentioned in the OGSA document.

>3. The definition of "Manageable resource" specifically calls out 
> provisioning. Why only provisioning and not monitoring, eventing, inventory 
> mgmt (hdw and software), etc.? 

We discussed definitions in the areas of manageability and resources at length, and made some significant changes.

> 
>4. In the definition of name, I would disagree that "human-oriented names" 
> uniquely identify an entity (as the opening sentence of the defn states).  
> Human-oriented names MAY NOT be unique, but certainly are criteria by which 
> an entity may be located.  Also in the definition of name, the following text 
> is found: "Abstract names are bound to addresses."  This seems very 
> vague.  What is the intent?  Within an implementation, an abstract name is 
> used to locate/address an instance/entity.  But, the binding may not be externally 
> visible and may not relate to an "address" as defined in the subsequent 
> bullet.  Lastly, as regards the definition of an address, what is a "concrete 
> name"?  This is a new term that is not defined.

We're in the process of reviewing naming definitions in light of this and other comments, and I do expect that we'll 
make some changes in this area before we submit the document.

>5. As regards the definition of policy, there is also a definition in IETF's 
> RFC3198. 

Good pointer!  We made no change made to the wording as our definition doesn't conflict, but this is a useful reference 
for several terms, so I added a Reference to RFC3198.

>6. The definition for "Self-management" is similarly restricted to 
> computers as is the definition for "Event".  Recommend making a similar 
> change to expand the scope beyond just "computers", or to define 
> a "system" as a compute, network or storage entity.

Done!

><>7. SLA and SLO terminology is also defined in IETF's RFC3198.
>
Right - see 5 above.

>8. Would also suggest including CIM, the Common Information Model from the DMTF, 
> in the list of defns.  It defines an object-oriented model for resource 
> management. 

Agreed, and done.

Thanks!

- Jem