[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Updated: (CAMP-87) Open Data Center Alliance issues
[ http://tools.oasis-open.org/issues/browse/CAMP-87?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adrian Otto updated CAMP-87:
----------------------------
Proposal:
Directional proposal:
To address #2: Add language to section 1.4 to clarify the scope of CAMP with respect to portability of applications and components.
Reply to the comment submitter regarding responses to #1 and #3.
> 1) We could not determine where the security dimension is adequately
> addressed, protecting interactions by means of the API's, and securing
> data transmitted via the API's
In general, security of a CAMP 1.1 Provider's API service is beyond the scope of our specification. Security is not part of our charter.
Section 6.1 requires all Providers to implement TLS 1.1. Consumers are not required to use HTTPS, but the spec says they SHOULD. If a Provider is concerned with security of the data transmitted, they can decide not to support HTTP, and only to support HTTPS. Upon resolution of issue CAMP-18, any authentication scheme may be used, and a method for allowing automatic discovery of the auth scheme is provided by the spec so that Providers have the option of making it discoverable.
> 2) Better positioning may be valuable as to whether these API's are
> meant to support application module inter-operability within a total system,
> or complete PaaS model Orchestration and Operation from a
> management perspective
CAMP aims to allow an ecosystem of Providers who intend to allow application portability between their platforms. Both components of applications and entire application assemblies could be exported from one platform and imported into another. In order for this to work, implementers need a consensus vocabulary about the types that describe semantics. CAMP provides the framework to facilitate that interoperability, but stops short of specifying the meaning of things like "what is an XXX language run-time environment? What features are supported by that stack?"
In section 1.4 CAMP 1.1 states a non-goal:
"The specification of functional interfaces specific to services provided by individual components is out of scope for this document. This is because such interfaces may be quite diverse and differ significantly from platform to platform."
We should make this language more clear about the scope of CAMP, and what we mean by "functional interfaces" being out of scope.
> 3) How do the functionality of theses interfaces benchmark against
> existing well defined PaaS provider solutions like Amazon, Google etc
> - are they sufficiently complete that functionality would not be lost?
CAMP offers a way for Providers to address most common PaaS use cases. It is extensible, and can be adapted to add additional features. This includes the sort of services offered by existing proprietary vendors if they took an interest in portability of applications between platforms.
> Open Data Center Alliance issues
> --------------------------------
>
> Key: CAMP-87
> URL: http://tools.oasis-open.org/issues/browse/CAMP-87
> Project: OASIS Cloud Application Management for Platforms (CAMP) TC
> Issue Type: Bug
> Components: Public Review
> Reporter: Gilbert Pilz
>
> The Open Data Center Alliance has submitted the following comments: https://lists.oasis-open.org/archives/camp-comment/201309/msg00009.html
> 1) We could not determine where the security dimension is adequately addressed, protecting interactions by means of the API's, and securing data transmitted via the API's
> 2) Better positioning may be valuable as to whether these API's are meant to support application module inter-operability within a total system, or complete PaaS model Orchestration and Operation from a management perspective
> 3) How do the functionality of theses interfaces benchmark against existing well defined PaaS provider solutions like Amazon, Google etc - are they sufficiently complete that functionality would not be lost?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]