1. Draft Minutes of OASIS TOSCA TC Meeting
URL OF CALENDAR EVENT (this also has meeting attendance): https://www.oasis-
open.org/apps/org/workgroup/tosca/event.php?event_id=32586
DATE: June 7, 2012
TIME: 12:00 noon EDT
Scribe: Richard Probst (SAP)
Meeting was quorate: YES
Observers:
Cloudsoft Corporation Limited Rich Miller
Hewlett-Packard Bryan Murray
Roster
[The co-chairs maintain the roster based on the TC Process rules. Since rights are
gained/lost at the end of a meeting and the co-chairs update between meetings, the roster
should be accurate at the start of each meeting. You can view it at: http://www.oasis-
open.org/apps/org/workgroup/tosca/members/roster.php]
Approval of Minutes
Simon Mosermoved for the below draft minutes to be approved. Seconded by Paul Lipton.
Date of meeting: May 31, 2012: https://www.oasis-
open.org/apps/org/workgroup/tosca/download.php/46146/TOSCA%20TC%20Minutes%202012-05-
31.docx
Motion PASSES by unanimous consent
Approved Agenda:
Based on review and discussion of the proposed agenda, Simon Moser moved for the below
agenda to be approved. Seconded by Paul Lipton.Motion PASSES by unanimous consent.
PROPOSED AGENDA
Welcome / Roll for those who cannot record their own attendance
Co-chair appoints a scribe
Review/approve draft proposed agenda
Review/approve draft minutes
* May 31: https://www.oasis-
open.org/apps/org/workgroup/tosca/download.php/46146/TOSCA%20TC%20Minutes%202012-05-
31.docx
* Thanks to Dale Moberg for scribing
Editors status report
* Problems, questions, etc.
Spec issues/Proposals/Bugs queue (time permitting)

2. NOTE: When practical, JIRA issues/proposals will be evaluated in the context of use cases detailed or
subtasked in TOSCA-8
* TOSCA-8: http://tools.oasis-open.org/issues/browse/TOSCA-8 (Use Case Bucket)
** Issues Related to Pretty Normal PHP Application in the formation of a Service Template - Tobias
Kunze
* TOSCA-17: http://tools.oasis-open.org/issues/browse/TOSCA-17 (Packaging Format for TOSCA)
** Follow-up on last week's discussion.
** Suggested strawpoll: consensus on eliminating Java specifics from packaging format and using
TOSCA-extended ZIP format?
General discussion: What are the primary remaining meta-language (spec only) gaps?
Continued: Spec issues/Proposals/Bugs queue (time permitting)
* TOSCA-12: http://tools.oasis-open.org/issues/browse/TOSCA-12 (Set of Basic Node Types for Defining
Topology Templates)
* TOSCA-11: http://tools.oasis-open.org/issues/browse/TOSCA-11 (Set of Fundamental Lifecycle
Operations)
* TOSCA-13 http://tools.oasis-open.org/issues/browse/TOSCA-13 (definitions of portability and
interoperability) [Subtask of TOSCA-16]
* TOSCA-16 http://tools.oasis-open.org/issues/browse/TOSCA-16 (Primer Deliverables - Uber Issue)
* TOSCA-18: http://tools.oasis-open.org/issues/browse/TOSCA-18 (Resource Requirements and
Capabilities)
* TOSCA-14: http://tools.oasis-open.org/issues/browse/TOSCA-14 (Policy Languages) [subtask of
TOSCA-3]
* TOSCA-3: http://tools.oasis-open.org/issues/browse/TOSCA-3 (Grouping element for policies - Uber
Issue)
Tabled Issues/Proposals/Bugs
* TOSCA-9: http://tools.oasis-open.org/issues/browse/TOSCA-9 (Relationship of Plans to
Infrastructure)
General discussion (time permitting)
* REMINDER: While a general approach can be decided by motion, specific technical proposals need to
be JIRA issues
* Next meeting
* AOB
Other Motions and Results (broken out from below):
None
Motion to Adjourn:
MOTION to adjourn by Simon Moser.Second byPaul Lipton. Motion PASSES by unanimous
consent. Meeting adjourned at 1:30 PMEDT

