Es wird kein Subnetting angewendet, die Bereiche werden lediglich organisatorisch getrennt und bilden ein großes Layer 2 Mesh
Genau deshalb hat Linus den Zusatz formuliert…
…da erst dieser eine Anbindung einer organisatorischen Domäne (Meta-Community) mit mehreren Kollisionsdomänen (Layer2 Meshs) in der Policy überhaupt erst ermöglichen würde und entsprechend erst mit diesem Zusatz die Anbindung einer Misch-Domäne wie bspw. Wupper es nun ist per Definition überhaupt möglich wäre…
Hier geht es um die Backbone Policy, wo vermutlich auch Mischumgebungen Berücksichtigung finden sollten. Dies war jedoch im ursprünglichen Entwurf nicht enthalten und wurde von Linus deshalb nachgereicht.
Übersetzt steht da dem Sinn nach:
Jedes zusätzliche Netzwerk, dem die Community Zugang ermöglichen will, muss dem Backbone Admin Team gemeldet werden. […] Dies schliesst auch das Splitten von Meta-Communities in eigene Kollisionsdomänen ein.
Also da wird nichts untersagt, sondern explizit, wenn auch mit Meldepflicht, erlaubt…
Du musst die Policy ja nicht akzeptieren, wenn Du auf die Backbone Anbindung verzichten kannst.
Ich verstehe das in etwa so:
Es gibt eine Leistung, die umfasst unter Anderem das Abführen von Traffic ins Internet. Auch IP-Adressen, AS Nummern und sonstige Nebenleistungen.
Zur Nutzung ist lediglich die Policy zu lesen, zu verstehen und zu akzeptieren.
Keine Community ist gezwungen diese Leistung in Anspruch zu nehmen, sei es weil kein Bedarf besteht, die NUB’s oder in diesem Fall Policy nicht tragbar ist oder aus sonstigen Gründen.
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?
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.
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.
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.
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.
Second that 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.
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
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?
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.
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.
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.
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.
