=============================================================================
_________________
/ FidoNet \ Offizielle deutsche Uebersetzung der
/ Region 24 \
/ _/( _/.\ )\_ \ F I D O N E T P O L I C Y 4 . 0 7
/ ////\_ (--_/ _/\\\\ \
| ///////\ / \ /\\\\\\\ | Uebersetzung Version 1.01, 11.11.1991
| ////////| |\\\\\\\\ |
| ////// /\ /\ \\\\\\ | erstellt von der
\ m/ /|\ \m /
\ //|\\ / Region Koordination fuer Region 24
\ Bundesrepublik /
\__ Deutschland __/ Alle Rechte vorbehalten ausser den folgenden:
Die private Nutzung dieses Textes ist allen FidoNet-Teilnehmern und allen
FidoNet-Interessenten gestattet. Die unentgeltliche Weitergabe des Textes
in Datenfernuebertragungsmedien (i.A. Mailboxen) ist ausdruecklich er-
wuenscht. Fuer weitergehende Nutzung, z.B. Veroeffentlichung in Print-
Medien, ist das schriftliche Einverstaendnis des RC 24 erforderlich;
Kontaktaufnahme ist mittels FidoNet Mail moeglich (wie sonst).
Hinweis: Der Hundesadler ist ein geschaetztes Markenzeichen des RC 24.
=============================================================================
Einleitung und Miesmacher:
--------------------------
Dieses Machwerk stellt das Ergebnis vieler Stunden gewissenhafter Ueber-
setzungarbeit dar, und das ist in der Tat auch bereits alles was es ist.
Es handelt sich hierbei nur insoweit um ein fuer eine deutschsprachige
verwaltungsmaessige FidoNet-Region verbindliches Policy-Dokument, als es
nach Ansicht des jeweiligen Regional Koordinators den Sinn der englischen
Original-Policy vernuenftig wiedergibt.
Fuer die Korrektheit der Uebersetzung besteht keinerlei Gewaehr, und bei
Zweifelsfragen (wie etwa Policy-Beschwerden) ist stets auf die gueltige
englische Original-Policy Bezug zu nehmen.
Hinweise auf unkorrekte oder missverstaendliche Uebersetzungen bitte via
Netmail an den Region-Coordinator der Region 24, FidoNet (2:24/0), senden.
=============================================================================
Noch ein paar Anmerkungen zur Uebersetzung:
-------------------------------------------
- Die Policy geht irgendwann dazu ueber, den Sysop direkt anzusprechen.
An diesen Stellen haben meine Helfer bei der Uebersetzung ganz selbstver-
staendlich die "Du"-Form fuer das "You" eingesetzt. Ich beliess es dabei,
denn dies ist die uebliche Umgangsform untereinander im FidoNet.
- Bemerkungen in eckigen Klammern [so wie dies hier] sind _NICHT_ Bestandteil
des englischen Originaltextes, sondern dienen in der Regel nur dem Ver-
staendnis der englischen Bezeichnungen bzw ihrer Uebersetzung. Im Anhang
dieser Datei werden einige englische Bezeichnungen die im FidoNet allgemein
gebraeuchlich sind erlaeutert.
- Diese Uebersetzung ist nicht dazu geeignet, um Spitzfindigkeiten bei der
Policy-Auslegung zu belegen. Sie soll vielmehr der Information aller Teil-
nehmer und Benutzer des FidoNet im deutschsprachigen Raum dienen, und gerade
denjenigen, die des Englischen nicht so maechtig sind, eine Gelegenheit
geben, die Grundsaetze des FidoNet kennenzulernen, denn ich finde, dass
das FidoNet wirklich eine gute und lesenswerte Policy anzubieten hat, aus
der viel vernuenftige Ueberlegung spricht.
Und nun ... v i e l S p a s s beim Lesen ! :-)
16.Okt.1991, Nieder-Roden Helge Ramdohr, RC24 (1991/92)
=============================================================================
I n h a l t
1 UEBERSICHT
1.0 Sprache
1.1 Einfuehrung
1.2 Organisation
1.2.1 Individuelle Systeme und Systembetreiber
1.2.1.1 Benutzer (User)
1.2.1.2 Points
1.2.3 Netzwerke [Networks] und Netzwerk Koordinatoren
1.2.3.1 Netzwerk Routing Hubs
1.2.4 Regionen und Regional Koordinatoren
1.2.5 Zonen und Zonen Koordinatoren
1.2.6 Zonen Koordinator Rat
1.2.7 Internationaler Koordinator
1.2.8 Top-Down Organisation, Kontrolle und Gleichgewicht
1.3 Definitionen
1.3.1 FidoNews
1.3.2 Geografie
1.3.3 Zone Mail Hour [Zonen Mail Stunde]
1.3.4 Nodelist
1.3.5 Uebermaessig veraergendes Verhalten
1.3.6 Kommerzielle Nutzung
2 SYSOP HANDLUNGSWEISEN
2.1 Allgemein
2.1.1 Die Grundlagen
2.1.2 Vertrautheit mit der Policy
2.1.3 Verantwortlichkeit fuer den gesamten Verkehr,
der ueber den Node in das FidoNet eintritt
2.1.4 Verschluesselung und Ueberpruefung von Mail
2.1.5 Keine Veraenderung von weitergeleiteter [routed] Mail
2.1.6 Private Netmail
2.1.6.1 Keine Enthuellung von Durchgangs-Mail [In-Transit Mail]
2.1.6.2 Private Mail, die an Dich adressiert ist
2.1.7 Nicht-Weiterleiten von Mail
2.1.8 Ausschliesslichkeit der Zone Mail Hour
2.1.9 Private Nodes
2.1.10 Beachtung der Mail Ereignisse
2.1.11 Benutzung der aktuellen Nodelist
2.1.12 Exkommunikation
2.1.13 Timing der Zone Mail Hour
2.1.14 Nicht-Einhaltung der Sommerzeit [daylight savings time]
2.2 Wie man eine Nodenummer erhaelt
2.3 Wenn Du 'Down' gehst
2.4 Wie man ein Netzwerk bildet
3 ALLGEMEINE HANDLUNGSWEISEN FUER ALLE KOORDINATOREN
3.1 Mache Differenzdateien [NodeDiffs] und FidoNews verfuegbar
3.2 Bearbeiten von Nodelistaenderungen und ihre Weitergabe
stromaufwaerts
3.3 Stelle sicher, dass die letzte Policy verfuegbar ist.
3.4 Minimiere die Anzahl der Huete die Du traegst
3.5 Sei ein Mitglied des verwalteten Gebiets
3.6 Ermutige neue Sysops in FidoNet einzutreten
3.7 Tradition und Praezedenz
3.8 Technisches Management
4 NETZWERK KOORDINATOR HANDLUNGSWEISEN
4.1 Verantwortlichkeiten
4.2 Weiterleiten eingehender Mail [Routing Inbound Mail]
4.3 Zuweisen von Node Nummern
4.4 Instandhaltung der Nodelist
4.5 Mache die Policy, Nodelist und FidoNews verfuegbar
5 REGIONAL KOORDINATOR HANDLUNGSWEISEN
5.1 Verantworltichkeiten
5.2 Zuweisung von Nodenummern
5.3 Ermutigung zur Bildung und zum Wachstum von Netzwerken
5.4 Zuweisung von Netzwerk Nummern
5.5 Instandhaltung der Nodelist
5.6 Geografische Ausnahmen
5.7 Ueberschauen des Betriebs der Netzwerke
5.8 Verfuegbarmachung der Nodelist, Policies und FidoNews
6 ZONEN KOORDINATOR HANDLUNGSWEISEN
6.1 Allgemeines
6.2 Auswahl
7 INTERNATIONALER KOORDINATOR HANDLUNGSWEISEN
7.1 Allgemeines
7.2 Auswahl
8 VOLKSABSTIMMUNGEN
8.1 Verfahrensaufnahme
8.2 Ankuendigung und Ergebnisbekanntgabe
8.3 Wahlberechtigung
8.4 Wahl Mechanismus
8.5 Abstimmung ueber das gesamte Policy Dokument
8.6 Wahlentscheidung
8.7 Anfechtung eines Zonen Koordinators
8.7.1 Verfahrensaufnahme
8.7.2 Handlungsweisen wie im Policy Volksentscheid
8.7.3 Wahlmechanismus
8.7.4 Beschraenkt auf einmal pro Jahr
9 LOESUNG VON STREITFRAGEN
9.1 Allgemein
9.2 Probleme mit einem anderen Sysop
9.3 Probleme mit Deinem Netzwerk Koordinator
9.4 Probleme mit anderen Koordinatoren
9.5 Einspruchsverfahren
9.6 Status von Beschraenkungen
9.7 Anrecht auf eine schnelle Entscheidung
9.8 Rueckkehr in das urspruengliche Netzwerk
9.9 Echomail
9.10 Fallgeschichten
10 ANHANG
10.1 Allgemein
10.2 Timing der Zone Mail Hour
10.3 Fallgeschichte
10.3.1 Der Fall vom betruegerischen Node
10.3.2 Der Fall vom 'Hacker' Mailer
10.3.3 Der Fall vom geplagten Meckerer
10.3.4 Der Fall vom fleissigen Bieber
10.3.5 Das Zeichen des Teufels
10.3.6 Der Fall vom Sysop Twit
10.3.7 Der Fall vom Echomail Suechtigen
10.3.8 Der Fall vom sprunghaften System
10.5 Lob, Anerkennungen usw
Index
---------------------------------
Deutscher Anhang:
- Fremdworte aus dem Fido-Jargon
=============================================================================
Fidonet Policy Dokument Version 4.07
9. Juni 1989
Dieses Policy Dokument ist durch Abstimmung der FidoNet Koordinatoren
Struktur akzeptiert worden, und ist das derzeit gueltige Fidonet Policy
Dokument bis es abgeloest wird.
(Es gibt keine Unterschiede zwischen dieser Version und 4.06 ausser der
obenstehenden Aussage.)
1 Uebersicht
Dieses Dokument bildet die Politik (Policy) fuer SysOps, die Mitglieder der
Fidonet Organisation von Mailbox Systemen sind. Fidonet wird durch eine
Nodeliste definiert die woechentlich durch den Internationalen Koordinator
ausgegeben wird.
Gesonderte Policy Dokumente koennen auf Zonen-, Regional- oder Netzebene aus-
gegeben werden, um zusaetzliche Details ueber oertliche Handlungsweisen zu
liefern. Gewoehnlich duerfen diese Policies dieser Policy nicht wider-
sprechen. Wie auch immer, mit der Billigung des Internationalen Koordinators
kann eine oertliche Policy verwendet werden, um Unterschiede auszufuehren,
die auf Grund oertlicher Bedingungen noetig sind. Diese oertlichen Policies
duerfen Mitgliedern des Fidonet keine zusaetzlichen Einschraenkungen
jenseits der in diesem Dokument enthaltenen auferlegen, ausser der Durch-
setzung oertlicher Mail-Zeitraeume.
1.0 Sprache
Die offizielle Sprache des Fidonet ist Englisch. Alle Dokumente muessen
in Englisch existieren. Die Uebersetzung in andere Sprachen wird ermutigt.
1.1 Einfuehrung
Das Fidonet ist ein elektronisches Amateur Mitteilungs System. Als solches
sind alle seine Teilnehmer und Betreiber unbezahlte Freiwillige. Von seinem
fruehen Anfang, bei dem ein paar Freunde Mitteilungen hin und her austausch-
ten (1984), enthaelt es heute (1989) ueber 5.000 Systeme auf 6 Kontinenten.
[Anm.: Zur Zeit dieser Uebersetzung, Ende 1991, sind es ueber 11000 Systeme.]
Das Fidonet ist kein allgemeines Transportmedium oder ein gebuehrenbehaftetes
Servicenetzwerk, und ist nur insoweit ein oeffentliches Netzwerk, als die
unabhaengigen jeweiligen Nodes individuell oeffentlichen Zugang zum dem
Netzwerk auf ihrem System geben wollen.
Fidonet ist gross genug, dass es schnell durch sein eigenes Gewicht zerfallen
wuerde, wenn ihm nicht eine Art Struktur und Kontrolle auferlegt waere.
Multinetz-Betrieb liefert die Struktur. Dezentralisierte Leitung liefert
die Kontrolle. Dieses Dokument beschreibt die Vorgehensweisen, die ent-
wickelt wurden um das Netzwerk zu handhaben.
1.2 Organisation
FidoNet-Systeme sind auf mehreren Ebenen gruppiert, und die Verwaltung ist
dezentralisiert, um mit diesen Gruppierungen uebereinzustimmen. Diese
Uebersicht liefert eine Zusammenfassung der Struktur; spezielle Pflichten
der Koordinatorposten werden spaeter in diesem Dokument angegeben.
1.2.1 Individuelle Systeme und Systembetreiber
Die kleinste Unterteilung des FidoNet ist das einzelne System, dass einem
einzelnen Eintrag in der Nodelist entspricht. Der Systembetreiber (SysOp)
formuliert eine Policy, um die Box laufen zu lassen und um mit Usern um-
zugehen. Der SysOp muss mit dem Rest des Fidonetsystems hantieren, um
Mitteilungen zu versenden und zu empfangen, und die oertliche Policy muss
mit anderen Ebenen des FidoNet vereinbar sein.
1.2.1.1 Benutzer (User)
Der SysOp ist fuer die Handlungen jeglichen Users verantwortlich, falls
sie den Rest des Fidonet betreffen. (Wenn ein User belaestigend ist, so
ist der Sysop belaestigend). Von jedem Verkehr, der in das Fidonet durch
einen gegebenen Node eintritt, wird wenn er nicht vom Sysop ist angenommen,
dass er von einem User ist und der Sysop dafuer verantwortlich ist. (siehe
Abschnitt 2.1.3.)
1.2.1.2 Points
Ein Point ist ein FidoNet-kompatibles System, dass nicht in der Nodelist
steht, aber mit FidoNet ueber einen Node kommuniziert, der Bossnode genannt
wird. Ein Point wird im allgemeinen genauso behandelt wie ein User, zum
Beispiel ist der Bossnode fuer die Mail des Points verantwortlich. (siehe
Abschnitt 2.1.3.) Points werden adressiert, indem die Adresse des Bossnodes
in der Nodelist verwendet wird; zum Beispiel koennte ein Pointsystem mit
dem Bossnode 249/11 als 249/11.99 bekannt sein. Mail, die an den Point
gerichtet ist, wird an den Bossnode geschickt, der sie dann zu dem Point
weiterleitet.
Beim Unterstuetzen von Points macht der Bossnode von einer privaten
Net-Nummer Gebrauch, welche nicht allgemein ausserhalb der Bossnode-Point-
Beziehung sichtbar sein sollte. Ungluecklicherweise erscheint die private
Net-Nummer als die Adresse des Anrufers, sollte ein Point ein anderes System
direkt anrufen (um zum Beispiel einen Filerequest zu taetigen). In dieser
Hinsicht unterscheiden sich Points von Usern, da sie FidoNet-kompatible
Mailer betreiben, welche faehig sind auch mit anderen Systemen ausser dem
Bossnode Kontakt aufzunehmen.
1.2.3 Netzwerke [Networks] und Netzwerkkoordinatoren [NC's]
Ein Netzwerk ist ein Sammlung von Nodes in einem geografisch lokalen Gebiet,
dass gewoehnlich als ein Gebiet mit vorteilhaften Telefonkosten definiert ist.
Der Netzwerkkoordinator ist dafuer verantwortlich, die Liste der Nodes des
Netzwerkes zu unterhalten, und Netmails weiterzuleiten, die von anderen
FidoNet-Nodes an Mitglieder des Netzwerks geschickt wurden. Der Netzwerk
Koordinator kann Vereinbarungen treffen um ausgehende Netmail zu hand-
haben, ist aber nicht gefordert dies zu tun.
Der Netzwerkkoordinator wird vom Regional Koordinator ernannt.
1.2.3.1 Netzwerk Routing Hubs
Netzwerk Routing Hubs existieren nur in einigen Netzwerken. Sie koennen
durch den Netzwerkkoordinator ernannt werden, um bei der Verwaltung eines
grossen Netzwerks zu assistieren. Die genauen Pflichten und Handlungsweisen
zu vereinbaren ist Sache des Netzwerkkoordinators und der Hubs, und wird
hier nicht eroertert werden, ausser dass ein Netzwerkkoordinator keine Ver-
antwortung uebertragen kann, um Streitfragen zu schlichten.
1.2.4 Regionen und Regional Koordinatoren
Eine Region ist ein wohldefinierter geografischer Bereich, der Nodes ent-
haelt, die in Netzwerken vereinigt sein koennen oder auch nicht. Eine
typische Region wird viele Nodes in Netzwerken enthalten, und ein paar
unabhaengige Nodes, die nicht Teil irgendeines Netzwerkes sind.
Der Regional Koordinator unterhaelt die Liste der unabhaengigen Nodes in der
Region, und nimmt Nodelisten von den Netzwerkkoordinatoren der Region an.
Diese werden zusammengebunden, um eine regionale Nodeliste zu erzeugen, die
dann zu dem Zonenkoordinator geschickt wird. Ein Regional Koordinator fuehrt
keinen Mitteilungs-Befoerderungsservice [Message-Forwarding] fuer Nodes der
Region aus.
Regional Koordinatoren werden vom Zonenkoordinator ernannt.
1.2.5 Zonen und Zonenkoordinatoren
Eine Zone ist ein grosser geografischer Bereich der viele Regionen ent-
haelt, ein oder mehrere Laender und/oder Kontinente abdeckend.
Der Zonenkoordinator stellt die Nodelist aus allen Regionen der Zone
zusammen und erzeugt eine Master Nodelist und eine Differenz-Datei, welche
dann durch das Fidonet in der Zone verbreitet wird. Ein Zonenkoordinator
fuehrt keinen Mitteilungs-Befoerderungsservice fuer Nodes der Region aus.
Zonenkoordinatoren werden durch die Regional Koordinatoren der Zone
ausgewaehlt.
1.2.6 Zonen Koordinator Rat
In bestimmten Faellen fungieren die Zonen Koordinatoren als eine Versammlung,
um den International Coordinator beratend zu unterstuetzen. Diese Kon-
stellation ist aehnlich der zwischen einem Praesidenten und seinen Beratern.
Insbesondere beruecksichtigt dieses Gremium interzonale Angelegenheiten.
Dieses beinhaltet, ist aber nicht beschraenkt auf: Ausarbeitung der Details
der Nodelist Erstellung, Schlichtung interzonaler Streitfragen und solche
Angelegenheiten, die auf einer niedrigeren Ebene des FidoNet nicht
angesprochen werden.
1.2.7 Internationaler Koordinator
Der Internationale Koordinator ist der "Erste unter Gleichen" der Zonen-
Koordinatoren, und koordiniert die gemeinsame Erstellung der Master Nodelist
durch die Zonen Koordinatoren.
Der Internationale Koordinator ist als Vorsitz des Zonen Koordinator Rates
und Beaufsichtiger von Wahlen taetig -- er regelt die Bekanntmachung von
Abstimmungen, das Sammeln und Auszaehlen der Wahlstimmen und gibt die
Ergebnisse fuer solche Angelegenheiten bekannt, die FidoNet als Ganzes
betreffen.
Der Internationale Koordinator wird von den Zonen Koordinatoren ausgewaehlt.
1.2.8 Hierarchische Organisation [Top-Down, von-oben-nach-unten],
Kontrolle und Gleichgewicht.
Diese Ebenen dienen dazu, die Verwaltung und Kontrolle des FidoNet bis auf
die unterste moegliche Stufe aufzuteilen, und dennoch koordiniertes Handeln
im gesamten Mail-System zu erlauben. Die Verwaltung wird durch eine Top-Down
Vorgehensweise ermoeglicht. Das heisst, eine Person auf einer gegebenen Ebene
ist [gegenueber] der Ebene ueber sich verantwortlich, und fuer die Ebene unter
sich verantwortlich.
Zum Beispiel ist ein Regional Coordinator gegenueber seinem Zonen Koor-
dinator fuer alles verantwortlich, was in der Region geschieht. Aus der
Sicht des Zone Coordinator ist der Regional Coordinator vollstaendig ver-
antwortlich fuer den reibungslosen Betrieb der Region. Entsprechend ist
der Netzwerk Koordinator aus der Sicht des Regional Koordinators voll-
staendig fuer den reibungslosen Betrieb des Netzes verantwortlich.
Wenn eine Person auf irgendeiner Ebene oberhalb des Sysops nicht in
der Lage ist ihre Pflichten ordnungsgemaess auszuueben, kann sie
von der Person auf der naechsthoeheren Stufe ersetzt werden. Wenn zum
Beispiel der Regional Coordinator in der Wahrnehmung seiner Pflichten
versagt, kann der Zone Coordinator ihn ersetzen.
Um Kontrolle und Gleichgewicht auf der hoechsten Ebene des FidoNet zur
Verfuegung zu stellen, gibt es zwei Ausnahmen von dieser 'von-oben-nach-
unten' Organisation. Zonen Koordinatoren und der Internationale Koor-
dinator werden durch eine mehrheitliche Wahl von den Koordinatoren der
Ebene darunter ausgewaehlt. Gleichermassen koennen Entscheidungen des
Internationalen Koordinators durch den Zonen Koordinator Rat aufgehoben
werden, und Entscheidungen eines Zonen Koordinators koennen durch die
Regional Coordinators aufgehoben werden. Siehe Abschnitt 6 und 7 fuer
Einzelheiten. Entscheidungen anderer Koordinatoren unterliegen nicht
der Aufhebung durch eine Wahl auf der niedrigeren Ebene, sondern
unterliegen stattdessen dem Einspruchsverfahren, das in Abschnitt 9.5
beschrieben wird.
1.3 Definitionen
1.3.1 FidoNews
FidoNews ist ein woechentliches Rundschreiben, dass in elektronischer
Form ueberall im Netz verbreitet wird. Es ist ein wichtiges Medium durch
welches FidoNet Sysops miteinander kommunizieren. FidoNews schafft ein
Gefuehl dafuer, eine Gemeinschaft von Leuten mit gleichen Interessen zu
sein. Dementsprechend werden Sysops und User ermutigt, Beitraege zu
den FidoNews zu leisten. Beitraege werden Node 1:1/1 zugeleitet; eine
Datei mit der Beschreibung des zu verwendenden Formats ist von 1:1/1
und vielen anderen Systemen erhaeltlich.
1.3.2 Geografie
Jede Ebene des FidoNet ist geografisch in der Ebene unmittelbar darueber
enthalten. Ein gegebener geografischer Standort ist abgedeckt von EINER
Zone und EINER Region innerhalb dieser Zone und ist entweder in EINEM
Netzwerk oder nicht in einem Netzwerk. Es gibt niemals zwei Zonen, zwei
Regionen oder zwei Netze die den selben geografischen Bereich abdecken.
Wenn sich ein Node innerhalb des Gebiets eines Netzes befindet, sollte
er in diesem Netz gelistet sein, und nicht als ein unabhaengiger Node
in der Region. (Die hauptsaechliche Ausnahme hiervon ist ein Node,
der ungewoehnlich viel 'host-routed Mail' empfaengt; siehe Abschnitt 4.2).
Netzwerkgrenzen basieren auf Anrufbereichen, wie sie von den oertlichen
Telefongesellschaften definiert sind. Sogar im Fall von Gebieten, in denen
die Nodedichte so gross ist, dass mehr als ein Netz benoetigt wird um einen
Anrufbereich zu bedienen, wird eine geografische Richtlinie verwendet, um
zu entscheiden, welche Nodes zu welchem Netz gehoeren. Die Mitgliedschaft
in einem Netz basiert auf geografischen oder anderen rein technischen
Vernunftgruenden. Sie basiert nicht auf persoenlichen oder sozialen Faktoren.
Es gibt Faelle, in denen die oertlichen Anrufbereiche zu Situationen
fuehren, in denen es die Logik gebietet, dass ein Node der physisch in
der einen Region ist, einer anderen zugewiesen werden sollte. In solchen
Faellen koennen mit Zustimmung der beteiligten Regional Koordinatoren und
des Zonen Koordinators Ausnahmen gewaehrt werden. Solche Ausnahmen werden
in Abschnitt 5.6 beschrieben.
1.3.3 Zone Mail Hour [Zonen Mail Stunde]
Die Zone Mail Hour (ZMH) ist eine definierte Zeit, waehrend der alle Nodes
in einer Zone in der Lage sein muessen, Netmail entgegenzunehmen. Jede
FidoNet Zone definiert eine ZMH, und gibt die Zeit ihrer ZMH allen anderen
FidoNet Zonen bekannt. Siehe dazu Abschnitt 2.1.8 und 10.2.
Die Zone Mail Hour wurde zuvor als National Mail Hour und Network Mail Hour
bezeichnet. Die Bezeichnung Zone Mail Hour ist zutreffender.
1.3.4 Nodelist
Die Nodelist ist eine woechentlich aktualisierte Datei, die die Adressen
aller bekannten FidoNet Nodes enthaelt. Diese Datei wird derzeit bis
spaetestens zur Zone Mail Hour eines jeden Samstags durch den Zonen Koor-
dinator zur Verfuegung gestellt, und ist elektronisch per Download oder
Filerequest gebuehrenfrei erhaeltlich. Um in der Nodelist eingetragen zu
sein, muss ein System die in diesem Dokument festgelegten Anforderungen
erfuellen. Andere Anforderungen duerfen nicht auferlegt werden.
Teillisten der Nodelist (z.B. fuer eine einzige Zone) koennen auf
verschiedenen FidoNet-Ebenen zur Verfuegung gestellt werden. Die gesamte
Liste, wie sie vom Internationalen Koordinator veroeffentlicht wird, gilt
als die offizielle FidoNet Nodelist, und wird unter solchen Umstaenden wie
der Feststellung einer Wahlberechtigung benutzt. Alle Teile, die die gesamte
Nodelist ausmachen, sind auf den Systemen aller Zonen Koordinatoren und
Regional Koordinatoren erhaeltlich.
1.3.5 Uebermaessig veraergerndes Verhalten [Excessively Annoying Behavior]
Es gibt die ganze Policy hindurch Hinweise auf "uebermaessig veraergerndes
Verhalten", insbesondere in Absatz 9 (Loesung von Streitigkeiten). Es ist
schwierig, diesen Ausdruck zu definieren, da er auf der Beurteilung der
Koordinator Struktur beruht. Allgemein gesprochen; veraergerndes Verhalten
reizt, belaestigt, oder fuegt einer andere Person Schaden zu. Es ist nicht
notwendig ein Gesetz zu uebertreten, um "veraergernd" zu sein.
Es gibt eine Unterscheidung zwischen "uebermaessig veraergerndem Verhalten"
und (einfach) "veraergerndem Verhalten". Beispielsweise gibt es eine Lern-
kurve die jeder neue Sysop hinaufsteigen muss, sowohl in den technischen
Angelegenheiten hinsichtlich der Einrichtung der Software, als auch in den
sozialen Angelegenheiten hinsichtlich der Interaktion mit dem FidoNet. Es
gibt selten einen Sysop, der es nicht an irgendeinem Punkt auf dieser Reise
fertig bringt, andere zu veraergern. Nur wenn solches Verhalten hartnaeckig
anhaelt nachdem der Sysop darauf hingewiesen wurde, wird es uebermaessig
veraergernd. Das impliziert nicht, dass es unmoeglich ist, ohne Wiederholung
uebermaessig veraergernd zu sein (z.B. waere die vorsaetzliche Faelschung
von Mitteilungen wahrscheinlich auch beim ersten Mal uebermaessig ver-
aergernd), sondern veranschaulicht lediglich, dass sich ein gewisses Mass
an Toleranz erstreckt.
Siehe Abschnitt 9 und die Fallstudien (Abschnitt 10.3) fuer mehr
Informationen.
1.3.6 Kommerzielle Nutzung
FidoNet ist ein Amateur Netzwerk. Die Teilnehmer investieren ihre eigene
Zeit und ihr eigenes Geld, um es zum Nutzen aller User gut funktionieren zu
lassen. Es ist nicht anstaendig von kommerziellen Unternehmen, Vorteil aus
diesen freiwilligen Bemuehungen ziehen, um ihre eigenen Geschaeftsinteressen
zu foerdern. Andererseits bietet das FidoNet ein bequemes und leistungs-
faehiges Mittel fuer den Informationsaustausch zwischen Firmen und Usern,
zum gegenseitigen Nutzen.
Netzwerk Koordinatoren koennten gedraengt werden kommerzielle Unter-
nehmungen durch die Weiterleitung von 'Host-routed Netmail' zu subven-
tionieren, und koennten sich selbst sogar in einem Gerichtsprozess verwickelt
finden, wenn irgendwelche Garantien fuer Mail Auslieferung angedeuted wurde.
"Kommerzielle Mail" schliesst Mail ein, die spezielle Geschaeftsinteressen
foerdert ohne dem Netz als Ganzem zu nuetzen. Beispiele beinhalten firmen-
interne Mail, konzerninterne Mail, spezielle Produktanfragen (z.B. Preis-
angaben), Bestellungen und ihre Folgekorrespondenz sowie alle anderen Themen,
die speziell mit Geschaeftlichem zusammenhaengen.
2 Sysop Verfahrensweisen
2.1 Allgemein
2.1.1 Die Grundlagen
Als Sysop eines einzelnen Nodes kannst Du im allgemeinen tun was Dir
gefaellt, so lange Du die Mail Events einhaelst, andere Nodes in FidoNet
nicht uebermaessig belaestigst und nicht die Verbreitung raubkopierter
Copyright-Software oder anderes ungesetzliches Verhalten ueber das FidoNet
foerderst oder daran teilnimmst.
2.1.2 Vertrautheit mit der Policy
Um die Bedeutung von "uebermaessig belaestigend" zu verstehen obliegt es
allen Sysops, gelegentlich die FidoNet Policy nochmals zu lesen. Neue Sysops
muessen sich mit der Policy vertraut machen, bevor sie eine Nodenummer
anfordern.
2.1.3 Verantwortlichkeit fuer den gesamten Verkehr,
der ueber den Node in das FidoNet eintritt
Der Sysop, der im Nodelist-Eintrag aufgefuehrt ist, ist fuer den
gesamten Verkehr der ueber diesen Node in das FidoNet eintritt verant-
wortlich. Dies beinhaltet (ist aber nicht beschraenkt auf) Verkehr,
der von Usern, Points oder jeglichen anderen Netzwerken fuer welche der
Node als Gateway dienen mag, eingespeist wird. Wenn ein Sysop erlaubt,
"auswaertige" Mitteilungen durch das System in das FidoNet einzuspeisen,
muss das Gateway-System klar und deutlich mittels FidoNet Nodenummer als
Ursprungsort dieser Mitteilung identifiziert sein, und es muss als Gateway
in die umgekehrte Richtung dienen. Sollte aus derartigem Verkehr eine
Verletzung der Policy resultieren, muss der Sysop die Situation korrigieren.
2.1.4 Verschluesselung und Ueberpruefung von Mail
FidoNet ist ein Amateur-System. Unsere Technologie ist derart, dass die
Vertraulichkeit von Mitteilungen nicht garantiert werden kann. Als Sysop
hast Du das Recht, Mail-Verkehr, der durch Dein System fliesst, zu ueber-
pruefen, und sei es aus keinem anderen Grund als sicherzustellen, dass
das System nicht fuer illegale oder kommerzielle Zwecke benutzt wird.
Verschluesselung macht diese Nachpruefung offensichtlich unmoeglich.
Deswegen stellt verschluesselter und/oder kommerzieller Verkehr der ohne
die ausdrueckliche Erlaubnis aller Verbindungen im Zustellsystem geroutet
wird, belaestigendes Verhalten dar [annoying behaviour]. Siehe Abschnitt
1.3.6 fuer eine Definition kommerziellen Verkehrs.
2.1.5 Keine Veraenderung von weitergeleiteter [routed] Mail
Du darfst nicht, ausser soweit fuer Routing oder andere technische Zwecke
erforderlich, Mitteilungen, Netmail oder Echomail, veraendern, die durch
das System von einem FidoNet Node zu einem anderen weitergereicht werden.
Wenn Du durch den Inhalt einer Mitteilung beleidigt wirst, muss die
in Abschnitt 2.1.7 beschriebene Verfahrensweise verwendet werden.
2.1.6 Private Netmail
Das Wort "Privat" sollte mit grosser Vorsicht benutzt werden, vor allem
bei Usern einer Mailbox. Manche Laender haben Gesetze die "private Post"
behandeln, und es sollte klar gemacht werden, dass das Wort "privat" nicht
andeutet, dass keine andere Person ausser dem Empfaenger die Mail lesen
kann. Sysops, die diese Unterscheidung nicht treffen koennen, sollten in
Betracht ziehen, Usern die Option "private Mail" nicht zur Verfuegung zu
stellen.
Wenn ein User eine "Private Mitteilung" abschickt, hat der User keine
Kontrolle ueber die Anzahl der vermittelnden Systeme, durch die diese Mail
weitergeleitet wird. Ein Sysop, der einem anderen Sysop eine Mitteilung
schickt, kann diesen Aspekt dadurch kontrollieren, dass er die Mail direkt
an das System des Empfaengers sendet, wodurch garantiert ist, dass nur der
Empfaenger oder eine andere Einzelperson der dieser Sysop Befugnis erteilt
hat die Mitteilung lesen kann. Daher darf ein Sysop andere Erwartungen als
ein Gelegenheits-User haben.
2.1.6.1 Keine Enthuellung von Durchgangs-Mail [In-Transit Mail]
Die Enthuellung oder jegliche Benutzung von Informationen, die in privaten,
nicht an dich adressierten und nicht von Dir geschriebenen Netmails
enthalten sind, wird als veraergerndes Verhalten betrachtet, es sei denn
dieser Verkehr ist von dem Autor oder dem Empfaenger als Teil einer
formellen Policy-Beschwerde herausgegeben worden. Dies trifft nicht auf
Echomail zu, die per Definition ein Verbreitungs-Medium ist, und bei der
private Mail haeufig benutzt wird um eine Sysop-Only Area abgeschraenkt
zu halten.
2.1.6.2 Private Mail, die an Dich adressiert ist
Die Angelegenheit privater Mail die an Dich adressiert ist, ist schwieriger
als die "In-Transit"-Frage die im letzten Abschnitt behandelt wurde. Eine
verbreitete rechtliche Ansicht behauptet, dass wenn Du eine Mitteilung er-
haelst, diese zu Deinem Eigentum wird, und Du ein legales Recht darauf
hast, damit zu tun was Du willst. Dein legales Recht entschuldigt Dich
nicht davon, andere zu veraergern.
Im allgemeinen sollte sensibles Material nicht mittels FidoNet versendet
werden. Dieses Ideal wird haeufig auf's Spiel gesetzt, da FidoNet unsere
primaere Kommunikationsart ist. Im allgemeinen gilt, wenn der Absender einer
Mitteilung ausdruecklich im Text darum ersucht, dass der Inhalt vertraulich
gehalten werden soll, kann das Freigeben der Mitteilung in ein oeffentliches
Forum als veraergernd betrachtet werden.
Es gibt Ausnahmen. Wenn jemand eine Sache in der Oeffentlichkeit und das
Gegenteil in privater Mail sagt, sollte der Empfaenger der privaten Mail
keinen Schikanen ausgesetzt sein, bloss weil der Absender wuenscht, dass
die Mitteilung nicht veroeffentlicht wird. Urteilsvermoegen und gesunder
Menschenverstand sollten auf diesem Gebiet, wie in allen anderen Aspekten
von FidoNet, angewandt werden.
2.1.7 Nicht-Weiterleiten von Mail
Du musst nicht Verkehr weiterleiten, wenn Du nicht zugestimmt hast dies
zu tun. Du bist nicht verpflichtet Verkehr fuer alle weiterzuleiten wenn
Du ihn fuer Einige weiterleitest, ausser Du bekleidest eine Netzwerk
Koordinator oder Hub Koordinator Position. Das Routen von Verkehr ueber
einen Node, der nicht zum Routen verpflichtet ist, ohne die Erlaubnis
dieses Nodes kann veraergerndes Verhalten sein. Dies schliesst unauf-
gefordert zugesandte Echomail ein.
Falls Du eine Mitteilung nicht befoerderst, wenn Du dich vorher dazu bereit
erklaert hattest derlei Weiterleitung auszufuehren, muss die Mitteilung
an den Sysop des Nodes wo sie in's FidoNet eingetreten ist zurueckgeschickt
werden, mit einer Erklaerung warum sie nicht weitergeleitet wurde. (Es ist
nicht noetig Mitteilungen zurueckzuschicken, die an einen Node adressiert
sind, der nicht in der aktuellen Nodelist steht.) Absichtliches Stoppen
einer "In-Transit" Mitteilung ohne dieser Vorgehensweise zu folgen stellt
veraergerndes Verhalten dar. Im Falle des Versagens beim Weiterleiten
von Verkehr aufgrund technischer Probleme wird es nicht veraergernd, es
sei denn es bleibt bestehen, nachdem der Sysop darauf hingewiesen wurde.
2.1.8 Ausschliesslichkeit der Zone Mail Stunde
Die ZMH ist das Herz des FidoNet, da dann Netmail zwischen den Systemen
weitergegeben wird. Jedes System dass Teil von FidoNet zu sein wuenscht,
muss waehrend dieser Zeit in der Lage sein Mail zu empfangen, mittels des
in den aktuellen FidoNet Technical Standards Comittee Veroeffentlichungen
definierten Protokolles (FTS-0001 z.Zt. dieser Niederschrift). Es ist
zulaessig weiterreichende Faehigkeiten zu haben (zum Beispiel zusaetzliche
Protokolle zu unterstuetzen oder erweiterte Mail-Stunden), aber die
minimale Anforderung ist FTS-0001 Faehigkeit waehrend dieser einen Stunde
des Tages.
Diese Zeit ist ausschliesslich fuer Netmail reserviert. Viele Telefon-
systeme rechnen auf einer Pro-Anruf Basis ab, gleichgueltig ob Verbindung,
keine Verbindung, oder Besetztsignal auftritt. Aus diesem Grund wird jede
andere Aktivitaet ausser normaler Netmail Bearbeitung, die ein System
waehrend der ZMH aufhaelt, als veraergerndes Verhalten betrachtet. Echomail
sollte nicht waehrend der ZMH uebertragen werden. User (BBS) Zugriff auf
ein System ist waehrend der ZMH verboten.
Ein System welches ein Mitglied eines oertlichen Netzwerks ist kann auch
erfordert werden zusaetzliche Mail Ereignisse einzuhalten, so wie vom
Netzwerk Koordinator definiert. Zugriffsbeschraenkungen waehrend oertlicher
Netzwerk Perioden sind dem Ermessen des Netzwerk Koordinators ueberlassen.
2.1.9 Private Nodes
Die seltene Ausnahme zur Einhaltung der ZMH sind private Nodes.
Personen die private Nodes beantragen sollten falls moeglich als Points
unterstuetzt werden. Ein privater Eintrag ist gerechtfertigt, wenn das
System mit vielen anderen Verbindung haben muss, so wie ein Echomail
Verteiler. In diesen Faellen wird die genaue Art und Weise und das Timing
des Mail-Ablieferns zwischen dem privaten Node und den anderen Systemen
vereinbart. Eine solche Vereinbarung zwischen einem privaten System und
einem Hub sind bei jeglichem Austausch dieses Hubs nicht bindend. Ein
privater Node muss Teil eines Netzwerkes sein (sie koennen keine unab-
haengigen Nodes [Independents] in der Region sein.)
Private Eintraege belasten jedes Mitglied des FidoNet, da sie Platz in
jedermanns Nodelist beanspruchen. Private Eintraege die der Bequemlichkeit
eines einzelnen Sysops dienen (auf Kosten jedes anderen Sysops im FidoNet)
sind ein Luxus, der nicht laenger moeglich ist. Unwesentliche, redundante
Eintraege (mehr als ein Eintrag fuer die selbe Telefonnummer, ausgenommen
wie durch FTSC Standards bevollmaechtigt) fallen ebenfalls in diese Kategorie.
Sysops die private oder redundante Eintraege beantragen, muessen diese mit
einer Erlaeuterung rechtfertigen, wie diese dem lokalen Netz oder dem gesamten
FidoNet nuetzen. Der Netzwerk Koordinator oder Regional Koordinator kann
diese Erklaerung jederzeit ueberpruefen, und Eintraege die nicht gerecht-
fertigt sind werden entfernt.
2.1.10 Beachtung der Mail Ereignisse
Die Unterlassung der Beachtung der richtigen Mail Ereignisse ist bei
jedem Node ein Grund, um ohne Mitteilung aus der Nodelist entfernt zu
werden (da solche Mitteilungen im allgemeinen mittels Netmail gemacht
werden).
2.1.11 Benutzung der aktuellen Nodelist
Netzwerk Mail Systeme arbeiten im allgemeinen unbeaufsichtigt und
plazieren Anrufe zu merkwuerdigen Stunden in der Nacht. Wenn ein System
versucht eine unkorrekte oder veraltete Nummer anzurufen, koennte es das
Telefon eines armen Buergers in den fruehen Morgenstunden klingeln lassen,
sehr zur Veraergerung unschuldiger Unbeteiligter und ziviler Amtsgewalt.
Aus diesem Grund ist ein Sysop der Mail sendet verpflichtet, die juengste
Ausgabe der Nodelist zu beschaffen und benutzen soweit praktikabel.
2.1.12 Exkommunikation
Ein System dass aus dem Netzwerk entfernt wurde wird als exkommuniziert
bezeichnet (d.h. die Kommunikation wird ihm verweigert). Wenn Du fest-
stellst, dass Du ohne Warnung exkommuniziert wurdest, war Dein Koordinator
nicht imstande Kontakt zu Dir aufzunehmen. Du solltest das Problem
korrigieren und Kontakt zu Deinem Koordinator aufnehmen.
Systeme koennen auch wegen eines [bestimmten] Grundes aus der Nodelist
entfernt werden. Siehe Abschnitt 9 und Abschnitt 4.3 und 5.2.
Es wird als veraergerndes Verhalten betrachtet, einem System, welches
exkommuniziert wurde, in Umgehung der Entfernung aus der Nodelist zu
assistieren. Wenn Du dich zum Beispiel entscheidest, Deinem Freund, der
exkommuniziert wurde, eine Echomail Versorgung bereit zu stellen, ist es
wahrscheinlich, dass Dein Eintrag ebenfalls entfernt werden wird.
2.1.13 Timing der Zone Mail Hour
Das genaue Timing der Zone Mail Hour fuer jede Zone wird vom Zonen
Koordinator festgesetzt. Siehe Abschnitt 10.2.
2.1.14 Nicht-Einhaltung der Sommerzeit [daylight savings time]
FidoNet beachtet nicht die Sommerzeit. In Gebieten welche die Sommerzeit
einhalten muessen die FidoNet Mail Zeitplaene in der selben Richtung in
der sich die Zeit aendert angepasst werden. Alternativ kannst Du auch
einfach Dein System auf Standard-Zeit belassen.
2.2 Wie man eine Nodenummer erhaelt
Du musst zuerst eine aktuelle Nodelist beschaffen, so dass Du Mail senden
kannst. Du benoetigst keine Nodenummer um Mail zu senden, aber Du musst
eine haben damit andere Dir Mail senden koennen.
Der erste Schritt um eine aktuelle Nodelist zu erhalten ist eine Fidonet
Mailbox ausfindig zu machen. Die meisten Mailbox Listen enthalten wenigstens
ein paar Fidonet Systeme und geben diese gewoehnlich als solche zu erkennen.
Benutze eine oertliche Quelle um Dokumente zu erhalten, weil viele Netzwerke
detaillierte Informationen verfuegbar haben, welche das von dem Netzwerk
abgedeckte Gebiet und jegliche speziellen Erfordernisse oder Verfahrens-
weisen erklaeren.
Wenn Du einmal eine Nodelist hast, musst Du feststellen welche Netzwerke
oder Regionen Dein Gebiet abdecken. Regionen sind von 1 bis 99 nummeriert;
Netzwerknummern sind groesser als 99. Netzwerke sind eingeschraenkter im
Gebiet als Regionen, aber sind bevorzugt, da sie den Fluss der Mail ver-
bessern und mehr Dienste fuer ihre Mitglieder bereit stellen. Wenn Du
kein Netzwerk finden kannst welches Dein Gebiet abdeckt, dann kannst Du
die Region nehmen die es tut.
Wenn Du einmal das Netzwerk oder die Region in Deinem Gebiet lokalisiert
hast, sende eine Mitteilung, die einen Antrag fuer eine Nodenummer ent-
haelt, an Node Null dieses Netzwerks oder dieser Region. Der Antrag muss
durch Netmail gesendet werden, da dies zu erkennen gibt, dass Dein System
FidoNet Faehigkeiten hat.
Du musst Deine Software so konfigurieren, dass die Absender-Adresse in
Deiner Mitteilung dem Koordinator der sie empfaengt keine Probleme
bereitet. Wenn Du die Adresse eines existierenden Systems benutzt,
wird dies offensichtlich Probleme verursachen. Wenn Deine Software
faehig ist, die Adresse -1/-1 zu benutzen, ist dies die traditionelle
Adresse die von potentiellen Sysops benutzt wird. Andernfalls benutze
Net/9999 (i.A. wenn Du den Antrag an Netz 123 stellst, konfiguriere Dein
System als 123/9999). Viele Netze haben spezielle Anweisungen fuer
potentielle Sysops verfuegbar, und diese Handlungsweisen koennen Bevor-
zugungen fuer die Absender-Adresse andeuten.
Die Mitteilung die Du sendest muss wenigstens folgende Informationen
enthalten:
1) Dein Name
2) Deine Telefon Nummer (fuer muendliche Gespraeche [Voice])
3) Der Name Deines Systems
4) Die Stadt und der Staat wo Dein System zuhause ist
5) Die Telefon Nummer die benutzt werden soll um Dein System anzurufen
6) Die Betriebs-Stunden, Netmail und Mailbox
7) Die maximale Baudrate die Du unterstuetzen kannst
8) Der Typ des Mailers und des Modems die Du benutzt
Dein Koordinator kann sich mit Dir wegen zusaetzlicher Information in Ver-
bindung setzen. Alle uebermittelten Informationen werden vertraulich
gehalten und werden niemandem zur Verfuegung gestellt, ausgenommen der
Person, die den Koordinator Posten bei der Amtsniederlegung der aktuellen
Koordinators uebernimmt.
Du musst zu erkennen geben, dass Du dieses Dokument und alle aktuellen
Policies des FidoNet gelesen hast, und zustimmst sie einzuhalten.
Bitte gestatte wenigstens zwei Wochen, um einen Node Nummer Antrag zu
bearbeiten. Wenn Du Deinen Antrag einem Regional Koordinator zugesendet
hast, kann er zu dem entsprechenden Netzwerk Koordinator weitergeleitet
worden sein.
2.3 Wenn Du 'Down' gehst
Wenn Dein Node fuer laengere Zeit (mehr als ein oder zwei Tage) 'Down'
[nicht verfuegbar] sein wird, informiere sobald wie moeglich Deinen
Koordinator. Es ist nicht die Verantwortlichkeit Deines Koordinators,
Dir fuer Status Reports hinterher zu laufen, und wenn Dein System
aufhoert Mail zu akzeptieren, wird es aus der Nodelist entfernt.
Schliesse niemals einen Anrufbeantworter oder irgendein anderes Geraet
welches das Telefon abhebt an Deine Telefonleitung an, waehrend du
'down' bist. Wenn Du es tust, erhalten anrufende Systeme immer wieder
die Maschine, wobei sie hohe Telefonrechnungen aufstellen, was sehr
aergerlich ist. Kurz gesagt, das Einzige was waehrend Perioden, in denen
die Nodelist anzeigt dass Dein Node Mail akzeptieren wird, jemals das
Telefon beantworten sollte, ist FidoNet-kompatible Software die Mail
akzeptiert.
Wenn Du Dein System fuer eine ausgedehnte Periode unueberwacht laesst
(so wie wenn Du in Urlaub bist), solltest Du Deinen Koordinator benach-
richtigen. Die Systeme haben eine Tendenz dann und wann "abzustuerzen",
so dass Du moeglicherweise Deinen Koordinator wissen lassen willst, dass
dies eine voruebergehende Bedingung ist, wenn es passiert waehrend Du
abwesend bist.
2.4 Wie man ein Netzwerk bildet
Wenn es diverse Nodes in Deinem Gebiet gibt, aber kein Netzwerk, kann ein
neues Netzwerk gebildet werden. Dies hat Vorteile fuer beide Seiten; Dich
und den Rest von Fidonet. Du erhaelst bessere Verfuegbarkeit von Nodelist
Differenz Dateien und FidoNews, und jedermann sonst kann Vorteile daraus
ziehen, Netmail zu dem neuen Netzwerk ueber den Host zu leiten [Host-
Routing].
Der erste Schritt ist, Kontakt mit den anderen Sysops in dem Gebiet aufzu-
nehmen. Du musst entscheiden, welche Nodes das Netzwerk umfassen soll,
und wen von diesen Nodes Du als Netzwerk Koordinator haben willst. Dann
konsultiere Deinen Regional Coordinator. Du musst folgende Informationen
absenden:
1) Die Region Nummer(n), oder Netzwerk Nummer(n) wenn ein Netzwerk
aufgeteilt wird, die von der Entstehung des neuen Netzwerks betroffen
sind. Der Regional Koordinator wird den Zonen Koordinator und die
Koordinatoren jeglicher betroffener Netzwerke informieren, dass ein
neues Netzwerk am Entstehen ist.
2) Eine Kopie des Nodelist-Segments von dem vorgeschlagenen Netzwerk.
Diese Datei sollte an die Mitteilung der Bewerbung um eine Netzwerk-
Nummer angehaengt werden [Attach], und sollte das Nodelist Format, dass
in der aktuellen Version der entsprechenden FTSC Veroeffentlichung
beschrieben ist, verwenden. Bitte waehle einen Namen der zu Deiner
Gruppe in Zusammenhang steht, zum Beispiel SoCalNet fuer Nodes im
South California Gebiet und MassNet West fuer das Western Massachusetts
Gebiet. Fuehre Dir in Erinnerung, dass wenn ihr euch DOGNET nennt, es
nicht euer Gebiet identifiziert.
Die Bewilligung einer Netzwerk Nummer geschieht nicht automatisch. Selbst
wenn der Antrag gewaehrt wird, mag das Netzwerk nicht genau so strukturiert
sein, wie Du angefordert hast. Dein Regional Koordinator wird Deine Be-
werbung ueberpruefen und Dich von der Entscheidung informieren.
Sende keinen Netzwerk Nummer Antrag an den Zonen Koordinator. Alle Netzwerk
Nummer Antraege muessen vom Regional Koordinator bearbeitet werden.
3 Allgemeine Handlungsweisen fuer alle Koordinatoren
3.1. Mache Differenzdateien [NodeDiffs] und FidoNews verfuegbar
Jeder Koordinator ist verantwortlich fuer die Beschaffung und das
verfuegbar machen der Nodelist Differenz Dateien und der FidoNews
auf einer woechentlichen Basis.
3.2. Bearbeiten von Nodelistaenderungen und ihre Weitergabe stromaufwaerts.
Jeder Koordinator ist dafuer verantwortlich, Nodelist Informationen von
der Ebene darunter zu erhalten, sie zu bearbeiten, und die Ergebnisse an
die naechsthoehere Ebene weiterzugeben. Das Timing dieses Vorgangs wird
durch die Erfordernisse des jeweils hoeheren Levels bestimmt.
3.3. Stelle sicher, dass die letzte Policy verfuegbar ist.
Ein Koordinator ist dafuer verantwortlich, die aktuelle Version dieses
Dokuments der Ebene darunter verfuegbar zu machen, und die Vertrautheit
damit zu foerdern.
Ausserdem wird von einem Koordinator verlangt, jegliche eingegangenen
oertlichen Policies zu der Ebene darueber weiterzuleiten, und solche
Policies zu ueberpruefen. Obwohl nicht unbedingt erforderlich, gebietet
es die allgemeine Hoeflichkeit, dass wenn eine oertliche Policy formuliert
wird, die Beteiligung der Ebene darueber erbeten werden sollte.
3.4. Minimiere die Anzahl der Huete die Du traegst [Aemter die Du hast]
Koordinatoren werden ermutigt, die Anzahl der FidoNet-Funktionen die
sie ausfuehren zu begrenzen. Ein Koordinator, der zwei verschiedene
Positionen inne hat, gefaehrdet das Berufungs Verfahren. Wenn zum Beispiel
der Netzwerk Koordinator auch noch der Regional Koordinator ist, wird den
SysOps in diesem Netzwerk eine Ebene der Anrufung verweigert.
Koordinatoren wird abgeraten, als Echomail- und Software-Verteilungs-Hubs
taetig zu sein. Wenn sie es tun, sollten sie die Echomail (oder andere
voluminoese Verteilung) auf einem anderen als dem administrativen System
handhaben. Ein Koordinator-System sollte bereitwillig den Ebenen unmittelbar
darueber und darunter zur Verfuegung stehen.
Ein weiterer Grund von mehrfachen Aemter abzuraten ist die Schwierigkeit,
die Serviceleistungen zu ersetzen, wenn jemand das Netzwerk verlaesst.
Wenn zum Beispiel ein Koordinator der Echomail-Hub und der Software-
Verteilungs-Hub ist, werden diese Dienste schwierig wiederherzustellen
sein wenn diese Person zuruecktritt.
3.5. Sei ein Mitglied des verwalteten Gebiets
Ein Koordinator muss ein Mitglied des verwalteten Gebiets sein. Das heisst,
ein Netzwerk Koordinator muss aufgrund geografischer Gegebenheiten ein
Mitglied in diesem Netzwerk sein. Ein Regional Koordinator muss entweder
ein Mitglied eines Netzwerks in der Region, oder ein 'independend'
[Netzwerk-unabhaengiger Node] in dieser Region sein.
3.6. Ermutige neue SysOps in FidoNet einzutreten
Ein Koordinator wird ermutigt, eine oeffentliche Mailbox zu betreiben,
welche fuer den Zweck der Austeilung von Policy, FidoNews und Nodelist
an potentielle neue Sysops frei zugaenglich ist. Die Verbreitung dieser
Information an Personen die potentielle FidoNet SysOps sind ist wichtig
fuer das Wachstum von FidoNet, und Koordinatoren sollten die Entwicklung
neuer Systemen foerdern.
3.7. Tradition und Praezedenz
Ein Koordinator ist nicht ueber den Rahmen dieses Dokuments hinaus durch
die Praktiken seines Vorgaengers oder Gleichrangiger gebunden.
Darueberhinaus hat ein Koordinator das Recht, jegliche Entscheidung, die
von Vorgaengern getroffen wurde, auf ihre Vertraeglichkeit mit der Policy
zu ueberpruefen, und was auch immer an Aktionen notwendig sein mag zu
unternehmen, um jegliche Situationen zu korrigieren die nicht in Ueber-
einstimmung sind.
3.8. Technisches Management
Die hauptsaechliche Verantwortlichkeit jedes Koordinators ist technisches
Management von Netzwerk Operationen. Entscheidungen muessen auf technischen
Gruenden beruhen.
4. Handlungsweisen fuer Netzwerk Koordinatoren
4.1 Verantwortlichkeiten
Ein Netzwerk Koordinator hat die folgenden Verantwortlichkeiten:
1) Eingehende Mail fuer Nodes in dem Network entgegen zu nehmen
und deren Auslieferung an die Empfaenger zu arrangieren.
2) Den Nodes in dem Netzwerk Nodenummern zuzuweisen.
3) Eine Nodelist fuer das Netzwerk zu pflegen und eine Kopie davon
an den Regional Koordinator zu schicken wann immer sie sich
aendert.
4) Nodes im Netzwerk neue Nodelist Differenz-Dateien [NodeDiff's],
neue Ausgaben der FidoNews und neue Revisionen von Netzwerk Policy
Dokumenten so wie sie empfangen werden zur Verfuegung zu stellen,
und periodisch zu ueberpruefen, dass sichergestellt ist, dass die
Nodes aktuelle Nodelisten benutzen.
4.2. Weiterleiten eingehender Mail [Routing Inbound Mail]
Es liegt in Deiner Verantwortlichkeit als Netzwerk Koordinator, den
Empfang und das Weiterleiten von ueber den Host geleiteter, eingehender
Netmail fuer Nodes in Deinem Netzwerk zu koordinieren. Der beste Weg
um dieses zu bewerkstelligen bleibt Deinem Ermessen ueberlassen.
Wenn ein Node in Deinem Netzwerk grosse Mengen an Mail erhaelt, kannst Du
darum ersuchen, dass der Sysop sich mit den Systemen welche diese Mail
verschicken in Verbindung setzt, und anfordert dass diese Mails nicht
mehr ueber den Host geleitet werden. Wenn das Problem hartnaeckig bestehen
bleibt, kannst Du Deinen Regional Koordinator ersuchen, diesem Node eine
Nummer als "Unabhaengigem" zu erteilen, und das System aus Deinem Netzwerk
zu entfernen.
Gelegentlich wird ein Node eine "Msg-Bombardierung" laufen lassen (eine
Mitteilung an eine grosse Anzahl Nodes schicken [bombing run]). Wenn ein
Node in einem anderen Netzwerk "Msg-Bombardierungen" an Deine Nodes macht
und diese durch Deinen Inbound Host leitet, dann kannst Du dich bei dem
Netzwerk Koordinator des missetaetigen Nodes beschweren. (Wenn der Node
ein "Unabhaengiger" ist, beschwere dich bei dem Regional Koordiantor).
"Msg-Bombardierungen" werden als belaestigend betrachtet.
Ein weiterer Grund fuer Routing Ueberlastung ist Echomail. Es kann nicht
zugelassen werden, dass Echomail die Faehigkeiten von FidoNet reduziert,
normalen Mitteilungs-Verkehr zu handhaben. Wenn ein Node in Deinem Netzwerk
grosse Mengen Echomail routet, kannst Du den Sysop ersuchen, entweder die
Menge der Echomail zu beschraenken, oder das Routing von Echomail einzu-
stellen.
Es wird nicht von Dir verlangt, verschluesselte, kommerzielle oder
illegale Mail zu befoerdern. Wie auch immer, Du musst den Handlungsweisen
die in Abschnitt 2.1.7 beschrieben sind folgen, wenn Du die Mail nicht be-
foerderst.
4.3 Zuweisen von Node Nummern
Es liegt in Deiner Verantwortung, neuen Nodes in Deinem Netzwerk Node-
nummern zuzuweisen. Du kannst auch Nummern von existierenden Nodes in
Deinem Netzwerk aendern, solltest dies jedoch mit Deinen Mitglieder
Nodes ueberpruefen, bevor Du es tust. Du kannst jegliche Nummern zuweisen
wie Du wuenschst, solange jeder Node innerhalb Deines Netzwerks eine
einzigartige Nummer hat.
Du darfst jeglichem System nicht eine Nodenummer zuweisen, bevor Du einen
formellen Antrag von dem System ueber FidoNet Mail erhalten hast. Das wird
sicherstellen, dass dieses System minimal betriebsbereit ist. Die strikte
Aufrechterhaltung dieses Grundsatzes ist eine der grossen Staerken von
FidoNet gewesen.
Es wird auch empfohlen, obwohl nicht erforderlich, dass Du ein System
welches sich um eine Nodenummer bewirbt anrufst, bevor ihm eine Nodenummer
zugewiesen wird.
Du darfst nicht einem Node in einem Gebiet, dass von einem existierenden
Netzwerk abgedeckt wird, eine Nodenummer zuweisen. Ferner, wenn Du Nodes
in einem Gebiet hast, dass von einem entstehenden Netzwerk abgedeckt wird,
muessen diese Nodes in das neue Netzwerk transferiert werden.
Du solltest Netzwerk Mail [Netmail] benutzen um einen neuen Sysop von der
Nodenummer zu informieren, da dies sicherzustellen hilft, dass das System
faehig ist Netmail zu empfangen.
Wenn ein Node in Deinem Netzwerk sich in ausreichend belaestigender Weise
verhaelt, dann kannst Du jegliche Aktion vornehmen die Du fuer passend
erachtest, entsprechend den Umstaenden des Falles.
4.4 Instandhaltung der Nodelist
Du solltest Namensaenderungen, Telefonnummeraenderungen und so weiter so
bald wie moeglich nachdem die Information erhalten wurde in Deinem Segment
der Nodelist durchfuehren. Du solltest auch gelegentlich an jeden Node
in Deinem Netzwerk eine Mitteilung senden, um sicherzustellen, dass sie
betriebsfaehig sind. Wenn sich herausstellt, dass ein Node ohne vorherige
Warnung nicht mehr 'online' ist, kannst Du den Node entweder als 'Down'
markieren oder ihn aus der Nodelist entfernen. (Nodes sind fuer maximal
zwei Wochen als DOWN zu markieren, wonach ihre Zeile aus der Nodelist
entfernt werden sollte).
Du kannst nach Deinem Ermessen einen Teil dieses Arbeitspensums an
'Routing Hubs' verteilen. In diesem Fall solltest Du die Nodelisten
von den Hub Koordinatoren in Deinem Netzwerk empfangen. Du wirst einen
Satz Nodelisten fuer jeden Hub innerhalb Deines Netzwerks zu unterhalten
haben, da Du nicht darauf zaehlen kannst, von jedem Hubkoordinator jede
Woche einen Update zu erhalten. Du solltest jede Woche eine Master
Nodeliste fuer Dein Netzwerk zusammenstellen, und sie an dem Tag und zu der
Zeit die festgelegt wurde zu Deinem Regional Koordinator senden. Es wird
vorgeschlagen, dass Du das so spaet wie praktabel tust, so dass jegliche
spaeten Aenderungen noch untergebracht werden, abgewogen mit dem Risiko,
die Verbindung mit Deinem Regional Koordinator zu verpassen und dadurch
eine Woche zu verlieren.
4.5 Mache die Policy, Nodelist und FidoNews verfuegbar
Als ein Netzwerk Koordinator solltest Du jede Woche eine neue Ausgabe der
Fidonews und eine neue Nodelist Differenz Datei von Deinem Regional
Koordinator besorgen. Die Nodelist Differenz Datei wird derzeit jeden
Samstag verfuegbar gemacht, und FidoNews wird jeden Montag veroeffentlicht.
Du musst diese Dateien allen Nodes in dem Netzwerk verfuegbar machen, und
Du wirst ermutigt, sie der allgemeinen Oeffentlichkeit zum Download ver-
fuegbar zu machen.
Du solltest auch die juengste Version der Policy Dokumente welche die
Mitglieder Deines Netzwerks binden beschaffen, und diese den Nodes in
deinem Netzwerk verfuegbar machen. Policies werden in sporadischen
Intervallen herausgebracht, also solltest Du auch die Nodes in Deinem
Netzwerk informieren wenn solch ein Ereignis eintritt, und sicherstellen
dass die Nodes allgemein mit den Aenderungen vertraut sind.
Policy, FidoNews und die Nodelist sind der Leim der uns zusammenhaelt.
Ohne sie wuerden wir aufhoeren eine Gemeinschaft zu sein, und lediglich
eine weitere zufaellige Ansammlung von Mailboxen werden.
5 Regional Koordinator Handlungsweisen
5.1 Verantwortlichkeiten
Ein Regional Koordinator hat die folgenden Verantwortlichkeiten:
1) 'Unabhaengigen' Nodes in der Region Node Nummern zuzuweisen.
2) 'Unabhaengige' Nodes in der Region zu ermuntern, sich existierenden
Netzwerken in der Region anzuschliessen, oder neue Netzwerke zu bilden.
3) Netzwerken in der Region Netzwerk Nummern zuzuweisen und ihre
Grenzen zu definieren.
4) Eine Nodeliste von allen Netzwerken und 'Unabhaengigen' in der
Region zusammenzustellen, und eine Kopie davon an den Zonen Koordinator
zu senden wann immer sie sich aendert.
5) Den reibungslosen Betrieb der Netzwerke in der Region sicherzu-
stellen.
6) Den Netzwerk Koordinatoren in der Region so bald wie praktikabel
moeglich neue Nodelist Differenz Dateien, Policies und Ausgaben der
FidoNews verfuegbar zu machen.
5.2 Zuweisung von Node Nummern
Es liegt in Deiner Verantwortung, 'unabhaengigen' Nodes in Deiner Region
Node Nummern zuzuweisen. Du kannst auch die Nummern existierender Nodes
in Deiner Region aendern, solltest dies jedoch mit den betreffenden Sysops
ueberpruefen, bevor Du es tust. Du kannst jegliche Nummern zuweisen
die Du wuenschst, so lange jeder Node innerhalb Deiner Region eine einheit-
liche Nodenummer hat.
Du solltest jeglichem System nicht eine Nodenummer zuweisen, bevor Du
einen formellen Antrag von dem System ueber FidoNet Mail erhalten hast.
Das wird sicherstellen, dass dieses System minimal betriebsbereit ist.
Die strikte Aufrechterhaltung dieses Grundsatzes ist eine der grossen
Staerken von FidoNet gewesen.
Es wird auch empfohlen, obwohl nicht erforderlich, dass Du ein System
welches sich um eine Nodenummer bewirbt anrufst, bevor ihm eine Nodenummer
zugewiesen wird.
Du solltest Netzwerk Mail [Netmail] benutzen um einen neuen Sysop von der
Nodenummer zu informieren, da dies sicherzustellen hilft, dass das System
faehig ist Netmail zu empfangen.
Wenn ein Node in Deiner Region sich in ausreichend belaestigender Weise
verhaelt, dann kannst Du jegliche Aktion vornehmen die Du fuer passend
erachtest, entsprechend den Umstaenden des Falles.
Wenn Du einen Antrag fuer eine Nodenummer von ausserhalb Deiner Region
erhaelst, musst Du ihn an den soweit Du feststellen kannst fuer den
Antragsteller am ehesten oertlichen Koordinator weiterleiten. Wenn du
einen Nodenummer Antrag von einem neuen Node erhaelst, der in einem
Gebiet ist, dass von einem existierenden Netzwerk abgedeckt wird, dann
musst Du den Antrag an den Koordinator dieses Netzwerks weiterleiten,
anstatt selbst eine Nummer zuzuweisen.
Wenn sich ein Netzwerk in einem Gebiet bildet, fuer welches Du 'unabhaengige'
Nodes hast, werden diese Nodes sobald praktikabel in das oertliche Netzwerk
transferiert.
5.3 Ermutigung zur Bildung und zum Wachstum von Netzwerken
Eine der hauptsaechlichen Pflichten eines Regional Koordinators ist es,
das Wachstum von Netzwerken in der Region zu foerdern.
Du solltest vermeiden, unabhaengige Nodes in der Region zu haben, die
innerhalb des Abdeckungsbereichs eines Netzwerks sind. Es gibt jedoch
gewisse Faelle wo ein Node nicht Mitglied eines Netzwerks sein sollte,
so wie ein System mit grossem Mengen eingehender Netmail; siehe Abschnitt
4.2.
Wenn sich diverse unabhaengige Nodes in Deiner Region in einem oertlichen
Gebiet befinden, solltest Du sie ermutigen ein Netzwerk zu bilden, und
falls notwendig kannst Du von ihnen anfordern ein Netzwerk zu bilden.
Weise auf Abschnitt 2.4 hin. Merke dass dies nicht dazu gedacht ist,
die Bildung trivilialer Netzwerke zu ermutigen. Offensichtlich macht EIN
Node noch kein Netzwerk. Die genaue Anzahl von Nodes, die fuer ein
erfolgreiches Netzwerk benoetigt wird, muss entsprechend den Umstaenden
der Situation beurteilt werden, und ist Deinem Ermessen ueberlassen.
5.4 Zuweisung von Netzwerk Nummern
Es ist Deine Verantwortlichkeit, neuen Netzwerken die sich in Deiner
Region bilden Netzwerk Nummern zuzuweisen. Du bekommst von Deinem Zonen
Koordinator zu diesem Zweck einen Vorrat von Netzwerk Nummern zugewiesen.
Als Teil dieser Funktion ist es die Verantwortlichkeit des Regional
Koordinators, die Grenzen der Netzwerke in der Region zu definieren.
5.5 Instandhaltung der Nodelist
Als ein Regional Koordinator spielst Du eine doppelte Rolle in der Pflege
der Nodeliste fuer Deine Region.
Erstens musst Du die Liste der 'unabhaengigen' Nodes in Deiner Region
pflegen. Du solltest versuchen, Namens-Aenderungen, Telefonnummer-
Aenderungen und so fort so bald wie moeglich in der Nodelist durchzu-
fuehren. Du solltest auch gelegentlich eine Mitteilung an jeden unab-
haengigen Node in der Region senden, um sicherzustellen, dass sie betriebs-
bereit sind. Wenn sich herausstellt, dass ein Node ohne vorherige
Warnung nicht mehr 'online' ist, kannst Du den Node entweder als 'Down'
markieren oder ihn aus der Nodelist entfernen. (Nodes sind fuer maximal
zwei Wochen als DOWN zu markieren, wonach ihre Zeile aus der Nodelist
entfernt werden sollte).
Zweitens musst Du die Nodelisten von den Netzwerk Koordinatoren in Deiner
Region empfangen. Du wirst einen Satz Nodelisten fuer jedes Netzwerk
innerhalb Deiner Region zu unterhalten haben, da Du nicht darauf zaehlen
kannst, von jedem Netzwerk Koordinator jede Woche einen Update zu erhalten.
Du solltest jede Woche eine Master Nodeliste fuer Deine Region zusammen-
stellen, und sie an dem Tag und zu der Zeit die festgelegt wurde zu Deinem
Zonen Koordinator senden. Es wird vorgeschlagen, dass Du das so spaet wie
praktisch moeglich tust, so dass spaete Aenderungen noch untergebracht
werden, abgewogen mit dem Risiko die Verbindung mit Deinem Zonen
Koordinator zu verpassen und dadurch eine Woche zu verlieren.
5.6 Geografische Ausnahmen
Es gibt Faelle, in denen die oertliche Telefonanruf-Geografie nicht den
FidoNet Regionen folgt. In Ausnahmefaellen einigen sich die der beteiligte
Regional Koordinator und der Zonen Koordinator ueber Ausnahmen von den
geografischen Richtlinien. Eine solche Ausnahme ist kein Recht, und sie
ist nicht permament. Wenn ein Netzwerk im passenden Gebiet gebildet wird,
dass dem ausgenommenen Node einen oertlichen Telefonanruf-Zugriff liefern
wuerde, ist es nicht laenger eine Ausnahme. Eine Ausnahme kann jederzeit
von den beteiligten Koordinatoren ueberprueft und widerrufen werden.
5.7 Ueberschauen des Betriebs der Netzwerke
Du bist verantwortlich dafuer, Netzwerk Koordinatoren fuer die Netze in
Deiner Region zu ernennen. Wenn der abgehende Netzwerk Koordinator einen
Nachfolger vorschlaegt, bist Du nicht verpflichtet dieses Individuum zu
akzeptieren, obwohl Du es normalerweise tun wirst. Entsprechend bist du
nicht verpflichtet das Individuum zu akzeptieren, dass die Mitglieder des
Netzwerks in einer Wahl gewaehlt haben, obwohl Du es normalerweise tun wirst.
Es ist Deine Verantwortlichkeit als Regional Koordinator, sicherzustellen,
dass die Netzwerke innerhalb Deiner Region in akzeptabler Weise arbeiten.
Dies bedeuted nicht, dass von Dir gefordert wird, diese Netzwerke zu be-
treiben; das ist die Verantwortlichkeit der Netzwerk Koordinatoren. Es be-
deuted, dass Du dafuer verantwortlich bist sicherzustellen, dass die
Netzwerk Koordinatoren innerhalb Deiner Region verantwortungsbewusst
handeln.
Wenn Du findest, dass ein Netzwerk Koordinator innerhalb Deiner Region
seine in Abschnitt 4 umrissenen Pflichten nicht anstaendig ausfuehrt,
solltest Du welche Aktion auch immer Du fuer notwendig haelst unternehmen,
um die Situation zu korrigieren.
Wenn ein Netzwerk so gross wird, dass es nicht vernuenftig den Fluss des
Verkehrs waehrend der Zone Mail Hour aufzunehmen vermag, kann der Regional
Koordinator die Erschaffung eines oder mehrerer neuer Netzwerke aus diesem
Netzwerk anordnen. Diese neuen Netzwerke, obwohl sie innerhalb eines
einzigen oertlichen Anrufbereichs sein moegen, muessen sich immer noch
nach einer geografischen Grundlage fuer die Feststellung der Mitgliedschaft
richten.
Es ist Deine Verpflichtung als Regional Koordinator, einen direkten und
vernuenftig haeufigen Kontakt mit den Netzwerken in Deiner Region zu
unterhalten. Die genaue Methode um dies zu erreichen ist Deinem Ermessen
ueberlassen.
5.8 Verfuegbarmachung der Nodelist, Policies und FidoNews
Als ein Regional Koordinator ist es Deine Verantwortlichkeit, die letzte
Nodelist Differenz Datei, Netzwerk Policies und die letzte Ausgabe der
FidoNews zu besorgen so wie sie veroeffentlicht werden, und sie den
Netzwerk Koordinatoren innerhalb Deiner Region verfuegbar zu machen. Die
Nodelist wird woechentlich am Samstag vom Zonen Koordinator veroeffen-
tlicht, und FidoNews wird woechentlich am Montag bei Node 1/1 ver-
oeffentlicht. Steze Dich mit ihnen wegen mehr Einzelheiten wie die
letzten Kopien jede Woche beschafft werden in Verbindung.
Es ist Deine Verantwortlichkeit, diese allen Netzwerk Koordinatoren in
Deiner Region so bald wie praktikabel verfuegbar zu machen nachdem Du sie
erhaelst. Die Methode der Verteilung bleibt Deinem Ermessen ueberlassen.
Es wird nicht von Dir verlangt, sie an jeglichen 'unabhaengigen' Node in
Deiner Region auszuteilen, obwohl Du das darfst wenn Du es wuenschst. Du
wirst ermutigt, alle diese Dokumente zum Download durch die allgemeine
Oeffentlichkeit verfuegbar zu machen.
6 Zonen Koordinator Handlungsweisen
6.1 Allgemeines
Ein Zonen Koordinator fuer FidoNet hat die primaere Aufgabe der Instand-
haltung der Nodelist fuer die Zone, sie mit den anderen Zonen Koor-
dinatoren zu teilen, und die Verteilung der Master Nodelist (oder Differenz
Dateien) an die Regionen in der Zone sicherzustellen. Der Zonen Koordinator
ist auch verantwortlich fuer die Koordination der Verteilung der Netzwerk
Policy Dokumente und FidoNews an die Regional Koordinatoren in der Zone.
Der Zonen Koordinator ist verantwortlich fuer die Instandhaltung der Node-
liste fuer die verwaltetungsmaessige Region. Die verwaltungsmaessige Region
hat die gleiche Nummer wie die Zone und besteht aus Nodes, die fuer admin-
istrative Zwecke zugewiesen wurden, die nicht in Zusammenhang mit dem
Senden und Empfangen von normaler Netmail in Zusammenhang stehen.
Ein Zonen Koordinator ist mit der Aufgabe belastet, den reibungslosen
Betrieb der Zone sicherzustellen, was durch Ernennung und Beaufsichtigung
der Regional Koordinator getan wird.
Wenn ein Zonen Koordinator feststellt, dass ein Regional Koordinator
die in Abschnitt 5 umrissenen Pflichten nicht anstaendig ausfuehrt,
sollte ein Ersatz gefunden werden.
Der Zonen Koordinator definiert die geografischen Grenzen der Regionen
innerhalb der Zone und setzt die Zeit fuer die Zone Mail Hour fest.
Der Zonen Koordinator ist verantwortlich fuer die Ueberpruefung und
Genehmigung jeglicher geografischer Ausnahmen wie in Abschnitt 5.6
beschrieben.
Der Zonen Koordinator ist verantwortlich dafuer, den reibungslosen Betrieb
von Uebergaengen [Gates] zwischen dieser Zone und allen anderen Zonen fuer
den Transfer internationaler Mail sicherzustellen.
Die Zonen Koordinatoren sind verantwortlich fuer die Wahl des inter-
nationalen Koordinators aus ihren Reihen.
6.2 Auswahl
Der Zonen Koordinator wird durch eine absolute Mehrheit der Regional
Koordinatoren innerhalb der Zone ausgewaehlt.
7 Internationaler Koordinator Handlungsweisen
7.1 Allgemeines
Der Internationale Koordinator ist der "Erste unter Gleichen" der Zonen
Koordinatoren.
Der Internationale Koordinator hat die primaere Aufgabe der Koordination
der Erzeugung der Master Nodelist, indem er die Verteilung der Zonen Node-
listen zwischen den Zonen verwaltet. Der Internationale Koordinator ist
verantwortlich fuer die Definition neuer Zonen und fuer die Verhandlung von
Vereinbarungen fuer Kommunikation mit anderen Netzwerken. ("Andere Netz-
werke" bedeuted in diesem Zusammenhang, andere Netzwerke mit denen FidoNet
gleichgestellt kommuniziert, nicht "Netzwerk" im Sinne der FidoNet
Organisations Ebene).
Der internationale Koordinator ist auch dafuer verantwortlich, die Verteilung
der Netzwerk Policies und FidoNews an die Zonen Koordinatoren zu koor-
dinieren.
Der internationale Koordinator ist verantwortlich dafuer, die Aktivitaeten
des Zonen Koordinator Rates zu koordinieren. Der Internationale Koor-
dinator fungiert als der Sprecher der Zonen Koordinator Versammlung.
In Faellen, die nicht speziell von diesem Dokument abgedeckt werden, kann
der Internationale Koordinator spezielle Auslegungen oder Erweiterungen
dieser Policy erlassen. Der Zonen Koordinator Rat kann solche Regelungen
durch eine mehrheitliche Wahl aufheben.
7.2 Auswahl
Der Internationale Koordinator wird durch eine absolute mehrheitliche
Wahl der Zonen Koordinatoren ausgewaehlt (oder entfernt).
8. Volksabstimmungen
Die Handlungsweisen die in diesem Abschnitt beschrieben sind werden benutzt,
um eine neue Version der FidoNet Policy zu ratifizieren, was der Mechanismus
ist durch welchen die Policy geaendert wird. Diese Handlungsweise wird auch
benutzt um einen Zonen Koordinator anzufechten.
8.1 Verfahrensaufnahme
Eine Volksabstimmung ueber Policy Modifikation wird heraufbeschwoert, wenn
eine Mehrheit der FidoNet Regional Koordinatoren den Internationalen Koor-
dinator informieren dass sie eine neue vorgeschlagene Version der Policy
erwaegen wollen.
8.2 Ankuendigung und Ergebnisbekanntgabe
Vorgeschlagene Aenderungen zur Policy werden unter Benutzung der selben
Struktur verteilt, welche benutzt wird, um Nodelist Differenz Dateien und
FidoNews zu verteilen. Ergebnisse und Ankuendigungen, die sich auf die
Volksabstimmung beziehen, werden von der Koordinator Struktur als Teil der
woechentlichen Nodelist Differenz Dateien verteilt. Der Internationale
Koordinator versorgt den Editor der FidoNews fuer die Aufnahme darin mit
Kopien, obgleich die offiziellen Ankuendigungen und Wahl Termine an die
Nodelist Verteilung gebunden sind.
Wenn es angenommen wird, setzt der Internationale Koordinator das Wirk-
samkeitsdatum fuer eine neue Policy durch Ankuendigung in der woechentlichen
Nodelist Differenz Datei fest. Das Wirksamkeitsdatum wird nicht mehr als
einen Monat nach Abschluss der Wahlen sein.
8.3 Wahlberechtigung
Jedes Mitglied der FidoNet Koordinator Struktur ab und ueber Netzwerk
Koordinator ist wahlberechtigt. (Hub Koordinatoren waehlen nicht). Im
Fall, dass die Position waehrend des Wahlvorgangs umbesetzt wird, kann
entweder der bisherige oder der neue Koordinator waehlen, aber nicht beide.
Wenn eine Person mehr als eine Koordinator Position inne hat, erhaelt sie
immer noch nur EINE Stimme.
Es wird von Netzwerk Koordinatoren erwartet, dass sie die Meinungen der
Mitglieder ihres Netzwerks einschaetzen, und entsprechend waehlen. Eine
formale Wahl ist nicht notwendig, aber der Netzwerk Koordinator muss
das Netz von den Begebenheiten und dem erbetenen Eingang informieren.
Der Netzwerk Koordinator fungiert als der Repraesentant der Mannschafts-
Mitglieder von FidoNet.
8.4 Wahl Mechanismus
Der aktuelle Wahl Mechanismus, einschliesslich ob die Wahl geheim ist, und
wie die Stimmen zusammengetragen, verifiziert und gezaehlt werden sollen,
bleibt dem Ermessen des Internationalen Koordinators ueberlassen. Idealer-
weise sollte die Stimmensammlung irgendein sicheres Mitteilungs System sein,
verbunden ueber FidoNet selbst.
Um eine Diskussions Periode bereit zu stellen, muss die Ankuendigung fuer
jegliche Wahl mindestens zwei Wochen vor dem Termin des Wahlbeginns erfolgen.
Die Wahlperiode muss wenigstens zwei Wochen betragen.
8.5 Abstimmung ueber das gesamte Policy Dokument
Gegeben dass die Policy verflochten und selbstverweisend ist, kann eine
relativ einfache Aenderung diverse Aenderungen des Dokuments erfordern.
Um diesen Vorgang zu vereinfachen, werden Abstimmungen zwischen Auswahlen
ganzer Dokumente gemacht, anstatt individueller Verbesserungen. Im ein-
fachsten Fall bedeuted dies, mit 'Ja' oder 'Nein' ueber ein neues Dokument
abzustimmen. Wenn eine Anzahl von Ausweichmoeglichkeiten in Betracht
zu ziehen ist, muessen sie als ganze Dokumente praesentiert werden, aus
denen ausgewaehlt wird.
8.6 Wahlentscheidung
Eine Policy Verbesserung wird als in Kraft betrachtet, wenn sie am Ende
der Wahlperiode eine Mehrheit der abgegebenen Stimmen erhalten hat. Wenn
es zum Beispiel 350 Wahlberechtigte gab, von denen 100 eine Stimme abgaben,
dann waeren wenigstens 51 bestaetigende Simmen erforderlich, um die Ver-
besserung als in Kraft zu erklaeren.
Im Fall mehrfacher Policy Aenderungen, die in der gleichen Wahl erwogen
werden, muss eine Version mehr als 50% der abgegebenen Stimmen erhalten
um als ratifiziert zu gelten. "Enthaltung" ist in diesem Fall eine
gueltige Stimmabgabe und ist effektiv eine Stimme dafuer die aktuelle
Policy nicht zu aendern, da es einfach die Anzahl der Stimmen erhoeht,
die erforderlich sind, um die vorgeschlagene Aenderung zu ratifizieren.
8.7 Anfechtung eines Zonen Koordinators
8.7.1 Verfahrensaufnahme
In extremen Faellen kann ein Zonen Koordinator durch Volksabstimmung
in Zweifel gezogen werden. Die Anfechtung eines Zonen Koordinators er-
fordert nicht eine Verletzung der Policy. Ein Anfechtungsvorgang wird
herbeigerufen, wenn eine Mehrheit der Regional Koordinatoren in einer
Zone beim Internationalen Koordinator anfordern, ihn in Gang zu setzen.
8.7.2 Handlungsweisen wie im Policy Volksentscheid
Die Vorkehrungen von Abschnitt 8.2 und 8.3 treffen auf Anfechtungs-
Volksentscheide zu.
Die Definition von "Mehrheit" in Abschnitt 8.6 trifft zu. Nur Koordinatoren
in der betroffenen Zone waehlen (selbst wenn der Zonen Koordinator auch der
Internationale Koordinator ist).
8.7.3 Wahlmechanismus
Von einem Regional Koordinator, der von dem angezweifelten Zonen Koordinator
ausgewaehlt wird, werden die Handlungsweisen fuer die Abstimmung festgesetzt,
die Stimmabgaben eingesammelt und die Ergebnisse angekuendigt. Die Entfernung
des Zonen Koordinators ist zwei Wochen nach Ende der Stimmabgaben in Kraft
wenn die Anfechtung durchgeht.
8.7.4 Beschraenkt auf einmal pro Jahr
Die Entfernung eines Zonen Koordinators ist primaer dafuer gedacht, um ein
Mechnanismus zu sein, durch den das Netz als Ganzes seinen Unmut ueber die
Art ausdrueckt, wie die Policy interpretiert wird. Dann und wann ist jeder
ungluecklich darueber wie die Policy interpretiert wird. Zu dem Zweck die
Zonen Koordinatoren davon abzuhalten, die Policy so zu interpretieren, dass
sie sich widersetzt sie selbst zu verteidigen, muss wenigstens ein volles
Kalenderjahr zwischen Anfechtungs-Volksabstimmungen verstreichen (unab-
haengig davon wie viele Personen waehrend dieses Jahres die Position des
Zonen Koordinators inne hatten).
Sollte ein Zonen Koordinator waehrend eines Anfechtungsvorgangs zurueck-
treten, wird der Vorgang als null und nichtig betrachtet und beansprucht
nicht die "Einmal-pro-Jahr-Quote".
9 Loesung von Streitfragen
9.1 Allgemein
Die beurteilende Philosophie des FidoNet kann in zwei Regeln zusammen-
gefasst werden:
1) Du sollst andere nicht uebermassig veraergern.
2) Du sollst nicht zu leicht veraergert sein.
Mit anderen Worten, es gibt keine harten und festen Verhaltensregeln, aber
vernuenftig hoefliches Verhalten wird erwartet. Auch werden bei jeglicher
Streitfrage beide Seiten untersucht, und Handlungen koennen gegen eine oder
beide Seiten vorgenommen werden. ("Richte nicht auf dass Du nicht ge-
richtet wirst.")
Die Koordinator Struktur hat die Verantwortlichkeit, "uebermaessig ver-
aergernd" zu definieren. Wie eine allgemeine Definiton der Pornografie
("Ich kann es nicht definieren, aber ich kenne es, wenn ich es sehe."),
ist eine harte und schnelle Definition akzeptablen Betragens in FidoNet
nicht moeglich. Die Richtlinien in dieser Policy sind bewusst vage um
die Freiheit zu liefern, die die Koordinator Struktur benoetigt, um auf
die Erfordernisse einer wachsenden und sich veraendernden Gemeinschaft
zu reagieren.
Der erste Schritt in jeglichem Disput zwischen Sysops ist, dass die Sysops
versuchen direkt miteinander zu kommunizieren, zumindest durch NetMail,
bevorzugt muendlich. Jede Beschwerde die gemacht wird, die diesen grund-
legendsten Kommunikationsschritt ausgelassen hat, wird zurueckgewiesen
werden.
Eine foermliche Beschwerde [Complaint] einzureichen ist keine Handlung,
die leicht genommen werden sollte. Die Nachforschung und Beantwortung von
Beschwerden erfordert Zeit, welche Koordinatoren lieber mit konstruktiveren
Aktivitaeten verbringen wuerden. Personen die hartnaeckig darauf bestehen
triviale Beschwerden einzureichen, koennen sich selbst auf der falschen
Seite einer uebermaessig-veraergernden Beschwerde wiederfinden. Beschwerden
muessen von verifizierbaren Nachweisen begleitet sein, im allgemeinen
Kopien von Mitteilungen; eine einfache Hoeren-Sagen Beschwerde wird sogleich
abgewiesen.
Das Versaeumnis, den hier beschriebenen Handlungsweisen zu folgen (insbe-
sondere indem ein Koordinator uebergangen wird oder ein Koordinator mit
einbezogen wird der nicht in der Anrufungskette ist), ist an sich und von
selbst veraergerndes Verhalten.
9.2 Probleme mit einem anderen Sysop
Wenn Du Probleme mit einem anderen Sysop hast, solltest Du zuerst versuchen,
mittels Netmail oder muendlicher Konversation mit dem anderen Sysop klar-
zukommen.
Wenn dies fehlschlaegt um das Problem zu loesen, solltest Du Dich bei
Deinem Network Koordinator und bei dem Network Koordinator des anderen
Sysops beschweren. Wenn einer oder beide von euch nicht in einem Netzwerk
ist, dann beschwere Dich bei dem entsprechenden Regional Koordinator.
Sollte dies die Zufriedenstellung versagen, hast Du das Recht, dem
Anrufungsverfahren zu folgen, dass in Abschnitt 9.5 beschrieben ist.
9.3 Probleme mit Deinem Netzwerk Koordinator
Wenn Du Probleme mit Deinem Netzwerk Koordinator hast, und findest dass
Du nicht anstaendig behandelt wirst, hast Du Anspruch auf eine Ueber-
pruefung Deiner Situation. Wie bei allen Streifragen ist der erste Schritt,
direkt zu kommunizieren um das Problem zu loesen.
Der naechste Schritt ist, Kontakt zu Deinem Regional Koordinator aufzunehmen.
Wenn Dein Fall von Bedeutung ist, gibt es diverse moegliche Handlungsver-
laeufe, einschliesslich eines Wechsels des Netzwerk Koordinators oder sogar
einer Aufloesung des Netzwerks. Wenn Du von Deinem Netzwerk Koordinator
exkommuniziert worden bist, kann dieses Urteil aufgehoben werden, in welchem
Fall Du wieder in Dein Netz aufgenommen wirst.
Wenn Dir die Unterstuetzung Deines Regional Koordinators versagt bleibt,
hast Du das Recht dem Anrufungsverfahren zu folgen, dass in Abschnitt 9.5
beschrieben wird.
9.4 Probleme mit anderen Koordinatoren
Beschwerden betreffs veraergerndem Verhalten seitens irgendeines Koord-
inators werden wie in Abschnitt 9.2 behandelt und sollten mit der naechsten
Koordinatorebene gefuehrt werden. Wenn Du zum Beispiel findest, dass Dein
Regional Koordinator des veraergenden Verhaltens schuldig ist (Im Gegensatz
zu einem Versaeumnis Pflichten als ein Koordinator auszufuehren), solltest
Du Deine Beschwerde mit dem Zonen Koordinator fuehren.
Beschwerden, die die Leistungen eines Koordinators in Ausfuehrung seiner
wie von der Policy verbindlich vorgeschrieben Pflichten betreffen, werden
nur von der Ebene unmittelbar darunter akzeptiert. Zum Beispiel wuerden
Beschwerden betreffend der Leistungen eines Regional Koordinators von
Netzwerk Koordinatoren und 'Unabhaengigen' in der Region akzeptiert werden.
Solche Beschwerden sollten an den Zonen Koordinator adressiert sein, nach
einem anstaendigen Versuch sie durch direkte Kommunikation zu klaeren.
9.5 Einspruchsverfahren
Mit einer Entscheidung, die von einem Koordinator getroffen wurde, kann man
sich an die naechste Ebene wenden. Einsprueche muessen innerhalb zwei Wochen
der Entscheidung gegen die Einspruch erhoben wird eingelegt werden. Alle
Anrufungen muessen der Kommandokette folgen; wenn Ebenen uebergangen werden,
wird der Einspruch sogleich abgewiesen.
Eine Berufung hat keine vollstaendige Untersuchung zur Folge, sondern wird
auf den Dokumentationen beruhen, die von den Parteien auf der niedrigeren
Ebene bereitgestellt werden. Zum Beispiel wird ein Einspruch gegen eine
Entscheidung eines Netzwerk Koordinators vom Regional Koordinator auf den
Informationen basierend entschieden werden, die von dem Koordinator und dem
beteiligten Sysop bereitgestellt wurden; es wird nicht von dem Regional
Koordinator erwartet, einen unabhaengigen Versuch zu machen, Informationen
zu sammeln.
Die Einspruchs Struktur ist wie folgt:
Die Entscheidungen eines Netzwerk Koordinators koennen bei dem
entsprechenden Regional Koordinator berufen werden.
Die Entscheidungen eines Regional Koordinators koennen bei dem
entsprechenden Zonen Koordinator berufen werden. An diesem Punkt
wird der Zonen Koordinator eine Entscheidung treffen und den
Regional Koordinatoren in dieser Zone mitteilen. Diese Entscheidung
kann von einer mehrheitlichen Wahl der Regional Koordinatoren aufgehoben
werden.
Die Entscheidungen eines Zonen Koordinators koennen bei dem
Internationalen Koordinator berufen werden. Der Internationale Koor-
dinator wird eine Entscheidung treffen und es dem Zonen Koordinator Rat
vortragen, welcher sie durch mehrheitliche Wahl aufheben kann.
Wenn Dein Problem mit dem Zonen Koordinator an sich ist, das heisst dass
ein Zonen Koordinator eine Policy Verletzung gegen Dich veruebt hat, sollte
Deine Beschwerde an den Internationalen Koordinator gerichtet sein, der eine
Entscheidung treffen wird, und sie bei dem Zonen Koordinator Rat fuer eine
moegliche Aufhebung einreichen wird wie oben beschrieben.
9.6 Status von Beschraenkungen
Eine Beschwerde kann nicht mehr als 60 Tage nach dem Datum der Entdeckung
der Quelle des Rechtsbruchs eingereicht werden, entweder durch Eingestaendnis,
oder technische Offensichtlichkeit. Beschwerden koennen nicht mehr als 120
Tage nach dem Vorfall eingereicht werden, sofern sie nicht ausdruecklich
illegales Verhalten betreffen.
9.7 Anrecht auf eine schnelle Entscheidung
Es wird von einem Koordinator verlangt, innerhalb von 30 Tagen eine
abschliessende Entscheidung zu treffen, und die Parteien vom Empfang
der Beschwerde oder des Einspruchs zu benachrichtigen.
9.8 Rueckkehr in das urspruengliche Netzwerk
Sobald eine Policy Streitfrage geloest ist, werden jegliche Nodes, die
auf Einspruch hin wiederaufgenommen wurden, wieder in das oertliche Netzwerk
oder die Region zurueckgefuehrt, zu der sie geografisch oder technisch
gehoeren.
9.9 Echomail
Echomail ist eine wichtige und maechtige Kraft in FidoNet. Fuer den Zweck
von Policy Streitfragen ist Echomail einfach eine andere Form der Netmail,
und ist daher von der Policy abgedeckt. Durch seiner Natur stellt Echomail
einheitliche technische und soziale Ansprueche an das Netz, ueber jene
hinaus die durch diese Version der Policy abgedeckt sind. Dies erkennend,
wird eine Echomail Policy, die die allgemeine Policy erweitert (und ihr
nicht widerspricht), die von den Echomail Koordinatoren gepflegt und durch
einen aehnlichen Vorgang wie dem in diesem Dokument beschriebenen ratifiziert
wird, von den FidoNet Koordinatoren als eine gueltige Struktur fuer Streit-
loesungen in Angelegenheiten anerkannt, die Echomail betreffen. Zu einem
kuenftigen Datum kann die Echomail Policy mit diesem hier zusammengefuegt
werden.
9.10 Fall Geschichten
Das meiste der FidoNet Policy ist von Natur aus Auslegungssache. Niemand
kann voraussehen, was in unserer rapide wechselnden Umgebung kommen wird.
Die Policy selbst ist nur ein Teil dessen, was als die grundlegenden Regeln
fuer die Schlichtung von Streitfragen benutzt wird -- ebenso oder wichtiger
noch sind die Praezedenzfaelle.
Um diesen Vorgang aufzunehmen, koennen von dem Internationalen Koordinator
diesem Dokument Fallstudien hinzugefuegt oder daraus entfernt werden, wobei
solch eine Revision Gegenstand der Aufhebung durch den Zonen Koordinator Rat
ist. Sollte die Policy in einer Weise verbessert werden, dass ein Praeze-
denzfall ungueltig wird, loest die Policy besagten Praezendenzfall ab.
(Eine sorgfaeltig vorbereitete Verbesserung wuerde dies durch die Entfernung
der Bezugnahme auf den Praezendenzfall als Teil der Verbesserung ansprechen).
Obwohl ein Fall entfernt werden kann, kann der Text einer Fall Geschichte
nicht durch irgendeinen Mechanismus modifiziert werden. Fall Geschichte
wird nahe an der Zeit der Entscheidung von den Beteiligten geschrieben.
Die Verbesserung des Textes einer Fallgeschichte ist das gleiche, wie
die Geschichte revidieren zu wollen, etwas ziemlich Unanstaendiges in
einer Organisation, die der Bewegung von Information gewidmet ist.
10 Anhang
10.1 Allgemein
Die Anfuegungen dieses Dokumentes sind Ausnahmen vom normalen Ratifizierungs
Prozess. Abschnitt 10.2 kann von dem entsprechenden Zonen Koordinator
geaendert werden, und Abschnitt 10.3 darf vom Internationalen Koordinator
geaendert werden (siehe Abschnitt 9.10).
10.2 Timing der Zone Mail Hour
Die Zone Mail Hour wird jeden Tag beachtet, einschliesslich Wochenenden und
Ferien. Die Zeit basiert auf dem 'Universal Time Code' (UTC), auch als
'Greenwich Mean Time' bekannt (GMT). In Gebieten, in denen waehrend Teile
des Jahres die Sommerzeit eingehalten wird, wird sich die oertliche Zeit der
Zone Mail Hour aendern, weil FidoNet nicht die Sommerzeit einhaelt. Das
genaue Timing der Zone Mail Hour wird fuer jede Zone vom Zonen Koordinator
festgesetzt.
In FidoNet Zone 1 wird die Zone Mail Hour von 09:00 bis 10:00 UTC
eingehalten. In jeder der Zeit-Zonen ist dies:
Eastern Standard Time 04:00 bis 05:00 Uhr
Central Standard Time 03:00 bis 04:00 Uhr
Mountain Standard Time 02:00 bis 03:00 Uhr
Pacific Standard Time 01:00 bis 02:00 Uhr
Hawaii Standard Time 23:00 bis 00:00 Uhr
In FidoNet Zone 2 wird die Zone Mail Hour von 02:30 bis 03:30 Uhr UTC
eingehalten.
In FidoNet Zone 3 wird die Zone Mail Hour von 18:00 bis 19:00 Uhr UTC
eingehalten. In jeder der beteiligten Zeit Zonen ist dies:
GMT +12 Zone 06:00 bis 07:00
(New Zealand)
GMT +10 Zone 04:00 bis 05:00
(East Australia)
(Papua New Guinea)
(Micronesia)
GMT +9.5 Zone 03:30 bis 04:30
(Central Australia)
GMT +9 Zone 03:00 bis 04:00
(Japan)
(Korea)
(Eastern Indonesia)
GMT +8 Zone 02:00 bis 03:00
(Hong Kong)
(Taiwan)
(Central Indonesia)
(Philippines)
(Western Australia)
GMT +7 Zone 01:00 bis 02:00
(Malaysia)
(Singapore)
(Thailand)
(Western Indonesia)
10.3 Fallgeschichte
Fall Geschichten vergangener Streitfragen sind lehrreich um allgemeine
Handlungsweisen und Methoden zu zeigen. Jegliche Entscheidung kann durch
eine mehrheitliche Wahl entweder des Zone Koordinator Councils oder der
Regional Koordinatoren eingeschlossen werden.
Policy4 aendert wesentlich die Funktionen des Zonen und des Inter-
nationalen Koordinators. Ersetze in den folgenden Faellen, die unter
Verwendung von Policy3 entschieden wurden, alle Vorkommen von "Inter-
national Koordinator(*)" durch "Zonen Koordinator".
10.3.1 Der Fall vom betruegerischen Node
Der Sysop eines oertlichen Nodes benutzte Netmail, um sich mit unethischen
Geschaeftspraktiken zu beschaeftigen. Der Network Coordinator wurde
darueber sehr veraergert, und entfernte den Oertlichen aus der Nodelist.
Der Oertliche wandte sich an den Regional Koordinator fuer die Zuweisung
eines 'unabhaengigen' Node. Der Regional Koordinator entschied nach
Klaerung mit dem Network Koordinator, dass der Network Koordinator zurecht
veraergert war. Der 'unabhaengige' Status wurde verweigert.
Der Internationale Koordinator(*) griff nicht ein.
10.3.2. Der Fall vom 'Hacker' Mailer
Der Sysop eines oertlichen Nodes machte Gebrauch von File-Attaches fuer
besondere Benutzer, um sich selbst die USER.BBS Datei von einigen Mailboxen
zu senden [USER.BBS = Benutzer- und Passwort-Datei diverser Mailbox-
Programme]. Die Sysops dieser Mailboxen fuehlten sich davon belaestigt,
und wandten sich an ihren Network Koordinator, der zustimmte, und den
missetaetigen Node aus der Nodelist entfernte.
Der Regional Koordinator wurde nicht konsultiert.
Der Internationale Koordinator(*) griff nicht ein.
10.3.3 Der Fall vom geplagten Meckerer
Ein oertlicher Node wurde veraergert ueber den Netzwerk Koordinator wegen
des Versaeumnisses Dienste bereitzustellen. Wiederholte Beschwerden
an den Network Koordinator befriedigten ihn nicht, also rief er den
Internationalen Koordinator(*) an.
Der Internationale Koordinator(*) wies die Beschwerde ab, weil der Regional
Koordinator nicht konsultiert worden war.
Der oertliche Node uebertrug die Beschwerde an seinen Regional Koordinator,
der den Fall untersuchte und entdeckte, dass es da eine gewisse Recht-
fertigung fuer die Beschwerde gab. Er beriet den Network Koordinator und
assistierte bei der Konfiguration seines Systems, um einen verbesserten
Stand der Dienste fuer die oertlichen Nodes zu liefern.
Der Regionale Koordinator entschied auch, dass der oertliche Node zu leicht
veraergert war, und dass er Dienste erwartete, die normalerweise nicht von
einem Netzwerk Koordinator verlangt werden. Der oertliche Node wurde ueber
die wahren Pflichten eines Network Koordinators informiert, und wurde es
wurde ihm angeraten, seine Erwartungen zu reduzieren.
10.3.4 Der Fall vom fleissigen Biber
Ein oertlicher Node, der von einem Einzelhandels Unternehmen betrieben
wurde, war damit beschaeftigt 'Message-Bombardierungen' [bombing runs]
laufen zu lassen, um Werbung ueber FidoNet zu versenden. Der Netzwerk
Koordinator fuehlte sich belaestigt, ausgehenden Verkehr fuer kommerzielle
Operationen zu erledigen, und forderte den Node auf, das Netzwerk zu ver-
lassen.
Der oertliche Node wandte sich an den Regional Koordinator und bekam
den Status eines 'unabhaengigen' Nodes in der Region bewilligt.
10.3.5 Das Zeichen des Teufels
Ein oertlicher Sysop dessen Mailbox in Verbindung mit Voodoo Ritualen,
'Hacken', 'Phreaken' [Betruegen der Telefongesellschaften] und obszoenem
Material benutzt wurde, wandte sich an den Netzwerk Koordinator wegen einer
Node Nummer. Der Netzwerk Koordinator fand, dass diese Mailbox uebermaessig
aergerlich sei, und verweigerte den Antrag.
Der Regional Koordinator wurde nicht konsultiert.
Der Internationale Koordinator(*) wies den Fall sogleich zurueck, als er
sah, dass der Regional Koordinator nicht konsultiert wurde. Es fand keine
weitere Berufung statt.
10.3.6 Der Fall vom Sysop Twit
Ein Stammgast diverser oertlicher Nodes war rundherum von allen Sysops als
ein Bloedmann erkannt worden. Der User besorgte sich sein eigenes System,
wurde ein Sysop, und beantragte eine Nodenummer. Der Netzwerk Koordinator
verweigerte den Antrag. Es wurde keine Berufung eingelegt.
10.3.7 Der Fall vom Echomail Suechtigen
Ein oertlicher Node wurde gefesselt von Echomail, und schloss sich diversen
Konferenzen an, wobei er Mail durch sein Netzwerk leitete. Er startete
dann eine eigene Echomail Konferenz, und begann Echomail zwischen ver-
schiedenen Systemen zu uebertragen, wobei er es wieder alles durch das
Netzwerk leitete.
Sein Netzwerk Koordinator beobachtete, dass die Leistungsfaehigkeit des
Netzwerks ernsthaft beeintraechtigt wurde. Dem missetaetige Node wurde
gesagt, es gering zu halten. Ein Kompromiss wurde erreicht, bei dem viel
von dem Echomail Verkehr nicht weiterhin durch das Netzwerk geleitet wurde,
und ge-'routete' Mail wurde auf zwanzig Mitteilungen pro Nacht limitiert.
Es wurden keine Berufungen gemacht.
10.3.8 Der Fall vom sprunghaften System
Ein oertlicher Benutzer entschied sich einen Node einzurichten, um eine
wertvolle Wohltaetigkeit zu unterstuetzen. Die benutzte Maschine wurde
auch fuer verschiedene andere Aktivitaeten waehrend des Tages benutzt, und
der Sysop wurde oft weg gerufen. Seine Mitarbeiter vergassen haeufig das
Board am Ende des Tages hochzufahren wenn er weg war, und so war der Node
haeufig fuer ausgedehnte Perioden 'down'. Der Netzwerk Koordinator, der
den Node nicht imstande fand Mail zu empfangen, markierte ihn als 'Down'.
Der Sysop kehrte zurueck, startete das Board wieder, und bat darum, wieder
eingestellt zu werden. [Und dann wieder von neuem das Spiel.]
Der Netzwerk Koordinator entschied schliesslich, dass der Sysop nicht in
der Lage war ein zuverlaessiges System instand zu halten, und entfernte ihn
vollstaendig aus der Nodelist. Nachfolgende Antraege fuer eine Node Nummer
vom selben Sysop wurden niedergeschlagen. Es wurden keine Anrufungen gemacht.
10.5 Lob, Anerkennungen usw.
Fido und FidoNet sind eingetragene Warenzeichen von Fido Software, Inc.
-----------------------------------------------------------------------------
Index
[Reihenfolge in Uebersetzung fuer alphabetische Sortierung geaendert]
-1/-1 (Traditionelle Nodenummer fuer Node-Antrag), 2.3
Abstimmungs Periode 8.4
Adresse in der Mitteilung fuer einen Node Antrag 2.2
Aendern von Node Nummern 4.3, 5.2
Aktuelle Nodelist 2.1.11
Anforderungen um in der Nodelist zu sein 1.3.4, 2.1.2, 2.2
Anklage 8.7
Ankuendigung von Ergebnissen 8.2
Ausnahmen 5.6
Ausschliesslichkeit der Zone Mail Hour 2.1.8
Ausnahmen, Node Standort 1.3.2, 5.6
Automatische Anrufbeantworter 2.3
Beachtung der Mail Ereignisse 2.1.8, 2.1.10
Beitraege zu FidoNews 1.3.1
Bekanntgabe von Wahlergebnissen 8.2
Berufungs Verkettung 9.5
Beschaffung einer Node Nummer 2.2
Beschwerde (Policy) 2.1.6.1, 9
Bestellungen (kommerzielle) 1.3.6
Bombardierung mit Messages, Bombing run 4.2
BossNode 1.2.1.2
Differenz Dateien (NodeDiffs) 4.5, 5.8, 8.2
Diskussions Periode 8.2
Down [Nodelist Marke] 2.3, 4.4, 5.5
Download von Benutzern 3.6, 4.5, 5.8
Dreischichtige Netzwerke 1.2.3.1
Ebenen des FidoNet 1.2, 1.4
EchoMail 4.2, 9.9
Einreichungen an FidoNews 1.3.1
Enthuellung privater Mail 2.1.6
Ernennung von Koordinatoren 1.2.3, 1.2.4, 5.7, 6.1
Ersetzen von Diensten 3.4
Ersetzen von Koordinatoren 1.2.8
Exkommunikation 2.1.12, 4.3, 5.2, 9
Fallgeschichte 9.10, 10.3
FidoNews 1.3.1
Verfuegbarkeit 3.1, 4.5, 5.8
FTSC 2.1.8, 2.1.9, 2.4
Garantie fuer Mail Auslieferung 1.3.6
Gateway [Netzwerk-Uebergang] 2.1.3
Geografie 1.3.2, 5.6
Geschaeftliche Benutzung des FidoNet 1.3.6
Grenzen 1.3.2
Herkunftsort 2.1.3
Host-routed Mail 4.2
Hub 1.2.3.1, 4.4
Huete [mehrere Aemter] 3.4
Illegale Mail 4.2
Independent (Network-unabhaengiger) Node 4.2, 5.2
In-transit Mail 2.1.6.1
Internationaler Koordinator 1.4.1, 1.4.9, 7
Interzonale Fragen 1.2.6
Kommandokette 1.2.8
Kommerzielle Mitteilungen 1.3.6, 2.1.4, 4.2
Kontrolle und Gleichgewicht 1.2.8
Leim [der das FidoNet zusammenhaelt...] 4.5
Loesung von Streitfragen 9
Lokale Anruf Bereiche 1.3.2
Lokale Policies 1.2, 3.3
Mail 1.2.3, 4.2
Mailer 2.2
Mehrheit [bei Wahlen] 8.6, 8.7.2
Mitglied des verwalteten Gebiets 3.5
Modem 2.2
National Mail Hour - siehe Zone Mail Hour
Network [Netzwerk]
Definition 1.2.3
Formierung 2.4, 5.3
Grenzen 1.3.2, 5.4
Hub 1.2.3.1, 4.4
Nummern 2.2, 5.4
Vorteile 2.2
Network Coordinator 1.2.3
Austausch 5.7, 9.3
Verfahrensweisen 4
Network Mail Hour siehe Zone Mail Hour
Neue Sysops 2.1.2, 3.6
Node-Nummer, wie man eine bekommt 2.2
Nodelist 1.3.4, 2.2, 4.4, 5.5
Aenderungen 4.4, 5.2
Aktuelle 2.1.11
Definition 1.3.4
Format 10.3
Offizielle 1.3.4
Verfuegbarkeit 3.1, 4.5, 5.8
Node Nummern 4.3, 5.2
beschaffen 2.2
Nodes
Definition 1.2.1
Down 2.3
Oeffentliches BBS 3.6
Offensive Mitteilungen 2.1.5
Points 1.2.1.2, 2.1.3
Policy 3.1, 3.3, 4.5, 5.8
Aenderung 8
Beschwerde 2.1.6.1, 9
Vertrautheit mit- 2.1.2, 2.2
Oertliche- 1.2, 3.3
Praezendenzfaelle 3.7, 9.10, 10.3
Private Mitteilungen 2.1.6
Privates Netzwerk 1.2.1.2
Private Nodes 2.1.9
Problem Loesung 9
Protokoll 2.1.8
Ratifizierung [von Policy Dokumenten bzw Aenderungen] 7.1
Raubkopierte Software 2.1.1
Rechtfertigung 'privater' nodes 2.1.9
Redundante [unnoetige] Nodes 2.1.9
Referendum [Volksabstimmung] 1.2.7, 8
Regeln 9.1
Regional Coordinator 1.2.4
Ersetzen des- 6.1, 9.4
Handlungsweisen 5
Regionen 1.2.4
Routing 2.1.4 - 2.1.7, 4.2
Routing Hub 1.2.3.1, 4.4
Ruecktritt eines ZC [Zonen Koordinators] 8.7.4
Schnelle Entscheidung 9.7
Standards (FTSC) 2.1.8, 2.4
Status von Beschraenkungen 9.6
Streitfragen 9
Sommerzeit (Daylight Savings Time) 2.1.14
Sprache [offizielle des FidoNet] 1.0
Sysop Handlungsweisen 2
System Betreiber (Sysop) 1.2.1
Teil-Nodelist 1.3.4
Telefonanruf-Bereiche 1.3.2, 5.6, 5.7
Timing der Zone Mail Hour 2.1.13, 2.1.14, 10.2
Top-down 1.4.9
Tradition 3.7
Triviales Netzwerk 5.3
Uebermaessig veraergerndes Verhalten 1.2.1.1, 1.3.5, 2.1.1, 2.1.2, 2.1.4,
2.1.6, 2.1.7, 2.1.8, 2.1.11, 2.3,
4.2, 4.3, 5.2, 9, 10
Ueberpruefung von Entscheidungen 3.7
Ueberpruefung ge-'routeten' Verkehrs 2.1.4
Ungesetzliches Verhalten 2.1.1, 9.6
Unueberwachte Systeme 2.3
Updates zur Nodelist 3.2
Urlaub 2.3
User 1.2.1.1
User Zugriff waehrend der ZMH 2.1.8
Veraenderung von Mail 2.1.5
Verfuegbarkeit der Nodelist 1.3.4
Veraergerndes Verhalten (Annoying Behavior) 1.3.5, 1.4.8, 2.1.1, 2.1.2,
2.1.4, 2.1.6, 2.1.7, 2.1.8,
2.1.11, 2.3, 4.2, 4.3, 5.2, 9, 10
Verschluesselung 2.1.4, 4.2
Verteilung von Abstimmungen [Policy Aenderung] 8.2
Vertrautheit mit der Policy 2.1.2, 2.2
Verwaltungsmaessige (administrative) Region 6.1
Voice Telefone Nummer [fuer muendliche Gespraeche] 2.2
Vorteile der Teilnahme an einem Network 2.2
Wahl 8
Berechtigung 8.3, 8.7.2
Wahl von Koordinatoren 1.2.5, 6.2, 7.2
Wirksamkeitsdatum (Policy Aenderung) 8.2
Zeit-Begrenzung von Entscheidungen 9.7
ZMH siehe Zone Mail Hour
Zonen Koordinator 1.2.5, 6
Anfechtung 8.7
Entfernung 6.2
Handlungsweisen 6
Ruecktritt waehrend Anfechtung 8.7.4
Wahl 6.2
Zonen Koordinator Rat 1.2.6, 7.1
Zone Mail Hour 1.3.3, 2.1.8
Timing 2.1.13, 2.1.14, 10.2
Zonen 1.2.5, 1.3.2
Zusaetzliche Mail Events in oertlichem Network 2.1.8
========================================================================
WOERTERBUCH EINIGER ENGLISCHER STANDARD-BEZEICHNUNGEN DER FIDONET POLICY
========================================================================
Einige englische Bezeichnungen stellen feste Begriffe im FidoNet dar.
Diese Begriffe und ihre deutschen Bedeutungen sind im folgenden Anhang
gelistet :
annoying - veraergernd; (auch: belaestigend, stoerend)
annoying behaviour - veraergerndes Verhalten
(siehe auch -> excessively annoying)
Attach - siehe File-Attach
BBS - "Bekanntmachungs-Brett-System"; ein Rechnersystem,
das seinen Benutzern Zugriff auf gemeinsame
Abteile fuer Mitteilungen gestattet. Haeufig
werden auch Abteile mit Software und Texten
angeboten. (siehe auch -> Mailbox)
Bulletin Board System - siehe BBS
Board - siehe BBS
Bombing Run - Bombardierung eines Mail-Verteilers durch Versenden
vieler Kopien eines Briefes an die Downlinks des
Verteilers (i.A. Host)
Bossnode - Der Node, ueber den Netmail an den Point geroutet
werden kann, weil der Point dort pollt.
Box - siehe -> Mailbox
Complaint - Beschwerde (i.A. bei einem NC, RC, ZC oder dem IC)
Down - nicht erreichbar; System ist 'heruntergefahren'
Download - "Herunterladen"; Dateien (von einer Mailbox)
empfangen.
Echomail - Brief-Abteilungen, die zwischen vielen Mailboxen
ausgetauscht werden, und die i.A. thematisch streng
begrenzt sind. In Echomail-Abteile koennen oft die
Benutzer Hunderter (oder im Falle internationaler
Abteile sogar Tausender) von Mailboxen Briefe mit-
einander austauschen.
Excessively Annoying - uebermaessig veraergend/belaestigend/stoerend
(nach illegalen Aktivitaeten das schlimmst-
moegliche Verhalten im FidoNet!)
File Attach - "Angehaengte Datei"; bei bestimmten Mailern
werden Dateien verschickt, indem sie sozusagen
an Briefe "mit drangehaengt" werden.
Forward - befoerdern, "vorwaertsleiten" (von Mail)
FTSC - FidoNet Technical Standards Commitee
Gateway - Uebergang zu einem anderen Netz (als FidoNet)
Host - 'Wirts-Rechner' eines Netzwerks, der eingehende
Netmail fuer das Netzwerk entgegen nimmt, und
an die Nodes des netzwerks weiterleitet.
Host-Routed - Ueber den Host eines Netzwerks einem Node des
Netzwerks zugestellt (Mail, Dateien)
Hub - 'Naben-Rechner' eines Netzwerks, der eingehende
Netmail an die Nodes des Hub-Bereiches entgegen
nimmt, und an diese weiterleitet.
seines HUB-Bereichs weiterleitet.
IC, International - Internationaler Koordinator fuer alle FidoNet-Zonen.
Coordinator
Inbound - Eingang (eines Rechner- oder Netzwerk-Systems)
indepenend node - (Netzwerk-) Unabhaengiger Node
In Transit Mail - Durchgangs-Post
Mail - Post, (Gesamtheit der) Briefe
Mailbox - "Elektronischer Briefkasten"; Rechnersystem,
welches seinen Benutzern den Austausch von
Mitteilungen gestattet. (siehe auch -> BBS)
Mailer - DFUe-Software zum automatischen Austausch von
Dateien. Mailer arbeiten oft ohne menschliche
Aufsicht ueber lange Zeitraeume selbsttaetig.
Mail Event - "Post-Ereignis", i.A. Zeitraum fuer Netmail-Empfang
Message - Mitteilung, einzelner "elektronischer Brief"
NC, Network Coordinator - Netzwerk Koordinator
Net, Network - Netzwerk, Netz in der Adresse :/
Netmail - Netzwerk Mitteilung; urspruengliche Form des
Mitteilungsaustausches zwischen zwei Sysops
im FidoNet.
Node - 'Knoten-Rechner'; kleinste Einheit im FidoNet
Online - "An der Leitung"; in Verbindung mit einem
DFUe-System stehend.
Outbound - Ausgang (eines Rechner- oder Netzwerk-Systems)
Point - Subsystem mit Fidonet Faehigkeiten, dass unter
einem Node arbeitet, und ueber diesen adressiert
wird. (siehe auch -> Bossnode)
Policy - Politik, Verfahrens-Grundsaetze (fuer das FidoNet)
Poll - Anruf bei einem Node; i.A. um Mail zu holen/senden
RC, Region Coordinator - Regional Koordinator
Region - Zusammenfassung mehrerer FidoNet Netzwerke in einem
geografisch eindeutigen grossen Gebiet (i.A. Land)
zu verwaltungsmaessigen Zwecken
Restricted - beschraenkt (im Zugriff; siehe auch -> Sysop-Only)
Route, 'routen' - Leiten einer Mail ueber andere Nodes als den
Absender und den Empfaenger
Routing - Weiterleiten (von Mail)
Routing Hub - siehe -> Hub
Sysop - System Operator; Betreiber eines DFUe-Systems.
Sysop-Only - Nur fuer Sysops (beschraenkte Echomail-Abteilung)
Top-Down -
Twit - Bloedmann; jemand, der die elementaren Verhaltens-
weisen trotz Ermahnung beharrlich verletzt
Update - Aktualisierung (einer Datei)
User - Benutzer (einer Mailbox)
Voice - 'Stimme'; muendliche Kommunikation (Telefon)
ZC, Zone Coordinator - Zonen Koordinator fuer eine FidoNet-Zone
ZMH, Zone Mail Hour - Zonen Mail Stunde
Zone - Zusammenfassung mehrerer FidoNet Regionen in einem
geografisch eindeutigen sehr grossen Gebiet (i.A.
Kontinent) zu verwaltungsmaessigen Zwecken
==============================================================================
|S __
Dankeschoen ... |S o| | |
--------------- o| o| o|
... das Publikum war wundervoll ...
... und leise klingt der Schlussakkord in Moll ...
D A N K E ... an ...
- Tom Jennings; fuer die Erschaffung von FidoNet
- Langenscheidt; fuer das Englisch-Deutsch-Woerterbuch
- Konrad Duden; fuer die deutsche Rechtschreibung (sorry wegen der
diversen Patzer, Konrad, aber niemand ist perfekt :-)
- die Dark*Star-Points Torsten Edelmann, Matthias Peter, Joachim Proepper
und Axel Schafia; fuer die Roh-Uebersetzungen diverser Textabschnitte
- an die diversen "Beta-Leser" der Version 1.00, die ausser der Kommasetzung,
einigen Tippfehlern und der stellenweisen Holprigkeit nichts einzuwenden
hatten, weshalb ich die Policy nun nach diesen unwesentlichen Korrekturen
in der Version 1.01 veroeffentliche, obwohl sie weit davon entfernt sein
mag, eine "perfekte" Uebersetzung zu sein.
- So, das war's denn. Bis zur naechsten Policy-Aenderung.
=============================================================================
> Hinweise auf weitere deutsche Policies und Texte zum FidoNet findest Du <
> in den Kommentarzeilen der regionalen deutschen REGION24 Nodelist, die <
> vom Region Koordinator der Region 24 erstellt und verteilt wird. <
=============================================================================
|