På sidan:
| Table of Contents |
|---|
Översikt relationer
| draw.io Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Figur 1, piloten
R1, federationsoperatör mot anslutningsoperatör. Digg mot Inera respektive Internetstiftelsen. Heldragen, alltså en etablerad federationsrelation som regleras direkt. Detta är operatörsavtalet.
R2, anslutningsoperatör mot federationsmedlem. En av operatörerna mot EHM. Heldragen. Detta är anslutningsavtalet, och det är den enda vägen in i federationen för en federationsmedlem.
Figur 2, framtida läge
R1 upprepas när ytterligare anslutningsoperatörer tillkommer. Streckad, alltså framtida.
R2 upprepas per federationsmedlem, oberoende av vilken operatör som anslutit dem. Heldragen mot EHM, streckad mot tillkommande medlemmar.
R3, anslutningsoperatör mot anslutningsoperatör. Röd streckad, alltså indirekt. Operatörerna har ingen egen relation utan är förbundna genom att båda har R1 mot samma federationsoperatör. Det är den relationen som bär tilliten mellan medlemmar anslutna via olika operatörer.
R4, federationsmedlem mot federationsmedlem. Blå, alltså övrig avtalsrelation och inte en federationsrelation. Här ligger det verksamhetsmässiga utbytet mellan parterna, utanför det federationen reglerar.
Möjlig lösning
| draw.io Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Att skriva samma materiella regler i varje avtal skapar tre problem. Reglerna glider isär över tid, en ändring kräver omförhandling med varje part, och det blir oklart vad som egentligen gäller lika för alla.
Lösningen är att samla det som gäller lika för alla på ett ställe. Federationsoperatören publicerar Federationsregelverk BAS, och varje avtal hänvisar till det. Genom hänvisningen blir regelverket avtalsinnehåll i just den relationen. Parterna binds alltså inte till varandra av regelverket i sig utan var och en till sin motpart, med samma innehåll.