P2. FNAL: to send detailed information about the requirements for storage reservation and example use cases A: (to check email archive about the contact person)

P3(DONE). check if appendix B should be alphabetically ordered

P4. add more descriptive text to each element (e.g., benchmark, applicationHandle) A: scheduled the writing

P5. consider to add non-normative examples to the realization document or to a new document (e.g. GLUE 2.0 Primer) A: we plan to put it in the realization document; describe three scenarios: 1 for main entities, 1 for computing, 1 for storage; add examples for each rendering; defined actions

P6(DONE). multiplicy between Endpoint-Share Share-Resource and all the specialization in computing and storage, at the moment they are different; verify by use cases if they can be made equal (22, 42)

A: change both to *---*

P7(DONE). add CreationTime and Validity in the Inherited Properties section of each table subclassing from Entity A: OK

P8(DONE). evaluate if the following attributes should be added to the Entity: Name, OtherInfo

A: we add Name to the Entity class defined as "human-readable name"; we remove Name from all other classes and we add it in the inhereted properties

• for the XML rendering, we define the XSD so that Name is always second element after ID/LocalID, while OtherInfo is the last one before Extensions

P9(DONE). evaluate if to have only global ID’s (in this case, we could add ID to the Entity class) (43) A: we agree to add ID everywhere and push it in the Entity

P10(DONE). evaluate if adding OtherInfo in the Location entity is needed A: OtherInfo is now in Entity, so inherited

P11. improve UserManager of UserDomain and evaluate if it should be represented as assocation (31bis) A: options:

• • 1. UserManager as an Endpoint.ID, recommend that Endpoint.ID is published in the info service in the context of a Service+Endpoint entities; this makes possible to discover its URL, interface, etc.
  • 2. UserManager as an Endpoint.URL, the related Service+Endpoint class instances may not exist if the interface type/version is know in the context
  • 3. go for 1., plus if people need 2. for avoiding extra query when interface is know a priori, then they can use OtherInfo or Extensions

We lean towards 1. (wait comments from Balazs and others)

P12. improve Member properties of UserDomain A: (verify who asked for this and the related use case)

P13(DONE). revise the capability_t enumeration based on experience; reconsider if we want it mandatory (120) A: the enumeration will be revised after experience, anyway it is an open enumeration accomodating for extension

• make it optional 0..*

P14(DONE). Service.Type: refine definition and enumeration; add EGEE, OSG and NorduGrid types (121)

P15(DONE). improve AdminDomain.Owner description

P16(DONE). Endpoint.Interface: to be split into type and version (with Type having an enumeration?) (37) A:

• use case: GridFTP supporting different interface versions
  • proposal: split InterfaceName (1) and InterfaceVersion (0..*)

need to make an initial enumeration for InterfaceName

P17(DONE). define integrated state model for Service.QualityLevel and Endpoint.QualityLevel after experience (38)

P18(DONE). MappingPolicy.Default: evaluate how to express default mapping (i.e., what is the mapping if you do not express any preference); two options so far (53): a. Add to the policy rule syntax b. Add as a property of mappingPolicy; in this case we need to allow multiple policy instances with same scheme

A:

• Maarten: EGEE is moving to Most-Specific Match shortly instead of "first-match in ordered list"; this evaluation strategy is captured by the policy scheme; there is no need to add extra attributes
• Stephen: the scheme definition should contain the evaluation strategy
• Decision: not to add any attributes; add this paragraph to mapping policy section:

P19(DONE). reconsider job-related attributes and the Grid vs. local jobs in computingService/computingShare

P20(DONE). change ExecuntionEnvironment.Homogeneity to ExecutionEnvironment.Homogeneous (64)

P21(DONE). evaluate if to drop ComputingManager.NetworkInfo (65)

P22. evaluate TmpDir/ScratchDir/ApplicationDir (ask JP) and their relationship to WorkingArea (66)

P23(DONE). evaluate a better name for ApplicationEnvironment.Name (77)

P24. improve description of ApplicationEnvironment.Repository (79)

P25(DONE). storage: evaluate how to use access protocol in case of simple disk server with gridftp storagendpoint; evaluate if storage endpoint can be used for listing access protocol types as well (89, 144)

A: - if a type of storage access protocol needs to be discoverable, then the storage access protocol class SHOULD be used - if a certain access protocol has a URL and this URL needs to be discoverable, then the access protocol SHOULD be also published via the storage endpoint To be added to the spec

P27(DONE). evaluate the usage of the word capacity and extent in the storage context (90,91) A: did in previous list of comments

