Naming Convention Poll

Xu Yang

Prefer to align with IFA names to ease the implementation

Kevin Scaggs

• IFA is not consistent

• The turn-around time in IFA to make updates is slow

• We should not limit ourselves to just ETSI standard  

• We should lead in setting standards, not just follow

• You may recall we earlier discussed that we would not follow and adhere to just one industry standard, but make use of whatever standard from whatever standard body that solved the issue at hand.   Option 1 is in opposition to that approach.

Arun Gupta

• What Kevin wrote.

• Feedback to ETSI about changes should be after we have a working implementation that uses the data model.

  Added by ?

• Seems like the most expedient way forward..

• It would be good to adopt a set of conventions from one of the SDOs that have them, and apply it consistently across ONAP.
  
  Arun Gupta, in response to the above - there is no issue in using ETSI as the basis, but we need to make the naming consistent where ETSI is not, may need to add missing elements; remove ETSI elements that are not applicable; collapse some classes that are always 1:1; turn some ETSI classes that have no natural identifier into datatypes, etc.etc.  

Andy Mayer

We have an opportunity in ONAP to correct the inconsistencies in the IFA011 model and provide feedback to ETSI. We will ensure that we track any name changes and provide proper mapping back to the original IFA011 names.

Alex Vul

Given our intent for a "best of breed" approach in the standards space, having our own conventions would be helpful....

 Steve Polston

Best of breed approach where we advocate for our standards in ETSI and other bodies, but minimize constraints from their inconsistencies, and administrative processes.

Pamela Dragosh

Brian Hedstrom

See my question below...

Lingli Deng 

 Prefer to keep aligned with spec published names as the origin to avoid confusion for tracking and comparison.

Tao Shen

 Prefer to keep aligned with spec published names as the origin to avoid confusion for tracking and comparison.

wenyao guan

 Prefer to keep aligned with spec published names as the origin to avoid confusion for tracking and comparison.

victor gao

Aligned with published spec names more friendly for developer.

Yan Yang

Keep consistent with IFA can help understand and avoid confusion

Yuan Liu

Prefer to simplify the concepts to align with ETSI.

maopeng zhang

Perfer to use the ETSI naming convention to make concepts in the same page easily and avoid to create "new wheels" in the industry. For long term, we should have a mechanism to let ONAP and ETSI cooperate with each other.

Zhaoxing Meng

Prefer aligning with ETSI to simplify and ease understanding of the IM

using ETSI as the basis

add missing elements, give feedback to ETSI

Chengli Wang

Prefer to align with IFA names to ease the implementation

Priya TG [NEC/Netcracker]

Prefer aligning with ETSI to simplify and ease understanding of the IM

jianguo zeng

 I agreed that ONAP should not limit to just ETSI standard, But as the following concept is in scope of ETSI NFV: "VNFD/VNFDesc, VDU/VDUDesc, VirtualCpuData/VirtualCPUDesc, VirtualMemoryData/VIrtualMemoryDesc, Cpd/CPDesc" 

So, it seems most convenient to make the naming consistent with ETSI NFV in principle. But if found any thing need correct, it's possible to discuss and take action such as using own name or provide feedback to ETSI.

Chuanyu Chen

Prefer to keep consistent with IFA for ease understanding and implemetation.

 andreik

 Prefer aligning with ETSI

Zhuoyao Huang

Prefer aligning with ETSI for ease understanding and implementation.