 conjunction with products and services (for policy scopes that are related to these), or separately for policies of scopes orthogonal to these (i.e., unrelated to particular products and services). Orthogonal policies may include various policies for operations, security, infrastructure optimization, etc. Note that the architecture shown is a logical architecture, and may be implemented in various ways. Some functions in whole or in part may be implemented either as separate virtualized ele- ments or within other (nonpolicy) functions. 7.7.4 POLICY UNIFICATION AND ORGANIZATION In an expandable, multipurpose policy framework, many types of policy may be used. Policy may be organized using many convenient dimensions in order to facilitate the workings of the frame- work within a network cloud. A flexible organizing principle termed policy scope will enable a set of attributes to specify (to the degree/precision desired, and using any set of desired dimensions) the precise scope of both policies and policy-enabled functions/components. Useful organizing dimen- sions of policy scope may include the following: 1. Policy type or category, for example, taxonomical 2. Policy ownership/administrative domain 3. Geographic area or location 4. Technology type and/or specifics 5. Policy language, version, etc. 6. Security level or other security-related values/specifiers/limiters 7. Particular defined grouping 8. Any other dimensions/attributes as may be deemed helpful, for example, by operations. Note that attributes can be defined for each dimension. By then setting values for these attributes, policy scope can be used to specify the precise policy scope of the following: 1. Policy events or requests/triggers to allow each event/request to self-indicate its scope, for example, which can then be examined by a suitable function for specifics of routing/ delivery 2. Policy decision/enforcement functions or other policy functions to allow each policy func- tion to self-indicate its scope of decision making, enforcement, or oth