Rheinland Backbone Documents and Policies

Zum Glück ist es ja alles noch ein Entwurf:

Nur verstehe ich nicht wieso wir (Freifunk Rheinland e. V.) uns Regeln ans Bein binden sollen wofür es keine Notwendigkeit gibt.

Da ja nur öffentliche Adresseräume im Rheinland Backbone vorhanden sind gibt es schon mal keine technische Notwendigkeit. Also welche rechtliche Notwendigkeit gibt es?

ack. Dem stimme ich 100% zu. guter Ton +1 :smile:

ack.

Das BB-Team trifft ausschlißlich operative Entscheidungen die für den Betrieb des Backbones relevant ist. Es ist nicht unsere Aufgabe irgendwelche anderen Dinge zu beurteilen oder zu entscheiden.

Die Endgeräte einer Community sind für das Backbone nicht relevant. Ich schlage vor, dass diese Themen getrennt betrachtet werden.

Ein IPv6 Netz ist für die Community ein zugewiesenes Netz allerdings kann die Community das ja nach freiem Willen entscheiden wie es segmentiert wird.

Keine. Es macht aus meiner Sicht keinen Sinn das zu verbieten. In der Konsensversion mit dem Vorstand gibt es dazu keine Regelung.

Der Status ist zwar noch Grundlage für Policies in Entwicklung. Inhaltlich ist der Inhalt meines ersten Postings ohne jede Ergänzung bis zum Release der konkreten Policies mit dem Vorstand abgestimmt und bindend. Für die bestehenden Verbindungen musst ja eine Regelung her.

Alle Backbone-Teilnehmer haben Verpflichtungen gegenüber dem Datenschutz und gegenüber anderen Parteien. Diese müssen geregelt sein. Die Frage ob es eine Policy geben wird diskutieren wir hier nicht mehr.

Für alle strittigen Fragen habe ich nun oben eine Liste der zu klärenden Punkte erstellt. Diese werden wir bei der nächsten Iteration über die Policy in der Runde mit dem Vorstand diskutieren müssen.
Ich bitte alle die sich an diesem Thema bisher beteiligt haben die Themen die nichts mit der Policy zu tun hat von diesem Thema zu trennen.

Hallo thomasDOTwtf,

ich möchte Dich bitten einmal darzustellen, was eine Policy Deiner Meinung nach rechtlich sein soll. Vielleicht ein beiderseitiger Vertrag, ein Auftrag, eine Verhaltensregel, ein Verhaltenskodex , oder … .
Wenn Du Dir nicht sicher bist, was es genau ist, dann erklär mir bitte welche Rechte die Parteien der Vereinbarung jeweils aus der Policy ableiten sollen. Ich versuche das dann in deutsches Recht einzuordnen. Die amtliche Übersetzung der EU für Policy ist Regel, und das ist ohne einen speziefischen Zusatz, z.B. Verhaltensregeln, ein unbestimmter Rechtsbegriff.

Bitte erklär mir auch noch einmal, wer genau Partei dieser Vereinbarung sein soll. Im Ausgangstext werden einige Gruppen (Community, Admins) genannt, die keine eigene Rechtsform haben oder keine Geschäftsvollmacht haben und deshalb keine Vereinbarungen schließen können.

Vielen Dank für deine Mühe
Uwe Hohenstein

1 „Gefällt mir“

Dals trifft es. Es ist eine Verhaltensregel für Parteien die an eine Policy gebunden sind. Rechtskraft ist nicht gegeben. Worstcase bei Verstößen ist abschaltung. Dazu gibt’s eine offene Frage bzgl. der Vorgehensweise bei Verstößen s.o.

Grüße
Thomas

Ich glaube, hier gab es eine Verwechselung technischer Begriffe. Eine Kollisionsdomäne ist eine Verbindung, in der Kollisionen auftreten können. Es handelt sich hier also um ein OSI Layer 1, wie z.B. Luft oder Twisted-Pair-Kabel. Auf dieser Ebene baut ein Layer-2-Protokoll auf, das Datenpakete (PDU) definiert und den gemeinsamen Zugriff auf Layer 1 regelt, so dass Kollisionen möglichst nicht mehr stattfinden. Die aktuelle Version des Ethernet-Protokolls leistet dies.

Meta-Communities, die eine solche Broadcast-Domäne betreiben, nennen wir deswegen Domäne. Bei der Begriffsfindung ist zugegebenermaßen nicht berücksichtigt worden, dass auch auf Layer 1 von einer Domäne gesprochen wird.

