5. maj 2024 19:26 - Michael Riviera

Owned by Klaus Vilstrup
Last updated: May 13, 2024
4 min read

Subject: Desirability

 Hi Siraj,

 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.

 

Much of that “being part of a network” is built on top of the equivalence of business identifiers and routing identifiers. If the routing identifier were different from the business identifier, the sender would first need to contact the receiver to get their routing identifier. This is why the EAS list for 99% consists of business identifiers.

 

There can be exceptions where organizations are so complex that they want separate routing identifiers for certain scenarios. My experience is that these can usually be solved with a BuyerReference (which is meant for routing behind the AP) or, if nothing else works, GLN numbers - which are cheap. It is much better to force a C1 to include a BuyerReference than to force them to use a special routing identifier, because the BuyerReference is an id at the business level, but the routing identifier is an id at the message/transport level which a C1 does not operate at.

 

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!

  1. 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 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

  • make sure SMP clients interpret a non-200 response not as a "is not on Peppol" but as a "there is a lookup problem" and stop the sending flow

  • ... 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.

 

Again, I would like to thank you for the opportunity to add my 2cts via this email message.

 

If you have any questions or remarks, please let me know!

 

Best regards,

Michael Riviera

CTO

‘s-Gravelandseweg 46D

1211 BT  Amsterdam Hilversum

The Netherlands