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.
Würde auch gerne erst darüber diskutieren sobald die Version mit Amtsdeutsch vorhanden ist.
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 
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“
also ich nutze schon freifunk also extra netz … zum 3G/4G … ich muss aber sagen das wir ein VPN druber aufbauen …
Es rennt ein Ping auf dem Interface auf den Gateway im Fahrzeugt und der sucht den besten weg. Und wenn der Weg ist nimmt der halt den anderen 
@MPW
Ich hätte einen Vorschlag zu machen, wäre es nicht Sinnvoll als ersten Punkt den Gültigkeitsbereich zu definieren?
Zum Beispiel: diese Dokument hat Gültigkeit für den Bereich so und so…
Auch wäre es gut zu wissen wer diese Dokument erstellt hat und wie es beschlossen wurde
Zum Beispiel:Wurde erarbeitet von der Gruppe… und mit 2/3 Mehrheit bei der Mitgliederversammlung verabschiedet.
Ich hätte einen Vorschlag zu machen, wäre es nicht Sinnvoll als ersten Punkt den Gültigkeitsbereich zu definieren?
Zum Beispiel: diese Dokument hat Gültigkeit für den Bereich so und so…
Auch wäre es gut zu wissen wer diese Dokument erstellt hat und wie es beschlossen wurde
Zum Beispiel:Wurde erarbeitet von der Gruppe… und mit 2/3 Mehrheit bei der Mitgliederversammlung verabschiedet.
Das steht doch in den ersten 2 Absätzen.
@CHRlS
Habe ich da „this document applies to“ überlesen?
Ich finde es nicht, oder muss ich mir das selber zusammen reimen für wen es Gültigkeit hat?
Da haste recht, das steht nur schwammig im Kontext der ersten 5 Absätze drin.
Das könnte man imho hinzufügen, unter dedizierter Benennung wofür es gilt und für wen es gilt, damit klar und eindeutig aus dem Umkehrschluss hervorgeht für wen es nicht gilt. Und in diesem Zusammenhang beide Zielgruppen einzeln aufführen, Vereinsinterne und -externe.
Aus meiner Sicht haben wir eigentlich nur 2 Hauptzielgruppen:
-
Es gilt für:
Rheinland Backbone auf Seite des FFRL - und alle
angeschlossenen nicht dem Verein zugehörigen Freifunk Communities,
denen Transit gewährt wird, unter automatischer Anerkennung der
Policy -
Sowie:
Rheinland Backbone und aller Domänen des FFRL
Für den 2. Fall, innerhalb des Vereins, haben die Domänen entsprechend die Regelungen intern zu ihren Subdomänen und Communities zu verantworten.
Die Dokumentation der Punkte soll ja nur eine Grundlage für die Ausformulierung der konkreten Dokumente bilden.
Die Gültigkeit ist klar zu definieren dann aber in den jeweiligen Dokumenten für:
- Backbone-Admins
- Verbundene Communities
- Betreiber von Supernodes
- Betreiber von Knoten
ect.
Grüße
Thomas
1 „Gefällt mir“
Hier übrigens die von der Community übersetzte Variante: