Uwe Ohse

Informationen über das MausNet

Sysoptreffen 1993

Protokoll des MausNet-Sysoptreffens vom 07.10. - 10.10.1993 in Stuttgart.
Autoren: Rosemarie Rosenboom, Edgar Rosenboom, Martin Loos, alle @ UN HTML-Markup und alle dabei entstandenen Fehler: Uwe Ohse.
Tagesordnungspunkte: Zu Beginn schlug Jörg Henne (der die Diskussion leitete) vor, Abstimmungen am Sonntag en Block durchzuführen. Dieser Vorschlag wurde mehrheitlich abgelehnt. Alle Abstimmungen erfolgten im Anschluß an die Diskussion.

1.0 Technik

1.1 Bericht der Programmierer

Gereon Steffens gibt einen groben Überblick über den bisherigen Stand der Planungen zur Maus 9. Mit dieser sollen 65535 Gruppen und 65535 Mäuse realisiert werden. Die "Maus-To-Maus-Gates" fallen weg. Stattdessen sollen regionale Gruppen über ein Crashnetz direkt zwischen den beteiligten Mäusen ausgetauscht werden können. Die Baumstruktur (das heutige Nachtnetz) bleibt erhalten. Hardwarevoraussetzungen werden steigen, da Maus 9 DPMI-fähig werden soll. Es darf keine Rolle mehr spielen, ob für die Userdatei 1 KB oder 18-20 KB pro User benötigt werden. Mit Maus 9 wird ein MausTausch Level 1 (O-Ton Gereon: "Was auch immer das sein mag") eingeführt. Die Umstellung von Maus 7 auf Maus 9 wird eine Stichtagumstellung, ähnlich der Postleidzahlenumstellung (O-Ton Gereon: "Nicht fünf ist Trümpf, sondern drei ist Brei oder so"). Für die Umstellung werden zur Konvertierung der User- und Message-Dateien Hilfsprogramme geschrieben. Das sind bisher alles nur Ideen.

Zur Maus 7 kündigte Gereon einige Änderungen an. Es wird in Zukunft möglich sein, das MausMeter per MausTausch abzurufen. Diese Version wird frühestens in 2 Wochen freigegeben, da dieses Feature noch nicht von den Frontends unterstützt wird. Diese Infofiles benötigen keine CRC-Berechnung, da sie bei jedem Abruf verschieden sein werden. Für Remote-SysOps ist es dann auch möglich, das MCALL.LOG per MausTausch abzurufen. Gereon kündigte auch an, daß er für vernünftige Anregungen jederzeit offen ist, solange es sich nicht um irgendwelche obskuren Vorschläge handelt (O-Ton Gereon: "Nicht wahr, Wolfgang?").

Die Mausprogrammierer haben sich bereits Gedanken gemacht, was nach Maus 9 kommen soll. Der Hintergrund ist der, daß für Maus 9 nicht irgendwelche Datenstrukturen festgelegt werden, die in 2 Jahren wieder umgeworfen werden müssen. Diese "Maus 10" soll eine Multi-Port-Maus werden, wodurch ein Multitasking-Betriebsystem (z. B. OS/2) vorausgesetzt wird. Hier wurde auch daran gedacht, DR-DOS 7.0 als Betriebsystem zu verwenden (O-Ton Gereon: "Bitte nicht schlagen"), wobei eine Art Client-Server-Struktur Verwendung finden könnte.

Jörg Stattaus äußerte sich skeptisch, was die Fertigstellung der Maus 9 angeht. Bisher wurde davon ausgegangen, daß die Maus 9 im Jahre 1993 fertiggestellt wird (siehe auch Flensburger Protokoll 3.1), was aus Zeitmangel der Programmierer nicht möglich war. Jörg stellte die Frage, ob jemand in "C" eine neue Maus programmieren möchte, da eine Portierung nicht sinnvoll ist. Die aktuelle Maus soll dabei als Pflichtenheft angesehen werden. Diese Maus soll eine Alternative zur Maus 9 sein, was nicht heißen soll, daß Maus 9 begraben wird.

Fritz Elfert gab darauf bekannt, daß eine Mailingliste existiert, in der bereits Grundüberlegungen zu einer Unix-Maus (UMaus) angestellt wurden. Evtl. kann Ende 1993 in die Programmierung eingestiegen werden. Mitte des Jahres wurden die ersten Planungen dazu begonnen, die sich mit den Vorstellungen von Gereon zur Maus 10 decken. Diese Maus soll auf jeden Fall netzwerkfähig werden. Allerdings befindet sich diese Maus noch im Planungsstadium. Jörg, Kai und Gereon gaben bekannt, daß sie diese Maus unterstützen werden. Sie werden alle Informationen (insbesondere zu den Datenstrukturen) zur Maus herausgeben. Nach Jörg's Aussagen können beide Seiten davon profitieren.

Frank Baumgart gab abschließend noch einen kurzen Überblick über den derzeitigen Stand der Quark-Soft, die inzwischen komplett von BASIC nach C portiert wurde. Die Quark-II wird "in der nächsten Woche" wieder in die Beta-Phase gehen. Es gibt nach Franks Worten bereits Überlegungen zu einer Quark-III, die ebenfalls in C programmiert werden soll und so portabel wie möglich gehalten werden soll, damit sie auf alle Plattformen (TOS, Linux) leicht portiert werden kann. Diese Quark-Version wird auch multiport-fähig sein.

1.2 ISDN

