...
- 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.
Expand | ||
---|---|---|
| ||
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://wiki.onap.org/display/DW/BBS+Modeling To enable use of "Metadata" and "Metadatum" in relationship-list, add EdgeRules for:
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:
For generic-vnf "RG MAC Address" field proposal to do one of:
For generic-vnf "Service Type" field proposal to do one of:
For generic-vnf "Upstream speed" and "Downstream speed" field proposal to do one of:
For generic-vnf "Access ID" field proposal to do one of:
For pnf "MAC Address" field proposal to do one of:
For pnf "Manufacturer" field proposal to do one of:
For pnf "SerialNumber" field proposal to do one of:
For pnf "Model" field proposal to do one of:
For pnf "Type" field proposal to do one of:
For pnf "SW version" field proposal to do one of:
For cp "OLT Name" field proposal to do one of:
For cp "OLT PON Slot" field proposal to do one of:
For cp "OLT PON Port" field proposal to do one of:
For cp "CVLAN" field proposal to do one of:
For cp "Expected ONT ID" field proposal to do one of:
|
Attachments
Attachments | ||
---|---|---|
|
...