In general, first option is written as "add <new attribute> to <class>".

• First justification for this action is that the <new attribute> is more generally applicable to other uses, not just this one case.
• Second justification is that it will be used in high percentage of cases (not left empty) and have additional properties such as being mandatory.
• Third justification is that there will be core code written that depends on this attribute, so it should be a core part of the schema
• Fourth justification is that the exact nature and number of <new attributes> is well-known, so it will not require frequent schema changes to adjust to the conditions.

In general, the second option is written as "add Metadata sub-object then configure <new attribute> Metadatum entry".

• First justification for this action is that the <new attribute> is more specifically applicable to this one case only.
• Second justification is that it will be left empty in high percentage of cases, i.e. not mandatory.
• Third justification is that there will be none of the core code depends on this attribute, but the information needs to be conveyed somehow
• Fourth justification is that the exact nature and number of <new attributes> is variable or unbounded, so this avoids frequent schema changes to adjust to the conditions.

In general, the third option is written as "configure <new attribute> Metadatum entry linked from service-instance into relationship-list".

• First justification for this action is that schema change is to be avoided as much as possible.
• Second justification is that the <new attribute> is more specifically applicable to this one case only
• Third justification is that it will be shared/linked/referred from several other objects via the relationship-list
• Fourth justification is that there will be none of the core code depends on this attribute, but the information needs to be conveyed somehow
• Fifth justification is that the exact nature and number of <new attributes> is variable or unbounded.

Victor to confirm the details below as discussed, after matching up existing AAI attributes to the proposals in the Model Design diagram for "HSIA CFS" in https://lf-onap.atlassian.net/wiki/display/DW/BBS+Modeling

To enable use of "Metadata" and "Metadatum" in relationship-list, add EdgeRules for:

• generic-vnf to metadatum
• pnf to metadatum
• cp to metadatum

Use the "service-instance" with existing "Metadata" sub-object to contain all the relevant Metadatum entries (as per options described below).

To enable use of "CvlanTagEntry" and "VlanTag" in relationship-list, add EdgeRules for:

• cp to cvlan-tag-entry
• cp to vlan-tag

For generic-vnf "RG MAC Address" field proposal to do one of:

• add "MAC Address" attribute
• add "Metadata" sub-object, then configure "RG MAC Address" Metadatum entry
• configure "RG MAC Address" Metadatum entry from service-instance into relationship-list

For generic-vnf "Service Type" field proposal to do one of:

• add "Service Type" attribute
• add "Metadata" sub-object, then configure "Service Type" Metadatum entry
• configure "Service Type" Metadatum entry from service-instance into relationship-list

For generic-vnf "Upstream speed" and "Downstream speed" field proposal to do one of:

• move to "logical-link", use speed-value to represent the connection speeds
• move to "service-instance", use existing "Metadata" sub-object with "Upstream speed" and "Downstream speed" Metadatum entries

For generic-vnf "Access ID" field proposal to do one of:

• add "Access ID" attribute (represents foreign key to data in an external management system in ESR)
• add "Metadata" sub-object, then configure "Access ID" Metadatum entry
• configure "Access ID" Metadatum entry from service-instance into relationship-list

For pnf "MAC Address" field proposal to do one of:

• add "MAC Address" attribute
• add "Metadata" sub-object, then configure "MAC Address" Metadatum entry
• configure "MAC Address" Metadatum entry from service-instance into relationship-list

For pnf "Manufacturer" field proposal to do one of:

• use existing "equipVendor" attribute

For pnf "SerialNumber" field proposal to do one of:

• use existing "serialNumber" attribute

For pnf "Model" field proposal to do one of:

• use existing "equipModel" attribute

For pnf "Type" field proposal to do one of:

• use existing "equipType" attribute

For pnf "SW version" field proposal to do one of:

• use existing "swVersion" attribute

For cp "OLT Name" field proposal to do one of:

• add "cpName" attribute
• add "Metadata" sub-object, then configure "OLT Name" Metadatum entry
• configure "OLT Name" Metadatum entry from service-instance into relationship-list

For cp "OLT PON Slot" field proposal to do one of:

• add "slotId" attribute
• add "Metadata" sub-object, then configure "OLT PON Slot" Metadatum entry
• configure "OLT PON Slot" Metadatum entry from service-instance into relationship-list

For cp "OLT PON Port" field proposal to do one of:

• use existing "portId" attribute

For cp "CVLAN" field proposal to do one of:

• configure "CvlanTagEntry" object into relationship-list (only for cvlan)
• configure "VlanTag" object into relationship-list (capable of cvlan and svlan)

For cp "Expected ONT ID" field proposal to do one of:

• add "Expected ONT ID" attribute (is this related to the proposed "attachmentPoint" attribute on pnf?)
• add "Metadata" sub-object, then configure "Expected ONT ID" Metadatum entry
• configure "Expected ONT ID" Metadatum entry from service-instance into relationship-list