Jörg Henne gab einen kurzen Überblick zum Thema ISDN, das durch die ansteigenden Datenmengen interessanter wird. Auf Nachfrage, wer sich bisher damit beschäftigt hat, meldete sich Klaus Abele, der auf die dabei auftretenden Probleme hinwies. Mit dem MausNet ist bisher kein Mischbetrieb (analog/ISDN) möglich, da von der Software derzeit nur eine Schnittstelle unterstützt wird. Eine einfache Lösung wäre ein Kombigerät, welches automatisch zwischen Modem- und ISDN-Anruf unterscheiden kann. Von Fritz Elfert kam daraufhin der Vorschlag ins MausNet einzubauen, daß in der MAUSNET.CFG für jede Maus der Port (Modem/ISDN) einzeln konfiguriert werden kann. Kai warf daraufhin ein, daß er noch keinerlei ISDN-Erfahrung habe, aber die Anregung notiert ist. Von Klaus kam noch der Vorschlag, daß eine Multitasking-Maus das Netz als eigenen Task abwickeln sollte, damit die Box für diese Zeit nicht heruntergefahren werden muß. Klaus erläuterte abschließend noch kurz die Kosten, die bei einer ISDN-Anbindung entstehen würden (Grundgebühr, Hardware- und Anschlußkosten).

1.3 Gruppennamen

Zunächst wurde nochmal kurz auf Maus 9 eingegangen. Jörg Stattaus erklärte, daß Gruppennamen maximal 255 Byte lang werden können. Aufgrund der langen Gruppennamen sind Gruppenhierarchien möglich. Was es an softwaremäßiger Unterstützung dafür geben wird, ist unklar. Die Gruppenselektion wird wahrscheinlich so aussehen, daß die Gruppen durch "taggen" (wie derzeit im Programmteil) ausgewählt werden. Von Kai kam der Hinweis, daß der hierarchische Gruppenaufbau eine administrative Angelegenheit sei und nicht Sache der Programmierer. Auf Anfragen zur Messagegröße bzw. Anzahl der Nachrichten erklärte Jörg, daß eine Messagegröße von 64 KByte geplant sei. Diese Größe wird aber konfigurierbar sein. Die Anzahl der Nachrichten wird eine 32-Bit-Zahl sein, also theoretisch ca. 2-4 Giga Nachrichten. Kai wies dann noch darauf hin, daß die Nachrichten ruhig theoretisch länger als 64 KByte werden können, nur der Header dürfe nicht länger als 64 KByte werden. Für jede Header-Zeile sind maximal 255 Bytes vorgesehen. (O-Ton Kai:) "Das technische Limit muß nicht notwendigerweise das administrative Limit sein"

