...
# | Questions/Open Issues | Notes | Decisions | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | What kind of naming validation should be in place? | According to this ONAP Documentation it should be alphanumeric with underscores(_) VNF and PNF Modeling Requirements - Resource IDs | We have currently decided to follow this approach, and add any extra characters as seen fit.
| ||||||||||||
2 | Should CM-Handle ID's be more strict, or carry the same amount of strictness as anchor names. Due to the fact that we create a corresponding anchor for every CM-Handle it cannot be less strict. | As part of this commit, we can modify the code so anchor creation will happen for the cm handle registration. So if it fails the validation at this point, the CM-Handle will not be registered. | |||||||||||||
3 | Should validation also be applied to Get/Query API's as opposed to just creation of the functions above? | Not recommended as this will add little value, at a high cost | Have decided not to implement this currently. | ||||||||||||
4 | Should dashes be included? | A lot of dummy data and tests within CPS use dashes as part of their Network Function ID's. If we decide to not use dashes, we should also change these. | |||||||||||||
5 | Implementation approach for validation | We have discussed 3 possible libraries for implementing this validation. These include java's util library, spring validator at the service level of CPS, along with using open api's 'keyword' for dealing with CM-Handle ID validation, or using apache commons validation regex library. |
...