3. Raw Chat Log:
Paul Lipton (Co-Chair) C: Hi, all. Welcome to today's meeting of the TOSCA TC
(starting promptly at 5 minutes after the hour)!
Attendance Recording: Participants are responsible to log their attendance on
the Kavi calendar event at http://www.oasis-
open.org/apps/org/workgroup/tosca/event.php?event_id=32585. This page also
has phone bridge, proposed agenda, links to resources and more. Please look
now, if you have not already done so.
When you join the meeting, use this page to record your attendance by
clicking "Record My Attendance". If you are not on the internet, you can
request the co-chair to record your attendance on your behalf.
PHONE BRIDGE AND WEB CONFERENCING: THIS MEETING ONLY. PLEASE SEE THE EMAIL
AT:
https://www.oasis-
open.org/apps/org/workgroup/tosca/email/archives/201206/msg00005.html
Scribe Queue (we need volunteers!):
Michael Schuster (21 June)
Simon Moser will be running today's meeting.
anonymous1 morphed into Dale Moberg, Axwat
Dale Moberg, Axwat morphed into Dale Moberg, Axway
anonymous morphed into Simon Moser (co-chair)
Simon Moser (co-chair): Hello everybody
Simon Moser (co-chair): Please note that the teleconference information has
changed - today we need to use a different call-in number
anonymous morphed into Bryan Haynie (VCE)
Simon Moser (co-chair):https://www.oasis-
open.org/apps/org/workgroup/tosca/email/archives/201206/msg00005.html
anonymous morphed into Paul Zhang (Huawei)
Paul Lipton (Co-Chair) C: I seem to be on mute. How do you get off mute on
this bridge (and hi)?
Aaron(Huawei): Can anyone tell me what the access code is for the meeting?
Paul Lipton (Co-Chair) C: Also, the web conference did not work with Google
Chrome for me, FYI*.
Thomas Spatzier (IBM): @Paul: try *6
Simon Moser (co-chair): 12533845
Simon Moser (co-chair): is the access code
Paul Lipton (Co-Chair) C: Tried *6 and it didn't work. Will dial in again.
Aaron(Huawei): Thanks
anonymous morphed into Doug Neuse (CA)
Richard Probst (SAP) morphed into scribe - Richard Probst (SAP)
scribe - Richard Probst (SAP): meeting is quorate
Simon Moser (co-chair): P R O P O S E D A G E N D A
Welcome / Roll for those who cannot record their own attendance
Co-chair appoints a scribe
Review/approve draft proposed agenda
Review/approve draft minutes
* May 31: https://www.oasis-
open.org/apps/org/workgroup/tosca/download.php/46146/TOSCA%20TC%20Minutes%202
012-05-31.docx
* Thanks to Dale Moberg for scribing

