DRAFT CHARTER – 19 July 2012

Name 
OASIS Cloud Requirements Technical Committee
(abbreviated as OASIS CloudReqs TC). 

Statement of Purpose 
Many organizations are evaluating the use of, and increasingly converting many of their information and communication technology ("ICT") systems to cloud and other remote distributed computing services and installations. The nature of these relatively novel systems requires some re-examination of the requirements generally applied to ICT functions on which they rely, including their: 
•	Safety, reliability, stability and minimal risk;
•	Legislative conformance;
•	Regulatory compliance; 
•	Degree of control and auditability by or on behalf of the responsible organization; 
•	Reliance on and vulnerability to single sources, vendors, formats, applications or computing protocols; 
•	Usability and extensibility of data and data functions by anticipatable stakeholders; 
•	Portability of data;  
•	Portability and composability of data functions across multiple systems and clouds operating in concert; 
•	Cost effectiveness; and
•	Skills needs.

The increased speed, functionality, reach and efficiencies sought and availability from cloud computing methods in some cases puts unique stresses on the foregoing conventional ICT requirements, and may also give rise to special needs not encountered or well defined in segregated, stand-alone computing installations. 
Some work has been done (as cited below) in creating typologies of cloud computing service function levels, and towards models of services; and several recently-formed coalitions have proposed requirements lists at one or another level of cloud activity. However, there is little help available to integrate those lists into common, readily-understood rules that inform procurement, auditable assurance and conformance testing and acquisition criteria; and little or no openly available, vendor-neutral information mapping such requirements to the rather large but loosely-organized body of existing ICT standards. 
The foregoing state of affairs can lead to haphazard, constantly-changing criteria; serious difficulties in comparing or evaluating possible cloud services; accidental data architectures (or none at all); and a failure to take advantage of easily-used but hard-to-fine bodies of existing openly-available work. The Cloud Requirements (CloudReqs) TC will draw together a common set of attributes and operational requirements that are generic and relevant to all business domains at each of the major service levels of cloud systems and provide more specific subsets for particular business domains, eg the public sector.  In addition it will map these requirements to existing open standards and published works that supply methods of measurement and definition. 

Scope of the TC's work 
The committee will develop a set of common required functional elements, and measurable criteria or qualities that should be present in cloud computing services or installations employed by all organizations, whether purchased, hired or self-created and self-installed.  In this context, "should be present" refers to aspects of a cloud service or installation that are likely to be necessary to reflect acceptable risk profiles.  

In addition the committee will develop a number of specific business domain subsets of the general model, the first one being for the public sector. 

The objective of this work will be to provide a framework of readily-understood requirements that can be sued in the procurement, auditability, and conformance testing and accreditation of cloud services.

Out of Scope: The TC's deliverables will not recommend or require the use of specific tools, products, technologies, software systems or branded commercial or noncommercial services. However, the TC may demonstrate implementation by publishing profiles based on specific protocols, and may identify which tools are used in connection therewith where needed to permit replication of results. 

Deliverables 
1	The TC will develop and deliver a measurable and auditable implementation/conformance profile for all business domains.  The profile will include as a minimum the following: a base set of required attributes, expressed as architecture-neutral functional features, that generally should be sought in any cloud or remote computing infrastructure employed by or on behalf of organizations (including computer networking, network management, data storage and shared repository, service or device management and virtualization management). 
2	A base set of required attributes, expressed as architecture-neutral functional features, that generally should be sought in any cloud or remote computing platform services employed by or on behalf of organizations (including common transactional, eventing, notification and messaging operations such as middleware and enterprise service buses, and interaction patterns and protocols among autonomous physical or virtual machines). 
3	A base set of required attributes, expressed as architecture-neutral functional features, that generally should be sought in any cloud or remote computing data application services employed by or on behalf of organizations (including application program interfaces (APIs) and end-user software applications). 
4	A subset of the base set of attributes mentioned above for specific business domains.  The first such subset being for the public sector with others to follow as the demand arises.
5	If deemed useful and feasible, a similar requirements analysis for any other specific levels of cloud or remote computing services that the TC identifies and views as significant and requiring distinct treatment. 
6	If deemed feasible, a synthesis of the foregoing requirements across levels of service and abstraction. Whether generalized statements of universally applicable common requirements, bridging across multiple architectural levels, can be made meaningfully and are useful will be a question for the TC. 
7	In each of the foregoing, identification of existing ICT standards and openly-available, vendor-neutral specifications that are available to implement and measure the foregoing requirements. 
8	If deemed useful and feasible, gap analysis identification of those requirements where additional openly-available methods are needed for implementation and measurement. 
9	If deemed useful and feasible a Cloud Reference Model that would include amongst other aspects a common taxonomy of online services and a shared information model.

