Figure PR.30 - Representing Administering and Owning a Resource

Given this background, we can define additional relationships needed to represent administration and ownership of PhysicalResources.<br/>Briefly, the owner of the Resource is the person or group that is responsible (e.g., organizational, financial, and so forth) for the Resource. This is a different concept than the person or group that administers the Resource. From a business perspective, the owner has to either appoint or give permission to the administrator to administer the Resource that is owned. This is shown in the Figure below.<br/>The two associations, called OwnsResource and AdministersResource, serve these roles. Note that the OwnsResource aggregation defines the set of Resources (physical and/or logical) that a particular Party, playing the role of Administrator, can administer (through the AdministersResource association). The owner of the Resource is the person or group that is responsible (e.g., organizational, financial, and so forth) for the Resource.<br/>In contrast, the AdministersResource association defines the set of Resources (physical and/or logical) that a particular Party, playing the role of Administrator. From a business perspective, the owner has to either appoint or give permission to the administrator to administer the Resource that is owned.<br/>The third item, ManagementDomain, is fundamental to how network management is done. Addendum 1-POL defines a ManagementDomain as follows:  A ManagementDomain class represents a special grouping of ManagedEntities that has two important properties. First, it is used to partition managed objects into a meaningful logical grouping. One important use of such a grouping is to provide a means to define which EMS (as well as which NMS) manages, monitors, etc. which set of devices. It also provides a means to show how management functions are distributed and scaled. Second, it defines a common administrative domain that is used to administer the managed objects that it contains. This implies that all of the managed objects contained in this ManagementDomain are administered similarly - either by the same user, group of users or policy.<br/>ManagementDomains often have a direct correlation with DeviceRoles. For example, in an MPLS VPN, there is a fundamental difference between routers that are operating as customer premise, provider edge, and provider core routers. (For those not familiar with MPLS VPNs, a customer premise device provides customer access to the Service Provider network over a data link to one or more provider edge routers; provider edge routers function as the ingress and egress routers of the Service Provider network; provider core routers provide connectivity between the provider edge routers. An example of a high-level MPLS VPN model is provided in part of Addendum 4). This can be done by associating a type of PartyRole (representing a ManagementDomain) with a type of DeviceRole. Note that in this use case, there are specific hardware as well as software requirements of the different types of routers playing the CustomerPremise, ProviderEdge, and ProviderCore roles. This is where the concepts of PhysicalDeviceRole and LogicalDeviceRole will pay dividends in the overall model.<br/>Thus, ManagementDomains are intelligent containers of managed entities, where different container represent different domains of control that reflect one or more appropriate management structures, such as organizational structure. PhysicalResources within a particular domain are administered by a particular person or group of people. While it is easy enough to define a relationship between ManagementDomain and PartyRole, the management of PhysicalResources in ManagementDomains by Party and PartyRole entities should be represented and controlled using policies. Thus, this topic will be deferred to the Policy Addendum.<br/>