re: Imports with name conflicts via ETSI NFV LS

Hi Chris,

Thanks for preparing the reply document. In general, the content looks fine. I change the document structure a little bit to make it clear, in addition, I would suggest moving the proposal and example in the annex as further information for ETSI NFV to consider.

Another thing is that there are 2 issues as mentioned in ETSI NFV LS, it is necessary to include the answer of the second issue in this LS reply as well.

Best regards,

Shitao

åää: Chris Lauwers [mailto:lauwers@ubicity.com]
åéæé: 2021å9æ11æ 6:24
æää: Lishitao <lishitao@huawei.com>
æé: Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>; Nguyenphu, Thinh (Nokia - US/Dallas) <thinh.nguyenphu@nokia.com>; Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>; tosca@lists.oasis-open.org
äé: RE: Imports with name conflicts via ETSI NFV LS

Hi Shitao, apologies for not completing an official response. I started summarizing our discussions to date about the âconflicting importsâ in the attached document. Please send comments and feedback.

Thanks,

Chris

From: Lishitao <lishitao@huawei.com>
Sent: Monday, September 6, 2021 1:27 AM
To: Chris Lauwers <lauwers@ubicity.com>
Cc: Arturo Martin De Nicolas <arturo.martin-de-nicolas@ericsson.com>; Nguyenphu, Thinh (Nokia - US/Dallas) <thinh.nguyenphu@nokia.com>; Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>
Subject: re: Imports with name conflicts via ETSI NFV LS

Hi Chris and all,

The NFV#35 meeting will be started on next Monday (9-13), it would be helpful to provide the issues reply at this meeting. Since the formal LS reply document is not ready, at this moment, I only include what we have discussed in the TOSCA report for NFV#35, can you please check if the content is suitable for sharing with ETSI NFV? Other comments is also welcome.

Best regards

Shitao

åää: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org] äè Arturo Martin De Nicolas
åéæé: 2021å9æ6æ 15:21
æää: Nguyenphu, Thinh (Nokia - US/Dallas) <thinh.nguyenphu@nokia.com>; tosca@lists.oasis-open.org
æé: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>
äé: [tosca] RE: Imports with name conflicts via ETSI NFV LS

Hi Thinh,

Thanks for pointing this text out. That was actually my belief and what I stated in the adhoc language meeting, i.e. that two imported type definitions with the same type name should be an error unless the definitions were identical.

Best regards,

Arturo

From: tosca@lists.oasis-open.org <tosca@lists.oasis-open.org> On Behalf Of Nguyenphu, Thinh (Nokia - US/Dallas)
Sent: Friday, September 3, 2021 3:43 PM
To: tosca@lists.oasis-open.org
Cc: Marton, Gabor (Nokia - HU/Budapest) <gabor.marton@nokia.com>
Subject: [tosca] Imports with name conflicts via ETSI NFV LS

Hi Chris and others,

Per our Thursday TC call, I would like to follow-up our discussion. I would like to clarify the 1^st bullet point of âsummary of the discussionâ from Ad-hoc language call meeting note. The bullet should be âThe general rule is that parsers should flag an error on name conflicts, when the definition is different with the same nameâ. The rational for this correction is based on the additional requirement from section 3.1.3.1 (see yellow highlighted).

- Chris: summary of the discussion:

- The general rule is that parsers should flag an error on name conflicts (i.e., definitions with the same name)

- Namespaces should be used to solve the name conflict problem.

- To address the problem of identifying import that are intended to be the same, profiles should be used.

- Unfortunately, profiles are not supported in 1.3

3.1.3.1 Additional Requirements

The URI value âhttp://docs.oasis-open.org/toscaâ, as well as all (path) extensions to it, SHALL be reserved for TOSCA approved specifications and work. That means Service Templates that do not originate from a TOSCA approved work product MUST NOT use it, in any form, when declaring a (default) Namespace.
Since TOSCA Service Templates can import (or substitute in) other Service Templates, TOSCA Orchestrators and tooling will encounter the âtosca_definitions_versionâ statement for each imported template. In these cases, the following additional requirements apply:
- Imported type definitions with the same Namespace URI, local name and version SHALL be equivalent.
- If different values of the âtosca_definitions_versionâ are encountered, their corresponding type definitions MUST be uniquely identifiable using their corresponding Namespace URI using a different Namespace prefix.

Regards,

Thinh

Thinh Nguyenphu

Bell Labs CTO

Nokia

thinh.nguyenphu@nokia.com

+1 817-313-5189

tosca message