Zur genaueren Definition: Eine Domäne ist ein Layer-2-Netz (Broadcast-Domäne) des Freifunk-Netzwerks. Üblicherweise ist dies ein Mesh-Netzwerk, das über Ad-Hoc-WLAN-Verbindungen und VPN-Tunneln aufgebaut wird. Eine Domäne wird von einer einzigen Freifunk-Community oder von mehreren gemeinsam (Meta-Community) betrieben.

Ziel des Projekts Rheinland Backbone ist es, diese Domänen mit IP-Routing ans Internet anzuschließen. Dies gilt für Netzwerke außerhalb der Autonomen Systeme der Freifunk Community. Für Verbindungen innerhalb soll das Projekt IC-VPN dienen. Die über dieses System ans Internet angeschlossenen Communities können auch als eine Meta-Community bezeichnet werden, da sie das erweiterte Admin-Team des Backbone delegieren.

Diese Art von Domäne ist der derzeitige Stand unserer Entwicklung. Es gibt Überlegungen, wie dynamisch Domänen erzeugt werden. Sollte dazu ein Projekt aktiv werden, bildet sich eine Meta-Community, die mehrere Domänen an das Backbone anschließt und gemeinsame Router in einem Transfer-Netzwerk betreibt. Dieses Projekt nenne ich bisher „Freifunk Cloud“.

Ich glaube, gewollt ist Autonomie für Communities. Anstatt bei Wachstum das Netzwerk zu unterteilen und per weiterer Routing-Ebene anzuschließen, wünschen wir uns eine direkte Anbindung an den Rheinland Backbone (und das IC-VPN). Es besteht m.E. kein Vorteil darin, Hierarchien in den Domänen einzuführen.

1 „Gefällt mir“

@thomasDOTwtf, @nomaster

Die Diskussion hier scheint ja abgeschlossen oder eingeschlafen zu sein …

Ich würde vorschlagen wir machen den Thread hier mal zu und machen uns mal an die Übersetzung der Policy ins „Amtsdeutsch“ ?

Second that :wink: Nachdem dies geschehen ist, würde ich auch gerne ein, zwei Punkte anbringen, wo ich aktuell noch überschießenden Aktionismus sehe, der mit der Notwendigkeit der rechtlichen Klarheit imho weniger zu tun hat.

Würde auch gerne erst darüber diskutieren sobald die Version mit Amtsdeutsch vorhanden ist.

@wusel go for it! schreib Deine Punkte bitte direkt dazu.

Ist die Policy schon so final? Würde sie gerne in einem Beipackzettel für Router mit rausgeben…

Die Punkte wurden ja im Mailwechsel besprochen. Dennoch würde ich gerne ein „ping“ absetzen auf #629125, denn trotz Updates per Web scheint das Ticket versandet zu sein :frowning:

Und, FTR, trotz Hinweis am 10.02. rennt https://ticket.freifunk-rheinland.net nach wie vor auf MET-0040 … So richtig gepflegt scheint das Ticketsystem weder technisch noch inhaltlich zu werden?

Hi,

hier kam unter den Freifunkern die Idee auf, Freifunk zu einer weiteren Kommunikationsnetz für Hilfsorganisationen im Katastrophenfall zu machen, denn Freifunk wäre in einem solchen Fall bei ausreichender Meshdichte ja relativ unzerstörbar, solange eben noch Strom da ist. Die Leute aus dem Roten Kreuz, mit denen wir das mal etwas überlegt haben, fanden die Idee auf jeden Fall gut.

Nun haben wir uns weiter überlegt, dass man dafür allerdings in einem solchen Katastrophenfall die Endgeräte der Katastrophenschutzangehörigen priorisieren müsste, denn wie man das ja von Handynetzen kennt, sind diese in solchen Fällen immer hoffnungslos überlastet. Hier entsteht also ein Problem. Wir müssten QoS machen, was ja im Pico Peering Agreement komplett ausgeschlossen wird.

Könnte man eventuell für klar definierte Fälle, wie eben einem ausgesprochenen Katastrophenstatus, welcher ja relativ genau gesetzlich definiert ist, die QoS-Regelung lockern? Oder ist die Missbrauchsgefahr einfach zu groß?

Wir hatten uns das grob so vorgestellt, dass dieser Status im Netz über ein Broadcast-Paket ausgelöst werden kann und die Router dann eine Liste von priorisierten Mac-Adressen laden und anwenden. Man könnte auch die Mac-Listen dann wie die Autoupdater Manifests durch mehrere Schlüssel signieren lassen, um Missbrauch vorzubeugen. Die genaue Implementierung haben wir noch nicht besprochen, weil wir erstmal eine Meinung zu dem Thema generell einholen wollten.

Gruß
fusselkater

