[Discuss] Adress-Vergabepraxis, Aktualität der Daten, neue Konfigurationskonzepte - war: Re: [Wien] ip-adresse (KNOTENDICHTE)

[(spam-protected)]

Am 25. November 2013 21:59 schrieb Felix Ehritz <
(spam-protected)>:

> Ich möchte hier auch meinen senf dazu geben:
> <SENF>
> Auch wenn ich bei diesem Thema weit weg von der Materie bin wäre es evtl
> zu überlegen ob man nicht irgendwo etwas einbaut, das die aktuelle
> hard/firmware der eingesetzten Geräte zusammen zentral abfragt. Ähnlich des
> aktuellen olsr interface am z.b. tunnelserver nur halt
> knoten/ips/hardware/firmware+version.
>
Ja, diese Daten wären sicher auch interessant. Aber vermutlich nur bei von
uns (Joe) entwickelter Firmware machbar. Bei Geräten die mit Fremdfirmware
laufen wirds sehr schwer werden, automatisiert Hard- und Firmware
festzustellen. Müsste man sich für jedes Gerät ansehen, was für
spezifisches Verhalten es zeigt, an Hand dessen man es von Anderen
unterscheiden könnte. Eher nicht mit realistischem Aufwand bewältigbar.


> Erstens würde man sehr schön sehen wie die einzelnen IPs aufgeteilt sind
> und welche Geräte mit welcher Firmware-Aktualität im Einsatz sind.....das
> würde vielleicht Aufschluss geben auf welche images man mehr Rücksicht
> nehmen sollte.
> </SENF>
> LG Felix
>  Am 25.11.2013 16:36 schrieb "(spam-protected)" <(spam-protected)>:
>
>> Am 25. November 2013 16:31 schrieb L. Aaron Kaplan <(spam-protected)>:
>>
>>>
>>> On Nov 25, 2013, at 4:26 PM, (spam-protected) wrote:
>>>
>>> > Bin auch dafuer, aber achtung, ich glaube da braucht es einen Schalter
>>> im Webinterface / im UCI config:
>>> > "Ich will dass mein Router per SNMP abgefragt werden kann JA/NEIN"
>>> (mit default Wert "Nein")
>>> >
>>> > Also den Schalter halte ich auch für sinnvoll, um ein opt-out einfach
>>> möglich zu machen.
>>> > Ich würde dennoch default Wert auf JA setzen. Sonst können wir uns die
>>> Arbeit gleich spaaren, denn großen Nutzen bringt uns das nur, wenn wir
>>> damit einen großen Teil des Netzes abfragen können, was nur möglich ist mit
>>> opt-out statt opt-in. (denn selbst bei opt-out haben wir nur einen gewissen
>>> prozentsatz der diese firmware überhaupt verwenden wird)
>>> >
>>> >
>>>
>>>
>>> Eh! Das stimmt schon.
>>> Allerdings ist einfach der Opt-in der fairere Ansatz. Warum? Weil es gab
>>> hier (oder auf wien@) mal  eine ganz grosse Diskussion wegen
>>> Datenschutz. Im Zuge dessen wurde auch argumentiert, dass das Volumen an
>>> Traffic von einem Node auskunft darueber gibt, ob die Person zu Hause ist
>>> oder nicht. Der Effekt ist, dass diese Daten besser geschuetzt wurden.
>>>
>>
>> Also Trafic-Volumen würd ich da sowieso nicht mitreinnehmen, weil es wie
>> du schon argumentiert hast viel zu privat ist. Ich hatte eher an Latenz,
>> Bandbreite (aus einer iperf messung oder sowas), Packet-Loss usw. zu jedem
>> der vorhandenen Nachbarn gedacht.
>>
>>
>>>
>>> SNMP Daten sind aber potentiell viel genauer als das.
>>> Sprich: entweder man macht ein opt-in Verfahren oder man ueberlegt sich
>>> ein Opt-out aber dann muss man sich auch sehr genau ueberlegen, wie man die
>>> Daten klassifizert, wie sie behandelt werden, welche Schutz-Mechanismen da
>>> sind etc etc.
>>> Sprich: es wird komplexer.
>>>
>>> Aber natuerlich gebe ich dir recht, dass ein Opt-in den Nachteil haben
>>> wird, dass wenige Leute mitmachen.
>>>
>>
>> Ein möglicher Kompromiss wäre vielleicht, die Entscheidung verprflichtend
>> in den auch schon (bei den letzten Testtagen) viel diskutierten
>> Config-Wizard der beim ersten aufrufen der Web-Config-Maske nach dem
>> Firmware-flashen aufpoppen soll mit reinzunehmen, und somit den User zu
>> zwingen ja oder nein zu drücken.
>>
>>
>>>
>>> lg,
>>> a.
>>>
>>>
>> LG, Thomas
>>
>>
>> --
>> Discuss mailing list
>> (spam-protected)
>> https://lists.funkfeuer.at/mailman/listinfo/discuss
>>
>
-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.funkfeuer.at/pipermail/discuss/attachments/20131126/39f13d0c/attachment.htm>