QoS B: update of request parameter for serviceArea#87
Conversation
jlurien
left a comment
jlurien
left a comment
There was a problem hiding this comment.
I have doubts about the convenience to add this new ID having already AREANAME
| Type of this area. | ||
| CIRCLE - The area is defined as a circle. | ||
| POLYGON - The area is defined as a polygon. | ||
| AREAID - The area is defined as an area ID. |
There was a problem hiding this comment.
Currently AREANAME already supports any kind of string values and it it is not limited to human friendly names. What is the benefit of having a separated AREAID for areas identified by UUIDs?
I would wait to have a more clear understanding of the Area discovery mechanisms and the possibility to have a transversal common Area APIs, and if that is the case we may refer explicitly to the equivalence of these fields in the other API.
There was a problem hiding this comment.
Sure. In my understanding, the benefit of a AREAID is to guarantee uniqueness from technical perspective.
I think it is better to keep discussion on it also with those who proposed the common Area API.
There was a problem hiding this comment.
I would move this one to draft until we have a clear understanding of the new Area API, wdyt?
There was a problem hiding this comment.
This PR is not for Sync26. So it is ok for me to move it to draft.
2 participants
What type of PR is this?
What this PR does / why we need it:
To update CreateBooking so that API invoker can specify an area by either
idornamebased on the invoker's preference. This is a proposal to align with dedicated-network-areas API which is expected to be a common area API.Which issue(s) this PR fixes:
Fixes #86
Special notes for reviewers:
This PR will merge only after consolidating and defining our common Area API.
Changelog input
Additional documentation
None