So schön man sich so ein Szenario vorstellen mag, ich bezweifle zum einen die Verfügbarkeit eines MESH in einem wirklichen Katastrophenfall. Zum anderen haben die einzelnen Hilfeleistungsorganisationen selber die nötige Technik um auch weitreichende Nachrichten und Datenverbindungen herzustellen.

Fernmeldedienst Rotes Kreuz:

Mein Landkreis hat sich so was hier geleistet mit SAT Uplink:
http://www.gimaex.com/?Mod1=artikel&MenuID=2087&MainMenuID=5&Sprache=D

Das THW ist auch gut gerüstet:
http://www.thw-dortmund.de/einheiten-und-technik/fachgruppe-fuehrungkommunikation/

Zudem gibts noch die Notfunker unter den lizenzierten Amateurfunkern, welche auch ganz offiziell in mögliche Katastrophen Szenarien eingebunden werden könnten.
http://www.darc.de/distrikte/n/notfunk-distrikt-n

Was ich eigentlich sagen will ist, erst muss die Flächendeckung von Freifunk vorhanden sein und dann kann man vielleicht mal drüber nachdenken ob es Sinn macht. Und wer weiß ob nicht irgendeiner der aktiv bei den Hilfsorganisationen in den Fernmeldegruppen tätig und zufällig auch überzeugter Freifunker ist, in irgendein Staufach wo noch Platz ist ne Pico oder Nanostation unterbringt mit passend langen Kabeln zum Anschluss an was auch immer. Aber die Geräte werden niemals Teil einer offiziellen Ausstattung bzw. eines Ablaufes sein und wenn dann nur wirklich als allerletztes Mittel vielleicht zum Einsatz kommen.

2 „Gefällt mir“

Das hilft überhaupt nicht bei einer Überlegung, ob man das Pico Peering Agreement dahingehend ändert oder nicht. Dieser Thread ist für die Diskussion für die Ausarbeitung des Pico Peering Agreement gedacht. Wenn das erstmal steht und von den angebundenen Communites unterschrieben ist, lässt es sich nur schwer ändern. Daher ist es sinnvoll, sich mit solchen Ideen auch schon vor einer Flächenabdeckung zu befassen, zumal es einige Communites gibt, die bereits zumindest in der Innenstadt eine sehr gute Abdeckung haben.

Natürlich werden die Geräte niemals Teil einer offiziellen Ausstattung. Da gibt es aber zumindest hier auch noch einiges mehr, was nicht zur offiziellen Ausstattung gehört, aber trotzdem vorgehalten wird. Wie gesagt, hier war durchaus Interesse dafür, das zu ermöglichen.

Verstehe jetzt noch nicht wieso deswegen das Picopeer Agreement geändert werden sollte?

Es lässt sich schon jetzt schwer ändern diese „Einschränkungen“ sprich privilegierten Traffic mittels QOS dort hinein zu bekommen. Ich möchte das definitiv nicht und würde mir z.B. keine Firmware flashen die $Dinge tut wenn Irgendwer Irgendwo ein bestimmtes Paket im Netz broadcastet.

Ich spinne das jetzt mal weiter. In $Stadt ist ne Demo gegen $Irgendwas am laufen. Die Teilnehmer kommunizieren mittels Freifunk untereinander. Und zwar Frei und ohne Mitlauscher. Und jetzt kommt $Behörde, broadcastet das „Katastrophen“ Paket und schon kommt das Netz zum erliegen für die Demonstranten.

Das Freifunk Netz ist so wie es ist Best Effort und damit kann jeder leben, auch Hilfsorganisationen.

Wenn man davon ausgeht, dass Behörden die Möglichkeit haben, eine Mac-Liste zu signieren, also Zugriff auf die privaten Schlüssel der Berechtigten haben, dann können sie auch direkt die Firmwaresignaturschlüssel verwenden und die Knoten über ein kaputtes Firmwareupgrade abschalten.
Ich habe nicht so recht das Gefühl, dass du meinen Text überhaupt gelesen hast. Aber wie auch immer. Deine Meinung dazu ist klar.

Ich würde mich jetzt einfach aus dem Fenster lehnen und sagen: Wenn es tatsächlich einen Katastrophenfall gibt, und ihr mit QoS oder Verletzung der Netzneutralität recht konkret Menschenleben retten könnt, dann scheißt einfach solange auf das PPA…

1 „Gefällt mir“

im übrigen kann ich mir kein Szenario ausdenken, bei dem FF zuverlässiger, umfassender und schneller wäre, als die vorhandenen Einrichtungen in öffentlicher oder NGO-Hand. Im Gegenteil: geringe Reichweite, Abhängigkeit von einzelnen Steckdosen (die u,U. alle mal eben tot sind) , uvm.
Also eine utopische Idee ohne realen technischen Untergrund.

1 „Gefällt mir“