Please put your @name in one of the option column and provide any comments you might have.

Option 1	Option 3	Poll Comments
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 (Deactivated)	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.

Browser not supported