EmneSubject: Desirability
Hi Siraj,
Many Many thanks for opportunity to provide some input via email following the 2023-04-30 meeting. I was one day late expressing my interest in participating and as a result the first meeting I was invited for was that one. I have now gone through the videos as well as your "2024.04.15 Critical Infrastructure WG 2" deck.
1. Things to retain
Peppol probably is many things to many people. It is a complex network with many aspects, so it will be hard for me to succinctly describe how I look at it. But I will try. The one "truth that I hold as self-evident" is that in order for Peppol to grow, senders must be able to dynamically find receivers without first having to contact them. It is the one thing that sets the Peppol network apart from legacy point-to-point EDI connections. It is this that enables a "Peppol-first" strategy where the sender first checks Peppol and if the receiver is not on Peppol does their other thing (usually email). It is also this principle that allows C4s to change their C3 without first having to inform their C1. Nothing changes for C1, because C1 and C4 are both part of a network.
...
My point about the proposals that I have seen in the previous meeting is from this perspective: these don't look like desirable solutions. Let's not throw the baby out with the bathwater!
What is Critical?
I am 100% behind Philip's questions about the goal of federation - what is the problem we are solving? It looks to me like we dove right into technical solutions, but without clear goal posts. The DBNAlliance have not introduced any technical changes in their 4-corner model, but they have introduced the roles of "registrar" and "agent" in their network. And so it may turn out that changes in governance are all that is required. But we don't know because we don't yet know where we want to get to. Is federation critical and if so, what is it?
In In the initial DBNA meetings there was much confusion about the term "SML" and again in the 2024-04-30 meeting. OpenPeppol uses the term SML to mean the system that authenticates SMP certificates and uses that to authorizes access in order to make changes to the DNS. I often get maintenance notifications from the OO saying "the SML will be down, but don't worry DNS will still work". OASIS however uses the term SML to describe the entire lookup subsystem and, as far as I know, does not have names for the separate parts. I will use "Registration Service" and "Lookup Service". And I define "Lookup Service" to be both DNS and SMP together.
The critical part here is the lookup service. If that is down, the network is down. The registration service is less important. If we want to make the lookup service more resilient, we need to focus on that. A quick brainstorm:
...
use three DNS providers, each on its own domain. Then have a quorum of 2 decide.
don't use DNS but use something like blockchain. Everyone can have their own local copy and it's always available
...
... probably many others...
...
Next
I feel that the question about which problem we are solving has not been addressed sufficiently to be able to jump into solution mode. For instance, I understood from Philipe that a solution is required to support different APs for different documents. Where in the project does it state that as a problem to address? Same for federation, it is not clear to me which problem we are solving.
...