**Special Item Number 518210C - Cloud and Cloud-Related IT Professional Services**

**Specific Information for Offerors**

**Table 1: Cloud Computing Services (IaaS/PaaS/SaaS)**

1) **DESCRIPTION OF CLOUD COMPUTING SERVICES (IaaS/PaaS/SaaS) AND PRICING**

a) The information provided below is designed to assist Offerors to categorize cloud computing services and provide complete descriptions.

b) In addition to standard pricing requirements, all pricing models must have the core capability to meet the NIST Essential Cloud Characteristics[footnoteRef:1], particularly with respect to on-demand self-service, while allowing alternate variations at the task order level at agency discretion, pursuant to the guidance on the NIST Essential Characteristics. [1:  https://nvlpubs.nist.gov/nistpubs/legacy/sp/nistspecialpublication800-145.pdf] 

Table 2: Cloud Service Description Requirements (below) summarizes the additional Offeror provided description requirements for services proposed under the Cloud Computing Services (IaaS/PaaS/SaaS). All mandatory description requirements must be complete, and adequate according to evaluation criteria.

1) The NIST Service Model provides sub-categories for SIN 518210C (Cloud SIN) and is strongly encouraged, and offerors are not required to submit sub-categories. Contractors may select the single service model most closely corresponding to the specific service offering.

2) If a sub-category is selected**,** it will be evaluated with respect to the NIST Service Model definitions and guidelines in “Guidance for Contractors**.**"

**Table 2: Cloud Service Description Requirements**

2) **GUIDANCE FOR OFFERORS**

This section offers guidance for interpreting Table 2 (above), including the NIST essential cloud characteristics, service models, and deployment models. This section is for offeror’s reference only.

Offeror specific definitions of cloud computing characteristics and models or significant variances from the NIST essential characteristics or models will not be considered in the scope of this SIN or accepted in response to evaluation factors. The only applicable cloud characteristics, service model/sub-categories, and deployment models for this SIN will be drawn from ~~the~~ NIST SP 800-145. Services qualifying for listing as cloud computing services (IaaS/PaaS/SaaS) under this SIN must substantially satisfy the essential characteristics of cloud computing as documented in the NIST Definition of Cloud ComputingSP 800-145.[footnoteRef:3] [3:  http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf] 

Both Cloud service model (IaaS/PaaS/SaaS) and deployment model (public, etc.) designations must align with NIST definitions. Guidance is offered in this document on making the most appropriate selection.

NIST’s essential cloud characteristics provide a consistent metric for whether a service is eligible for inclusion in this SIN. It is understood that due to legislative, funding, and/or other constraints, Government entities cannot always leverage a cloud service to the extent that all NIST essential characteristics are commercially available. For the purposes of SIN 518210C (Cloud SIN), meeting the NIST essential characteristics is determined by whether each essential capability of the commercial service is available for the service, not whether the Ordering Activity actually requests or implements the capability. The guidance in Table 3: Guidance on Meeting NIST Essential Characteristics (below) offers examples of how services might or might not be included based on the essential characteristics, and how the Contractor should interpret the characteristics in light of current Government contracting processes.

**Table 3: Guidance on Meeting NIST Essential Characteristics**

Cloud Services (IaaS/PaaS/SaaS) may depend on other cloud services, and cloud service models such as PaaS and SaaS are able to inherit essential characteristics from other cloud services that support them.  For example, a PaaS can inherit the broad network access made available by the IaaS it runs on, and in such a situation would be fully compliant with the broad network access essential characteristic. Cloud Services (IaaS/PaaS/SaaS) inheriting essential characteristics must make the inherited characteristic fully available at their level of delivery to claim the relevant characteristic by inheritance.

Inheriting characteristics does not require the inheriting provider to directly bundle or integrate the inherited service, but it does require a reasonable measure of support and identification. For example, the Ordering Activity may acquire an IaaS service from “Provider A” and a PaaS service from “Provider B.” The PaaS service may inherit broad network access from “Provider A,” but must identify and support the inherited service as an acceptable IaaS provider.

Typically broad network access for public deployment models implies high bandwidth access from the public internet for authorized users. In a private cloud deployment internet access might be considered broad access, as might be access through a dedicated shared high bandwidth network connection from the Ordering Activity, in accordance with the private nature of the deployment model.

All cloud resource pools are finite and only give the appearance of infinite resources when sufficiently large, as is sometimes the case with a public cloud. The resource pool supporting a private cloud is typically smaller with more visible limits. A finite pool of resources purchased as a private cloud service qualifies as resource pooling so long as the resources within the pool can be dynamically allocated to the ultimate users of the resource, even though the pool itself appears finite to the Ordering Activity that procures access to the pool as a source of dynamic service allocation.

