1. TOSCA Namespaces for tosca-nfv-profile
Shitao li

2. Namespace discussion in TOSCA
TOSCA Namespacing Explained - Draft.pptx

3. Main issues need to consider in tosca-nfv-profile
tosca_definitions_version ?
conclusion from TOSCA NFV adhoc ( ): In the tosca-nfv-profile spec, it is suggested to set this value to tosca_simple_yaml_1_2
Namespace Alias ?
conclusion from TOSCA NFV adhoc ( ): : 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
Namespace URI ?
conclusion from TOSCA NFV adhoc ( ): : It is suggested to use the existing one ( already defined in tosca-nfv-profile.
Namespace Prefix ?
concluson from TOSCA NFV adhoc ( ): : It is suggested to use “nfv: ” as the namespace prefix in tosca-nfv-profile

4. 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)

5. 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, ?

6. 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?

7. 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

8. Other issues? Remain issues:
Issue 1: when will tosca-simple-profile-yaml v1.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. SOL001, 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

9. Backup

10. 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