Architectural discussion on the Inter-Pool Connection

[cpalbr]

Jerome B. created the following comment in the word document:

Is the architectural discussion on how to search/sync/fetch/... CCBs between pools settled to a consensus?
If not, the first step is to define the architecture: P2P, client/server, ...; sync by request, full sync, ...; the CCBs directory (not needed if P2P); ...

Jean-Marc R. added the following text to that topic:

OPNC must be compatible with the existence of several pools operators. Two topologies will coexist:
• An actor could be connected to several pools in the same time.
• Pools could be connected with other pools in order to be accessible by actors via a single connection. This is what is named “Pools interoperability”
Because the actors have the choice of the topologies they will implement (individual, business and strategic rationale), OPNC must be compliant with both topologies.

@ALL How do we want to set up the inter pool connection?

[steffenrhinow]

. this was investigated and tested by the joint activities with elaad and vedecom/gireve last year. for gdpr reasons we should stick to the defined approach - on request.
we showed that both concepts are possible - connect to multiple pools and use the connected service approach (broadcast). it's already in the APIs here in opnc included as a parameter. happy to explain it in the next group sessions

[cpalbr]

Hi @steffenrhinow,

that sounds great. I also recommend to follow the tested approach at Elaad. Who can summarize that approach in a text which we can use in the protocol? What needs to be done in the API to realize it?

[Fritzlor]

Hey @steffenrhinow, You mentioned we already have APIs documented for the broadcast feature. Did I read the comment above correctly? Could you point me to them? I have not had much luck tracking them down.

Thanks,
Fritz

[steffenrhinow]

Hi, Yes this is described in Processes. The broadcast flag which is used to do that is defined as well in the relevant calls like "specification/apis/pcp/pcp.api.v1.provisioningCertificateByPcid.json"
Hope that helps

[steffenrhinow]

happy to create that, as the broadcast parameter is already existing.

[steffenrhinow]

here also the slide from Paul from elaad. At the end we decided to go for "by Request"

[thesimmermon]

Is there any documentation on how interoperability will work? Is there a place where the interoperability use cases are defined and how to solve them using this protocol?

[steffenrhinow]

#64

I added a description and a reference for that

[thesimmermon]

This mechanism seems to suggest that each ecosystem knows about the other.

Is there a central repository of where the ecosystem addresses are known? How does a new implementor know to which other ecosystems to broadcast?

Have we discussed how authentication between ecosystems would work? I don't recall the conversation, but I missed a few meetings.

Are there metrics for how long the pass-through pool should await for responses before giving up?

Doesn't this favour large, established ecosystems in that they will not have to block often (thus taking up resources) as they will have many records in their pools and have no need to proxy the call? Also, would this present a barrier to entry over time for new pool operators? Since, starting small, they may simply be proxying calls to other pool operators? Or, is the vision that this is handled somehow with onboarding or some kind of chargeback?

[steffenrhinow]

Yes, that was the outcome of the Project between a lot of stakeholders. Any central repository as hub was not seen as likely. Additionally as mentioned the STF (European Commission) defined rules and will continue there
Authentication needs to be the same as for all actors. Hubject is using Oauth2 with a PEN tested rights and roles system.
The only time critical metric are coming out of the ISO15118 - CertInstallationReq/Res. The rest is not timecritical and needs to be adjusted between the connected systems as it depends on their needs and their customer SLAs.
This concept enables also small systems directly from the beginning.

[thesimmermon]

How are we handling interoperability in this specification? As three companies are currently working on an interop-like solution, should we add some of this work product to the specification? It would be useful to have this documented somewhere along with potential paths forward, next steps, etc. Possibly, we won't want to put this into the specification, but we should at least indicate in here that the broadcast flag is part of a defined process and have a pointer to that process. I would hate for a new party to come along and think that just implementing the broadcast flag was all that is needed to solve interoperability.