4. Editors status report
* Problems, questions, etc.
Spec issues/Proposals/Bugs queue (time permitting)
NOTE: When practical, JIRA issues/proposals will be evaluated in the context
of use cases detailed or subtasked in TOSCA-8
* TOSCA-8: http://tools.oasis-open.org/issues/browse/TOSCA-8 (Use Case
Bucket)
** Issues Related to Pretty Normal PHP Application in the formation of a
Service Template - Tobias Kunze
* TOSCA-17: http://tools.oasis-open.org/issues/browse/TOSCA-17 (Packaging
Format for TOSCA)
** Follow-up on last week's discussion.
** Suggested strawpoll: consensus on eliminating Java specifics from
packaging format and using TOSCA-extended ZIP format?
General discussion: What are the primary remaining meta-language (spec only)
gaps?
Continued: Spec issues/Proposals/Bugs queue (time permitting)
* TOSCA-12: http://tools.oasis-open.org/issues/browse/TOSCA-12 (Set of Basic
Node Types for Defining Topology Templates)
* TOSCA-11: http://tools.oasis-open.org/issues/browse/TOSCA-11 (Set of
Fundamental Lifecycle Operations)
* TOSCA-13 http://tools.oasis-open.org/issues/browse/TOSCA-13 (definitions of
portability and interoperability) [Subtask of TOSCA-16]
* TOSCA-16 http://tools.oasis-open.org/issues/browse/TOSCA-16 (Primer
Deliverables - Uber Issue)
* TOSCA-18: http://tools.oasis-open.org/issues/browse/TOSCA-18 (Resource
Requirements and Capabilities)
* TOSCA-14: http://tools.oasis-open.org/issues/browse/TOSCA-14 (Policy
Languages) [subtask of TOSCA-3]
* TOSCA-3: http://tools.oasis-open.org/issues/browse/TOSCA-3 (Grouping
element for policies - Uber Issue)
Tabled Issues/Proposals/Bugs
* TOSCA-9: http://tools.oasis-open.org/issues/browse/TOSCA-9 (Relationship of
Plans to Infrastructure)
General discussion (time permitting)
* REMINDER: While a general approach can be decided by motion, specific
technical proposals need to be JIRA issues
* Next meeting
* AOB
Paul Lipton (Co-Chair) C: Sorry about the phone bridge and web access, but I
wasn't sure I'd have connectivity.
Paul Lipton (Co-Chair) C: Simon kindly provided both.
Paul Lipton (Co-Chair) C: Paul seconds motion to approve agenda
scribe - Richard Probst (SAP): Simon moves agenda, Paul seconds
scribe - Richard Probst (SAP): agenda accepted without objection
Paul Lipton (Co-Chair) C:@Richard, just wanted to see if I could type faster
than you, Richard.
scribe - Richard Probst (SAP): Simon moves to accept minutes, Paul seconds
scribe - Richard Probst (SAP): minutes accepted without objection

