OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tosca message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [tosca] Groups - Proposed changes to tosca-nfv-v1 0-csd04 uploaded


Bruce,

I understand the purpose of uploading the document is for continuing the discussion from the last 2 days - for the TOSCA TC benefit.

I agree "as a process" with what you have done here documenting the types that have similarities in TOSCA to some of the new types in NFV profile.

However, for the benefit of TOSCA TC I want to make it clear that, if you are asking this specific text to be agreed to be included in the draft, I cannot support it. Simply because this text basically rubber-stamps the current direction of the NFV profile, with those "similar" types being derived from root, and leaving any re-alignment work to some potential FFS later spec.
This is not in line with our discussion and agreement in the last 2 days calls - where we agreed that the goal for THIS iteration of the NFV profile is to derive all new NFV profile types for which a similar type can be identified in the TOSCA Simple YAML spec, to be derived from the latter types instead of from root.

For the broader TOSCA TC, I want to make it clear that even by doing this, we are in fact creating a split in the TOSCA community, between the Simple YAML followers, and the (ETSI) NFV profile followers - and perhaps in a short-term this may be the best we can achieve. However, I cannot support deepening this split by allowing multiple new NFV profile types to be derived from root, when a similar normative type exist in TOSCA. By doing this we are doing not doing a favor to NFV in general, and not even to ETSI NFV - we are in fact creating a separate TOSCA-like dialect. Those using this dialect will continue to derive types, as needed, from the new branches created under root, and deepen that split.
Instead of bringing ALL NFV flavors together, and in the bigger picture, instead of bringing IT/Enterprise and Telco/NFV together, we will contribute to deepening the divide between those domains, and splitting the NFV domain itself.
Instead of elevating Simple YAML to a data modeling framework for cloud applications for every use case, we are acquiescing that this is not possible, and not likely to happen because we are not raising to the challenge. Imagine a world where IT/Enterprise and Telco/NFV would have adopted different dialects of the IP protocol. That kind of says it all.

Best regards,
Michael



On Wed, Jul 12, 2017 at 1:23 PM, Bruce Thompson <brucet@cisco.com> wrote:
Document Name: Proposed changes to tosca-nfv-v1 0-csd04

Description
This document includes updates to reflect the node types defined in
tosca-nfv-v1 0-csd04 for which there are similar normative node types in
the TOSCA Simple Profile for Yaml. Additional text has been added to allow
model developers to choose to develop using TOSCA normative node types in
cases where the new nodes defined in tosca-nfv-v1 0-csd04 are similar to
existing TOSCA normative nodes.
Download Latest Revision
Public Download Link

Submitter: Mr. Bruce Thompson
Group: OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TC
Folder: Working Documents
Date submitted: 2017-07-12 10:23:04




--
Michael Brenner, Chief Architect NFV

M: +1-732-895-5772http://getcloudify.org@cloudifysource
      

 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]