1. Normative Types & connectsTo The RelationshipType base type of “connectsTo” in the current draft on Normative Types in Tosca seems to be incomplete. In the following, options for resolving this incompleteness are surveyed in the light of emerging ideas about simplification, json exchange formats, procedures for obtaining information from the environment, and clarifying the scope of “network feature” specification in TOSCA.

2. RootRelationshipType : ConnectsTo ValidSource typeRefdescription EndpointRequirementRootRequirementType ValidTarget namedescription EndpointCapabilityRootCapabilityType Interfaces nameparmsdescription TBD Properties nametypePrescripti on default description TBD Definition Relationship that indicates a node can “connect” to another node of a specified type. For example: A WebApplication node “connectsTo” a Database node. Known Subclasses IPEndpointRequreiment, HTTPEndpointRequirement, IPEndpointCapability, HTTPEndpointCapability Can we not flatten??? Using properties such as “protocol” (or protocol list?) InstanceStates statedescription N/A-

3. Tiers & Dependencies SugarCrmApp [SugarCRMApplication] SugarCrmDb [SugarCRMDatabase] ApacheWebServer [ApacheWebServer] MySql [MySQL] connects to hosted on depends on VmApache [Server] VmMySql [Server] hosted on OsApache [OperatingSystem] OsMySql [OperatingSystem] hosted on WebTier [Tier] DbTier [Tier] PhpModule [ApachePHPModule]

4. Networked Service Endpoints Service Endpoint Network Layers  URL:  DNS/NIS/hostsfile name to address resolution  IP Routing, Reachability, Public, Private, NAT  DHCP: MAC to IP (Probably not in scope) ConnectsTo network info. between OS levels? But, why not just instead modeled as TOSCA Property? Static vs Dynamic values issues. GetsFromEnv or SetsToEnv e.g. hostname to IP mapping in some name resolution table?

5. Delete it  and capture network information as a value in a Property element, e.g. service URL.  And/or: add a node for a network tier, with layers for hostedOn dependencies, and depicting installation constraints (such as “app and service on same subnet” by using “dependsOn” relations from app or service to network tier)  Some other modeling using existing containers. What are some pros/cons for Deletion? Delete or Fix “connectsTo” as a Normative type

6. Pros for Deletion Pros:  Overall simplification. Main use cases relate to service endpoint configuration. Handle with Properties and environmental procedures (getEndpointInfo(node n)).  YAML models already “collapse” flavors of dependencies, and use environmental procedures to get/set.  Avoid spending time on “fixing/completing” normative type sections

7. Cons for Deletion Cons  Still need to tell modelers what network information belongs where in a TOSCA model...  And what should be omitted (I.e, left to the implementation to default or handle sensibly)?  TOSCA model (imo) should be able to specify placing a tier on a separate subnet. For example, if multiple services are used by central application, some may be in on-premise DB services (“hybrid” clouds). Should have some TOSCA approach for models of this style of cloud deployment/topology...

8. If Direction is to “Fix” Decide on scope of networking feature specification relating to life-cycle operations!  For example, service endpoint network installation, configuration, start/stop. Add way for service invoker to obtain endpoint information in form needed for install/config/start (environment procedures).  Or, add way to specify a constraint on OS routing table so as to make service reachable from invoker.  Or, add way to request that a service be in protected/private domain.  Can default networking features be defined when multiple tiers are present – at least as guidance for modelers?