5. scribe - Richard Probst (SAP): editor update from Thomas: work in progress
but nothing to discuss this week
scribe - Richard Probst (SAP): continue discussion on TOSCA-8
Paul Lipton (Co-Chair) C:Wanna put this in the web conference?
scribe - Richard Probst (SAP): Tobias has been mapping his use-case to TOSCA,
has come up with about 9 node types
Alex Heneveld (Cloudsoft): I'm on Chrome and it's okay for me ... but that's
no guarantee
Bryan Haynie (VCE): chrome works for me
scribe - Richard Probst (SAP): Tobias created node templates for the elements
of his PHP use-case, using YAML (hopefully easier to parse)
scribe - Richard Probst (SAP): PHP use-case expects a PaaS -- the service
template references services provided by the platform
scribe - Richard Probst (SAP): Tobias has not yet added relationships to
service template
scribe - Richard Probst (SAP): showed internal document how RedHat thinks of
relationships -- they have operations
scribe - Richard Probst (SAP): Tobias has identified 9 issues
Paul Lipton (Co-Chair) C: # ISSUES
8 #
9 # 1 Node Type components need to be addressable, either via interfaces or
10 # in a more structured way. Component role must be understood (e.g.
11 # what is PHP, what is ZF)
12 # Suggest to introduce "Component" as a technical term, denoting the,
13 # well, components of a NodeType. Also, suggest that these
14 # components are addressed using period (".") as a separator
15 # 2 Some NodeTypes are "abstract", e.g. "myapp". Static files (kind of)
16 # become part of *staticserver and Code (kind of) becomes part of
17 # *zendserver.php
18 # 3 "Require"/"Provide" is a much more flexible mechanism than just
19 # referencing NodeTypes with "DerivedFrom".
20 # 4 The inheritance aspects of the "DerivedFrom" element need to be
21 # complemented with a separate, immutable form that occurs when a
22 # NodeType is provided by the platform. E.g.
23 # 5 When a NodeType is provided, the ability to express requirements
24 # (e.g. applying to resource allocation or specific run modes) becomes
25 # important
26 # 6 The NodeType ID field is superfluous
27 # 7 NodeTypes should have a "Version" field
28 # 8 NodeTypeProperties need "name", "value", and optionally maybe "type"
29 # 9 Naming and capitalization is odd, e.g. "NodeTypeProperties" vs
30 # "requestURI" vs "name"
31
Frank Leymann (IBM): Comment: I don't understand why something that is
superfluous (item #6) results in an issue.
Paul Lipton (CA) A morphed into Paul Lipton (Co-chair) A
Aaron(Huawei):execue me, but could anyone tell me the link for web
conference? I can't find the new link for today's meeting
Matt Rutkowski (IBM)1: Simon can you please record my attendance
scribe - Richard Probst (SAP): Thomas comments on issue #1 -- isn't this the
same as Deployment Artifact?
scribe - Richard Probst (SAP): at least the concept is already the same
anonymous morphed into Rich Miller
scribe - Richard Probst (SAP): Tobias agrees this seems similar, but should
PHP component be seen as a DA? PHP component is made available thru Apache as
library

6. Aaron(Huawei): ? I see Paul's (Co-chair) message in WebEX, but can't find the
link
Paul Lipton (Co-Chair) C: @Frank, let's go through each issue that Tobias has
identified. Please reserve for item #6.
scribe - Richard Probst (SAP): Tobias: more general issue is that elements
need to know about components of other elements
KoertStruijk (CA): Lotus Live:
1. Go to the URL - http://www.webdialogs.com
2. Click 'Join a Meeting' button in the top right corner of the page
3. Enter the Conference ID 1204304
4. Enter your name and email address
5. Click the 'Log In' button
Paul Lipton (Co-Chair) C: @Aaron, see email at: https://www.oasis-
open.org/apps/org/workgroup/tosca/email/archives/201206/msg00005.html
scribe - Richard Probst (SAP): Thomas thinks a node contained in a node can
satisfy the need to name components, without introducing a new top-level
concept
Aaron(Huawei): @Koert: Many thanks. Got it.
scribe - Richard Probst (SAP): Tobias will try to use nested nodes to
represent components
scribe - Richard Probst (SAP): and also will try using DAs, and also doing it
with a new "component" concept, to see which works best
Thomas Spatzier (IBM): So "nested" Nodes would be: NodeTemplate A (of
NodeType a) -> contains relationship ->NodeTemplate B (of NodeType b)
scribe - Richard Probst (SAP):<scribe hat off> +1 to Requires/Provides !
Alex Heneveld (Cloudsoft): +1 require/provide definitely
scribe - Richard Probst (SAP): Paul asks to test consensus around Tobias's
issues
scribe - Richard Probst (SAP): Tobias: issue 4 means a service provided by a
platform should not be modeled as DerivedFrom since it cannot be modified
Derek Palma (Vnomic): To me point 3 means: Node Type derivation should not
allow extension beyond the restricted domains of the super Node Type
Frank Leymann (IBM): Can we solve #4 by introducing a "final" attribute for
properties...?
Derek Palma (Vnomic): that is one common way
scribe - Richard Probst (SAP):<scribe hat off> how would over-provisioning be
modeled?
Derek Palma (Vnomic): but it really has to enforce that the domain is not
expanded. I.e. it's a subset.
Simon Moser (co-chair): (co-chair hat off) +1 to Franks suggestion to
introduce things like "final" on node type attributes
scribe - Richard Probst (SAP): Tobias agrees a "final" attribute could be a
solution to issue 4
scribe - Richard Probst (SAP): Simon heard consensus on 2 and 3, agreement
that something like 4 is needed, issue 1 needs to be reviewed
scribe - Richard Probst (SAP): issue 5 is more a demonstration of need than
an issue
scribe - Richard Probst (SAP): Simon (with co-chair hat off) says issue 6
(NodeType ID is superfluous) may apply to YAML but not to other
implementations
Thomas Spatzier (IBM): In TOSCA in the current spec, we state that the fully-
qualified name (QName) of a NodeType is built from targetNamespace and id.
Therefore it is required.
scribe - Richard Probst (SAP): Tobias: 3 choices: (1) name is required, ID is
optional; (2) ID is required, name is optional; (3) YAML uses name, XML uses
ID

7. Thomas Spatzier (IBM): The name attribute is optional and meant to be a
human-readable name.
Derek Palma (Vnomic): id guarantees uniqueness. name is not necessarily
unique. We need some notion of identity to be carried across all
serializations.
Frank Leymann (IBM): +1 to derek
scribe - Richard Probst (SAP): Marv says names may not be unique
scribe - Richard Probst (SAP): Tobias agrees names might not be unique, which
would be a problem
Matt Rutkowski (IBM): You would have to qualify an ID as a GUID and decide if
you want it URI based or not
Paul Lipton (Co-Chair) C: @Marv, did you say id may not be unique, either?
Matt Rutkowski (IBM): or a UUID for instances
Paul Lipton (Co-Chair) C: gotcha
Marv Waschke (CA): @Matt Exactly!
Matt Rutkowski (IBM): then you would have to decide if the UUIDs are time
dependent or not and reference approved mechanisms/algorithms
Marv Waschke (CA): Global uniqueness is always an issue. I prefer a name
space approach, myself.
scribe - Richard Probst (SAP): Tobias proposes to replace ID with human-
readable name, to remove 1 "geek field"
Matt Rutkowski (IBM): Then TOSCA would have to decide who the "authority"
would be (DNS may not work)
KoertStruijk (CA): You might want to be able to have a group of items - if
you reuse the same name, the id allows you to still individually address the
items. I can't think of a use case for this at the moment, though.
scribe - Richard Probst (SAP): Tobias has similar reaction to some of the
details of the packaging proposal -- remove the geek fields!
Paul Lipton (Co-Chair) C: Do Service Template names really need to be
globally unique (just wonderin')?
Paul Lipton (Co-Chair) C: I mean names within a Service Template. I guess so,
if you were to import, for example.
scribe - Richard Probst (SAP): Derek says that translation between XML and
YAML need to be handled carefully to preserve what is guaranteed to be unique
Marv Waschke (CA): If templates are to be shared, it seems awkward to have to
change the id as it moves from installation to installation.
scribe - Richard Probst (SAP): Especially if you translate back and forth XML
to YAML to XML to YAML
Paul Lipton (Co-Chair) C: So, is consensus that we need to make this work on
YAML and on XML side? Does this need to be a JIRA issue?
Paul Lipton (Co-Chair) C: Oops! Somebody just asked the same thing.
Alex Heneveld (Cloudsoft): ID=1 is not likely be globally unique
Alex Heneveld (Cloudsoft): what about ID="user-agent", with convention it
should be locally unique, inheriting a namespace which gives it global
uniqueness
scribe - Richard Probst (SAP): Simon proposes we should open JIRA issues on
most / all of Tobias's issues
scribe - Richard Probst (SAP): Paul would prefer not to open so many tiny
JIRA issues -- maybe just aggregate as 1
scribe - Richard Probst (SAP): Thomas says issue 8 is already in the spec
scribe - Richard Probst (SAP): Thomas says capitalization (issue 9) was on
purpose -- maybe only a problem when translating to YAML?
scribe - Richard Probst (SAP): Tobias argues for being language-agnostic and
readable -- remove the Java-isms
Marv Waschke (CA): @alex- that would satisfy my concerns.
Frank Leymann (IBM): I don't understand at all what the Java-isms are.

8. scribe - Richard Probst (SAP): Simon agrees with goal of maximizing adoption,
so let's look at the proposals
Frank Leymann (IBM): The style of naming currently used in TOSCA (e.g.) can
be found in many other standards too.
scribe - Richard Probst (SAP): Paul has created TOSCA-20 and asks Tobias to
fill with references to today's document and today's minutes
Derek Palma (Vnomic): Can we get a list of what these Java-isms are because
at the XML level they are not obvious to me.
Frank Leymann (IBM): +1 to Derek
scribe - Richard Probst (SAP): Paul asks re consensus on issues 6 thru 9
scribe - Richard Probst (SAP): Tobias likes idea of making ID a string, but
then why not call it "name"
Thomas Spatzier (IBM): ID can be a string today.
Thomas Spatzier (IBM): It's of type xs:ID
Derek Palma (Vnomic): We have to have a notion of identity for uniqueness. We
don't need to dictate this for specific serializations.
Alex Heneveld (Cloudsoft): would it be useful to be able to refer to
NodeTypes defined in other projects?
Alex Heneveld (Cloudsoft): +1 ... ID and NAME serve the same function don't
they?
scribe - Richard Probst (SAP): Paul asks if we should remove ID? Tobias says
eliminate either name or ID
Sundaresh(CA) : Agree with Tobias. Remove ID
scribe - Richard Probst (SAP): Marv agrees with Tobias
Derek Palma (Vnomic): Currently we have ID and display name. We have to have
ID.
Thomas Spatzier (IBM): name is optional
Doug Davis (IBM): why not keep a user-friendly "name" ?
Frank Leymann (IBM): IDs are for uniqueness, Names are for humans
Doug Davis (IBM): exactly
Frank Leymann (IBM): names are optional, if you don't like them, omit then
Matt Rutkowski (IBM): I disagree
Doug Davis (IBM): names do not need to be unique at all
Matt Rutkowski (IBM): Names and IDs are necessary
Frank Leymann (IBM): Many XML based standards work exactly the same as we
have it in TOSCA today
Matt Rutkowski (IBM): Please see comments I made above
scribe - Richard Probst (SAP): Derek says we need ID in XML, and we can map
it when translating to YAML
Doug Davis (IBM): ID should be globally unique, Name should be optional and
not requirement for it to be unique. Make it clear that Name is for humans.
Matt Rutkowski (IBM): +1 Doug
Matt Rutkowski (IBM): GUID at the very least
scribe - Richard Probst (SAP): Tobias asks if ID is required by XML
validator?
Alex Heneveld (Cloudsoft): can ID be something like "user-agent" ?
Frank Leymann (IBM): +1 to Doug, that's in the spec today
Alex Heneveld (Cloudsoft): best of both worlds
Thomas Spatzier (IBM): @Alex: Yes, it can.
Doug Davis (IBM): to me "Name" goes along with a "description" type of field
- for humans - provider shouldn't do anything with them except echo them back
to clients.
Alex Heneveld (Cloudsoft): thanks @Thomas. great. nice if these _files_ can
be written by a user ... if we use class-name style for ID's that's possible
harder if i'm expected to write 243A4E0
scribe - Richard Probst (SAP): Derek says don't worry about this, just
provide a (good) translator

9. scribe - Richard Probst (SAP): from XML to YAML and vice versa
Doug Davis (IBM): that's a yaml issue, not a tosca model issue, no?
scribe - Richard Probst (SAP): Tobias doesn't see why we have to use XML IDs
Doug Davis (IBM): maybe some serializations won't expose all fields - would
be a shame but that's their choice as long as those fields are optional.
Thomas Spatzier (IBM): If the XSD type is xs:ID, the XML processor ensures
that the id is unique in the document.
Thomas Spatzier (IBM): For global uniqueness we have the namespace in
addition.
scribe - Richard Probst (SAP): Simon: let's split the issues into those we
have consensus on and those we still need to debate
scribe - Richard Probst (SAP): Paul asks Tobias to create TOSCA-21 for just
his issue 6
Matt Rutkowski (IBM): Namespace does NOT guarantee uniqueness unless
"authority" guarantees it
Tobias Kunze (Red Hat): @Thomas: but XML doesn't force you to do it that way
scribe - Richard Probst (SAP): Simon moves to adjourn, Paul seconds
Matt Rutkowski (IBM): the discussion of GUID is too XML centric
Doug Davis (IBM): btw - you don't need a motion to end the meeting if your at
the designated endtime
Thomas Spatzier (IBM): But nice to leverage features of the XML processor.
scribe - Richard Probst (SAP): adjourned without objection
Matt Rutkowski (IBM): it should be more about a unique reference mechanism
Alex Heneveld (Cloudsoft): bye all