NOTE: This poll closes on February 28th, 2018


There're two naming conventions for the current information model: 1) ETSI IFA011 names; 2) new proposal to align the class names within ONAP IM.

Examples: (IFA011 name / proposal for change)

VNFD/VNFDesc, VDU/VDUDesc, VirtualCpuData/VirtualCPUDesc, VirtualMemoryData/VIrtualMemoryDesc, Cpd/CPDesc, ...

Poll Question

Which one of the following options you would like to follow to resolve the naming convention divergence?

Option 1: be consistent with ETSI IFA011 naming convention; give feedback to ETSI about the new proposals and make change to ONAP according to the result

Option 2: make changes in ONAP IM and keep a mapping (e.g., in the description of the class/attribute) of ETSI names with ONAP ones

Option 3: Option 2 + feedback to ETSI about the changes

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

Option 1Option 2Option 3Poll 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 MayerWe 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.


Alexander Vul

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



 spolstonBest 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 HedstromSee 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.
Weitao 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



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.

 Andrei Kojukhov



 Prefer aligning with ETSI
Zhuoyao Huang

Prefer aligning with ETSI for ease understanding and implementation.






  • No labels

8 Comments

  1. Jessie S Jewitt

    Before I vote, I'd like to better understand the answers to the following two questions:

    1. Why do we believe it is better to have the word "Desc" appended to classes such as VDU, or spell it out as is the case with VNFD?
    2. Why are we creating classes such as VirtualCPUDesc and VirtualMemoryDesc when they are datatypes in the ETSI model?

    1. Arun Gupta

      Jessie,

      My answers are:

      1. I've seen endless confusion about in the model about what is a specification versus what is an instance.  Uniformly having the suffix Desc (or any other common suffix) would help.
      2. Yes, I think there is some confusion about datatypes and classes; perhaps the translation from ETSI "Information element" to UML was messed up.

      -Arun

      PS: cracking open ETSI NFV IFA-015, blue and yellow colors are used in the diagrams to distinguish between logical and deployment views, in my opinion, the names should also reflect that, not just colors in diagrams.



  2. Brian Hedstrom

    ONAP will be following the IISOMI guidelines for naming styles (e.g., Upper Camel Case for Class names, Data Types and Lower Camel Case for Attributes).  Is ETSI following the IISOMI guidelines for naming styles?

    1. Xu Yang

      ETSI is using upper camel for "information element" (similar concept to class or data type) and lower camel for attributes and parameters.

  3. Alexander Vul

    A technical question - how are we doing the vote? one per company? by other means?


  4. Thinh Nguyenphu

    Even though, the poll deadline has passed. I would like to share my opinion.  My preference is Option #1. 

    My understanding is that ETSI NFV IFA011 and IFA014 information model is based on their agreed naming convention document.  I am requesting ETSI NFV to share their IM naming convention. Perhaps, ONAP can apply same naming convention approach, if possible.

  5. Chesla Wechsler

    Looks as if I missed the deadline as well.  There is a lot of confusion between when you're talking about the design time artifact and when you're talking about the runtime artifact.  Having been on the instance end of things, if we are not modeling REALLY CLEARLY as to when we're talking about the descriptor and when we're talking about the result, I think there is a great deal of weight that should be given to the opinion of folks living the nightmare of the implementation aspects.  I think coming up with best of breed and feeding back what we've learned should be WELCOMED at the standards level.  I vote for option 3.

  6. Thinh Nguyenphu

    I would like to share with the team on the result from ETSI NFV IFA WG discussion on the IE and attributes renaming.  At the time the development of IFA011 and IFA014 IM models, IFA WG adopted a set of guidelines of their naming convention for the information model.  Last week, ETSI NFV ISG released the IFA naming conventions and abbreviations documents. The document is publicly available at https://docbox.etsi.org/ISG/nfv/Open/Other/NFVIFA(16)000922r6_Conventions_for_the_use_of_abbreviations.zip. My understanding is that these documents should clarify the changes request by ONAP with respect to renaming IEs or attributes.  Please note that these documents are applicable to the IFA documents (Stage 2 type of specification).