All the listed attributes (for simplicity).
Brian Hedstrom: The link provided above for Key-Value Pair Registries.docx, for the HPA Key Value Pairs, is linking to an OLD version of the file. The vduComputeRequirements Registry Example provided in the link above DOES NOT MATCH the vduComputeRequirements Registry Example provided in NFVIFA(18)000162r1. It's not clear to me if we are voting on the attributes only in this attribute table, or also voting on supporting the key value pairs per NFVIFA(18)000162r1. I would suggest the key value pairs be a separate poll/discussion. My vote here is for the attribute table only.
Xu Yang: to Brian, the vote is only for the attribute table, not the key value pairs.
maopeng zhang:
I agree HPA requirements.
- All changes for HPA in R2 should not effect R1 VoLTE case. It needs the data model compatible, which the VoLTE case already used.
If this can be pre-condition in R2, I agree with add HPA attributes. But how to add, we needs more details.
- please make it clear that add cloumn for OPT2, what attributes to be removed and how to removed(remove from KVP or remove from attributes existed in the clean page)
Depend on the clear and furthur more details, I can decide whether to support the remove option.
@Michela Bevilacqua: updated version of the key value pairs registry to be supported in R2 and identification of deprecated (legacy) attributes to be finalised.
Thinh Nguyenphu (Unlicensed): With Option 1 or Option 2, there is a way in TOSCA grammar to indicate the status of each TOSCA properties (supported, unsupported, experimental, deprecated). Thus, we can indicate to implementer how some of these duplicate attributes status. Of course Option 2 is possible, it would requires these supporting companies to bring concrete CRs to remove these duplicate attributes, as soon as possible. It is not good practice to remove an attribute(s) once a specification is already published without early notification.