OASIS Charter Submission Discuss

Expand all | Collapse all

Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

  • 1.  Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-20-2011 12:19
    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: oasis-charter-discuss@lists.oasis-open.org. 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, steve.g.jones@capgemini.com (Capgemini) Jani Anttila, jani.anttila@capgemini.com (Capgemini) Paul Lipton, paul.lipton@ca.com (CA Technologies) Efraim Moscovich, Efraim.Moscovich@ca.com (CA Technologies) Rachid Sijelmassi, Rachid.Sijelmassi@ca.com (CA Technologies) Chandrasekha Sundaresh, Chandrasekha.Sundaresh@ca.com (CA Technologies) Naveen Joy, najoy@cisco.com (Cisco Systems) Roland Wartenberg, roland.wartenberg@citrix.com (Citrix Systems, Inc.) Shishir Pardikar, Shishir.Pardikar@citrix.com (Citrix Systems, Inc.) Wayne Adams, wayne.adams@emc.com (EMC) Simon Moser, smoser@de.ibm.com (IBM) Mike Baskey, mbaskey@us.ibm.com (IBM) Thomas Spatzier, thomas.spatzier@de.ibm.com (IBM) Gerd Breiter, GBREITER@de.ibm.com (IBM) Frank Leymann, Frank.Leymann@iaas.uni-stuttgart.de (IBM) Dhiraj Pathak, PhD, dhiraj.pathak@us.pwc.com (PwC) Mark Little (Red Hat) mlittle@redhat.com - Primary Contact Carl Trieloff (Red Hat) ctrielof@redhat.com - Secondary Contact John Dunning (Red Hat) jdunning@redhat.com - Technical Contact David Lutter (Red Hat) lutter@redhat.com - Technical Contact Sherry Yu (Red Hat) syu@redhat.com - Technical Contact Vijay Sarathy (Red Hat) vsarathy@redhat.com - Marketing Contact Steve Winkler, steve.winkler@sap.com, SAP Richard Probst, richard.probst@sap.com, SAP Michael Schuster, michael.schuster@sap.com, SAP Allen Bannon, allen.bannon@sap.com, SAP Kevin Poulter, kevin.poulter@sap.com, SAP Prasad Yendluri, Prasad.Yendluri@softwareag.com (Software AG) Derek Palma, Dpalma@virtunomic.com, (Virtunomic) Afkham Azeez, azeez@wso2.com (WSO2) Thilina Buddhika, thilinab@wso2.com (WSO2) Paul Fremantle, paul@wso2.com (WSO2) Srinath Perera, srinath@wso2.com (WSO2) Selvaratnam Uthaiyashankar, shankar@wso2.com (WSO2) Sanjiva Weerawarana, sanjiva@wso2.com (WSO2) Charith Wickramarachchi, charith@wso2.com (WSO2) 2.e Primary Representative Approval Statements: Steve Jones, steve.g.jones@capgemini.com 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, ncamwing@cisco.com 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, paul.lipton@ca.com 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, roland.wartenberg@citrix.com 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, robert.philpott@emc.com 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, ings@ca.ibm.com 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, dhiraj.pathak@us.pwc.com PricewaterhouseCoopers LLP Mark Little, mlittle@redhat.com 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, sanjay.patil@sap.com 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, prasad.yendluri@softwareag.com 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, Dpalma@virtunomic.com 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, paul@wso2.com 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. -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open


  • 2.  RE: [oasis-charter-discuss] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-20-2011 13:41
    Chet, Is reference [1] publicly available anywhere, or available to OASIS members. Its hard to determine interest without it! Martin. >


  • 3.  RE: [oasis-charter-discuss] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-20-2011 17:50
    Hi Martin, consistent with common OASIS practice, the authoring companies have decided to share the specification only at the first meeting, where it will be an input document for the upcoming TC. In the meantime, we can share an overview presentation with you - see http://www.slideshare.net/sdmoser/tosca-9798191 . Hopefully you can participate in this first meeting, and until then use the presentation and the charter to determine whether you would be interested in participating in this standardization effort. Mit freundlichen Grüßen / Kind regards Simon Moser Cloud Computing Architect Dept. C453, IBM Research & Development Boeblingen ------------------------------------------------------------------------------------------------------------------------------------------- IBM Deutschland Schoenaicher Str. 220 71032 Boeblingen Phone: +49-7031-16-4304 Fax: +49-7031-16-4890 E-Mail: smoser@de.ibm.com ------------------------------------------------------------------------------------------------------------------------------------------- IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294 From: Martin Chapman <MARTIN.CHAPMAN@ORACLE.COM> To: Chet Ensign <chet.ensign@oasis-open.org>, tc-announce@lists.oasis-open.org, members@lists.oasis-open.org, oasis-charter-discuss@lists.oasis-open.org, Staff <staff@lists.oasis-open.org> Cc: steve.g.jones@capgemini.com, ncamwing@cisco.com, roland.wartenberg@citrix.com, ings@ca.ibm.com, dhiraj.pathak@us.pwc.com, mlittle@redhat.com, "Patil, Sanjay" <sanjay.patil@sap.com>, prasad.yendluri@softwareag.com, Dpalma@virtunomic.com, Paul Fremantle <paul@wso2.com>, azeez@wso2.com, thilinab@wso2.com, srinath@wso2.com, sanjiva@wso2.com, charith@wso2.com, steve.winkler@sap.com, "Probst, Richard" <richard.probst@sap.com>, michael.schuster@sap.com, allen.bannon@sap.com, kevin.poulter@sap.com, vsarathy@redhat.com, syu@redhat.com, lutter@redhat.com, jdunning@redhat.com, ctrielof@redhat.com, Frank.Leymann@iaas.uni-stuttgart.de, Jeff Mischkinsky <JEFF.MISCHKINSKY@ORACLE.COM>, Gerd Breiter/Germany/IBM@IBMDE, Thomas Spatzier/Germany/IBM@IBMDE, mbaskey@us.ibm.com, Simon D Moser/Germany/IBM@IBMDE, wayne.adams@emc.com, Shishir.Pardikar@citrix.com, najoy@cisco.com, "Sundaresh, Chandrasekha" <Chandrasekha.Sundaresh@ca.com>, "Sijelmassi, Rachid" <Rachid.Sijelmassi@ca.com>, "Moscovich, Efraim" <Efraim.Moscovich@ca.com>, jani.anttila@capgemini.com, "Lipton, Paul C" <Paul.Lipton@ca.com>, shankar@wso2.com Date: 20.10.2011 15:40 Subject: RE: [oasis-charter-discuss] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC Chet, Is reference [1] publicly available anywhere, or available to OASIS members. Its hard to determine interest without it! Martin. >


  • 4.  Re: [oasis-charter-discuss] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-20-2011 19:05
    On Oct 20, 2011, at 10:49 AM, Simon D Moser wrote: Hi Martin, consistent with common OASIS practice I'm not sure why you think this is "common practice". AFAIK, the common practice has been to make input specifications available as part of the Charter review process and for it be actually contributed at the first meeting. How can anyone, except the authors look at your specification, conduct a proper evaluation of the charter? Aside from evaluating the technical particulars of the charter requirements to see if it fits with their business interests, how can a potential member make the required IPR commitment when they are unable to see the work which form the initial basis for TC's work.? Oracle will not be able to start its internal process for consideration of joining the TC until that information is available. cheers, jeff , the authoring companies have decided to share the specification only at the first meeting, where it will be an input document for the upcoming TC. In the meantime, we can share an overview presentation with you - see http://www.slideshare.net/sdmoser/tosca-9798191 . Hopefully you can participate in this first meeting, and until then use the presentation and the charter to determine whether you would be interested in participating in this standardization effort. Mit freundlichen Grüßen / Kind regards Simon Moser Cloud Computing Architect Dept. C453, IBM Research & Development Boeblingen ------------------------------------------------------------------------------------------------------------------------------------------- IBM Deutschland Schoenaicher Str. 220 71032 Boeblingen Phone: +49-7031-16-4304 Fax: +49-7031-16-4890 E-Mail: smoser@de.ibm.com ------------------------------------------------------------------------------------------------------------------------------------------- IBM Deutschland Research & Development GmbH / Vorsitzender des Aufsichtsrats: Martin Jetter Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart, HRB 243294 From: Martin Chapman <MARTIN.CHAPMAN@ORACLE.COM> To: Chet Ensign <chet.ensign@oasis-open.org>, tc-announce@lists.oasis-open.org, members@lists.oasis-open.org , oasis-charter-discuss@lists.oasis-open.org, Staff <staff@lists.oasis-open.org> Cc: steve.g.jones@capgemini.com, ncamwing@cisco.com, roland.wartenberg@citrix.com, ings@ca.ibm.com, dhiraj.pathak@us.pwc.com, mlittle@redhat.com, "Patil, Sanjay" <sanjay.patil@sap.com>, prasad.yendluri@softwareag.com, Dpalma@virtunomic.com, Paul Fremantle <paul@wso2.com>, azeez@wso2.com, thilinab@wso2.com, srinath@wso2.com, sanjiva@wso2.com, charith@wso2.com, steve.winkler@sap.com, "Probst, Richard" <richard.probst@sap.com>, michael.schuster@sap.com, allen.bannon@sap.com, kevin.poulter@sap.com, vsarathy@redhat.com, syu@redhat.com, lutter@redhat.com, jdunning@redhat.com, ctrielof@redhat.com, Frank.Leymann@iaas.uni-stuttgart.de, Jeff Mischkinsky <JEFF.MISCHKINSKY@ORACLE.COM>, Gerd Breiter/Germany/ IBM@IBMDE, Thomas Spatzier/Germany/IBM@IBMDE, mbaskey@us.ibm.com, Simon D Moser/Germany/IBM@IBMDE, wayne.adams@emc.com, Shishir.Pardikar@citrix.com, najoy@cisco.com, "Sundaresh, Chandrasekha" <Chandrasekha.Sundaresh@ca.com>, "Sijelmassi, Rachid" <Rachid.Sijelmassi@ca.com>, "Moscovich, Efraim" <Efraim.Moscovich@ca.com>, jani.anttila@capgemini.com, "Lipton, Paul C" <Paul.Lipton@ca.com>, shankar@wso2.com Date: 20.10.2011 15:40 Subject: RE: [oasis-charter-discuss] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC Chet, Is reference [1] publicly available anywhere, or available to OASIS members. Its hard to determine interest without it! Martin.


  • 5.  RE: [oasis-charter-discuss] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-21-2011 12:14
    I let OASIS Members decide if it is good or bad practice, but it thankfully isn't common practice! Martin. >


  • 6.  Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-20-2011 20:40
    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: oasis-charter-discuss@lists.oasis-open.org. 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, steve.g.jones@capgemini.com (Capgemini) Jani Anttila, jani.anttila@capgemini.com (Capgemini) Paul Lipton, paul.lipton@ca.com (CA Technologies) Efraim Moscovich, Efraim.Moscovich@ca.com (CA Technologies) Rachid Sijelmassi, Rachid.Sijelmassi@ca.com (CA Technologies) Chandrasekha Sundaresh, Chandrasekha.Sundaresh@ca.com (CA Technologies) Naveen Joy, najoy@cisco.com (Cisco Systems) Roland Wartenberg, roland.wartenberg@citrix.com (Citrix Systems, Inc.) Shishir Pardikar, Shishir.Pardikar@citrix.com (Citrix Systems, Inc.) Wayne Adams, wayne.adams@emc.com (EMC) Simon Moser, smoser@de.ibm.com (IBM) Mike Baskey, mbaskey@us.ibm.com (IBM) Thomas Spatzier, thomas.spatzier@de.ibm.com (IBM) Gerd Breiter, GBREITER@de.ibm.com (IBM) Frank Leymann, Frank.Leymann@iaas.uni-stuttgart.de (IBM) Dhiraj Pathak, PhD, dhiraj.pathak@us.pwc.com (PwC) Mark Little (Red Hat) mlittle@redhat.com - Primary Contact Carl Trieloff (Red Hat) ctrielof@redhat.com - Secondary Contact John Dunning (Red Hat) jdunning@redhat.com - Technical Contact David Lutter (Red Hat) lutter@redhat.com - Technical Contact Sherry Yu (Red Hat) syu@redhat.com - Technical Contact Vijay Sarathy (Red Hat) vsarathy@redhat.com - Marketing Contact Steve Winkler, steve.winkler@sap.com, SAP Richard Probst, richard.probst@sap.com, SAP Michael Schuster, michael.schuster@sap.com, SAP Allen Bannon, allen.bannon@sap.com, SAP Kevin Poulter, kevin.poulter@sap.com, SAP Prasad Yendluri, Prasad.Yendluri@softwareag.com (Software AG) Derek Palma, Dpalma@virtunomic.com, (Virtunomic) Afkham Azeez, azeez@wso2.com (WSO2) Thilina Buddhika, thilinab@wso2.com (WSO2) Paul Fremantle, paul@wso2.com (WSO2) Srinath Perera, srinath@wso2.com (WSO2) Selvaratnam Uthaiyashankar, shankar@wso2.com (WSO2) Sanjiva Weerawarana, sanjiva@wso2.com (WSO2) Charith Wickramarachchi, charith@wso2.com (WSO2) 2.e Primary Representative Approval Statements: Steve Jones, steve.g.jones@capgemini.com 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, ncamwing@cisco.com 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, paul.lipton@ca.com 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, roland.wartenberg@citrix.com 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, robert.philpott@emc.com 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, ings@ca.ibm.com 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, dhiraj.pathak@us.pwc.com PricewaterhouseCoopers LLP Mark Little, mlittle@redhat.com 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, sanjay.patil@sap.com 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, prasad.yendluri@softwareag.com 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, Dpalma@virtunomic.com 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, paul@wso2.com 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 patrick@durusau.net 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


  • 7.  RE: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-21-2011 14:29
    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. >


  • 8.  RE: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-21-2011 14:40
    Now there's an incentive if ever I saw one!  :-) thanks -Doug ______________________________________________________ STSM  Standards Architect    IBM Software Group (919) 254-6905    IBM 444-6905    dug@us.ibm.com The more I'm around some people, the more I like my dog. Martin Chapman <MARTIN.CHAPMAN@ORACLE.COM> Sent by: <oasis-charter-discuss@lists.oasis-open.org> 10/21/2011 10:28 AM To Patrick Durusau <patrick@durusau.net>, oasis-charter-discuss@lists.oasis-open.org cc Chet Ensign <chet.ensign@oasis-open.org>, tc-announce@lists.oasis-open.org, members@lists.oasis-open.org, Staff <staff@lists.oasis-open.org>, steve.g.jones@capgemini.com, ncamwing@cisco.com, roland.wartenberg@citrix.com, ings@ca.ibm.com, dhiraj.pathak@us.pwc.com, mlittle@redhat.com, "Patil, Sanjay" <sanjay.patil@sap.com>, prasad.yendluri@softwareag.com, Dpalma@virtunomic.com, Paul Fremantle <paul@wso2.com>, azeez@wso2.com, thilinab@wso2.com, srinath@wso2.com, sanjiva@wso2.com, charith@wso2.com, steve.winkler@sap.com, "Probst, Richard" <richard.probst@sap.com>, michael.schuster@sap.com, allen.bannon@sap.com, kevin.poulter@sap.com, vsarathy@redhat.com, syu@redhat.com, lutter@redhat.com, jdunning@redhat.com, ctrielof@redhat.com, Frank.Leymann@iaas.uni-stuttgart.de, GBREITER@de.ibm.com, thomas.spatzier@de.ibm.com, Mike Baskey/Poughkeepsie/IBM@IBMUS, smoser@de.ibm.com, wayne.adams@emc.com, Shishir.Pardikar@citrix.com, najoy@cisco.com, "Sundaresh, Chandrasekha" <Chandrasekha.Sundaresh@ca.com>, "Sijelmassi, Rachid" <Rachid.Sijelmassi@ca.com>, "Moscovich, Efraim" <Efraim.Moscovich@ca.com>, jani.anttila@capgemini.com, "Lipton, Paul C" <Paul.Lipton@ca.com>, shankar@wso2.com 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. >


  • 9.  RE: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-21-2011 14:44
    Agree - that is my experience as well. These deadlines typically turn out to be aspirational (but are still useful for planning and tracking purposes). Martin, may I buy a good sturdy hat for you, just in case ... ;-). Best wishes, Sanjay


  • 10.  RE: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-21-2011 19:46
    Hi Martin, Patrick, OASIS Members, We have been working very aggressively to prepare the specification for publication and standardization in OASIS. Based on our progress and the OASIS process, the timeline suggested the specification would be ready by the first meeting. The authors discussed today and we are prepared to further accelerate our efforts so that we can publish the specification prior to the meeting, which will hopefully provide potential participants enough time to review the content. Best Regards, Steve


  • 11.  Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-21-2011 23:32
    Steve, On 10/21/2011 03:46 PM, Winkler, Steve wrote: Hi Martin, Patrick, OASIS Members, We have been working very aggressively to prepare the specification for publication and standardization in OASIS. Based on our progress and the OASIS process, the timeline suggested the specification would be ready by the first meeting. The authors discussed today and we are prepared to further accelerate our efforts so that we can publish the specification prior to the meeting, which will hopefully provide potential participants enough time to review the content. Deeply appreciate the unseen amount of effort that goes into the development of specification, much less the editing, etc., work. A touchstone of the process at OASIS isn't that specifications are presented for review and then voted up or down (there are "standards" bodies like that) but that input is used as a starting point to elicit the requirements and concerns of OASIS members. It is that public dialogue with OASIS members that reveals both strengths and weaknesses that require modification and extension of a proposed specification so that it meets the needs of the broad community that is OASIS. In this particular instance, availability of the proposed input will help members of OASIS and/or the TAB to make informed comments on the proposed charter. It is difficult to comment on a charter for work based content that is known to the proposers but no one else. Although I would deeply enjoy watching Martin eat his hat, I think it would be more consistent with the nature of public review to say something like: "It is the goal of the TOSCA TC to complete a revision of the Topology and Orchestration Specification for Cloud Applications, and associated XML Schema plus conformance statements that meets the needs of members of the TOSCA TC as soon as possible, consistent with the OASIS process." Hope you are at the start of a great weekend! Patrick PS: The TC may also wish to consider whether the specification is supposed to meet "...the needs of the members of the TOSCA TC..." or if the standard also meets the needs of the public for standards that offer the public greater choices at lower cost. Best Regards, Steve


  • 12.  Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-23-2011 05:29
    Quite a hubbub on charter-discuss about TOSCA. Before I pipe up elsewhere, let me try out my thoughts on you folks. Thinking back, as Chet's great-great-grandpredecessor (or something) TCAdmin, I remember a lot of TC proposals and draft specs that arrived just barely in time. I don't immediately see as much bad intent in TOSCA as some seem to impute. 1. Lots of TCs have no starter spec at all, just a plan. We don't beat them up for being insufficiently prepared. Nothing in the rules requires one. 2. We do encourage proposed TCs to post artifacts, in their charters, if they have them ready by that time. 3. But I don't recall us ever slagging a proposed TC for NOT having some ready. Getting a bunch of diverse players to agree on a draft can be tough, and doesn't always happen as fast as proponents may wish it to. I don't assume bad faith, if someone's behind schedule. 4. Many TCs also announce an intent to quickly complete a phase 1 revision. BPEL a decade ago; AMQP most recently; lots of others. Again, I'm not sure I see an intrinsic problem there. We do strongly encourage proposers to plan for a later, more leisurely rev to take in expansive new contributions, if their first cycle is planned to be short. Is there such a thing as *too* short a first cycle? TC meetings + CSD + PR + CD takes a minimum of, what, 4.5 months? If we really believe that that's too fast to be fair and open, maybe that suggests that our TC Process rule deadlines are wrong? 5. Especially among groups of competitors, there often will be a handful of folks who are thoughtless, reflexive proponents of any given TC ... and a few who are thoughtless, reflexive opponents. As OASIS, we can't possibly keep up with who's aligned with who or consulting for who, in any given case. So when we start hearing a drumbeat of kvetching about a proposed TC ... but no whisper of a rule violation ... our standard position from HQ probably should be not to pay it too much attention. People who don't like a project, or its roll-out, can vote with their feet by declining to join it. Am I missing something? Regards Jamie James Bryce Clark, General Counsel OASIS: Advancing open standards for the information society http://www.oasis-open.org/who/staff.php#clark www.identi.ca/JamieXML www.twitter.com/JamieXML http://t.sina.cn/jamiexml http://facebook.com/oasis.open


  • 13.  Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-23-2011 13:26
    TOSCA looks very similar to AMQP where they are contributing something that already has some uptake and they would like to build on it. But they are coming to OASIS knowing our democratic rules and thus accepting that others will have input and opinions. If other members of OASIS decide that they don't like what they see, they have ample opportunities to have their voices be heard and even to take positions of opposition. While they haven't shared the proposed contribution itself yet, they will make that contribution as one of their first steps - just as AMQP did - and it will be out there for all the world to see. There will be time for people to read and react. Members have acted in the past when they felt something was being railroaded through. I've seen the process at work. So I am not worried about how this will sort itself out. Best, /chet On Sun, Oct 23, 2011 at 1:28 AM, Jamie Clark <jamie.clark@oasis-open.org> wrote: > Quite a hubbub on charter-discuss about TOSCA. > Before I pipe up elsewhere, let me try out my thoughts on you folks. > > Thinking back, as Chet's great-great-grandpredecessor (or something) > TCAdmin, I remember a lot of TC proposals and draft specs that arrived > just barely in time.  I don't immediately see as much bad intent in > TOSCA as some seem to impute. > > 1.  Lots of TCs have no starter spec at all, just a plan.  We don't > beat them up for being insufficiently prepared.  Nothing in the rules > requires one. > > 2.  We do encourage proposed TCs to post artifacts, in their charters, > if they have them ready by that time. > > 3.  But I don't recall us ever slagging a proposed TC for NOT having > some ready.  Getting a bunch of diverse players to agree on a draft > can be tough, and doesn't always happen as fast as proponents may wish > it to.  I don't assume bad faith, if someone's behind schedule. > > 4.  Many TCs also announce an intent to quickly complete a phase 1 > revision.   BPEL a decade ago;  AMQP most recently;  lots of others. > Again, I'm not sure I see an intrinsic problem there.  We do strongly > encourage proposers to plan for a later, more leisurely rev to take in > expansive new contributions, if their first cycle is planned to be > short.   Is there such a thing as *too* short a first cycle?   TC > meetings + CSD + PR + CD takes a minimum of, what, 4.5 months?  If we > really believe that that's too fast to be fair and open, maybe that > suggests that our TC Process rule deadlines are wrong? > > 5.  Especially among groups of competitors, there often will be a > handful of folks who are thoughtless, reflexive proponents of any > given TC ...  and a few who are thoughtless, reflexive opponents.  As > OASIS, we can't possibly keep up with who's aligned with who or > consulting for who, in any given case.  So when we start hearing a > drumbeat of kvetching about a proposed TC ... but no whisper of a rule > violation ... our standard position from HQ probably should be not to > pay it too much attention.  People who don't like a project, or its > roll-out, can vote with their feet by declining to join it. > > Am I missing something? > > Regards  Jamie > > James Bryce Clark, General Counsel > OASIS: Advancing open standards for the information society > http://www.oasis-open.org/who/staff.php#clark > > www.identi.ca/JamieXML > www.twitter.com/JamieXML > http://t.sina.cn/jamiexml > http://facebook.com/oasis.open > -- /chet ---------------- Chet Ensign Director of Standards Development and TC Administration OASIS: Advancing open standards for the information society http://www.oasis-open.org Primary: +1 973-378-3472 Mobile: +1 201-341-1393 Follow OASIS on: LinkedIn:     http://linkd.in/OASISopen Twitter:         http://twitter.com/OASISopen Facebook:   http://facebook.com/oasis.open


  • 14.  Re: [tab] Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-23-2011 14:43
    Chet, On 10/23/2011 09:25 AM, Chet Ensign wrote: TOSCA looks very similar to AMQP where they are contributing something that already has some uptake and they would like to build on it. But they are coming to OASIS knowing our democratic rules and thus accepting that others will have input and opinions. If other members of OASIS decide that they don't like what they see, they have ample opportunities to have their voices be heard and even to take positions of opposition. Yeah, right. Like when I objected to a schema that had *any* as the content model, that is any XML element/attribute content from any source, and the TC disposed of the comment by saying that was what they meant to say? Is that your definition of a voice being heard? The OASIS process has shortened reviews and allows the TC to ignore any comment it doesn't like or that is inconsistent with its view. What about that recommends itself to you as resulting in a quality standard? True enough, rather than running away from such TCs, people could spend their time maintaining voting rights, hopefully in such numbers that they can block progress of really poor work, but who has time to do that? Shouldn't blocking poor work or work completed by a small group of people and then rushed through public review for an OASIS stamp be part of the responsibility of OASIS? The organization? Our "democratic rules" have been weakened to put the TC and its proposers in charge of their work and only be great effort can public input be insisted upon. I think our rules are like that for a reason but I won't speculate on that now. While they haven't shared the proposed contribution itself yet, they will make that contribution as one of their first steps - just as AMQP did - and it will be out there for all the world to see. There will be time for people to read and react. Sure there will be. Have you looked at the review deadlines recently? Can anyone really review say a 100 page specification in 30 days? As in send to your technical and legal departments, then run it to whoever does standards, etc. Deliberately too short in my view. (To say nothing of the next ODF spec which I suspect will top out at 1,500 + pages. But people can read the ODF drafts, unlike in this case.) Members have acted in the past when they felt something was being railroaded through. I've seen the process at work. So I am not worried about how this will sort itself out. It isn't so much a question (for me) of the fate of this particular piece of work. Not having seen it but knowing the players, I have a good idea of its chances in the marketplace (if not OASIS). No harm, no foul as they say. So OASIS members can spend a lot of time and energy that could be avoided by OASIS staff simply saying: You can't come here with completed work that you won't show anyone else. How hard is that? Why isn't that democratic? If I were working for OASIS I would be willing to say exactly that. Publicly. If we want to claim "transparency," then let's be transparent. Hey, that sounds like campaign rhetoric doesn't it? Wonder what we would uncover if we were? Something to think about. Hope everyone is having a great weekend! Patrick PS: I will just write to one of the insiders and ask for a copy. What annoys me is that other OASIS members don't have the same privilege. All I am asking for is access and equal treatment for all. When people want to hide things, it is natural to suspect mens rea rather than incompetence or inexperience. Although looking over the proposers, I have to admit that incompetence is the most likely reason in this case. Best, /chet On Sun, Oct 23, 2011 at 1:28 AM, Jamie Clark<jamie.clark@oasis-open.org> wrote: Quite a hubbub on charter-discuss about TOSCA. Before I pipe up elsewhere, let me try out my thoughts on you folks. Thinking back, as Chet's great-great-grandpredecessor (or something) TCAdmin, I remember a lot of TC proposals and draft specs that arrived just barely in time. I don't immediately see as much bad intent in TOSCA as some seem to impute. 1. Lots of TCs have no starter spec at all, just a plan. We don't beat them up for being insufficiently prepared. Nothing in the rules requires one. 2. We do encourage proposed TCs to post artifacts, in their charters, if they have them ready by that time. 3. But I don't recall us ever slagging a proposed TC for NOT having some ready. Getting a bunch of diverse players to agree on a draft can be tough, and doesn't always happen as fast as proponents may wish it to. I don't assume bad faith, if someone's behind schedule. 4. Many TCs also announce an intent to quickly complete a phase 1 revision. BPEL a decade ago; AMQP most recently; lots of others. Again, I'm not sure I see an intrinsic problem there. We do strongly encourage proposers to plan for a later, more leisurely rev to take in expansive new contributions, if their first cycle is planned to be short. Is there such a thing as *too* short a first cycle? TC meetings + CSD + PR + CD takes a minimum of, what, 4.5 months? If we really believe that that's too fast to be fair and open, maybe that suggests that our TC Process rule deadlines are wrong? 5. Especially among groups of competitors, there often will be a handful of folks who are thoughtless, reflexive proponents of any given TC ... and a few who are thoughtless, reflexive opponents. As OASIS, we can't possibly keep up with who's aligned with who or consulting for who, in any given case. So when we start hearing a drumbeat of kvetching about a proposed TC ... but no whisper of a rule violation ... our standard position from HQ probably should be not to pay it too much attention. People who don't like a project, or its roll-out, can vote with their feet by declining to join it. Am I missing something? Regards Jamie James Bryce Clark, General Counsel OASIS: Advancing open standards for the information society http://www.oasis-open.org/who/staff.php#clark www.identi.ca/JamieXML www.twitter.com/JamieXML http://t.sina.cn/jamiexml http://facebook.com/oasis.open -- Patrick Durusau patrick@durusau.net 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


  • 15.  Re: [tab] Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-24-2011 17:53
    Thanks for these exchanges, they help clarify our options and situation. Patrick, here's your last comment that jumped out at me: > The OASIS process has shortened reviews and allows the > TC to ignore any comment it doesn't like or that is > inconsistent with its view. What about that recommends > itself to you as resulting in a quality standard? > * * * > Shouldn't blocking poor work or work completed by a > small group of people and then rushed through public > review * * * be part of the responsibility of OASIS? * * * > * * * > Our "democratic rules" have been weakened to put > the TC and its proposers in charge of their work and > only be great effort can public input be insisted upon. 1. Yes, working groups are not required to agree with every submitted comment. How is that different than ISO, JTC1 or W3C? How can it be otherwise? If a commenter dislikes the fact that her comments was not accepted, she can vote against, and campaign against, the member ballot. Because we're transparent. Heaven knows, there have been such campaigns. What other protections would you add? 2. "Rushing through public review." What could be done to the public review rules to moderate the qualities you refer to as a rush? Is your critique the current review durations? 3. "The responsibility of OASIS." Well, members vote on OASIS Standards. What else do you think OASIS ought to do, to exercise that responsibility? I know some big standards groups who have an opaque star chamber that gets to veto everything. Never seemed to me to improve quality. It just moved the game from open debates to back rooms. What devices did you have in mind? 4. "Only with great effort" ... I am missing something here. Sorry, may just not be reading this correctly. How did any of our rule changes make public input less welcome or more onerous? Other than requiring explicit votes & response logs, which we do, what else could we do? Regards Jamie James Bryce Clark, General Counsel OASIS: Advancing open standards for the information society http://www.oasis-open.org/who/staff.php#clark www.identi.ca/JamieXML www.twitter.com/JamieXML http://t.sina.cn/jamiexml http://facebook.com/oasis.open On Sun, Oct 23, 2011 at 7:43 AM, Patrick Durusau <patrick@durusau.net> wrote: > The OASIS process has shortened reviews and allows the TC to ignore any comment it doesn't like or that is inconsistent with its view. > > What about that recommends itself to you as resulting in a quality standard? > > True enough, rather than running away from such TCs, people could spend their time maintaining voting rights, hopefully in such numbers that they can block progress of really poor work, but who has time to do that? > > Shouldn't blocking poor work or work completed by a small group of people and then rushed through public review for an OASIS stamp be part of the responsibility of OASIS? The organization? > > Our "democratic rules" have been weakened to put the TC and its proposers in charge of their work and only be great effort can public input be insisted upon.


  • 16.  Re: [tab] Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-24-2011 23:29
    Jamie, A couple of quick comments and then an extended one: On 10/24/2011 01:52 PM, Jamie Clark wrote: Thanks for these exchanges, they help clarify our options and situation. Patrick, here's your last comment that jumped out at me: The OASIS process has shortened reviews and allows the TC to ignore any comment it doesn't like or that is inconsistent with its view. What about that recommends itself to you as resulting in a quality standard? * * * Shouldn't blocking poor work or work completed by a small group of people and then rushed through public review * * * be part of the responsibility of OASIS? * * * * * * Our "democratic rules" have been weakened to put the TC and its proposers in charge of their work and only be great effort can public input be insisted upon. 1. Yes, working groups are not required to agree with every submitted comment. How is that different than ISO, JTC1 or W3C? How can it be otherwise? If a commenter dislikes the fact that her comments was not accepted, she can vote against, and campaign against, the member ballot. Because we're transparent. Heaven knows, there have been such campaigns. What other protections would you add? I am puzzled by your "everybody else does it" defense. Perhaps you meant another one? I haven't heard that seriously urged since grade school. As far as vote/campaign, see below. Protection I would add? Staff with authority to raise the general bar for OASIS specification/standard quality. 2. "Rushing through public review." What could be done to the public review rules to moderate the qualities you refer to as a rush? Is your critique the current review durations? Not entirely duration although that is part of it. Any fixed rule for duration of review is going to be too long or too short. Even now, the review period is a minimum, but every TC I have ever seen treats it as a set period. That is a TC could ask for 90 day public review or 45 day public review. The problem is there is no one with any real authority to suggest to a TC what a good option would be. 3. "The responsibility of OASIS." Well, members vote on OASIS Standards. What else do you think OASIS ought to do, to exercise that responsibility? I know some big standards groups who have an opaque star chamber that gets to veto everything. Never seemed to me to improve quality. It just moved the game from open debates to back rooms. What devices did you have in mind? Offering members qualified editing assistance for their efforts would be one step. They don't all have to be "don't do that," "don't go there," kind of steps. OASIS could be an assisting standards body. No star chambers, etc. See below. 4. "Only with great effort" ... I am missing something here. Sorry, may just not be reading this correctly. How did any of our rule changes make public input less welcome or more onerous? Other than requiring explicit votes& response logs, which we do, what else could we do? Here is the extended comment: Say I am an OASIS sponsor, so I am paying out a fair amount of coin to start with. I have work that I and others think should be OASIS specifications/standards and so I pay my staff to work on those TCs. That meet for months that turn into years. And finally produce what is a high quality spec that floats all board. So that is more coin. In order to protect the OASIS brand, the OASIS staff tells me that I have to pay my staff to be members of TCs to oppose poor quality OASIS specifications or to campaign against poor work offered as OASIS standards. And the OASIS staff tells me, the OASIS sponsor who is already paying my staff to work on what I think are quality standards, that it isn't the business of OASIS staff that poor quality work is appearing as OASIS specifications/standards. So, what is it exactly that I am getting for my OASIS sponsorship? Other than 8 years to replace Kavi and we wind up with Kavi, again? I am not getting: 1) Professional assistance with the creation of my standards as in editing, 2) Professional assistance with the XML aspects of my standards, 3) Keeping the quality of work at OASIS high, 4) Keeping the OASIS brand polished and shiny. (ok, #4 is probably repetitive but I was on a roll.) I am getting: 1) Everyone can have their OASIS standard, 2) OASIS standards don't have to make sense, 3) OASIS standards don't have to be any known form of XML, 4) OASIS members, who are businesses after all, have to spend their before tax dollars to oppose shabby work that isn't of interest to them, in order to police OASIS specifications/standards. I don't doubt standards quality at OASIS has been a mixed experience. But unlike precedence, an poor quality work done in the past, need not be allowed again with impunity. Does that help? Hope you are having a great day! Patrick Regards Jamie James Bryce Clark, General Counsel OASIS: Advancing open standards for the information society http://www.oasis-open.org/who/staff.php#clark www.identi.ca/JamieXML www.twitter.com/JamieXML http://t.sina.cn/jamiexml http://facebook.com/oasis.open On Sun, Oct 23, 2011 at 7:43 AM, Patrick Durusau<patrick@durusau.net> wrote: The OASIS process has shortened reviews and allows the TC to ignore any comment it doesn't like or that is inconsistent with its view. What about that recommends itself to you as resulting in a quality standard? True enough, rather than running away from such TCs, people could spend their time maintaining voting rights, hopefully in such numbers that they can block progress of really poor work, but who has time to do that? Shouldn't blocking poor work or work completed by a small group of people and then rushed through public review for an OASIS stamp be part of the responsibility of OASIS? The organization? Our "democratic rules" have been weakened to put the TC and its proposers in charge of their work and only be great effort can public input be insisted upon. -- Patrick Durusau patrick@durusau.net 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


  • 17.  RE: [tab] Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-24-2011 12:10
    The difference here is that AMQP has existed elsewhere and the input is well known. To start a TC - or more correctly to start the charter review clock ticking- when even the submitters admit they may not have the input document ready for the first meeting is just plain premature. How on earth can anyone outside the group know what the TC is about, and how can anyone outside the group make any sensible review comments on the charter? Why have the charter review process at all if TC admin thinks it meets the requirements of the TC Process? Martin. >


  • 18.  RE: [tab] Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-24-2011 14:08
    I think it is best practise to publish in advance (Martin will recall that is exactly what was done for BPEL4People which I chaired). So I walk the talk. :-) However as Jamie points out it is not mandatory to have a draft document in hand in order to charter a TC. So arguably we have conceptual confusion here - it is being suggested that is OK to start a TC with nothing in hand but if you try and do better than nothing you'd better do so well in advance else a fuss will arise. This strikes me as inconsistent. It also begs the question of whether contributions after the first TC meeting should also be banned. Should they? For if we don't, how do we prevent people from omitting any mention of a contribution from the charter and then just making a contribution at the first or second meeting? Finally, if OASIS is going to mandate pre-publication, then it is going to have to provide hosting facilities, which is currently does not. So this requires a wee more :-) thought than just mandating pre-publication. Regards, Dave Ings, Emerging Software Standards Email: ings@ca.ibm.com Yahoo Messenger: dave_ings Martin Chapman ---2011-10-24 08:13:11 AM---The difference here is that AMQP has existed elsewhere and the input is well known. To start a TC - From: Martin Chapman <MARTIN.CHAPMAN@ORACLE.COM> To: Chet Ensign <chet.ensign@oasis-open.org>, Jamie Clark <jamie.clark@oasis-open.org> Cc: OASIS TAB <tab@lists.oasis-open.org> Date: 2011-10-24 08:13 AM Subject: RE: [tab] Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC Sent by: <tab@lists.oasis-open.org> The difference here is that AMQP has existed elsewhere and the input is well known. To start a TC - or more correctly to start the charter review clock ticking- when even the submitters admit they may not have the input document ready for the first meeting is just plain premature. How on earth can anyone outside the group know what the TC is about, and how can anyone outside the group make any sensible review comments on the charter? Why have the charter review process at all if TC admin thinks it meets the requirements of the TC Process? Martin. >


  • 19.  RE: [tab] Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-24-2011 14:34
    Dave,   All these are valid points. I guess the real meta-issue for me is what is the point/goal of the 30 day charter review process? Aside from pro-forma template issues which are easily checked by TC Admin it seems there is no point. What really helps though is for those not involved in charter creation to understand the goals and scope of a TC, and when one references an unavailable document it is very hard to do that.   As for pre-publication, attaching the proposed input to the announcement email would be adequate IMHO. And of course you cannot ban contributions after the first meeting, otherwise its just rubber stamping, given than any email is a contribution from an IPR perspective!   Martin.   From: Dave Ings [mailto:ings@ca.ibm.com] Sent: 24 October 2011 15:08 To: Martin Chapman Cc: Chet Ensign; Jamie Clark; OASIS TAB Subject: RE: [tab] Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC   I think it is best practise to publish in advance (Martin will recall that is exactly what was done for BPEL4People which I cha! ired). So I walk the talk. :-) However as Jamie points out it is not mandatory to have a draft document in hand in order to charter a TC. So arguably we have conceptual confusion here - it is being suggested that is OK to start a TC with nothing in hand but if you try and do better than nothing you'd better do so well in advance else a fuss will arise. This strikes me as inconsistent. It also begs the question of whether contributions after the first TC meeting should also be banned. Should they? For if we don't, how do we prevent people from omitting any mention of a contribution from the charter and then just making a contribution at the first or second meeting? Finally, if OASIS is going to mandate pre-publication, then it is going to have to provide hosting facilities, which is currently does not. So this requires a wee more :-) thought than just mandating pre-publication. Regards, Dave Ings, Emerging Software Standards Email: ings@ca.i! bm.com Yahoo Messenger: dave_ings Martin Chapman ---2011-10-24 08:13:11 AM---The difference here is that AMQP has existed elsewhere and the input is well known. To start a TC - From: Martin Chapman <MARTIN.CHAPMAN@ORACLE.COM> To: Chet Ensign <chet.ensign@oasis-open.org>, Jamie Clark <jamie.clark@oasis-open.org> Cc: OASIS TAB <tab@lists.oasis-open.org> Date: 2011-10-24 08:13 AM Subject: RE: [tab] Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC Sent by: <tab@lists.oasis-open.org> The difference here is that AMQP has existed elsewhere and the input is well known. To start a TC - or more correctly to start the charter review clock ticking- when even the submitters admit they may not have the input document ready for the first meeting is just plain premature. How on earth can anyone outside the group know what the TC is about, and how can anyone outside the group make any sensible review comments on the charter? Why have the charter review process at all if TC admin thinks it meets the requirements of the TC Process? Martin. >


  • 20.  RE: [tab] Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 11-03-2011 23:46
    I’d say it is hard to justify referencing an unavailable document in a charter – that is probably the main thing where proposers are at fault. That is something that TC admin could object to before publishing a charter.   Having a TC * really * starting on a blank slate is for sure an inconvenience to potential joiners who have nothing more than a charter to look at, but I see nothing wrong with that.   Now, the scenario that would be disingenuous is a charter without any input docs (should we say a “virgin” charter?), and yet soon after the TC started some co-proposer(s) is conveniently bringing-up a draft that clearly is the result of hard work predating the charter.   Some modest ideas to help the above: a no-input (virgin) charter could be required: -           to reference at least a requirements document, something more substantial than the outline in the charter (of course it could be evolved during TC work). -           To list as its first deliverable a requirements document.   -jacques   From: tab@lists.oasis-open.org [mailto:tab@lists.oasis-open.org] On Behalf Of Martin Chapman Sent: Monday, October 24, 2011 7:34 AM To: Dave Ings Cc: Chet Ensign; Jamie Clark; OASIS TAB Subject: RE: [tab] Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC   Dave,   All these are valid points. I guess the real meta-issue for me is what is the point/goal of the 30 day charter review process? Aside from pro-forma template issues which are easily checked by TC Admin it seems there is no point. What really helps though is for those not involved in charter creation to understand the goals and scope of a TC, and when one references an unavailable document it is very hard to do that.   As for pre-publication, attaching the proposed input to the announcement email would be adequate IMHO. And of course you cannot ban contributions after the first meeting, otherwise its just rubber stamping, given than any email is a contribution from an IPR perspective!   Martin.   From: Dave Ings [mailto:ings@ca.ibm.com] Sent: 24 October 2011 15:08 To: Martin Chapman Cc: Chet Ensign; Jamie Clark; OASIS TAB Subject: RE: [tab] Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC   I think it is best practise to publish in advance (Martin will recall that is exactly what was done for BPEL4People which I cha! ired). So I walk the talk. :-) However as Jamie points out it is not mandatory to have a draft document in hand in order to charter a TC. So arguably we have conceptual confusion here - it is being suggested that is OK to start a TC with nothing in hand but if you try and do better than nothing you'd better do so well in advance else a fuss will arise. This strikes me as inconsistent. It also begs the question of whether contributions after the first TC meeting should also be banned. Should they? For if we don't, how do we prevent people from omitting any mention of a contribution from the charter and then just making a contribution at the first or second meeting? Finally, if OASIS is going to mandate pre-publication, then it is going to have to provide hosting facilities, which is currently does not. So this requires a wee more :-) thought than just mandating pre-publication. Regards, Dave Ings, Emerging Software Standards Email: ings@ca.i! bm.com Yahoo Messenger: dave_ings Martin Chapman ---2011-10-24 08:13:11 AM---The difference here is that AMQP has existed elsewhere and the input is well known. To start a TC - From: Martin Chapman <MARTIN.CHAPMAN@ORACLE.COM> To: Chet Ensign <chet.ensign@oasis-open.org>, Jamie Clark <jamie.clark@oasis-open.org> Cc: OASIS TAB <tab@lists.oasis-open.org> Date: 2011-10-24 08:13 AM Subject: RE: [tab] Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC Sent by: <tab@lists.oasis-open.org> The difference here is that AMQP has existed elsewhere and the input is well known. To start a TC - or more correctly to start the charter review clock ticking- when even the submitters admit they may not have the input document ready for the first meeting is just plain premature. How on earth can anyone outside the group know what the TC is about, and how can anyone outside the group make any sensible review comments on the charter? Why have the charter review process at all if TC admin thinks it meets the requirements of the TC Process? Martin. >


  • 21.  Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-25-2011 18:18
    Thanks steve. We appreciate the effort. Nevertheless until the foundational specification is released we don't understand how anyone can properly evaluate the TC and make the necessary IPR commitments. We look forward to being able to read the specification and will be happy to start our internal review and process for joining an OASIS TC, should we decide we wish to participate AFTER it is made available. Just curious, how many weeks are going to give folks to digest the specification, which i would guess it going to be a significant piece of work, before you ask the TC to accept it? cheers, jeff On Oct 21, 2011, at 12:46 PM, Winkler, Steve wrote: Hi Martin, Patrick, OASIS Members, We have been working very aggressively to prepare the specification for publication and standardization in OASIS. Based on our progress and the OASIS process, the timeline suggested the specification would be ready by the first meeting. The authors discussed today and we are prepared to further accelerate our efforts so that we can publish the specification prior to the meeting, which will hopefully provide potential participants enough time to review the content. Best Regards, Steve


  • 22.  RE: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-27-2011 17:14
    Hi fellow OASIS members and Jeff, Thanks for your comments and suggestions to date regarding the proposed TOSCA TC. In response to the interest expressed in having more time before the first TC meeting to reflect upon the technical details of specification that we intend to propose as a foundational input document, we have posted the specification at www.tosca-open.org. We intend to submit this document at the first meeting, on December 8th, and hope that providing the draft specification now will encourage participation in the TC. Please review the documents and let us know if you have any questions. We look forward to seeing you at the first meeting. Best regards, Paul Lipton CA Technologies VP, Industry Standards and Open Source Member, CA Council for Technical Excellence Office Phone: +1 609 583-9718 Mobile: +1 267 987-6887 Email: paul.lipton@ca.com


  • 23.  Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 10-27-2011 17:26
    thanks paul! cheers, jeff On Oct 27, 2011, at 10:13 AM, Lipton, Paul C wrote: Hi fellow OASIS members and Jeff, Thanks for your comments and suggestions to date regarding the proposed TOSCA TC. In response to the interest expressed in having more time before the first TC meeting to reflect upon the technical details of specification that we intend to propose as a foundational input document, we have posted the specification at www.tosca- open.org. We intend to submit this document at the first meeting, on December 8th, and hope that providing the draft specification now will encourage participation in the TC. Please review the documents and let us know if you have any questions. We look forward to seeing you at the first meeting. Best regards, Paul Lipton CA Technologies VP, Industry Standards and Open Source Member, CA Council for Technical Excellence Office Phone: +1 609 583-9718 Mobile: +1 267 987-6887 Email: paul.lipton@ca.com


  • 24.  Re: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 11-11-2011 16:40
    Paul, Thanks! Just scanning the document, more detailed read to follow: 1) Instead of "The <RelationshipType> element has the following properties" consider: "The <RelationshipType> element has the following *attributes*" Attributes being the more common usage. 2) Consider giving every element separate numbered section. For example, if I refer to 5.2 Properties, do I intend a reference to <RelationshipType>, <RelationshipTypeProperties>, <InstanceStates>, or <InstanceState>? That may seem picky but if it is possible this standard may progress into ISO/IEC at some future point, that will be a requirement (well, not on first submission but later ones and it is good form to have unambiguous references). 3) You cite XPath 1.0 but the W3C is recommending XPath 2.0 for current work. Unless there was some breaking change, for which you need XPath 1.0, consider using the later version and validating using it, just to be sure there are no problems. Most of my comments are likely to be XML or formal standards drafting comments and not substantive to the subject matter. Probably more appropriate for the TC or its editor to consider after the first meeting. In other words my feelings won't be hurt if any observations I have time to make about the draft don't come up at the first meeting. The group will have a number of other things on its agenda. Hope you are looking forward to a great weekend! Patrick On 10/27/2011 01:13 PM, Lipton, Paul C wrote: Hi fellow OASIS members and Jeff, Thanks for your comments and suggestions to date regarding the proposed TOSCA TC. In response to the interest expressed in having more time before the first TC meeting to reflect upon the technical details of specification that we intend to propose as a foundational input document, we have posted the specification at www.tosca-open.org. We intend to submit this document at the first meeting, on December 8th, and hope that providing the draft specification now will encourage participation in the TC. Please review the documents and let us know if you have any questions. We look forward to seeing you at the first meeting. Best regards, Paul Lipton CA Technologies VP, Industry Standards and Open Source Member, CA Council for Technical Excellence Office Phone: +1 609 583-9718 Mobile: +1 267 987-6887 Email: paul.lipton@ca.com


  • 25.  RE: [oasis-charter-discuss] Re: [members] Proposed Charter for OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC

    Posted 12-08-2011 01:18
    Hi Patrick, Apologies for the delayed response and thank you for taking time to take a look at the spec contribution, which we plan to submit to the TC for consideration as an editorial starting point and for further discussion and development. I think it would be a good idea for the TC to take your comments below and generate an issue around them for further consideration. Of course, you can always join the TC and help guide us with your thoughts and suggestions more directly and in real-time (hint, hint). :-) Again, thanks for sharing your thoughts. Best regards, Paul   Paul Lipton CA Technologies VP, Industry Standards and Open Source Member, CA Council for Technical Excellence Office Phone: +1 609 583-9718 Mobile: +1 267 987-6887 Email: paul.lipton@ca.com THIS MESSAGE MAY CONTAIN CONFIDENTIAL, PRIVILEGED OR OTHER LEGALLY PROTECTED INFORMATION. IT IS INTENDED FOR THE ADDRESSEE ONLY. IF YOU ARE NOT THE ADDRESSEE (OR SOMEONE THE ADDRESSEE AUTHORIZED TO RECEIVE THIS MESSAGE), YOU ARE PROHIBITED FROM COPYING, DISTRIBUTING OR OTHERWISE USING IT. PLEASE NOTIFY THE SENDER AND RETURN IT AT OUR COST. THANK YOU.