actually the gate id is not available before the gateSet since it's the CMTS how returns it, what are the constraints behind the use of the ID?

create cmts --> provider —> consumer ( cmts )

id <—provider

right. are the calls blocking or async until the sequence is finished?
in fact, i think the provider could support both generate id AND provide id in the URI. ==> as far as i know it's a URI for a Rest access => one way flow unless there is a way to return back the values ?
for generated json can be returned? the osgi calls are async?

what does the provider support now according to the code? => create/delete/update (untested )

cmts and flows that are best effort?

default match = ipv4-destination ? default action = best effort => YES
in our case it feels awkward to make the application generate cmts id’s and flow ids. what seems right is ...
create flow -> cmts

id <—cmts

in fact could be the gate id. in the cmts case the provider could do a db like auto index

create cmts --> provider —> cmts

id <—provider

does this work for us or does the augmentation require us to work differently? in fact, i think the provider could support both generate id AND provide id in the URI.