Now there's an incentive if ever I saw
one! :-)
thanks
-Doug
______________________________________________________
STSM | Standards Architect | IBM Software Group
(919) 254-6905 | IBM 444-6905 |
The more I'm around some people, the more I like my dog.
Martin Chapman <>
Sent by: <>
10/21/2011 10:28 AM
To
Patrick Durusau <>,
cc
Chet Ensign <>,
, , Staff <>,
, , ,
, , , "Patil,
Sanjay" <>, ,
, Paul Fremantle <>, ,
, , , ,
, "Probst, Richard" <>,
, , ,
, , , ,
, , ,
, Mike Baskey/Poughkeepsie/IBM@IBMUS, ,
, , , "Sundaresh,
Chandrasekha" <>, "Sijelmassi,
Rachid" <>, "Moscovich, Efraim"
<>, , "Lipton,
Paul C" <>,
Subject
RE: [oasis-charter-discuss] Re: [members]
Proposed Charter for OASIS Topology and Orchestration Specification for
Cloud Applications (TOSCA) TC
Patrick,
I will eat my hat if they get to OASIS Committee Spec in 9 months - and
record it and put it on youtube. Dates like these are aspirational, common,
and always missed!
Martin.
> -----Original Message-----
> From: Patrick Durusau [mailto:]
> Sent: 20 October 2011 21:40
> To:
> Cc: Chet Ensign; ; -
> open.org; Staff; ; ;
> ; ; ;
> ; Patil, Sanjay; ;
> ; Paul Fremantle; ; ;
> ; ; ; ;
> Probst, Richard; ; ;
> ; ; ;
> ; ; ;
> ; ;
> ; ; ;
> ; ; ;
> Sundaresh, Chandrasekha; Sijelmassi, Rachid; Moscovich, Efraim;
> ; Lipton, Paul C;
> Subject: [oasis-charter-discuss] Re: [members] Proposed Charter for
OASIS
> Topology and Orchestration Specification for Cloud Applications (TOSCA)
TC
>
> Chet,
>
> First, OASIS needs to get the mailing lists configured so you can
post
> the list and thus replies will be to the list and not you.
>
> Second, I am troubled by the the language:
>
> > The TOSCA TC will provide the following set of deliverables:
> >
> > 1. A revised Topology and Orchestration Specification for Cloud
> > Applications, and associated XML Schema plus conformance statements
> > will be approved and completed by the TC within nine months of
the
> > first TOSCA TC meeting.
> > 2. A set of sample Cloud Service Templates and related artifacts
will
> > be approved and completed by the TC within nine months of the
first
> > TOSCA TC meeting. These examples are non-normative, but can be
used as
> > test cases for testing conformance of individual TOSCA implementations
> > as well as interoperability between multiple TOSCA implementations.
> > 3. Optionally, such other non-normative deliverables within the
scope
> > listed in paragraphs 1-8 such as tutorials or presentations),
as the
> > TC may elect, within nine months of the first TOSCA TC meeting.
> >
> > Maintenance: Once the TC has completed work on a deliverable
and it
> > has become an OASIS Standard, the TC will enter "maintenance
mode" for
> > the deliverable.
> > The purpose of maintenance mode is to provide minor revisions
to
> > previously adopted deliverables to clarify ambiguities,
> > inconsistencies and obvious errors. Maintenance mode is not intended
> > to enhance a deliverable or to extend its functionality.
>
> Apparently the proposers of this TC have some content in mind that
is
> sufficient in their view to become both a Committee Specification
as
> well as an OASIS Standard. That may or may not be the case.
>
> It is certainly *not the case* that proposers can set arbitrary
> deadlines for the completion of work that has yet to be seen by the
> OASIS members who will be called to vote upon it.
>
> I am well familiar with the "standards process is too slow"
refrain,
> which rings false in light of 2 or 3 year development cycles for serious
> software. I am excluding vaporware from consideration.
>
> I am also aware that the "9-month to approval" content has
not been
> disclosed and that is the subject of another thread. I won't repeat
> those concerns but I share them.
>
> Just in case the proposers are unfamiliar with OASIS, an *open*
> standards process doesn't have "gotcha" filing of documents,
pre-set
> limits on discussion and revision, pre-determined approval and
> maintenance schedules and the like.
>
> Just as an aside to the TAB: Perhaps we need a 2-3 page - How Open
> Standards Develop type document that closes with common mis-steps
like
> trying to force approval of not substantially revised proposals as
> "standards." There is a name for that sort of content but
"standard"
> isn't one of them.
>
> Hope you are having a great day!
>
> Patrick
>
>
>
>
> On 10/20/2011 08:18 AM, Chet Ensign wrote:
> > To OASIS Members:
> >
> > A draft TC charter has been submitted to establish the OASIS
Topology
> > and Orchestration Specification for Cloud Applications (TOSCA)
> > Technical Committee. In accordance with the OASIS TC Process
Policy
> > section 2.2: (http://www.oasis-open.org/committees/process-2009-07-
> 30.php#formation)
> > the proposed charter is hereby submitted for comment. The comment
> > period shall remain open until 11:45 pm ET on 3 November 2011.
> >
> > OASIS maintains a mailing list for the purpose of submitting
comments
> > on proposed charters. Any OASIS member may post to this list
by
> > sending email to: .
All
> > messages will be publicly archived at:
> > http://lists.oasis-open.org/archives/oasis-charter-discuss/.
Members
> > who wish to receive emails must join the group by selecting "join
> > group" on the group home page:
> > http://www.oasis-open.org/apps/org/workgroup/oasis-charter-discuss/.
> > Employees of organizational members do not require primary
> > representative approval to subscribe to the oasis-charter-discuss
> > e-mail.
> >
> > A telephone conference will be held among the Convener, the OASIS
TC
> > Administrator, and those proposers who wish to attend within
four days
> > of the close of the comment period. The announcement and call-in
> > information will be noted on the OASIS Charter Discuss Group
Calendar.
> >
> > We encourage member comment and ask that you note the name of
the
> > proposed TC (TOSCA TC) in the subject line of your email message.
> >
> > ---
> >
> > PROPOSED CHARTER
> >
> > 1.a Name of the TC:
> > OASIS Topology and Orchestration Specification for Cloud Applications
> > (TOSCA) Technical Committee
> >
> >
> > 1.b Statement of Purpose:
> > The goal of the Topology and Orchestration Specification for
Cloud
> > Applications (TOSCA) TC is to substantially enhance the portability
of
> > cloud applications and the IT services that comprise them running
on
> > complex software and hardware infrastructure.
> >
> > TOSCA will facilitate this goal by enabling the interoperable
> > description of application and infrastructure cloud services,
the
> > relationships between parts of the service, and the operational
> > behavior of these services (e.g., deploy, patch, shutdown) independent
> > of the supplier creating the service, and any particular cloud
> > provider or hosting technology. TOSCA will also enable the association
> > of that higher-level operational behavior with cloud infrastructure
> > management.
> >
> > This capability will greatly facilitate much higher levels of
cloud
> > service/solution portability without lock-in, including:
> >
> > * Portable deployment to any compliant cloud
> > * Easier migration of existing applications
to the cloud
> > * Flexible bursting (consumer choice)
> > * Dynamic multi-cloud provider applications
> >
> > Ultimately, this will benefit the consumers, developers, and
providers
> > of cloud-based solutions and provide an essential foundation
for even
> > higher-level TOSCA-based vocabularies that could be focused on
> > specific solutions and domains.
> >
> >
> > 1.c Scope of Work:
> > The TOSCA TC intends to accept as one input the draft TOSCA
> > specification [1] provided by Capgemini, CA Technologies, Cisco,
> > Citrix, EMC, IBM, PwC, Red Hat, SAP, Software AG, Virtunomic,
and
> > WSO2, as well as any subsequent input documents accepted by the
TOSCA
> > TC. The TOSCA TC will use this draft TOSCA specification as a
> > foundation for further standardization of a basic set of concrete
> > components, relationships and properties (with extension mechanisms
to
> > add additional components, relationships and properties). Further
work
> > on specific vocabularies, based on these extension mechanisms,
is out
> > of scope for this specification, but could begin in parallel
with this
> > project, using the TOSCA naming syntax.
> >
> > The scope of the TOSCA TC's work is to produce specifications
that
> > standardize the concepts as well as XML documents and XML Schema
> > renderings of the areas described below by further refinement
and
> > finalization of the input document and any subsequent input documents
> > accepted by the TOSCA TC. The following items are specifically
in
> > scope of the resulting TOSCA specification:
> >
> > 1. A language that provides the ability to specify a Service
Template
> > that can define the topology (or structure) of a service and
that can
> > utilize existing process modeling standards (especially BPMN
2.0) to
> > define orchestration (via "plans") that can invoke
the manageability
> > behavior of cloud services.
> > 2. A syntax for naming component types, components, relationship
> > types, relationships, and properties, and for grouping of components.
> > 3. The ability to constrain the use of the various elements and
their
> > properties that define the topology of a service.
> > 4. The ability to cross-reference Service Templates to enable
> > composition of services and to enable the management of instantiations
> > of a Service Template in heterogeneous environments.
> > 5. The ability to use virtual images as implementation artifacts
for
> > parts of a Service Template.
> > 6. The ability to use application artifacts (e.g. JEE, ABAP,
etc) as
> > deployment artifacts for parts of a Service Template.
> > 7. The ability to use other artifacts (e.g. EAR files, OVF files,
SCA
> > components, etc) as deployment artifacts for parts of a Service
> > Template.
> > 8. The ability to annotate the various elements that define the
> > topology of a Service Template with policies that influence use
of
> > instances of a Service Template. Such annotations could leverage
a
> > wide range of policy languages (e.g. WS-Policy [2], KaoS [3],
etc.).
> >
> > Compatibility: There are no formal requirements for upward
> > compatibility. Nevertheless, the specification should be compatible
> > with existing business process modeling standards like BPMN 2.0
[4]
> > and WS-BPEL [5]. Furthermore, interfaces of component types should
be
> > able to be expressed in a proper REST-style based on HTTP and
> > specified via WSDL 1.1, and allow for the use of scripts.
> >
> >
> > Out of Scope: The following is a non-exhaustive list. It
is provided
> > only for the sake of clarity. If some function, mechanism or
feature
> > is not mentioned here, and it is not mentioned in the Scope of
Work
> > section, then it will be deemed to be out of scope. The following
> > items are specifically out of scope of the TOSCA specification:
> >
> > 1. The definition of concrete cloud services, i.e. the definition
of
> > concrete component types, relationship types, and topology templates.
> > However, standardization of a basic set of concrete component
types,
> > relationship types and properties is intended to be enabled by
this
> > work, and could begin in parallel with this project, with appropriate
> > coordination.
> > 2. The definition of concrete plans, i.e. the definition of plans
in
> > any process modeling language like BPMN or BPEL.
> > 3. The definition of a language for defining plans (i.e. a new
process
> > modeling language).
> > 4. The definition of concrete policies influencing the management
and
> > use of instances of a Service Template.
> > 5. The emphasis of any particular single technology (e.g. hypervisor
> > virtualization) for the implementation of cloud services.
> > 6. The emphasis of any particular policy definition language
or mechanism.
> > 7. The architecture of a service container used to instantiate
service
> > definitions and manage such instances.
> > 8. The interface definitions of a service container.
> > 9. A graphical notation for modeling Service Templates.
> > 10. The definition of semantic models for cloud services.
> > 11. The specification of functional behavior as well as functional
> > composition of cloud services.
> >
> > Subsequent specifications may provide the Service Templates of
> > concrete cloud services. This will enable, for example, the creation
> > of catalogues of Service Templates in various application domains.
> >
> >
> > 1.d Deliverables
> > The TOSCA TC will provide the following set of deliverables:
> >
> > 1. A revised Topology and Orchestration Specification for Cloud
> > Applications, and associated XML Schema plus conformance statements
> > will be approved and completed by the TC within nine months of
the
> > first TOSCA TC meeting.
> > 2. A set of sample Cloud Service Templates and related artifacts
will
> > be approved and completed by the TC within nine months of the
first
> > TOSCA TC meeting. These examples are non-normative, but can be
used as
> > test cases for testing conformance of individual TOSCA implementations
> > as well as interoperability between multiple TOSCA implementations.
> > 3. Optionally, such other non-normative deliverables within the
scope
> > listed in paragraphs 1-8 such as tutorials or presentations),
as the
> > TC may elect, within nine months of the first TOSCA TC meeting.
> >
> > Maintenance: Once the TC has completed work on a deliverable
and it
> > has become an OASIS Standard, the TC will enter "maintenance
mode" for
> > the deliverable.
> > The purpose of maintenance mode is to provide minor revisions
to
> > previously adopted deliverables to clarify ambiguities,
> > inconsistencies and obvious errors. Maintenance mode is not intended
> > to enhance a deliverable or to extend its functionality.
> >
> > The TC will collect issues raised against the deliverables and
> > periodically process those issues. Issues that request or require
new
> > or enhanced functionality shall be marked as enhancement requests
and
> > set aside. Issues that result in the clarification or correction
of
> > the deliverables shall be processed. The TC shall maintain a
list of
> > these adopted clarifications and shall periodically create a
new minor
> > revision of the deliverables including these updates. Periodically,
> > but at least once a year, the TC shall produce and vote upon
a new
> > minor revision of the deliverables.
> >
> >
> > 1.e IPR Mode
> > This TC will operate under the "RF (Royalty Free) on Limited
Terms"
> > IPR mode as defined in the OASIS Intellectual Property Rights
(IPR)
> > Policy.
> >
> >
> > 1.f Anticipated Audience
> > The anticipated audience for this work includes:
> >
> > 1. Vendors and service providers offering products and/or services
> > designed to host or support cloud services, especially...
> > a. Solutions used to model and create cloud services
> > b. Solutions that support the execution of cloud
services
> > c. Solutions that manage cloud services
> > d. Solutions designed to provide (parts of) cloud
services as virtual
> images
> > e. Solutions designed to deploy or manage cloud
services across
> > multiple service providers
> > 2. Other specification authors that require cloud Service Templates
> > 3. Software architects who design, write, integrate and deploy
cloud
> > services in a cloud environment as well as in a mix of cloud
> > environments and on-premise environments
> > 4. End users implementing solutions that require an interoperable,
> > composable solution using cloud services Language
> >
> >
> > 1.g Language:
> > The output documents will be written in (US) English.
> >
> >
> > References:
> > [1] Topology and Orchestration Specification for Cloud Applications,
> > Draft Specification, September 2011.
> > [2] Web Services Policy 1.5 - Framework, W3C Recommendation,
available
> > via http://www.w3.org/TR/ws-policy/
> > [3] KAoS, Florida Institute for Human and Machine Cognition,
available
> > via http://ontology.ihmc.us/index.html
> > [4] OMG Business Process Model and Notation (BPMN) Version
2.0,
> > available via http://www.omg.org/spec/BPMN/2.0/
> > [5] OASIS Web Services Business Process Execution Language (WS-BPEL)
> > 2.0, available via
> > http://docs.oasis-open.org/wsbpel/2.0/wsbpel-v2.0.pdf
> >
> >
> > ADDITIONAL INFORMATION:
> >
> > 2.a Identification of similar or applicable work:
> > The proposed "TOSCA TC" will be incorporating definitions
and
> > terminologies from OASIS standards bodies as well as standards
work
> > done by non-OASIS organizations. As stated in the charter, The
TC will
> > use standard a standard from one non-OASIS organization and may
choose
> > to use the works of other OASIS TCs and standards from non-OASIS
> > organizations, as it sees fit. Liaisons may be established,
and the
> > TC may agree to concurrent work items with other TCs and
> > organizations, within the scope defined here. Among other things,
the
> > TC may establish liaisons with ISO JTC1 SC 38, the DMTF, and
such
> > other standards organizations, as it may choose.
> >
> >
> > 2.b The date, time, and location of the first meeting:
> > The proposed "TOSCA TC" will hold the first official
meeting on
> > December 8th, 2011 at 7:00am (PT) / 10:00am (ET) by telephone
and will
> > use a free conference call service.
> >
> >
> > 2.c The projected on-going meeting schedule for the year:
> > The TC will meet weekly or as otherwise agreed upon by the members
of
> > the technical committee.
> >
> >
> > 2.d The names, electronic mail addresses, and membership affiliations
> > of at least Minimum Membership who support this proposal:
> >
> > Steve Jones, (Capgemini)
> > Jani Anttila, (Capgemini)
> >
> > Paul Lipton, (CA Technologies)
> > Efraim Moscovich, (CA Technologies)
> > Rachid Sijelmassi, (CA Technologies)
> > Chandrasekha Sundaresh, (CA Technologies)
> >
> > Naveen Joy, (Cisco Systems)
> >
> > Roland Wartenberg, (Citrix Systems,
Inc.)
> > Shishir Pardikar, (Citrix Systems,
Inc.)
> >
> > Wayne Adams, (EMC)
> >
> > Simon Moser, (IBM)
> > Mike Baskey, (IBM)
> > Thomas Spatzier, (IBM)
> > Gerd Breiter, (IBM)
> > Frank Leymann, (IBM)
> >
> > Dhiraj Pathak, PhD, (PwC)
> >
> > Mark Little (Red Hat) - Primary Contact
> > Carl Trieloff (Red Hat) - Secondary Contact
> > John Dunning (Red Hat) - Technical Contact
> > David Lutter (Red Hat) - Technical Contact
> > Sherry Yu (Red Hat) - Technical Contact
> > Vijay Sarathy (Red Hat) - Marketing Contact
> >
> > Steve Winkler, , SAP
> > Richard Probst, , SAP
> > Michael Schuster, , SAP
> > Allen Bannon, , SAP
> > Kevin Poulter, , SAP
> >
> > Prasad Yendluri, (Software AG)
> >
> > Derek Palma, , (Virtunomic)
> >
> > Afkham Azeez, (WSO2)
> > Thilina Buddhika, (WSO2)
> > Paul Fremantle, (WSO2)
> > Srinath Perera, (WSO2)
> > Selvaratnam Uthaiyashankar, (WSO2)
> > Sanjiva Weerawarana, (WSO2)
> > Charith Wickramarachchi, (WSO2)
> >
> > 2.e Primary Representative Approval Statements:
> >
> > Steve Jones,
> > Global Director MDM, Capgemini
> > As Capgemini's Primary Representative, I approve the TOSCA TC
Charter
> > and its goals of standardising the management and orchestration
of
> > cloud solutions, and support our proposers (listed above) as
a named
> > co-proposers.
> >
> > Nancy Cam-Winget,
> > Distinguished Engineer, Cisco Systems, Inc
> > As Cisco Systems Primary Representative, I approve the TOSCA
TC
> > Charter and its worthwhile goals, and support our proposers (listed
> > above) as a named co-proposers.
> >
> > Paul Lipton,
> > VP, Industry Standards and Open Source, CA Technologies
> > As CA Technologies Primary Representative, I approve the TOSCA
TC
> > Charter and its worthwhile goals, and support our proposers (listed
> > above) as a named co-proposers.
> >
> > Roland Wartenberg, Director, Strategic
> > Alliances, Citrix Systems Inc.
> > As Citrix Primary Representative, I approve the TOSCA TC Charter
and
> > its worthwhile goals, and support our proposers (listed above)
as a
> > named co-proposers.
> >
> > Rob Philpott,
> > Senior Technologist, RSA division of EMC
> > As EMC's Primary Representative for OASIS, EMC is pleased with
the
> > prospect of developing the TOSCA specifications under OASIS,
and
> > approve the TOSCA TC Charter. I support our proposer as a named
> > co-proposer. Additionally, EMC plans to bring more representatives
to
> > this project once this important new work is established within
OASIS.
> >
> > Dave Ings,
> > Emerging Software Standards
> > As IBM's primary OASIS rep, I approve the TOSCA TC Charter, and
> > endorse our proposers (listed above) as named co-proposers.
> >
> > Dhiraj Pathak, PhD,
> > PricewaterhouseCoopers LLP
> >
> > Mark Little,
> > As the Red Hat's Primary Representative to OASIS, I approve the
TOSCA
> > TC Charter and its worthwhile goals, and support our proposers
(listed
> > below) as a named co-proposers.
> >
> > Sanjay Patil,
> > Standards Management& Strategy, SAP AG
> > As SAP's Primary Representative for OASIS, I am excited with
the
> > prospect of developing the TOSCA specifications under OASIS,
and
> > approve the TOSCA TC Charter. I support our proposers (listed
above)
> > as the named co-proposers.
> >
> > Prasad Yendluri,
> > VP& Deputy CTO
> > As Software AG's Primary Representative to OASIS, I approve the
TOSCA
> > TC Charter and its stated goals, and support our proposers (listed
> > above) as a named co-proposers.
> >
> > Derek Palma,
> > CTO Virtunomic Inc
> > As Virtunomic's Primary Representative for OASIS, I am excited
with
> > the prospect of developing the TOSCA specifications under OASIS,
and
> > approve the TOSCA TC Charter.
> >
> > Paul Fremantle,
> > As WSO2's primary representative to OASIS, fully support the
proposed
> > TOSCA TC charter, and support our proposers (listed above) as
named
> > co-proposers.
> >
> >
> > 2.f Convener:
> > Paul Lipton, CA Technologies
> >
> > 2.h Optional list of anticipated contributions:
> > The TOSCA TC intends to use as a foundation and input the draft
TOSCA
> > specification [1] provided by Capgemini, CA Technologies, Cisco,
> > Citrix, EMC, IBM, PwC, Red Hat, SAP, Software AG, Virtunomic,
and
> > WSO2, as well as any subsequent input documents accepted by the
TOSCA
> > TC.
> >
>
>
> --
> Patrick Durusau
>
> Chair, V1 - US TAG to JTC 1/SC 34
> Convener, JTC 1/SC 34/WG 3 (Topic Maps)
> Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
> Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)
>
> Another Word For It (blog): http://tm.durusau.net
> Homepage: http://www.durusau.net
> Twitter: patrickDurusau
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: -
> open.org
> For additional commands, e-mail: -
> open.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
