ITAPS Draft Response to
IT Schedule 70 Cloud SIN Request for Information (RFI)
Responses
Table 1: Administrative Information
#
Question
a
b
c
Company Name
File Name
Page Count (including cover)
Response
IT Alliance for Public Sector
ITAPS Response to IT70-Cloud-SIN-RFI 20140821
10
Table 2: B. Questions for Industry - Feedback on Proposed SIN Addition
#
Question
Response
1.a.
Proposed SIN Scope Does your company have
any feedback on the draft
scope as stated in Table 1?
Please provide a response
of any concerns as well as
any proposed changes to
the scope.
ITAPS believes that the draft scope in Table 1 (basic SIN plus Sub-SINs) covers the primary product and
service categories related to cloud computing services. However, some categories that are bundled with,
or integral to, cloud computing services may not be adequately represented, including cloud migration
services, cost optimization services, and software offerings that are seamlessly integrated into a cloud
platform that buyers can provision on-demand. It is our suggestion that the Sub-SINs should address the
more tangible and relevant characteristics outlined in the Deployment Models, and that GSA consider
additional SIN categories as needed. For example, GSA should consider a distinction between managed
and unmanaged services.
We further suggest modification to Table 1 as follows:
Schedule 70 Cloud Computing Services SIN Description
Grouping
● Commercially available cloud computing
Services
services
1
Sub-SINs
1. Private cloud
2. Community cloud.
#
1.b.
1.c.i.
Question
Response
● Meets the definition of one of the Deployment
3. Public cloud.
4. Hybrid cloud.
Models, one or more of the Essential
Characteristics, and one or more of the Service
Models as defined by National Institute for
Standards and Technology (NIST) definition of
Cloud Computing (SP800-154)
● Open to all deployment models (private, public,
community or hybrid) vendors specify
deployment models
● Open to all Service models and future service
models that are to be defined
● Will cover future cloud technology not
otherwise categorized by NIST cloud definition
Proposed SIN Scope - NIST ITAPS believes that any proposed “cloud” offering should meet one or more characteristics identified in
Characteristics - The
NIST Special Publication 800-145. However, we recommend that GSA should have the flexibility to offer
National Institute for
ancillary services and consider additional sub-categories of products and services that are bundled with, or
Standards and Technology focused solely on, cloud implementation and use so that no service is excluded (e.g., “cloud professional
(NIST) has defined the
services,” cloud hardware exclusively, or whose primary purpose is to implement and maximize cloud
essential characteristics of services, and cloud software designed specifically for cloud-based deployments). Typically, “professional
Cloud Computing. (NIST
services” entail cloud implementation services, which may be critical to buyers seeking to transition onSpecial Publication 800premises workloads to the cloud. SaaS offerings may be bundled with IaaS and other cloud services in the
145). For the purposes of stack. As one suggestion, XaaS services might be suited to cover these complementary/bundled software
providing commercially
and hardware appliance offerings.
available cloud services on
a Cloud SIN, should all
offerings meet these
essential characteristics or
are there any that should
be specifically excluded
from the list? Please
provide your rationale.
Proposed SIN Scope - Sub- ITAPS received mixed feedback to this question. Some companies believe that the more offering can be
SINs - The current
differentiated the more customers can understand the different offerings and their benefits, while others
2
#
Question
Response
proposed Sub-SINs are
IaaS, PaaS, SaaS, and XaaS
(See Table 1 in the RFI).
believed that defining sub-SINs would create too many variables when mixing service and deployment
models.
i. Do you see value in
requiring industry
partners to identify this
service model distinction
at the Sub-SIN level?
1.c.ii.
Proposed SIN Scope - SubSINs - The current
proposed Sub-SINs are
IaaS, PaaS, SaaS, and XaaS
(See Table 1 in the RFI).
The four proposed categories follow the NIST definitions and cover the defined layers in a cloud model.
They are specific to Cloud Computing and no other existing SINs based upon the NIST definitions.
ii. Do these four categories
address the range of
expected cloud services,
or would you suggest any
other relevant Sub-SINs? If
so, explain why this would
logically fall into the
category of Cloud
Computing and not any
other existing SINs.
1.c.iii.
Proposed SIN Scope - SubSINs - The current
proposed Sub-SINs are
IaaS, PaaS, SaaS, and XaaS
(See Table 1 in the RFI).
It is necessary for GSA to vet that the deployment models meet qualifications so agencies can be sure that
offerings between different vendors are highly similar. Given the evolution of cloud computing and
associated technologies, we believe that GSA should employ some flexibility in interpreting the scope of
any SIN (we believe that XaaS should help in this regard, especially for Deployment Models).
3
#
Question
Response
iii. Do you see value for
GSA to vet that the
services meet specific
qualifications for each
Sub-SIN category?
2.
Vendor Pricing
Methodology: What are
your commercial pricing
methodology structures
for a proposed Cloud SIN?
(Provide a link to a web
page if possible.) A
contemplated structure
would include firm-fixed
price units, for example components priced by
time units such as
minutes, hours, months or
years (such as per user per
month, storage cost per
unit (e.g. GB) per hour).
Our member companies offer a wide variety of commercial pricing models. One common denominator, is
allowing CSPs enough flexibility to achieve a pricing model that is scalable in order to achieve maximum
benefit of the cloud utility model. In addition, having terms that keep up with innovation and technology
changes as well as price reductions is highly recommended. As discussed in question #5, FAR Part 12.301
and 12.302 encourage current commercial pricing terms and structures and limit the tailoring of the CSPs’
standard clauses and terms in order to promote the flexibility needed to realize cloud benefits as defined
in NIST Special Publication 800-145.
3.
Industry SIN
Management: Given that
cloud services are
currently offered under
SINs 132-32, 132-52 and
132-51 (if not potentially
others), identify any
challenges you foresee
with adding the proposed
SIN, and identify any
The potential overlap of these existing SINS with a cloud SIN could cause ordering and pricing confusion,
especially considering that, over time, practices and a common understanding of terms and conditions
have evolved, and continue to evolve, in connection with these existing SINS. One obvious mitigation
action would be to exclude explicitly cloud services from all existing SINs where scope duplication could
exist.
Additionally, there was some debate amongst our member companies whether or not the XaaS will be as
inclusive as GSA is proposing. Some companies feel that it could, while others feel that the RFI’s proposed
structure unintentionally may disrupt comprehensive approaches to cloud services and otherwise create
misalignment with the manner in which cloud services are delivered in the commercial market. For
4
#
Question
Response
proposed mitigating
actions.
instance, comprehensive commercial provisioning of SaaS may include IaaS, as well.
Finally, understanding that commercial provisioning of cloud services may involve one or more of the subcategories identified in the RFI, application of the existing price reduction clause under the schedule could
be problematic, as there may be no suitable commercial analogy to use as a pricing baseline against which
the schedule offering could be assessed.
4.
Potential Service
Offerings: Please provide
a brief indication of
service offerings your
company would like to
offer in a proposed SIN
including sub SIN
categories.
Our member companies offer a wide variety of service offerings.
5.
Terms and Conditions: As
with other IT Schedule 70
SINs, a future Cloud
Computing Services SIN
would have special Terms
and Conditions.1 These
Terms and Conditions
would address both
industry partner
requirements as well as
information useful to
Ordering Activities. Please
identify any feedback on
The crux of any terms and conditions should be, in order of priority given the unique nature of the
applicable cloud services and scope of the offering (e.g., managed or unmanaged, passive or active, which
again has bearing on areas of responsibility for things such as security, backup/archiving, etc.): (i) the CSP’s
commercial terms and conditions, (ii) FedRAMP should be the standard from a security perspective, along
with the CSP’s standard terms and conditions concerning security, with very deliberate language for the
SIN that other security protocols beyond FedRAMP are highly discouraged (e.g., agencies creating their
own “unique” protocols that defeat the purpose of the FedRAMP program), and (iii) commercial item FAR
clauses to the extent consistent with the services being procured.
GSA should also consider including terms that afford maximum flexibility to allow the CSP to add new
services and changes in services (including price decreases and service terms, if applicable) to the GSA
cloud computing contract as they are released on the public cloud.
1
Refer to the “13 - Critical Information Specific to Schedule 70” package attachment on the IT Schedule 70 Solicitation published on FedBizOpps at the following URL:
https://www.fbo.gov/index?s=opportunity&mode=form&id=d24cd9e270944b554632f37b34866aa6&tab=core&_cview=1
5
#
5.a.i.
Question
Response
the proposed topic areas
and suggest any additional
terms and conditions topic
areas that GSA should
consider for this SIN.
Should there be a desire to contract directly with CSPs, we recommend that the GSA negotiate individually
with each major CSP in order to tailor and streamline the acquisition terms at the base contract level.
Additional terms and conditions may be added at the ordering level depending on the specific acquisition
situation.
Security/Information
Assurance:
FedRAMP: It is
contemplated that
FedRAMP will be
referenced in the Terms
and Conditions. The scope
does not currently
propose that industry
partners hold a FedRAMP
JAB provisional ATO or an
agency-granted FedRAMP
compliant ATO because
FedRAMP compliance is
already the de facto
standard and issuing an
ATO is the ultimate
responsibility of the
ordering agency. Does
your company see any
value in requiring a
FedRAMP-compliant ATO
Also, in accordance with FAR Part 12.301 and 12.302, maximizing current commercial terms and limiting
the tailoring of the CSP’s standard clauses and terms is highly encouraged in order to be consistent with
customary commercial practices (with due regard to certain limitations unique to Government
contracting).This allows CSPs to achieve a model that is scalable in order to achieve maximum benefit of
the cloud utility model. In addition, having terms that keep up with innovation and technology changes as
well as price reductions is highly recommended.
ITAPS agrees with the current contemplated action of referencing FedRAMP in the Terms and Conditions.
We encourage the agencies to leverage FedRAMP-compliant authorizations for their security requirements
within solicitations as it is the minimum standard for compliance for all CSPs providing services to the
government. FedRAMP authorizations as a requirement will satisfy government agencies’ requirements for
Federal Information Security Management Act (FISMA) compliance and should be the standard without
reference to the type of authorization. We would also suggest that the requirement of a FedRAMP –
compliant ATO be issued at the Task Order level.
6
#
Question
Response
or any other specific
FedRAMP compliance
language?
5.a.ii.
FISMA: It is contemplated
that the Federal
Information Security
Management Act (FISMA)
of 2002 will be referenced
in the Terms and
Conditions
Given that the NIST controls for FISMA and FedRAMP overlap and that FISMA first requires the Agency to
determine the FISMA level of the data to be protected, ITAPS suggests the reference be high-level only.
Task Orders may be more appropriate as the agency may determine the level of appropriate data security.
5.a.iii. Data Requirements: It is
contemplated that a set of
high level data
requirements may be
included in the Terms and
Conditions. Identify any
data requirements you
believe should be included
as Terms and Conditions
(for example,
requirements related to
data privacy, HIPAA,
interoperability, etc.)
Data requirements such as HIPAA compliance, interoperability, etc. should be identified and issued at the
ordering level and not as part of the general Terms and Conditions. In addition, GSA should consider the
weight of responsibility in developing Terms and Conditions for shared responsibility models of
unmanaged versus unmanaged cloud services, so it may be prudent to apply these terms at the Task Order
level to best serve the scope of each project.
5.a.iv. Information Assurance:
Identify any information
additional assurance
requirements you believe
should be included in the
Terms and Conditions.
Security requirements in the terms and conditions should leverage the standardized FedRAMP
requirements versus duplicating or adding to them. Agencies should be discouraged from imposing
additional security requirements over and above FedRAMP requirements as this results in an inefficient
and more costly procurement process for cloud services in general. To the extent that unique security
requirements are necessary (with due consideration to the shared security model), those requirements
should be specified and only applicable in the individual Task Orders and not the master contract.
7
#
Question
Response
5.b.
Legislative Requirements:
Identify any legislative
requirements you believe
should be referenced.
We do not suggest any further legislative requirements are needed.
5.c.
Service Model and
Delivery Model: It is
expected that industry
partners should provide at
minimum the service
model (e.g. IaaS, PaaS,
SaaS) and deployment
model (public, private,
community, hybrid, etc.)
of cloud services provided.
Our member companies offer a wide variety of service and delivery model combinations.
5.d.
NIST Characteristics: As
described in question 1b,
it is anticipated that in
some capacity the NIST
characteristics will form
the basis of determining
whether the service
provided is truly a cloud
service, and therefore
reflected in the Terms and
Conditions.
The NIST definitions should be leveraged where applicable. The NIST definition would not capture the
separation between cloud products versus cloud labor (i.e. unmanaged versus managed), for instance.
5.e.
Pricing: Specific pricing
requirements may be
included in the Terms and
Conditions; for example
pricing and/or billing
Our member companies offer a wide variety of pricing models and terms and conditions, hence as stated
in #5 we recommend that the GSA negotiate individually with each major CSP in order to tailor and
streamline the acquisition terms at the base contract level. Additional terms and conditions may be added
at the ordering level depending on the specific acquisition situation.
.
8
#
Question
Response
requirements to ensure
that government agencies
can take advantage of the
scalable and metered
nature of cloud services.
5.f.
Data Center Location:
Location of the data
centers can be a high
priority concern for many
government customers. It
is contemplated that the
data center locations will
not be restricted at the
SIN level, but must be
identified at the Task
Order level. Based on a
wide variety of customer
requirements it is
expected that it will be the
responsibility of the
Ordering Activity to make
a determination of
acceptable data center
locations and set any
location-specific
requirements.
ITAPS agrees that data center location should be the responsibility of the ordering activity. A high level set
of requirements for data center locations should be included with the SINs, (i.e. CONUS or OCONUS) with
the specifics left to the ordering activity.
6.
General Feedback: Does
your company have any
other general feedback
about the proposed SIN?
ITAPS has no further feedback for GSA at this time.
9
10