Dear Tiziana and Stephen,

I have some general comments and some specific remarks.

General comments

I have not read the GLUE 2 schema document, but it is clear that the
schema is very complex, both in structure and richness of classes and
attributes. I see the profile document as absolutely essential in
bringing the schema "back to earth". Still, I cannot help wondering how
much of what the document requires or recommends will be really done in
the middleware.
Another concern comes from the fact that GLUE 2 is totally
backward-incompatible. All information providers and consumers will need
to be heavily modified, or rewritten. Again, I feel skeptical about the
hope to see any of this working. Even so, the document is an important
step in the right direction.
Last, a question: is it really foreseen to keep using LDAP? Having
developed lcg-info many years ago, I learned that writing a proper
client to extract information from the BDII in a reasonably generic way
is a nightmare.

Specific comments:

- page 6: what's the difference between a null and an unknown vale?
- page 7: the difference between WARNING and INFO is rather fuzzy: the
former applies to values "likely wrong", the latter to values that "seem
unlikely". I would advise a better choice of words to mark the
difference in meaning;
- page 7: why a difference in character case is a WARNING and not an INFO?
- page 10: is it possible to specify compliance with more than one type
of profile (there may be other beside EGI) and more than one version per
profile?
- page 17: to what extent is it assumed that all published services
appear in the GOCDB and viceversa?
- page 17: probably it is out of ignorance, but the purpose of the
Capability attribute is not clear to me: what could be a real-life example?
- page 18: same question about Complexity: I really don't understand
what it is for;
- page 18: the StatusInfo attribute is not described in the text.
Actually this happens for dozens of attributes in the following tables.
Is that because the document is a draft, or simply the reader should
refer to the schema document?
- are the possible values of HealthState listed somewhere? Here only
"ok" and "warning" are mentioned;
- page 26: what is "post-execution" for staging jobs?
- page 29: how many nines constitute the placeholder value?
- page 30: what's the point in a MinCPUTime attribute?
- page 32: the "standard algorithm" for the EstimatedAverageWaitingTime
should be documented somewhere, otherwise it's pointless to tell the
developers that they SHOULD use it. They cannot be forced to take some
obscure code and use it as a black box;
- page 32: attributes like MaxWallTime, MaxCPUTime etc. are not (or
surely not only) for SD, but for SS, while the table does not put a
checkmark in SS;
- page 36: what are the WorkingArea attributes for?
- page 36: shhare -> share;
- page 38: is it really sensible to publish things like TmpDir in the
information system?
- page 43: shouldn't the ToStorageService class have an attribute with
the ID of the Storage Service? The local and the remote (?) path are
surely not enough;
- page 49: why TotalSize etc. should not be used for Service Selection?

I have nothing else.

Cheers,

	Andrea