Policy407/de: Unterschied zwischen den Versionen
Aus FidoPedia
Uli (Diskussion | Beiträge) K (Änderung 3322 von Uli (Diskussion) rückgängig gemacht.) Markierung: Rückgängigmachung |
Uli (Diskussion | Beiträge) K |
||
Zeile 1: | Zeile 1: | ||
+ | [[Kategorie:Glossar]] | ||
+ | |||
== Policy 4.07 (Deutsch) == | == Policy 4.07 (Deutsch) == | ||
Version vom 5. April 2023, 09:06 Uhr
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