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
Attachment: ETSI Liaison Response-shitao.docx Description: ETSI Liaison Response-shitao.docx