Policy407/de

Aus FidoPedia
Wechseln zu: Navigation, Suche

Policy 4.07 (Deutsch)

                          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 <Zone>:<Netz>/<Node>
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