Zur Problematik "einheitliche Gruppennamen im MausNet" wies Erwin Sienknecht darauf hin, daß Frontends keine Änderung des Gruppennamens erkennen, was bei der Namensänderung bestehender Gruppen zu Problemen führen würde. Da dies ein technisches Problem zwischen der Maus und den Frontends ist, wurden u. a. Steuermessages zur Gruppenumbenennung vorgeschlagen. Da dieses Thema bisher noch nicht zu einem Konsens in TAUSCHBAU geführt hat, wird es eine technische Lösung wohl so schnell nicht geben. Es stellte sich nun die Frage, ob eine "politische" Lösung gefunden werden sollte, oder ob die Gruppennamen wie bisher bleiben sollten. Frauke Cremer wies auf die Problematik der Quarks hin, die ihre Nachrichten bekanntlich per MausTausch bekommen. Frauke sagte, daß es ärgerlich sei, wenn eine neue Netzgruppe eingerichtet wird und in der Servermaus einen anderen Namen als den Netznamen bekommt. Der Quark-SysOp kann ja nur den Netznamen wissen, so daß die Quark bei abweichenden Gruppennamen die Fehlermeldung bekommt, daß es die bestellte Gruppe nicht gibt. Die folgende Abstimmung ergab eine deutliche Mehrheit zur Vereinheitlichung der Gruppennamen. Als Termin wurde der 1. November 1993 festgelegt. Michael Keukert brachte daraufhin den Einwand, daß manche Netzgruppennamen nicht korrekt seien (Beispiel: Die MausNet-Gruppe heißt CT, die Zeitschrift aber C'T). Es wurde per Akklamation beschlossen, daß Michael Keukert erstmal eine Vorschlagsliste erarbeitet. Anschließend sollen die Namen in den betreffenden Gruppen mit einfacher Mehrheit abgestimmt werden. Gereon machte abschließend noch den Vorschlag, in die Maus-Software etwas einzubauen, was diese Umstellung für die Frontends einfacher machen wird. Dieses Feature steht nach seinen Aussagen ganz oben auf der "Maus-to-do-Liste".

2.0 Allgemeines

2.1 einheitliches Logo

Jörg Henne stellt die Frage, ob wir ein einheitliches Logo wollen, wie es z. B. das Z-Netz hat. Von Kai kommt daraufhin der Vorschlag, ein Logo auf ASCII-Basis zu erstellen, da die einzige Ecke, wo ein Logo häufiger und wiedererkennbar auftauchen würde, das Netz wäre. Wolfgang Walter gibt zu bedenken, daß es derzeit verschiedene Logos gibt (Eissing, Lichti, PMaus) und daß Mäuse, die sich für ein abweichendes Logo entschieden haben um ihre Identität gebracht würden. Frauke vertrat den gleichen Standpunkt, da das Thema überflüssig sei. Wir sind keine Firma, sondern ein privates Hobby-Netz. Es gibt jetzt Maus-Pads, T-Shirts, und demnächst vielleicht auch noch Kugelschreiber. Die folgende Abstimmung ergab eine deutliche Mehrheit gegen ein einheitliches Logo.

2.2 Markenzeichen

Jörg Henne schnitt das Thema um die Rainbow BBS (Fido) an, deren SyOp von der Firma Rainbow verklagt wurde, da diese Firma den Namen "Rainbow" hat schützen lassen. Lutz Grünenwald gab daraufhin einen kurzen Bericht zum Ablauf und Ausgang des Prozesses. Im Fido gab es kürzlich Aufregung, weil ein User den Begriff "Fido" schützen ließ. Niemand weiß, was er damit bezwecken will. Um nun zu verhindern, daß mit "MausNet" etwas derartiges geschieht und den Mäusen die Benutzung dieses Begriffes untersagt wird, wurde der Vorschlag gemacht, daß sich die SysOps den Begriff MausNet schützen lassen. Es wurde auch vorgeschlagen die Begriffe "Maus" und "MausTausch" zu schützen, aber das wurde als aussichtslos aufgegeben. Jörg Stattaus brachte den Einwand, daß "Maus" ein normales Wort der deutschen Sprache ist und daher nicht geschützt werden kann. Dieses wurde von Frauke nochmal bestätigt. Stefan Rupp und Lutz Grünenwald gaben nun einen Überblick über die Vorgehensweise und die Kosten, die dabei eintstehen würden. Der Antrag kostet DM 300,-- und weitere DM 60,-- pro Sparte. Bei Ablehnung werden DM 150,-- erstattet. Das sind alles einmalige Zahlungen. Nach einer längeren Diskussion, ob "Maus" und/oder "MausNet" geschützt werden sollen, und ob der die Eintragung als Warenzeichen sinnvoll sei, machte Georg Bauer den Vorschlag den Versuch mit "MausNet" zu starten. Wenn wir MausNet nicht schützen können, kann es niemand. Und wenn es doch jemand schafft, haben wir es schriftlich, daß es gar nicht geht, bzw. wir es schon früher versucht haben und damit die älteren Rechte. Jörg Henne rief nun zur Abstimmung auf, den Begriff "Maus", "MausNet" oder keines von beiden schützen zu lassen. Die Abstimmung ergab eine knappe Mehrheit für "MausNet". Es wurden Stimmen laut, es trotzdem auch mit "Maus" zu versuchen, worauf die Abstimmung wiederholt wurde. Nun wurde abgestimmt, ob wir "Maus", "MausNet" oder beide Begriffe schützen lassen sollen. Die Abstimmung ergab eine eindeutige Mehrheit, es nur mit "MausNet" zu versuchen. Jede(r) Anwesende zahlte dafür DM 3,-- um die Eintragung zu finanzieren. Im Falle einer Ablehnung sollen die erstatteten DM 150,-- dem Netz zugute kommen (z. B. "Fonds für notleidende Mäuse", IN-Konto, ö. ä.)

3. Gruppe SYSOPS / Abstimmungen

Die Problematik der Gruppe SYSOPS war ja allen Anwesenden bekannt und braucht daher an dieser Stelle nicht wiederholt zu werden.

Von Florian Helm kam der Vorschlag, eine SysOp-Gruppe einzurichten, in der allerdings nur Betreiber schreiben dürfen. Gereon wies darauf hin, daß die Gruppe von ca. 5 Personen vollgemüllt wurde, wodurch eine Mengenbeschränkung sinnvoller sei als eine Betreibergruppe. Michael Keukert wandte ein, daß Mengen-Beschränkungen technisch derzeit nicht möglich, und von daher schwer durchzusetzen sind. Jörg Stattaus schlug vor, da befristete Schreibsperren gebraucht werden, evtl. mal über eine moderierte Gruppe SYSOPS nachzudenken. Michael zeigte dazu die derzeit üblichen Arten der Moderation (Fido: Moderator meckert User an, die Gruppen zumüllen und können diesen Schreibzugriff entziehen. UseNet: Mails werden als PM an den Moderator geschickt, der die Nachrichten dann in die Gruppe postet) auf. Georg Bauer brachte zu Jörgs Vorschlag, eine Betreibergruppe einzurichten, den Einwand, daß Betreiber als Moderatoren ihrer Co-SysOps unbrauchbar sind, da die letzten Diskussionen in SYSOPS gezeigt haben daß die Fronten zwischen den Mäusen und nicht zwischen den SysOps bestanden. Eine Betreibergruppe würde nichts ändern, da zwar weniger Namen zu lesen sind, aber immer noch die gleichen Argumente wiederholt werden.

Das bereits vor Wochen in SYSOPS angeregte Abstimmungsleiter-Team (AL-Team), könnte die Rolle eines Diskussionsleiter-Teams (DL-Team) übernehmen, schlug Jörg vor. Sevo bekräftigte dies, da Einzelpersonen als Abstimmungsleiter - wie die Erfahrung der letzten Jahre gezeigt hat - zu schnell demontiert werden. Frauke schlug vor, daß das DL-Team aus drei und nicht aus fünf Personen bestehen sollte, da unter 3 Leuten eher eine Einigung möglich sei als unter 5 Leuten. Michael regte an, für Diskussionen des DL-Teams eine eigene Gruppe einzurichten, die zwar von allen SysOps gelesen, aber nur vom DL-Team beschrieben werden kann.

Da schnell mal ein Mitglied des DL-Teams ausfallen kann (Klausur, Urlaub), regte Frauke an, drei Stellvertreter zu wählen (für jedes Mitglied einen). Kai schlug vor, daß die Mitglieder des DL-Teams aus verschiedenen Mäusen kommen sollten, da (wie schon von Georg festgestellt) die Fronten zwischen verschiedenen Boxen, aber nicht innerhalb einer Maus existierten. Jörg Henne griff nochmal den Vorschlag von Jörg Stattaus auf, das DL-Team solle in Personalunion mit dem AL-Team stehen.

Im Laufe der Diskussion wurde sich darauf geeinigt, daß dem DL-Team die Kompetenz eingeräumt werden soll, "totgelaufene" Diskussionen in SYSOPS für beendet zu erklären und evtl. SysOps, die sich daran nicht halten, für eine bestimmte Zeit aus der Gruppe SYSOPS auszuschließen. Jörg Stattaus stellte heraus, daß die Schreibsperre durch die Leserschaft der Gruppe SYSOPS zu legitimieren ist. Sevo machte darauf aufmerksam, daß der Abstimmungszeitraum kürzer gemacht werden sollten. Auf ein Abstimmungsergebnis zu einer Schreibsperre kann man nicht ein paar Wochen warten. Da das AL-Team mit der Gruppe SYSOPS und dem Lesen der Gruppen MAUS.INFO und MAUS überlastet wäre, schlug Michael Keukert vor, daß das AL-Team Abstimmungen über Gruppeneinrichtungen und Gruppenex- und Importe an User delegieren können sollte.

Die folgende Abstimmung, ob wir "eine Gruppe von Leuten, die auf die Gruppe SYSOPS irgendwie einwirken können" haben wollen, ergab eine deutliche Mehrheit - bei einer Gegenstimme - zugunsten eines DL-Teams.

Die Abstimmung über die Zusammensetzung des DL-Teams ergab 16 Stimmen für den Vorschlag, daß die Mitglieder des DL-Teams aus verschiedenen Orten kommen sollen und 54 Stimmen für den Vorschlag, daß die Mitglieder aus 3 verschiedenen Mäusen kommen müssen.

Bei den folgenden Abstimmungen ging es nun um die Kompetenzen des DL-Teams. Der Vorschlag "Das DL-Team hat die Kompetenz, ein Thema abzuwürgen" wurde mit einer Gegenstimme und fünf Enthaltungen angenommen. Der Vorschlag "Das DL-Team kann gegenüber einem Schreiber in der Gruppe SYSOPS eine Verwarnung aussprechen" wurde mit fünf Gegenstimmen und 4 Enthaltungen angenommen.

Diese Verwarnung kann ausgesprochen werden, wenn ein SysOp sich nicht an die Bestimmung hält, daß ein Thema beendet ist, oder wenn er rumflamed.

Ebenfalls eine deutliche Mehrheit fand der Vorschlag, daß der SysOp, über den der CFV läuft, während des CFV Schreibverbot hat. Mit deutlicher Mehrheit abgelehnt wurde der Vorschlag, daß während ein CFV gegen einen SysOp läuft (wenn dieser zu einem Thema geflamed hat), das Thema für alle in der Gruppe SYSOPS tabu ist. Dafür fand sich eine deutliche Mehrheit dafür, daß über den CFV nicht diskutiert werden darf, während dieser läuft.

Eine weitere Abstimmung über die Kompetenzen des DL-Teams ergab bei drei Gegenstimmen und sechs Enthaltungen, daß das DL-Team die Befugnis hat, gegen einen SysOp ein Schreibverbot zu verhängen. Dieses muß durch einen CFV durch die SysOps legitimiert werden. Das Schreibverbot gilt defaultmäßig für 14 Tage und das Ergebnis des CFV muß drei Tage nach posten des CFV veröffentlicht werden. Sonderregelungen für den Wiederholungsfall müssen seperat bestimmt werden. Die anschließende Abstimmung über die Verlängerung der Abstimmung von drei auf fünf Tage wurde bei vier Pro-Stimmen und 14 Enthaltungen abgelehnt.

Der Vorschlag, den Abstimmungsleiter durch das "3+3 AL-Team" zu ersetzten, wurde bei fünf Gegenstimmen und sechs Enthaltungen angenommen. Bei fünf Gegenstimmen und 12 Enthaltungen wurde Personalunion zwischen dem DL-Team und dem AL-Team beschlossen.

Die Amtszeit des AL-Teams wurde bei drei Gegenstimmen und 24 Enthaltungen auf ein halbes Jahr festgesetzt. Falls Proteste gegen das AL-Team aufkommen sollten, so finden die Regeln zur Abwahl des Abstimmungsleiters aus dem Mosbacher Protokoll für jedes einzelne AL-Team-Mitglied Anwendung. Dieses wurde ohne Gegenstimmen, bei 10 Enthaltungen beschlossen. Der alte Abstimmungsleiter (bzw. AL-Team) führt die Wahl zum neuen AL-Team durch. Die Wiederwahl ist möglich.

Ohne Gegenstimmen, bei drei Enthaltungen wurde auch das Wahlverfahren beschlossen: Jeder SysOp hat 3 Stimmen, die er auf 3 verschiedene Kandidaten verteilen kann. Die Ergebnisliste wird in der Reihenfolge der Anzahl der erhaltenen Stimmen von oben nach unten ausgewertet unter der Voraussetzung, daß aus einer Maus nicht mehr als 1 Mitglied pro Maus im AL-Team ist (außer als Stellvertreter eines anderen). An dieser Stelle verweisen wir noch auf die Thematik "Doppelmäuse", die zu einem späteren Zeitpunkt behandelt wurde (Anm. d. Protokollführer).

Mit einer deutlichen Mehrheit wurde beschlossen, daß das AL-Team von den SysOps gewählt wird. Acht Stimmen entfielen auf den Punkt "Wahl des AL-Teams durch die User" und sieben Enthaltungen wurden registriert.

Bezüglich einer eigenen Diskussionsgruppe SYSOP.AL für das AL-Team (alle SysOps dürfen lesen, schreiben darf nur das AL-Team) stimmten 10 SysOps gegen diesen Vorschlag, 16 enthielten sich der Stimme und die Mehrheit stimmte dafür.

4. Druckmittel für Mäuse, die Abstimmungsergebnisse ignorieren

Nach einer ca. einstündigen Diskussion einigten sich die Anwesenden mit deutlicher Mehrheit (bei einer Gegenstimme und sieben Enthaltungen) darauf, Sanktionen festzulegen und diese genauer zu definieren.

Nach anschließender Diskussion wurde dieses Ergebnis wieder verworfen und auf Antrag von Michael Keukert (mit deutlicher Mehrheit) festgehalten, daß der Ausschluß einer Maus zwar das letzte und schwerwiegendste Mittel ist, welches im Sanktionsfall eingesetzt werden kann, aber daß dieses Mittel existiert.

5.0 Gateways

5.1 Berichte der Betreiber

5.1.1 Fido

Sevo Stille gab einen Überblick über die derzeitige Situation im deutschen Fidonetz. Nach der Spaltung in GCC-Fido und Fido-Classic Mitte 1993 hat sich die Spaltung verhärtet. Dadurch herscht ein ziemliches Adresschaos, welches aufhören muß. Sevo berichtetet, daß es im zurückliegenden Jahr ein paarmal Probleme mit Moderatoren von Fido-Gruppen (Beispiel STARTREK) gegeben hat. Er wies darauf hin, daß wenn ein SysOp von einem Moderator angeschrieben wird, unbedingt der Gateway-SysOp informiert werden muß. Wichtig ist, daß dafür gesorgt wird, daß der User vorerst nichts mehr in der betreffenden Gruppe schreibt. Anschließend kann die Sache mit dem Moderator geklärt werden. Darauf zu warten, daß der Moderator die Gruppe für das Gateway sperrt ist sicher der falsche Weg. Da die Gruppen immer nur über ein Gateway rausgehen, ist an der Message-ID der Gateway zu erkennen. Beim GCC-Gateway (F) ist Sevo Stille der Ansprechpartner und beim Classic-Gateway (AC) ist es Jörg Stattaus.

Um das Adresschaos mit Fido-Adressen innerhalb des MausNet zu vermindern, sollen die Gateways umbenannt werden (Fido-F/Fido-AC), damit die Adresse eindeutiger ist.

5.1.2 Z-Netz

Klaus Atzpodien konnte über den Z-Netz-Gateway nichts neues berichten. Der Gateway läuft seit jahr und Tag stabil und macht keine Probleme. Vor Maus 9 wird sich an diesem Gateway auch nichts ändern. Auf Nachfrage, warum die Gruppen BIETE und SUCHE nicht mehr mit dem Z-Netz vernetzt sind, erklärte Klaus daß diese im Z-Netz aufgeteilt wurden und der Import eingestellt wurde, da nicht alle Gruppen dieser Hierarchie mit einer Gruppe vernetzt werden können.

5.1.3 GerNet

Michael Keukert berichtete über den neuen Gernet-Gateway. Die Gate-Soft muß noch installiert werden. PMs ins und aus dem GerNet werden über diesen Gateway laufen, ebenso wie die Gruppe C'T und evtl. noch andere gewünschte Gruppen. Derzeit ist alles noch eine Frage der Installtion. Was schon an PMs am Gateway ankommt wird aufgehoben und nicht weggeworfen.

5.1.4 Usenet

Über dieses Thema folgt an anderer Stelle ein eigenes Kapitel.

5.2 Gruppenexport

Anlaß zu diesem Thema war der umstrittene Export der Gruppe MAC ins UseNet.

Gegen eine Box, die sich nicht an Abstimmungsergebnisse hält, sollen Sanktionen verhängt werden können. Der Abstimmungaufruf zu Gruppenexporten soll in Zukunft eindeutiger formuliert werden.

Peter Böhnke regte an, anstelle der Stimmensammlung sofort eine Abstimmung durchzuführen, weil immer jemand gegen ist. Damit würde auch die Bewertung von "deutlichem Widerspruch" wegfallen. Vorgeschlagen wurde auch, den Ablauf der Gruppeneinrichtungen für Exporte zu übernehmen. Fritz Elfert schlug vor, einen Prozentwert der Teilnehmer anzusetzen. Wenn mehr als 10 % der Teilnehmer bei einer Umfrage unter den Lesern der Gruppe gegen einen Export sind, findet der Export nicht statt.

Weiterhin wurde angeregt, daß der Aufruftext standardisiert werden sollte. Peter Böhnke forderte, daß der Aufruf nur in der Gruppe und nicht in MAUS.INFO oder anderswo gepostet wird. Ebenso sollte der Aufruf, so Michael Keukert, positiv formuliert werden. Er sollte zum Beispiel nicht so aussehen: "Ist jemand dagegen, daß nicht exportiert wird?".

Der Vorschlag, den Ablauf zur Gruppeneinrichtung zu übernehmen wurde nochmals in die Diskussion eingebracht. Das Thema wurde damals ausreichend diskutiert, warum sollte es nochmals ausgearbeitet werden, zumal es gut funktioniert.

Folgender Ablauf zu Gruppenexporten wurde dann bei 8 Gegenstimmen und 6 Enthaltungen festgelegt: Der User (der den Export wünscht) wendet sich an das AL-Team, welches ihm eine Bestätigung und den formulierten Abstimmungsaufruf schickt. Hiermit autorisiert das AL-Team den User zum posten des Abstimmungsaufrufes und zur Stimmensammlung. Der Aufruf wird nur in der betreffenden Gruppe gepostet und enthält nur die Punkte "Dafür" und "Dagegen". Die einfache Mehrheit reicht für den Export.

Mit 4 Enthaltungen und keiner Gegenstimme wurde noch beschlossen, daß das Ergebnis von Exportabstimmungen grundsätzlich nach MAUS.INFO gepostet wird.

6.0 IN/Usenetgate

6.1 Bericht der Betreiber (K)

Stefan Radermacher konnte zur Funktion des Gateway nicht viel sagen, da dieses von zweien seiner Co-SysOps gewartet wird, die beide nicht anwesend waren, ebenso wie der Domainverantwortliche von .maus.de (Jürgen Conradi).

Stefan berichtete, daß der Gateway derzeit auf seinem Notbook läuft, aber er hofft, daß es in Kürze unter OS/2 auf der Maus K laufen wird.

6.2 Gebühren und Mailbeschränkung

Zum Thema Servergebühr berichtete Stefan, daß im Monat 50,-- DM an Kosten anfallen, die er sich nicht leisten kann. Daher möchte er diese gerne auf alle Mäuse umlegen, die Mail über den Kölner Gateway laufen lassen. Die TeX-Mailingliste (TEX-D-L) wird als News betrachtet.

Frauke Cremer bat noch einmal darum offenzulegen, an wen was bezahlt werden muß. Stefan erläuterte, daß der IN-Beitrag, der zur Teilnahme am IN und damit zum Bezug und Versand von Mail und News ins Usenet berechtigt, an den Domainverantwortlichen gezahlt wird. Die Servergebühr ist an die Maus Köln zu zahlen, da dies die Telefonkosten sind, die der Maus Köln für den UseNet-Gateway entstehen. Eine volumenabhängige Abrechnung will Stefan nicht erstellen, da der Aufwand zu hoch sei. Mäuse mit eigenem UseNet-Gateway brauchen keine Servergebühr bezahlen.

Zur Mailbeschränkung besteht derzeit folgende Regelung: Die maximale Mailgröße von einem User an den gleichen User ist pro Tag auf 48 KB festgelegt. Bei Überschreitung dieser Größe wird ab 100 KB eine Strafgebühr in Höhe von 10,-- DM pro angefangenem MB erhoben. Die Kosten sind eine reine Abschreckung und nicht die tatsächlichen Kosten, die hierbei entstehen.

Jörg Stattaus schlug vor, daß die Strafgebühren dem Gateway zugute kommen sollen und somit die Servergebühr vermindert werden kann.

Ohne Gegenstimme bei 11 Enthaltungen wurde beschlossen, daß die Grenze für Mailmassen weiterhin bei 48 KB liegt. Alles, was darüber hinausgeht, wird nicht weitergeleitet, sondern gelöscht. Absender und Empfänger erhalten eine freundliche Aufforderung, das in Zukunft doch besser zu unterlassen. Ab 100 KB werden pro angefangenem MB wird eine Strafgebühr in Höhe von DM 10,-- erhoben.

Eine Betreiberabstimmung zu Servergebühr ergab ein einstimmiges Votum für DM 8,-- pro Jahr und Maus die Mail über den Kölner Gateway laufen läßt.

6.3 MX-Records

Jörg Henne brachte das Thema MX-Records für .maus.de zur Sprache. Die beantragten MX-Records für die Mäuse DU/DU2, DO/DO2/MK/UN und MS3 wurden lt. Udo Erdelhoff von Frank Simon (alias Terra, Vorsitzender des IN) abgelehnt. Bisher haben alle Mäuse, die hinter HB hängen einen eigenen MX-Record, was technisch auch notwendig ist. Außerdem haben die Aachener Mäuse einen MX-Record. Mehr als diese werden .maus.de nicht zugesprochen.

6.4 Domainverantwortlicher maus.de

Es wurde einiges an Informationen weitergegeben, was die Finanzlage und die weitere Zukunft des IN angeht. Diese sind inzwischen durch das IN-Treffen überholt. Zum Thema Finanzen wurde der Wunsch formuliert, daß alle Mäuse weniger als durchschnittlich DM 15 zahlen. Beschlossen werden konnte nichts, da kein Vertreter der Domain-Verwaltung anwesend war.

Klaus Abele warf den Domainverantwortlichen vor, daß in SYSOP.IN ein Informationsdefizit bestehe. Es sollten mehr Informationen von den DVs an die SysOps weitergegeben werden. Peter Böhnke verteidigte die DVs. Wenn Jürgen oder Günter auf irgendwas angesprochen werden, erzählen sie immer was. Wenn sie nicht gefragt werden, können sie natürlich auch nichts sagen. Bisher ist auf Anfrage immer was von den beiden gekommen. Abschließend sagte Peter noch, daß wir uns um eine kostengünstigere Lösung kümmern sollten, worauf Michael Keukert noch zu bedenken gab, daß die billigste Lösung nicht immer die günstigste ist.

An dieser Stelle wurde die Diskussion dann beendet.

7.0 Maus-Lokales

7.1 Co-Sysops

Hier stellte Jörg Henne zu Beginn erst einmal die Frage, was Co-SysOps überhaupt sind.

Irgendwo sollte festgehalten werden, wer bei SysOp-Abtimmungen stimmberechtigt ist. Peter Böhnke machte den Vorschlag, daß Co-SysOps im ISB stehen sollten, damit das AL-Team eine Liste der bei SysOp-Abstimmungen stimmberechtigten Personen an der Hand hat. Vorschlag einer Definition: Co-Sysop ist, wer im ISB steht. Betreiber werden extra ausgewiesen. Kai warf ein, daß es "völlig Banane" ist, wer die Stimme für die Maus abgibt.

Die folgende Abstimmung ergab dann bei einer Enthaltung und sechs Gegenstimmen, daß SysOps und Co-SysOps mit ihrem Namen im ISB stehen müssen. Die Adresse ist keine Pflicht.

Nach kurzer Diskussion, bezüglich der Stimmberechtigung der SysOps wurde das Ergebnis der Abstimmung verworfen und die Abstimmung neu formuliert: "SysOps, die abstimmungsberechtigt sind, müssen im ISB stehen." Dieser Antrag wurde bei 15 Enthaltungen und vier Gegenstimmen angenommen.

Jörg Henne schlug vor, das ISB im PMK-Token-Format zu vereinheitlichen. Sam Jost befürwortete das, da die Abstimmungsleiter dann das ISB maschinell auswerten könnten. Wer seine SysOps dann nicht im PMK-Token-Format ins ISB einträgt, ist halt nicht abstimmungsberechtigt. Michael Keukert wies darauf hin, daß das ISB bei Maus 9 automatisch vorgegeben wird, um Fehler zu vermeiden. Daher sollte das derzeit noch nicht zur Pflicht gemacht werden.

Sevo teilte zum Thema ISB noch mit, daß die Maus F ihre Rufnummer jetzt im internationalen Format im ISB eingetragen hat. Damit Probleme mit den österreichischen und Schweizer Mäusen nicht auftreten, sollten das bei allen Mäusen so gemacht werden.

7.2 Doppelmäuse

Jörg Henne stellte die Frage, wie der Begriff "Doppelmaus" zu definieren sei und ob diese auch den doppelten IN-Beitrag zu zahlen hätte. Klaus Abele stellte heraus, daß das Ziel der Doppelmaus nicht ist, die Zahl an Usern und Zahlern zu verdoppeln, sondern den Usern mehr Zeit und bessere Möglichkeiten in die Box reinzukommen zu geben. Er möchte nicht hören "Ihr seid nur ein System, müßt aber für zwei Systeme zahlen". Klaus möchte ebenfalls den Begriff "Doppelmaus" festgelegt haben. Ist es eine große Maus oder wie zwei Mäuse in einer Stadt zu sehen. Das nächste Problem der Doppelmaus ist die Servergebühr für den IN-Gateway. Gereon machte den Vorschlag eine Doppelmaus als zwei Mäuse zu zählen, da sie die Möglichkeit hat die doppelte Anzahl an Usern zu versorgen. Klaus machte den Vorschlag die zweite Maus als kleine Maus gegenüber dem IN einzustufen, da sie am Anfang eine kleine Maus sei. Wenn sie größer wird, kann sie dann höhergestuft werden. Wolfgang Walter stellte heraus, daß Karlsruhe freiwillig den Beitrag für zwei Mäuse zahlt, da es quasi eine Maus mit zwei Ports ist. Fritz Elfert brachte ein kleines Gedankenspiel: "Wenn eine Maus acht Ports hat, versorgt sie dann auch achtmal soviele User und muß den achtfachen Beitrag zahlen?". Das Maß sollte nicht die Anzahl der Ports sein, sondern die Zahl der Zahler, da nur diese die IN-Leistungen nutzen können. Kai Henningsen stellte heraus, daß das im Prinzip von den gesamt eingenommenen Geldern der Zahler abhängt. Bisher wird nicht herumgegangen und gezählt, sondern die Systeme schätzen sich selbst ein, wie das in den meisten Bereichen auch ganz gut funktioniert. Gereon brachte zum Beispiel der Acht-Port-Maus das Argument, daß diese die Ports die gleiche Adresse haben, eine Doppelmaus aber zwei Adressen. Klaus Abele wandte ein, daß im IN Doppelmäuse nur als ein System abgerechnet werden. Claus Wickinghoff faßte das Problem nochmal zusammen, daß eine Doppelmaus die Rechte einer Maus, aber die Pflichten für zwei Mäuse haben.

Es folgte eine Abstimmung, ob ein System mit dem gleichen Betreiber, räumlich beieinander stehend, bei gleichem Angebot der beiden Systeme (Ausnahme z.B. UN(2), die auf dem zweiten Port nur Spiele usw. anbieten) als ein System oder mehrere Systeme zu betrachten sei. Dreizehn Stimmen fanden sich für den Punkt "mehrere Systeme", sieben Stimmen waren Enthaltungen und der Rest stimmte für den Punkt "ein System".

Nun fand eine Betreiberabstimmung über die Verteilung der IN-Gebühr statt. Jörg Stattaus schlug vor, daß die Mäuse sich selbst einschätzen (22 Stimmen). Der Vorschlag von Gereon Steffens, daß jede Maus das gleiche zahlt erhielt 18 Stimmen. Sieben Betreiber einthielten sich der Stimme.

Kai Henningsen regte an, diese Abstimmung in die Gruppe SYSOPS zu verlegen, da das Ergebnis recht knapp war. Dieser Vorschlag fand allgemeine Zustimmung.

8.0 Maus-Guide, Moderatoren

Jörg Henne stellte fest, daß es in letzter Zeit Ansätze zur Reglementierung (Rules, Vorschlag des Mausguide) bis zur Einführung von Moderatoren wie im Fido üblich, gegeben hat.

Marcel Sieling brachte den Einwand, daß das Thema lang und breit diskutiert wurde. Es gibt den MausNet-Guide, der fast fertig ist. Den lokalen SysOps sollte überlassen werden, was sie damit machen. Der MausNetGuide ist ganz gut konsensfähig, warum sollte SysOps, die sich nicht damit anfreunden können der Guide vorgeschrieben werden? Jede Maus sollte das halten wie die lokalen SysOps wollen. Michael Keukert vertrat die gleiche Meinung. Die Netiquette ist Sache der User und sollte nicht von oben herab bestimmt werden.

Die Abstimmung, ob der MausNet-Guide als freiwillige Richtschnur anzusehen ist, und es den lokalen Mäusen überlassen wird, was sie damit machen wurde ohne Gegenstimme bei drei Enthaltungen angenommen.

9.0 Anträge

9.1 DL-Team

Auf Wunsch von Dirk Steins wird ins Protokoll aufgenommen, daß das DL-Team nur für die Gruppe SYSOPS und nicht für andere Gruppen gilt!

9.2 Regeln

Peter Böhnke fragte nach, ob es eine allgemein gültige Regel gibt, wie mit Usern, die sich in Gruppen daneben benehmen (z. B. UUs in NETGAMES), verfahren wird. Dieses ist bisher nicht geregelt und wird individuell gehandhabt.

9.3 PM-Status

Michael Keukert berichtete über Ärger in den Gruppen NETZWESEN und GATEWAYS bezüglich des Status von PMs, insbesondere den "Gelesen"-Status.

Die lauten Vertreter der Leute außerhalb des MausNet sind der Ansicht, daß der "Gelesen"-Status ziemlich krass gegen den Datenschutz verstößt, allerdings scheint es auf der Seite auch einige Unklarheiten über die Technik zu geben. Erwin Timmerbeil hat einen Datenschutzbeauftragten gefragt, der meinte daß es kein Problem wäre, wobei es auch im MausNet ein deutliches Mißverständnis zwischen dem "Angekommen"-Staus und dem "Gelesen"-Status gibt. Der "Gelesen"-Status wird entweder explizit vom Frontend gesetzt oder eben nicht, Crosspoint setzt ihn, wenn eine bestimmte Option gesetzt ist, auf 12 Uhr anstatt ihn gar nicht zu setzen. Dieser Streit hat schon einige heftige Äußerungen ausserhalb des MausNet hervorgerufen hat, bis zur Äußerung, daß wir in einem faschistoiden Netz leben würden. Michael fragte noch, wie weit das bekannt sei, und wie weit Diskussionsbedarf besteht.

Sevo Stille vermutete, daß diese Leute den "Gelesen"-Status nicht ganz verstanden haben und von der Meinung ausgehen, daß das in irgendeiner Form öffentlich lesbar sei und daß dabei konkrete Zeiten mitgeschickt werden. Die Frontends sollten optional anbieten, die Uhrzeit mitzuliefern, was das Datenschutzproblem umgehen würde.

Michael Keukert regte an, in die MausTausch-Doku mit aufzunehmen, daß ein User, der den Status setzt, dies richtig zu tun hat. Wer den Status nicht herausgeben will, setzt den Status nicht, damit falsche Statusmeldungen unterdrückt werden. Jörg Stattaus machte deutlich, daß dieses defaultmäßig der Fall sein sollte.

Die folgende Abstimmung über den Vorschlag, daß Frontend-Programmierer dazu angehalten werden, den Status so zu behandeln, daß dieser vom Frontend richtig gesetzt wird, oder gar nicht wurde bei fünf Gegenstimmen und neun Enthaltungen angenommen.

Der Antrag, daß Statusmeldungen nur auf explizite Anforderung des Users verschickt werden, wurde bei fünf Enthaltungen und einer Pro-Stimme abgelehnt.

9.4 geheime Gruppe

Jörg Henne beantragte, eine geheime Gruppe einzurichten, deren einziger Zugriffsberechtigter der "Butler James" (ein Programm, welches in einer Reihe von Mäusen eingesetzt wird) ist. Diese Gruppe könnte auch für andere Programme benutzt werden.

Nach ausführlicher Diskussion über die Vor- und Nachteile dieser Gruppe wurde diese bei einer Abstimmung mit siebzehn Pro-Stimmen und vierunddreißig Enthaltungen abgelehnt.

9.5 SysOp-Treffen 1994

Rosemarie Rosenboom gab den Termin des SysOp-Treffens 1994 bekannt. Dieses findet vom 26.-28.08.94 in Oer-Erkenschwick statt. Ausrichter ist die Maus Unna.

9.6 Teilnehmerliste 1993

@AC  Jörg Stattaus
                         @HN  Frauke Cremer        @S   Gerhard Meiser
@AC2 Michael Keukert          Frank Düring              Inge Meiser
     Stefan Rupp                                        Andreas Frank
     Frank Landrock      @K   Stefan Radermacher        Hans-Peter Deist
                              Joachim Hoss
@AC3 Claus Wickinghoff                             @S2  Markus Wagenmann
                         @K2  Gereon Steffens           Peter Ahlert
@BB  Jörg Henne               Edgar Fuß                 Uwe Schlenther
     Ulrich Fey               Dirk Steins               Florian Unger

@BM  Marcus Schmidtke    @KA2 Wolfgang Walter      @S3  Fritz Meyer-Zu-Uptrup
                              Matthias Stürmer          Uwe Poliak
@BN  Florian Helm                                       Michael Wist
                         @KI  Klaus Atzpodien
@CB  Romeo Rakow              Nils-Henner Krüger   @SB  Ralf Bühr

@CLP Joachim Theile      @KL  Gabriel Schmidt      @SL  Marco Hahn
                                                        Michael Schlüter
@DO  Michael Roder       @KR  Elmar Höttges
     Stefan Hintz             Marcel Sieling       @SN  Jörn Kresse
     Peter Redecker           Harro Hedemann
                                                   @ST  Lorenz Isbeih
@DO2 Erwin Sienknecht    @L   Matthias Bachmann         Ralf Siepker
     Alfred Schmidt                                     Andre Dütsch
     Udo Erdelhoff       @LU  Olaf Boss                 Ralf Czekalla

@DU  Klaus Abele         @M   Lutz Grünewald       @ST2 Georg Bauer
     Georg Schroers                                /MS3 Martin Koyro
     Dietmar Hannemann   @M4  Christian Hohendorf
                              Claudia Hohendorf    @SU  Tobias Bartelt
                                                        Vanessa Rehde
@F   Sevo Stille         @MS  Kai Henningsen
     Timm Ganske                                   @TBB Hans-Peter Bock
     Petra Ilyes         @N   Udo Fleckenstein
     Detlef Woltmann                               @UN  Rosemarie Rosenboom
                         @NF  Gerhard Trimpin           Edgar Rosenboom
                              Joern Haase               Martin Loos
@FL  Maik Standtke
     Sam Jost            @OG  Andreas Mandel       @WOB Jens Barth
     Thomas Przetak           Stefan Llabres
                                                   @WÜ  Markus Klingspor
@GÖ  Mario Adam          @PB  Bernd Becker              Fritz Elfert
                              Frank Baumgart            Jochen Krapf
@H   Friedrich Lämmle         Uwe Ohse
     Dittmar Knoop                                 @WUN Sebastian Hempel
     Andreas Zenner      @PB2 Carsten Ellermann
     Wolfgang Völker                               @ZW  Andreas Mayer
                         @PE  Lars-Iver Kruse           Ulrich Pfister
@HB2 Peter Böhnke             Jürgen Stessun
     Ulli Handorf             Steffen Engel
     Thomas Wilkens           Jürgen Loos

                         @R   Thomas Gallert
@HD  Philipp Oelwein          Markus Fertsch

@HG  Ralf Lenz           @RO  Marian Maier
     Thomas Fey
                         @RS  Thorsten Floeck
@HH  Harald Labeit            Claudia Hessling
     Michael Przetak          (Gast)

@HL  Karsten  Iwen

Nachtrag

Der folgende Nachtrag bezüglich des Mißtrauensantrags wird noch an das Protokoll angehängt:
Eine nachträgliche SysOp-Abstimmung zum Thema DL-Team ergab folgendes: Ein Mißtrauensantrag muss von mindestens 3 stimmberechtigten Sysops unterstützt werden - den Antragsteller eingeschlossen. Wird er im CFV abgelehnt, so wird gegen das betroffene Mitglied des AL-Teams für einen Monat (Datum des Antrags) kein weiterer bearbeitet. Ein neuer Antrag muss sich in mindestens zwei Unterstützern von allen bisher gegen diese Person gestellten unterscheiden.
so long... Die Protokollführer (Rosi, Netgar und Mattin)
Copyright (C) der HTML Version (C) 1997 Uwe Ohse. Kommentare/Fragen an uwe@ohse.de.