Hi All, I think I came on a scenario which has not been addressed in any other Use Case works. There may be circumstances where unconfigured resources are provisioned for a cloud consumer outside of OCCI. Unconfigured resources may be storage or network resources which are provisioned but not assigned to any compute resource. These resources may be created though provider "back office" utilities, or though other cloud management interfaces, including SNIA's CDMI or IaaS cloud providers' native interfaces. OCCI does not have a way to report "provisioned" but still unconfigured resources. I'm proposing a new type of resource identified as "group", it's an organizational construct more than a traditional OCCI IaaS resource. The "group" does not infer any specific organization for its membership, such as a hierarchy or a network. The "group" indicates the existence of a relationship between the members and provides a name space, via attributes, to identify and address the membership as an atomic unit. Though attributes, we can define the role of the group, where it can represent unconfigured resources, administrative accounts, providing organization structure for administrators or other unforeseen aspects of evolving cloud provider implementations. Imposing a hierarchal relationship between the group and its membership, provides a direct mapping to canonical URI forms described in the OCCI specification.. I've been hesitant proposing the introduction of an abstract organizational entity into OCCI and resisted pushing it as an agenda item, especially due to the late point in the game. Considering the recent adoption of "consumer defined attributes" into the specification, IMO the introduction of "group"s is an important descriptive capability for representing IaaS cloud provider implementations. Again IMO, the proposal for adoption of this new capability and the technical details warrants further email discussion. cheers, gary