The deliverables shall: 
a.	Be vendor-neutral and product-agnostic. (The TC may also elect to point to or provide proof-of-concept instances of specific protocol uses, but will strive for catholicity and multiple examples, and facilitate ease of implementation regardless of protocol choices.) 
b.	Wherever feasible, specify and explain methodologies for compatibility with legacy system integration and incremental adoption. 
c.	Indicate opportunities for the utilization of existing, stable open standards and openly-published criteria, generally supporting re-use of existing artifacts where plausible. The foregoing does not preclude references to ongoing but incomplete specifications, nor statements about the need for future or alternative projects. 

IPR Mode 
The committee will operate under the [Non-Assertion Mode] of the OASIS IPR Policy. 

Anticipated audience 
•	All entities responsible for data and computing resources, particularly those who have migrated or are evaluating migrating to cloud computing architectures. 
•	Market participants who consume rely on and transact with those resources. 
•	Regulators and policymakers with an interest in the procurement, control, interoperability, auditability, certification and accreditation of cloud resources. 
•	Providers of cloud computing services, devices and advisory assistance who support the evaluation, initialization, migration, maintenance and monitoring of cloud computing services and installations. 
•	Data integrators for the products & services used by the foregoing. 
•	Providers of certification and accreditation services.

Language 
The TC will conduct its business in English but will strive to translate its deliverables in a number of non-English languages. The TC may elect to form subcommittees that produce localized documentation of the TC's work in additional languages. 
Additional Non-normative Information 

Similar or applicable work 
The proposers are unaware of any currently published work that covers the entire scope described here.  Some elements of the project may be informed by or related to the following: 
•	OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) Technical Committee 
•	OASIS Identity in the Cloud Technical Committee, and particularly its ID-Cloud Gap Analysis Data Collection (cataloging distributed identity service use cases) 
•	OASIS Transformational Government Framework Technical Committee, and particularly its TGF Pattern Language Core Patterns (cataloging, among other things, policy goals for ICT egov operations in a controlled vocabulary) 
•	ODCA Open Data Center Usage Models v1 (June 2011): 
•	Security Monitoring 
•	Security Provider Assurance 
•	IO Control (for QoS coordination across networks) 
•	VM Interoperability 
•	Common Management & Policy Regulatory Framework 
•	Guide industry in requirements and compliance management best practices 
•	Cloud Service Catalog 
•	Standard Units of Measurement for IaaS 
•	ISO/IEC JTC1/SC38 (Distributed application platforms and services) Working Group 3 on Cloud Computing, and particularly its Use case Analysis Methodology and Principle of Cloud Service Delivery 
•	The European Interoperability Framework, v2, European Commission (2010) 
•	SOA Reference Model v1.0, OASIS Standard (2006) 
•	SOA Governance Framework v1, The Open Group (2009) 
•	OASIS Test Assertions Guidelines (TAG) Technical Committee 
•	Cloud Audit ("A6") Project, Cloud Security Alliance 
•	DMTF Common Information Model ("CIM") v2.30.0 (2011) 
•	DMTF Open Virtualization Format ("OVF") v1.1.0 (2010) 
•	OASIS Privacy Management Reference Model (PMRM) Technical Committee
•	Kantara Initiative CloudIDsec  WG
•	[Others?] 

Date & time of first meeting 
[To be discussed. Target would be to hold the first meeting adjacent to the OASIS ICS 2012 event in Washington DC on 10-12 October 2012.] 

Ongoing meeting schedule 
[To be decided by the committee. Monthly teleconferences and (semi-annual) face to face work session may be appropriate.] 

Participants 
The names, electronic mail addresses, and membership affiliations of at least Minimum Membership who support this proposal: 
Adil Soussi Nachit, adil.soussinachit@minfin.fed.be, Belgian SPFF
John Borras, johnaborras@yahoo.co.uk, Individual
Peter Brown, peter@peterfbrown.com, Individual
Neil McEvoy, [neil.mcevoy@l5consulting.net],  iFOSSF.org
[ODCA]
[Others?]

Convener 
The convener will be John Borras. 
Member Section Affiliation
[eGov]