DMTF

The DSP0263 specification describes the model and protocol for management interactions between a cloud Infrastructure as a Service (IaaS) Provider and the Consumers of an IaaS service. The basic resources of IaaS (machines, storage, and networks) are modeled with the goal of providing Consumer management access to an implementation of IaaS and facilitating portability between cloud implementations that support the specification. This document specifies a Representational State Transfer (REST)-style protocol using HTTP. However, the underlying model is not specific to HTTP, and it is possible to map it to other protocols as well.  

CIMI addresses the management of the life cycle of an infrastructure provided by a Provider. CIMI does not extend beyond infrastructure management to the control of the applications and services that the Consumer chooses to run on the infrastructure provided as a service by the Provider. Although CIMI may be to some extent applicable to other cloud service models, such as Platform as a Service (PaaS) or Storage as a Service ("SaaS"), these uses are outside the design goals of CIMI.

The definition of a CMDB in the context of this specification is based on the definition described in the IT Infrastructure Library (ITIL): a database that tracks and records configuration items associated with the IT infrastructure and the relationships between them. Strictly speaking, the ITIL CMDB contains a record of the expected configuration of the IT environment, as authorized and controlled through the change management and configuration management processes. The federated CMDB in this specification extends this base definition to federate any management information that complies with the specification’s patterns, schema, and interfaces, such as the discovered actual state in addition to the expected state. Typically, an administrator selects the data to be included in a CMDB by configuring the tool that implements the CMDB.

In order to promote the wide spread adoption of OVF it is important that software vendors have confidence in the ability to build an OVF that can be deployed on a set of target virtualization platforms (aka hypervisors). To this end it is useful to define additional constraints and requirements on the OVF package to enable automated deployment and portability. Interoperability, i.e., the ability to be deployed on target virtualization platforms, is also enhanced.
The Open Virtualization Format standard defines conformance requirements, but these are not sufficient for the use cases that this specification addresses. Conformance can be done by inspection, checking for the ovf:required tag in the OVF and noting the conformance level as specified in the standard.
Software developers need guidelines for what needs to be included in each section of the environment file to ensure that a deployment function is capable of deploying the OVF.

This document makes use of the common meta-model used by CADF, the Cloud Audit Data Federation to describe the events used by the OpenStack Cloud Management Platform.
 
The document DSP0262 defines the CADF model.

Concerns over cloud provider security remain one of the top inhibitors to adoption of cloud deployment models. Potential consumers of cloud deployments need assurance that the security policies they require on their applications are consistently managed and enforced “in the cloud” as they would be in their enterprise.
A cloud provider’s ability to provide specific audit event, log, and report information on a per-tenant and application basis is essential. It is apparent that in order to meet these customer expectations, cloud providers must provide standard mechanisms for their tenant customers to self-manage and self-audit application security that includes information about the provider’s hardware, software, and network infrastructure used to run specific tenant applications.
A proven method to address such needs is to develop open standards to enable information sharing. Specifically, this specification provides a data format and interface definitions that support the federation of normative audit event data to and from cloud providers in the form of customized reports and logs. This specification also defines a means to attach domain-specific identifiers, event classification values, and tags that can be used to dynamically generate customized logs and reports for cloud subscribers or customers.
Adoption of this and other open standards by cloud providers’ management platforms would go far to instill greate trust in “cloud hosted applications” and be a significant step forward in fulfilling the promise of an open cloud marketplace.

The Open Virtualization Format (OVF) Specification describes an open, secure, efficient and extensible format for the packaging and distribution of software to be run in virtual systems. The OVF package enables the authoring of portable virtual systems and the transport of virtual systems between virtualization platforms. This version of the specification (2.1) is intended to allow OVF 1.x tools to work with OVF 2.x descriptors in the following sense:

• Existing OVF 1.x tools should be able to parse OVF 2.x descriptors.
• Existing OVF 1.x tools should be able to give warnings/errors if dependencies to 2.x features are required for correct operation.

If a conflict arises between the schema, text, or tables, the order of precedence to resolve the conflicts is schema; then text; then tables. Figures are for illustrative purposes only and are not a normative part of the standard.

A table may constrain the text but it shall not conflict with it.

The profile conforms to the cited CIM Schema classes where used. Any requirements contained in the cited CIM Schema classes shall be met. If a conflict arises the CIM Schema takes precedence.
The profile conforms to the cited OVF XML Schema. It may constrain the schema but it shall not conflict with it. If a conflict arises the OVF XML Schema takes precedence.
 
This standard is also published as ISO/IEC 17203:2017

This document makes use of the common meta-model used by CIM, the Common Information Model to describe the CIMI logical model. This is defined in DSP004, CIM Infrastructure Specification 2.7.

Transformation of the CIMI CIM into CIM metamodel conformant representations enables access of the services defined by CIMI in CIM-based environments. Such environments encompass a broad range of supported operating systems, languages, platforms, protocols, and other technologies.

This specification describes transformations in a manner that enables any CIM metamodel conformant representation. This document will utilize MOF for examples of such transformations.

This specificationis a component of version three (v3) of the Common Information Model(CIM) architecture. CIM v3 is a major revision of CIM. CIM v3 preserves the functionality of CIM v2, but it is not backwards compatible. The DMTF continuesto support the specifications that define CIM v2. However, new CIM v3 architectural features may not be added to CIM v2 specifications. This standard describes the Common Information Model (CIM) Meta model version 3, which is based on the Unified Modeling Language: Superstructure specification. CIM schemas represent object-oriented models that can be used to represent the resources of a managed system, including their attributes, behaviors,and relationships. The CIM Metamodelincludes expressions for common elements that must be clearly presented to management applications (for example, classes, properties, methods, and associations).

This standard defines a mapping of CIM-XML messages to the Hypertext Transfer Protocol (HTTP and HTTPS) so that implementations of CIM can operate in an open, standardized manner. It also defines the notion of conformance in the context of this mapping, and it describes the behavior animplementation of CIM shall exhibit to be a conforming CIM implementation.

CIM information could be represented within XML in many different ways. In the interest of interoperability between different implementations of CIM,there is an obvious requirement for standardization of this representation.  The following criteria have been applied in the design of the representation presented here:

• Fully standardized technologies are used wherever possible, in preference to Working Drafts.
• Where use is made of a Working Draft, the intention is to track the changes to the Working Draft in this specification.
• Completeness is favored over conciseness (all aspects of CIM should be modeled).

This specification describes an efficient method for WBEM Clients to discover WBEM Servers and WBEM Server capabilities. The objectives of this specification are to:

• Provide a mechanism that allows WBEM Clients to discover WBEM Servers
• Use existing standards and protocols for rapid development and deployment
• Provide a mechanism that scales from small environments to enterprise environments
• Provide WBEM Clients sufficient information in the advertisement to determine the WBEM
• Servers to communicate with

Scope the level of advertisement to avoid security holes The Service Location Protocol provides a flexible and scalable framework for providing clients, represented by User Agents, with access to information about the existence, location, and configuration of services, represented by Service Agents. Traditionally, clients have had to know the name and access method of services. The SLP eliminates the need for a client to know the name and access point of services. With SLP the client supplies a request for the desired type of service. The client receives information regarding the requested services

This specification contains the requirements for an implementation of the SM CLP to provide access to, and implement the behaviors of, the Base Server Profile.