1) NIST Service Model

The Contractor may optionally document the service model of cloud computing (e.g. IaaS, PaaS, SaaS) that most closely describes their offering, using the definitions in The NIST Definition of Cloud Computing SP 800-145. Contractors should carefully select the NIST service model most closely corresponding to each service offered. Contractors should not invent, proliferate, or select multiple cloud service model sub-categories to distinguish their offerings, because ad-hoc categorization prevents consumers from comparing similar offerings. Instead, vendors should fully make use of the existing NIST categories possible. The following guidance is offered for the proper selection of service models.

NIST’s service models provide this SIN with a set of consistent sub-categories to assist ordering activities in locating and comparing Cloud services (IaaS/PaaS/SaaS) of interest. The service model is primarily concerned with the nature of the service offered and the staff and activities most likely to interact with the service. Contractors should select a single service model most closely corresponding to their proposed service based on the guidance below. It is understood that cloud services can technically incorporate multiple service models and the intent is to provide the single best categorization of the service.

For example, in this SIN, an offering commercially marketed by a Contractor as “Storage as a Service” would be properly characterized as Infrastructure as a Service (IaaS), storage being a subset of infrastructure.  Services commercially marketed as “LAMP as a Service” or “Database as a Service” would be properly characterized under this SIN as Platform as a Service (PaaS), as they deliver two kinds of platform services. Services commercially marketed as “Travel Facilitation as a Service” or “Email as a Service” would be properly characterized as species of Software as a Service (SaaS) for this SIN. 

However, Contractors can and should include appropriate descriptions (including commercial marketing terms) of the service in the full descriptions of the service’s capabilities.

When choosing between equally plausible service model sub-categories, Contractors should consider several factors:

a) Visibility to the Ordering Activity: Service model sub-categories in this SIN exist to help Ordering Activities match their requirements with service characteristics.  Contractors should select the most intuitive and appropriate service model from the point of view of an Ordering Activity.

b) Primary Focus of the Cloud Service (IaaS/PaaS/SaaS): Services may offer a mix of capabilities that span service models in the strict technical sense. For example, a service may offer both IaaS capabilities for processing and storage, along with some PaaS capabilities for application deployment, or SaaS capabilities for specific applications.  In a service mix situation, the Contractor should select the service model that is their primary focus. Alternatively, contractors may choose to submit multiple service offerings for the SIN, each optionally and separately subcategorized.

c) Ordering Activity Role: Contractors should consider the operational role of the Ordering Activity’s primary actual consumer or operator of the service. For example**,** services most often consumed by system managers are likely to fit best as IaaS; services most often consumed by application deployers or developers as PaaS, and services most often consumed by business users as SaaS.

d) Lowest Level of Configurability: Contractors can consider IaaS, PaaS**,** and SaaS as an ascending hierarchy of complexity, and select the model with the lowest level of available Ordering Activity interaction.  As an example, virtual machines are an IaaS service often bundled with a range of operating systems, which are PaaS services. The Ordering Activity usually has access to configure the lower level IaaS service, and the overall service should be considered IaaS.  In cases where the Ordering Activity cannot configure the speed, memory, network configuration, or any other aspect of the IaaS component, consider categorizing as a PaaS service.

Cloud management and cloud broker services should be categorized based on their own characteristics and not those of the other cloud services that are their targets. Management and broker services typically fit the SaaS service model, regardless of whether the services they manage are SaaS, PaaS, or IaaS. Use Table 3 to determine which service model is appropriate for the cloud management or cloud broker services or, alternately, choose not to select a service model for the service.

The guidance in Table 4: Guidance on Mapping to NIST Service Models (below) offers examples of how services might be properly mapped to NIST service models and how a Contractor should interpret the service model sub-categories.

**Table 4: Guidance on Mapping to NIST Service Models**

****

2) Deployment Model

Deployment models (i.e., private, public, community, or hybrid) are not restricted at the SIN level and any specifications for a deployment model are the responsibility of the Ordering Activity.

Multiple deployment model selection is permitted, but at least one model must be selected. The guidance in Table 4 offers examples of how services might be properly mapped to NIST deployment models and how the contractor should interpret the deployment model characteristics. Contractors should take care to select the range of NIST deployment models most closely corresponding to each service offered.

Note that the scope of this SIN does not include hardware or software components used to construct a cloud, only cloud capabilities delivered as a service, as noted in the Scope section.

**Table 5: Guidance for Selecting a Deployment Model**

1