TOSCA Namespaces for tosca nfvprofile Shitao li Namespace

TOSCA Namespaces for tosca -nfv-profile Shitao li

Namespace discussion in TOSCA • 2017 -11 -02 - TOSCA Namespacing Explained - Draft. pptx

Main issues need to consider in tosca-nfv-profile 1. tosca_definitions_version ? • conclusion from TOSCA NFV adhoc (2017. 11. 08): In the tosca-nfv-profile spec, it is suggested to set this value to tosca_simple_yaml_1_2 2. Namespace Alias ? • conclusion from TOSCA NFV adhoc (2017. 11. 08): : It is suggested to choose option 1 (not to set namespace Alias in tosca-nfv-profile)unless there is a clear usage of the namespace alias 3. Namespace URI ? • conclusion from TOSCA NFV adhoc (2017. 11. 08): : It is suggested to use the existing one (http: //docs. oasis-open. org/tosca/ns/simple/yaml/1. 0/nfv/1. 0/) already defined in tosca-nfv-profile. 4. Namespace Prefix ? • concluson from TOSCA NFV adhoc (2017. 11. 08): : It is suggested to use “nfv: ” as the namespace prefix in tosca-nfv-profile

1, tosca_definitions_version • Can we suggest in tosca-nfv-profile that the “tosca_definitions_version ” keyname needs to always follow the same processing procedure in tosca-simple-profile-yaml? • The only valid values now for “tosca_definitions_version” in tosca-nfv-profile are “tosca_simple_yaml_1_2”, “tosca_simple_yaml_1_1” and “tosca_simple_yaml_1_0 (namealias representing a TOSCA YAML Simple Profile specification)

2, Namespace Alias • This is related to the first issue for “tosca_definitions_version” keyname • Namespace alisa : In the TOSCA Simple Profile, TOSCA Service Templates MUST always have, as the first line of YAML, the keyword “tosca_definitions_version” with an associated TOSCA Namespace Alias value. • If the first suggestion is yes, • Option 1: does not define namespace alias in tosca-nfv-profile, • Delete the namespace alias in tosca-nfv-profile • Option 2: define a new namespace alias, but clearly indicate that this namespace alias shall not be used as a valid value of “tosca_definitions_version”, it is only used for qualified type names or URI, for example, tosca_simple_nfv_1_0: nfv. nodes. Vdu • There is a defined namespace Alias in tosca-nfv-profile, that is “tosca_simple_profile_for_nfv_1_0”, if we keep it as it is, some explanation of its usage should be added. • If the first suggestion is no, • ?

3, Namespace URI • There is a defined namespace URI in tosca-nfv-profile. • Do we want to keep it, or change it to another one?

Namespace Prefix • Namespace Prefix has not defined in tosca-nfv-profile right now. • As suggested from Matt’s slide, Vender specific type defines and namespace prefix should be allowed, but from standard perspective, a standard prefix for the basic types of NFV applications should be given. It is suggested to define a namespace prefix in tosca-nfv-profile for interoperability purpose. For example: nfv: tosca. nodes. nfv. cpd or nfv: nfv. nodes. cpd

Other issues? Remain issues: • Issue 1: when will tosca-simple-profile-yaml v 1. 2 be availabe as a offical reference? Does a guidance for distinguishing implementation and specifiaction is needed so old version of simple-profile can also be used by the implementation? • Issue 1: How to use multiple documents(profiles) in a particular order? Is there a way that the designer can design its application by using any types as defined in multiple profiles (e. g. SOL 001, ONAP, tosca-nfv-profile) • This relates to the “Imports ” usage in TOSCA, more clarification is needed from simple yaml group • Issue 2: Does the type name convention in tosca-nfv-profile need to be different compared to tosca-simple-profile-yaml, for example, change the type conention from tosca. nodes. nfv. Cpd nfv. nodes. Cpd

Backup

Profiles & Conformance What is intended • • • Approved, TOSCA Namespace URI - define a TOSCA-approved Namespace URI for the Profile’s Types that matches spec. version • i. e. , for default/target namespace Extensibility via Profile Types - define new Types needed to model the subject area for the Profile • These Types would be bound to the TOSCA approved Namespace URI for the Profile Simplified Import – allow profile types to be imported “on-top” of TOSCA Simple Profile base types • Ideally, “import” of a Profile’s Types should be accomplished with one (1) line of YAML • Namespace Prefix: possible a reserved Namespace Prefix for the Profile • Note: TOSCA base profile version compatibility is an issue to discuss What is not intended • • No new Grammar - Profiles are not allowed to define new grammar • Should not define new “keywords” for TOSCA entities • Profile WGs should submit uses cases to the Simple Profile WG that express needs in the base profile Limited ability to describe additional Requirements (prose) on individual Types • e. g. , describe special treatment of property/attribute values • Perhaps “constraints” grammar is not expressive enough? or one Property value depends on another? • Note: the Profile WG should try to submit uses cases to Simple Profile WG when they find limitations that could be fixed via the core grammar