P28(DONE). to make consistent association labeling across main/computing/storage entities (92, 159)

A: Sergio to fix it

P29(DONE). improve definition of size-related attributes in storage*capacity entities (94, 103)

A: improved added differentiation between installed and available; there is no case for implicit path; there are cases for default path, in this case the path attribute can be used P30(DONE). improve path default when implicit and description (98)

A: we make it optional to deal with cases where it make no sense (e.g., scratch area);

P31(DONE). improve tag definition (99)

A: improved

P32(DONE). improve description of storage share (101)

A: we will add description for each class, this should improve the understaning of storage share

P33(DONE). Manager: Type seems a slightly strange name for the attribute, things like "enstore" and "castor" aren't really types. Actually this applies to ComuptingManager too although I didn't pick it up there, are "lsf" and "pbs" types? Also since both CM and SM have a Type attribute should it anyway be defined in the parent Manager entity? (ditto Version).

A: change Type to ProductName; move ProductName to Manager entity; add ProductVersion

P33(DONE). evaluate if to rename storage resource to data store (108)

A: change to DataStore

P34(DONE). ToComputingService: The AccessProtocol relation is marked as multiplicity 1, but I think it should be *. On one side you could have a "close SE" relation involving several protocols (e.g. rfio and file). On the other side you may want to have the network info regardless of protocol (e.g. for gridftp).

A: Ok, change to *

P35(DONE). rediscuss deny and wildcards in basic policy syntax; improve also general description (118, 119)

P36(DONE). verify semantics of policy rules against EGEE semantics (119)

A: the basic scheme that we defined is not meant to cover the complexity of EGEE semantics. No action needed

P37(DONE). refine endpointTechnology_t enumeration

A: we drop legacy as a possible value; TODO: think on a different attribute name to narrow the meaning (instead of Technology, e.g., ProtocolTechnology)

P38(DONE). reconsider OSFamily/OSName/OSVersion to this: http://goc.grid.sinica.edu.tw/gocwiki/How_to_publish_the_OS_name

A: OSFamily is OK, OSName should be aligned with SystemName in the wiki page, OSVersion gets the SystemRelease values SystemVersion has no mapping into GLUE 2.0; the published values in the wiki page seem also not very consistent

P39(DONE). License_t rediscuss open vs. closed and values A: we change to open enum and remove Other value

P40(DONE). check capitalization of MUST, MAY, … (129)

P41(DONE). change all can to MAY, SHOULD (130)

P42. check consistency in referecence styles; e.g. URI in line vs. in reference section (131)

P43. fix appendix numeration by letters (133)

P44. Make entity names typesetting consistent in the text; use same style of entity name in table + italics (134)

P45(DONE). check statements about ID and URI (137)

TODO: reconsider after pending change to the document on ID/LocalID is applied

P46(DONE). discuss persistency of LocalID/ID (140) http://www.nla.gov.au/padi/topics/36.html

A: we agreed that we only have ID which are URI. URI typically should be designed in order not to change (http://www.w3.org/Provider/Style/URI). In the general statements section; add guidelines for persistency of ID. We propose: "As a general guideline, ID's SHOULD be persistent at least for a day when assigned to an entity"

P47. add explicit redefinition of associations in UML (142)

P48. recheck definition of latency: maximum under normal operating conditions vs. actual vs. maximum (147) check with Paul

P49. add references to XML, LDAP, and SQL

P50. add clarification about interoperability profiles (149) A: to add definition of (interoperability) profile in the last paragraph of section 1

P51. add reference to URI/URN

P52. improve reference to SI (154)

P53(DONE). choose either attribute or property as a term

A: change to Attribute

P54(DONE). clean paragraph (172)

The para describing Virtual Organisations seems a little out of sequence. For example, "VO" is used before it's defined in the second sentence. The term is defined in the third sentence, rather than where "Virtual Organisation" is first used. Someone should spend a little bit of time tidying up that para. The final para should be changed: "This structure /MAY/can berepresented /a/via the "participates in" association."

P55(DONE). evaluate renaming of statusPage (174)

A: change to StatusInfo, keep type URL

P56. improve Supported Profile definition (177) A: to be improved

P57(DONE). Policy: Neither the Scheme or Rule properties appear to be particularly well defined (182)

P58(DONE). 185

There's many references to "unknown value" or similar. I feel these should all be changed to "place-holder value". I've tried to note where the occur, but searching should find them all.

P59(DONE). add xrootd to access prot enum + definition (194)

A: to be added, check if xroot is the right value

P60. improve definition of enum in storage (195)