Hi, Sorry this took so long, had a family medical emergency which took up most of last half of week and the weekend. There is one or two items about attributes that I believe needed to be clarified. As well as one or two items that are potential for conflicts. I listed them below, they will warrant a discuss and vote to see which capability we would consider supporting. 1) I believe we need a definition for attributes in the document... The definition needs to qualify the role of attributes and properties of the attributes. 2) Differentiate between OCCI Resource attributes and Attributes defined by Mixins. 3) Mixins may reference attributes defined in external schemas, DMTF's CIM for example. We need a way to filter attributes sourced from external schemas and hopefully not overload OCCI clients, servers or other information management vehicles (ie templates). This capability may also be required for the converse case, identifying attributes that will be used, all other will be ignored. This use case may also valid for OCCI Resource defined attributes. 4) The OCCI server should have the ability to override attributes defined in external schemas and OCCI Resources. The overridden attributes warrants a discrete definition, not to confuse externally defined attributes with server defined attributes. These attributes may fall into the class of "calculated attributes". 5) Indicators: An Indicator is threshold based logic used to show whether a metric is operating within a set of limits. Indicators may be polled by the client using traditional client/server technologies or pushed to the client by the server through asynchronous methods. What an indicator looks like is interesting.. we need to determine the following: a) Do Indicators contain more then one threshold? b) Can Indicators send or trigger asynchronous events, if yes, what does it look like ? c) Should each Indicator have a name ? c) How is MetricName/Indicator naming schema defined ? What does the canonical form look like ? cheers, gary