Stand: 21.01.96 Regionale Policy der FidoNet-Region 24 (Deutschland) V. 1.00 Inhalt: 0. Praeambel 1. Definition der FidoNet-Struktur in R24 1.1 Netzgebiet, calling areas 1.2 Grenzgebiet 1.3 Ausnahmeregelungen 1.4 Vorgehensweise bei Aenderungen der Tarifstruktur der Anbieter von Telekommunikationsdienstleistungen 1.5 Netzgroesse, Aufspaltung von Netzen 2. Node in R24 2.1 Nodewerdung/Nodeantrag 2.2 Aenderungen der Nodenummer 3. Wahl des NC in Region 24 4. Wahl des RC 24 5. Mailrouting in R24 5.1 Netmailrouting in R24 5.1.1 Grundsaetze 5.1.2 Das I/O-Gate 5.1.3 Vertraulichkeit von gerouteter Netmail 5.1.4 Verschluesselte Netmails 5.2 Echomail in R24 5.2.1 Gueltigkeit einer Echomail-Policy 5.2.2 Freiheit des Echomailbezugs 5.2.3 Grundsaetze des Echomailroutings in R24, Add-to-seen-by 5.2.4 Costsharing in R24 5.3 Routing aus und in FidoNet 5.3.1 Gates 5.3.2 Relays 5.3.3 Mailrouting an/von Points 6. Der Net-Coordinators Council (NCC) 6.1 Definition 6.2 Formale Abstimmung 7. Probleme und Problemloesungen im FidoNet 7.1 Beschwerden (Complaints) 7.1.1 Echomail-Vergehen ("Echomail Offence") 7.1.2 Netmail-Vergehen ("Netmail Offence") 7.1.3 Vergehen im Amt ("Administrative Offence") 7.1.4 Privates Vergehen ("Private Offence") 7.1.5 Technisches Vergehen ("Technical Offence") 7.1.6 Allgemeines Vergehen ("General Offence") 7.2 Offizialdelikte 7.3 Vorgehensweise bei Bearbeitung eines formalen Complaints 7.4 Allgemeine Richtlinien 7.5 Ausschluss von Fido-Teilnehmern aus dem Netz 7.6 Auseinandersetzungen von Nodes, Friedenspflicht 8. Sonstiges 8.1 Kommerz im FidoNet 8.2 Region-Independent AKAs 8.3 User 8.4 Points 8.4.1 Point-Mailboxen 8.4.2 Point-Policy 9. Aenderungen dieser Policy 9.1 Gueltigkeitsdauer der Region-Policy 9.2 Ersetzen / Aenderung der Region-Policy 9.3 Ablauf bei einer geplanten Aenderung der Region-Policy 10. ANHANG 10.1 Nodeantrag 10.2 Der formale Complaint 10.2.1 Vorbemerkungen 10.2.2 Beispiel eines formalen Complaints 10.2.3 Beispiel eines Complaint-Bescheides 10.3 Ausfuehrungsbestimmungen zur NC-Wahl in R24 10.3.1. Wahlleiter 10.3.1.1 Einleitung 10.3.1.2 Voraussetzungen fuer die Uebernahme des Wahlleiter-Amtes 10.3.1.3 Ernennung des Wahlleiters, Widerspruch gegen den Wahlleiter 10.3.2 Der Wahlkontrolleur 10.3.3 Die Wahlberechtigten 10.3.3.1 Feststellung der Wahlberechtigten 10.3.3.2 Multiline-Systeme 10.3.4 Kandidaten 10.3.4.1 Voraussetzungen fuer eine Kandidatur 10.3.4.2 Wahlmoeglichkeit "Enthaltung" 10.3.4.3 Einsetzen des NCs, NC-Vertreter, Temporaerer NC 10.3.5 Ablauf der NC-Wahl 10.3.5.1 Grundsaetzliches 10.3.5.2 Benachrichtigung der wahlberechtigten Nodes 10.3.5.3 Stimmabgabe 10.3.6. Wahlergebnisse 10.3.6.1 Veroeffentlichung des Wahlergebnisses 10.3.6.2 Ergebnis des ersten Wahlgangs / Wahlwiederholung 10.3.7. Zweiter Wahlgang / Stichwahlen 10.3.7.1 Ablauf des zweiten Wahlgangs 10.3.7.2 Ergebnis des zweiten Wahlgangs / Stichwahl 10.3.7.3 Stichwahl 10.3.8 Wartefrist / Amtsuebernahme 10.3.9 Einsprueche gegen die Wahl / Complaints 10.3.10 Verfahrensweise bei weniger als 2 Kandidaten 10.3.11 Amtsperiode 10.3.12 Abwahl des NC, vorgezogene Neuwahlen 10.3.13 Ergaenzungen/Besonderheiten 10.3.14 Beispiele fuer die Stimmauswertung 10.3.15 Flussdiagramm: Ablauf einer NC-Wahl 10.4 Ausfuehrungsbestimmungen zur RC-Wahl in R24 10.4.1 Durchfuehrung der Wahl 10.4.2 Wahlleiter der RC-Wahl 10.4.3 Der Wahlkontrolleur 10.4.4 Temporaere Listung 10.4.5 Uebergabe der Amtsgeschaefte 10.4.6 Amtsperiode des RC 24 10.4.7 Abwahl des RC, vorgezogene Neuwahlen 10.4.8 Anpassung der Regelungen 10.5 Glossar Praeambel Gut sechs Jahre nach Verabschiedung der Policy 4.07 und nach Vervielfachung der Node-Anzahl ueber Jahre ist nach Ueberzeugung der Nodes in R24 nunmehr der Punkt erreicht, an dem FidoNet in R24 an einem Scheideweg steht. Durch den sprunghaften Anstieg der Anzahl von Nodes und Nutzern des Mediums Fido waechst der Bedarf nach inneren Regelungsstrukturen fuer Probleme, die Folge dieses Wachstums sind und im Rahmen des Ordnungssystemes, das die Policy 4 bietet, nicht immer rasch und eindeutig genug geloest werden koennen. Die interpretierende Anwendung verschiedener Regeln der Policy 4.07 war in der Vergangenheit aufgrund der geringen Node-Anzahl und der Tatsache, dass FidoNet ein Zusammenschluss groesstenteils persoenlich bekannter Spezialisten mit aehnlichen Interessen war, noch moeglich. Aufgrund der umwaelzenden Aenderungen der letzten Jahre muessen die Regeln aber heute den Erfordernissen des modernen FidoNet im spezifischen Umfeld der Bundesrepublik Deutschland und der grossen Anzahl der Teilnehmer angepasst und praezisiert werden. Zugleich wird seitens nationaler und internationaler Instanzen zunehmend ein Bedarf gesehen, den Bereich der DFUE staerker als bisher aktiv zu regulieren. Ein mittlerweile so grosses Netz wie Fido in R24 hat dem Rechnung zu tragen und seine Strukturen auch von aussen erkennbar so zu gestalten, dass sie den geltenden Gesetzen nicht zuwiderlaufen. Diese Region-Policy stellt nichts anderes dar als eine Ergaenzung der Policy 4.07 unter Beruecksichtigung der spezifischen Erfordernisse der R24, wie einleitend von der Policy vorgesehen: "Separate policy documents may be issued at the zone, region, or net level to provide additional detail on local procedures." {Diese Region Policy besteht aus durchnumerierten Textabschnitten, die die verbindlichen Regeln fuer jeden Node in R24 beinhalten, sowie aus Text, der diese Regeln erlaeutert und der an den geschweiften Klammern {} zu erkennen ist. Dessen Inhalt muss in jedem Fall ebenfalls als zur Policy gehoerig und verbindlich angesehen werden. Im Zweifelsfall gilt die grund- saetzliche Regelung. Der Text dieser Region-Policy liegt in deutscher und englischer Sprache vor und ist in beiden Fassungen gueltig. Bei Auseinandersetzungen, in denen ausschliesslich Nodes der Region 24 beteiligt sind, gilt der deutsche Text, ansonsten der englische. Wo in dieser Policy Prozent- oder Bruchzahlen erwaehnt werden, um z.B. eine benoetigte Mehrheit zu beschreiben, ist im Falle eines nicht-ganzzahligen Ergebnisses auf die naechsthoehere Ganze Zahl aufzurunden.} 1. Definition der FidoNet-Struktur in R24 (Deutschland) FidoNet in R24 ist der durch die woechentliche FidoNet-Nodeliste definierte Zusammenschluss eigenstaendiger und eigenverantwortlicher Betreiber von FTS-kompatiblen Systemen in der Bundesrepublik Deutschland. FidoNet dient der Kommunikation seiner Teilnehmer. Die Ausuebung des gemeinsamen Hobbies erfolgt ohne kommerzielle Interessen. Durch die FidoNet-Nodeliste wird nur die technische Struktur zur Verwaltung der eigenstaendigen und eigenverantwortlichen Systeme vorgegeben; eine darueber hinausgehende rechtliche Verbindlichkeit oder eine gemeinsame Haftung kommt durch die Listung in der woechentlichen FidoNet-Nodeliste ausdruecklich nicht zustande. 1.1 Netzgebiete, Calling Areas {Policy 4.07 definiert in 1.2.3 das Gebiet eines Netzwerks folgender- massen: "A network is a collection of nodes in a local geographic area, usually defined by an area of convenient telephone calling. Networks coordinate their mail activity to decrease cost" Einerseits definiert die Policy demnach ein "Netzwerk" geographisch (1.2.3, 1.3.2), andererseits wird die Bestimmung eines Netzes eindeutig dahingehend definiert, dass die Telefonkosten fuer den einzelnen Node und das Netz in seiner Gesamtheit so niedrig wie moeglich zu halten sind (s.o., 1.2.3). Die genannten "areas of convenient telephone calling" existieren in der von den USA bekannten Form in R24 nicht, daher muss versucht werden, eine telefontarifliche Grundlage fuer die Definition eines Netzes zu finden:} Ein FidoNet-Netzwerk der Region 24 (Deutschland) ist ein regional begrenzter Zusammenschluss mehrerer FidoNet-Systeme, der aufgrund seiner inneren Struktur (insbesondere der Lage und Anordnung der Hubs) moeglichst vielen seiner Nodes die Gelegenheit zu moeglichst guenstigem Mail-Bezug gibt. Die Gebietsdefinition eines FidoNet-Netzes erfolgt anhand einer Liste mit den von dem Netz versorgten Ortsnetzkennzahlen. Ein Netz hat hinsichtlich der in seinem Gebiet ansaessigen Nodes Aufnahmepflicht, soweit die Voraussetzungen zur Erteilung einer Node-Nummer ansonsten gegeben sind. Innerhalb eines regionalen Netzwerks besteht fuer den einzelnen Node die freie Wahl seines Hubs. Die Verpflichtung eines Hubs, einen bestimmten Node aufzunehmen, besteht nicht. 1.2 Grenzgebiet {Im Grenzgebiet zwischen zwei oder mehreren Netzen kann es durch die Tarif- struktur der Dt. Telekom zu Ueberlappungen kommen, so dass ein Node zu einem ihm geographisch zugeordneten Netz hoehere Kosten hat als zu einem benachbar- ten anderen Netz. Im Sinne der in der Policy bereits vorhandenen Moeglichkeit fuer eine Ausnahmeregelung auf Regionen-Ebene (5.6) ist es daher vernuenftig, fuer Haertefaelle auch auf Node-Ebene eine Grenzregelung zuzulassen:} Hat ein Node im Grenzgebiet eines Netzes gleiche oder guenstigere Telefonkosten zu Uplinks eines anderen Netzes als zu Uplinks des eigent- lich fuer ihn zustaendigen Netzes, so darf er sich das Netz aussuchen, sofern die betroffenen NCs zustimmen. Der NC eines Netzes mit guenstigerem Tarif darf den Node nicht abweisen, soweit sonst die Bedingungen zur Erteilung einer Nodenummer gegeben sind. Koennen sich die NCs ueber den Verbleib des Nodes nicht einigen, so entscheidet der RC. Gegen dessen Entscheidung besteht Einspruchsmoeglichkeit beim ZC2. 1.3 Ausnahmeregelungen Ausserhalb des fuer ihn zustaendigen Netzgebietes darf ein Node dann gelistet werden, wenn seine Abwesenheit vom eigentlichen Netzgebiet voruebergehend ist und soweit beide NCs und der RC zustimmen. 1.4 Vorgehensweise bei Aenderungen der Tarifstruktur der Anbieter von Telekommunikationsdienstleistungen Sollten sich durch Aenderungen der Tarifstruktur der Anbieter von Telekom- munikationsdienstleistungen tarifliche Nachteile fuer bestimmte Nodes durch die zum Zeitpunkt der Aenderung bestehende Listung ergeben, so ist durch eine Umstrukturierung der Netze oder Hubs zu gewaehrleisten, dass die betroffenen Nodes auch weiterhin die kostenguenstigste verfuegbare Moeglichkeit des Mail- bezugs nutzen koennen. Bei solchen Neufestlegungen der Netze muessen alle betroffenen NCs in Abstimmung mit ihren Nodes zustimmen; bei Streitfaellen entscheidet der RC in Abstimmung mit dem NCC und mit Widerspruchsmoeglichkeit beim ZC2. 1.5 Netzgroesse, Aufspaltung von Netzen Unter verwaltungsmaessigen Gesichtspunkten sollte eine Mindestgroesse von 50 Nodes fuer neu zu gruendende Netze angestrebt werden; eine Maximalgroesse sollte vom Funktionieren des Netzes abhaengig gemacht werden. Sind die Nodes eines oder mehrerer Netze der Meinung, dass in der aktuellen Struktur technische Probleme (oder technische Nachteile gegenueber einem Alternativmodell mit Splittung des/der Netze/s) vorhanden sind, so sollte von dem/den NC/s in Zusammenarbeit mit den Hubs zunaechst versucht werden, die Maengel durch interne Aenderungen der Organisation zu beseitigen. Fuehrt dies nach 8 bis 12 Wochen nicht zum Erfolg, so ist die Auftrennung des/der Netze/s und Neugruendung eines Netzes unter folgenden Bedingungen moeglich: 2/3 der von einer Netzneugruendung direkt betroffenen Nodes, mindestens jedoch 50 Nodes insgesamt, sprechen sich fuer eine Aufsplittung des/der Netze/s und Gruendung eines neuen Netzes aus. {Direkt betroffene Nodes sind solche, fuer die eine Umstellung der AKA bei der Netzneugruendung noetig wuerde}. Stets hat nach beschlossener Aufteilung des/der Netze/s die Umstellung aller im Gebiet des neuen Netzes befindlicher Nodes zu erfolgen, es sei denn, zwischen den alten und neuen Netzen kommt eine Grenzgebietsregelung gemaess 1.2 zum Tragen. Kommt es zu Einspruechen gegen die Listung des neuen Netzes, versucht der RC, mit allen betroffenen Nodes einen Kompromiss herbeizufuehren. 2. Node in R24 2.1 Nodewerdung/Nodeantrag Nur natuerliche Personen koennen im FidoNet Node werden. Der Node-Anwaerter hat folgende Kriterien zu erfuellen: - korrekt fuer FidoNet konfiguriertes FTS-kompatibles System online zur ZMH - Kenntnis und Bereitschaft zur Einhaltung der gueltigen Policies - keine vorliegende gueltige Exkommunikation Der Nodeanwaerter hat folgende Daten mit dem Nodeantrag zu uebermitteln: - seinen Namen - eine Voice-Telefonnummer, unter der er erreichbar ist - den Namen des Systems - die Stadt/Gemeinde und das Bundesland, in dem das System sich befindet - die Telefonnummer, unter der das System erreicht werden kann - die Betriebszeiten des Systems fuer Netmail und BBS - die maximale BPS-Rate, die das System unterstuetzt - den Typ des Mailers (incl. Versionsnummer) und des Modems, die benutzt werden. Darueberhinaus koennen folgende Punkte sinnvoll und u.U. nuetzlich sein, deren Beantwortung aber stets freiwillig, dem Node-Anwaerter freigestellt und ohne Einfluss auf die Nodenummern-Vergabe sein muss: - Adresse des Nodes - Alter des Nodes, ggf. Kopie eines amtlichen Ausweises - bereits bestehende Echomail/File-Links Ein Musterantrag fuer alle Netze in R24 findet sich im Anhang; er ist Bestandteil dieser Policy und sollte zur Arbeitserleichterung fuer die Node- anwaerter und fuer die NCs von allen Netzen verwendet werden. Rein technische Details des Antrages (Flags u.ae.) koennen vom Net Coordi- nators Council (NCC) mit einfacher Mehrheit der abgegebenen Stimmen geaendert werden; bezueglich solcher Aktualisierungen des Nodeantrages ist keine formale Aenderung der Policy erforderlich. 2.2 Aenderungen der Nodenummer Gemaess Policy 4.07 haben der NC bzw. der RC das Recht, die Nodenummer eines Nodes des Netzes bzw. der Region zu aendern (4.3 bzw. 5.1). In jedem einzelnen Fall ist jedoch dafuer zuvor die Zustimmung des betreffenden Nodes einzuholen. Die Zustimmung jedes einzelnen betroffenen Nodes ist nicht erforderlich, wenn die Zonen-Nummer durch den IC oder die Regions-Nummer durch den ZC2 geaendert wird. Eine Zustimmung ist auch dann nicht erforderlich, wenn eine Netzauf- teilung oder Netzneugruendung gemaess Abschnitt 1.5 dieser RegPol erfolgt, oder bei Entzug oder Aenderung einer Region-Independent oder technisch- funktionellen AKA (zB. Hub, Server). 3. Wahl des NC in Region 24 Der NC eines Netzes in der Region 24 des FidoNet wird von den wahlberechtigten Nodes seines Netzes gewaehlt. Die Wahl erfolgt gemaess den Ausfuehrungsbe- stimmungen zur NC-Wahl (Anhang 10.3). 4. Wahl des RC 24 Der RC der Region 24 des FidoNet wird von den wahlberechtigten Nodes der Region gewaehlt. Die Wahl erfolgt gemaess den Ausfuehrungsbestimmungen zur RC-Wahl (Anhang 10.4). 5. Mailrouting in R24 5.1 Netmailrouting in R24 5.1.1 Grundsaetze Die Pflicht zum Routen von Netmails besteht allein fuer Hubs, Hosts und ihnen gleichgestellte Systeme, sofern es sich um eingehende (Inbound) Netmails an die von ihnen versorgten Systeme handelt. Wo immer moeglich ist bei Inbound-Netmail fuer andere Nodes auf ein klares Host-Hub-Routing zu achten. Ergeben sich vorteilhaftere Moeglichkeiten fuer ein Netmail-Routing, insbe- sondere hinsichtlich der Kosten, der Laufzeit der gerouteten Mails und der Zuverlaessigkeit, koennen diese mit dem Einverstaendnis der Nodes, denen durch dieses Routing erhoehte Kosten entstehen koennten, genutzt werden. Wenn es wegen eines solchen Routings zu Beschwerden seitens der Netmail- Empfaenger kommt, sorgt deren NC in Zusammenarbeit mit den routenden Systemen fuer eine Problemloesung. Das Routen von ausgehender (Outbound) Netmail ist Vereinbarungssache: Eine Absprache des Verfassers mit allen am Routing beteiligten Systemen ist bei unkodierter und nicht-kommerzieller Netmail sowie ueblichem Netmail- Volumen nicht erforderlich: in diesem Fall reicht die Zustimmung des unmittelbaren Uplink-Systemes; von der Zustimmung dessen weiterer Uplinks kann stillschweigend ausgegangen werden. Wer sich bereiterklaert, Netmail fuer Andere zu routen, ist bezueglich deren Netmail routendes System im Sinne von Policy 4.07 und darf solche geroutete Netmail nicht kommentarlos loeschen oder anders als fuer die technische Verarbeitung notwendig veraendern. Eine Pflicht zum Routen von automatisch durch Programme erzeugten Netmails (z.B. Mails an/von Robots) besteht nur dann, wenn sie zum Funktionieren von FidoNet im weiteren Sinne beitragen (z.B. Bounce-Mails, MakeNL-Mails). Ohne Einverstaendnis versandte automatisierte Mails, die aus anderen als technischen Gruenden eingesetzt werden oder das uebliche Volumen persoenlich verfasster Mitteilungen ueberschreiten, koennen von den routenden Systemen als veraergernd angesehen werden. Mails mit ungueltiger Empfaengeradresse muessen nicht geroutet werden. Die Adresse eines Points, dessen Bossnode gelistet ist, gilt als gueltige Adresse. Eine Pflicht zum Routen von Netmails an und von Gates besteht nur insoweit, als es sich um offizielle in der Nodeliste aufgefuehrte Gates handelt. Verweigert ein Node den Transport einer Netmail, obwohl er diesem zuvor zu- gestimmt hat, so muss er Empfaenger oder Absender darueber informieren. Auch in anderen Faellen (z.B. fehlgeleitete Mail) sollte dies geschehen. Kommentarloses Loeschen von Netmail sollte - auch wenn keine Pflicht zu ihrem Transport besteht - in jeden Fall unterbleiben. 5.1.2 Das I/O-Gate Das I/O-Gate wird in Abstimmung mit den Netz-Hosts vom RC24 ernannt. Das I/O-Gate wickelt in dessen Auftrag in Zusammenarbeit mit den Hosts der Netze, den I/O-Gates anderer Regionen und den Zone-Gates den Netmail- Verkehr der Region ab. Fuer die Funktion des I/O-Gates ist ein stabil laufendes System erforderlich, das im optimalen Fall mehrere Zugangsmoeglichkeiten - analog und digital - anbietet. Die Funktionalitaet und Stabilitaet des Systems darf durch erhoehte Systemauslastung aufgrund anderer Verpflichtungen (Echomail, File-Echos) nicht spuerbar beeintraechtigt werden. Sollte zukuenftig das zentrale Netmailrouting in R24 einer anderen Struktur als der derzeit bestehenden (I/O-Gate) folgen (z.B. "Netmail-Backbone" o.ae.), so gelten die obigen Regelungen im uebertragenen Sinne. 5.1.3 Vertraulichkeit von gerouteter Netmail Der Inhalt von "in-transit" Netmails ist vertraulich und darf nicht unerlaubt weitergegeben, kopiert oder anderweitig verwertet werden, es sei denn, konkrete technische Probleme erfordern dies. Ein grober Verstoss gegen die Vertraulichkeit (etwa durch unerlaubte Veroeffentlichung von "in-transit" Netmails in Echos) kann als extrem veraergerndes Verhalten (XAB) angesehen werden. Solange der rechtliche Status von Netmail nicht eindeutig geklaert ist, sollte zum eigenen Schutz des Sysops/Bossnodes jeder User oder Point darauf hinge- wiesen werden, dass eine Netmail von den routenden Systemen zur Kontrolle jederzeit eingesehen werden kann und dafuer ein Schutz im Sinne des Briefgeheimnisses nicht gewaehrleistet werden kann. 5.1.4 Verschluesselte Netmails Das Routen verschluesselter Netmails bedarf der Zustimmung aller am Routing beteiligten Systeme (Pol. 4.07, Abs. 2.1.4). Bietet ein Node seinen Usern und Points Empfang von Netmail-Nachrichten an, so sollte er per direct-mail empfangene verschluesselte Nachrichten an eigene Points und User dem Empfaenger zukommen lassen. Auf Nachfrage teilt ein Node seinem Downlink mit, ob er damit einverstan- den ist, verschluesselte Netmail im Sinne des obigen Absatzes zuzustellen. Eine einmalige direkt uebersandte verschluesselte Netmail an einen eigenen User oder Point stellt kein veraergerndes Verhalten dar. War allein ihre Verschluesselung Grund fuer die Loeschung einer Netmail, so muessen davon Absender oder Empfaenger oder beide informiert werden. 5.2 Echomail in R24 5.2.1 Gueltigkeit einer Echomail-Policy In R24 ist bis zur Verabschiedung und Inkraftsetzung eines anderen Dokumentes die Echopol 1 in der derzeitig gueltigen Fassung vom 1. Februar 1989 verbindlich. Offensichtlich unzutreffende Regelungen (z.B. Bezug auf den Backbone oder auf Zone 1) sind sinngemaess anzuwenden. 5.2.2 Freiheit des Echomailbezugs Die Vergabe einer Nodenummer sowie die Netzzugehoerigkeit duerfen nicht vom Bezug von Echomail abhaengig gemacht werden; eine Pflicht zum Echomail- bezug besteht nicht. Ein Node hat die freie Wahl seines Echomail-Uplinks. 5.2.3 Grundsaetze des Echomailroutings in R24, Add-to-seen-by Loeschen oder Aendern von "in-transit" Echomails fuer Dritte ueber die von der Echopol vorgesehenen Ausnahmen hinaus ist nicht statthaft und kann als XAB angesehen werden. Nachrichten, die unstrittig gegen geltendes Recht verstossen (z.B. Hakenkreuz, Kinderporno), duerfen in Uebereinstimmung mit der Echopol (V 3) geloescht werden; in diesem Fall sind der Absender sowie der NEC des entsprechenden Netzes (bzw. der REC bei Region-Independent AKAs) von der Loeschung zu informieren. Das Hinzufuegen einer fremden Systemadresse zu den seen-bys einer Echomail, ohne die Mail auch tatsaechlich an sie zu tossen (seen-by-adding), ist unzu- laessig und kann als XAB gewertet werden. Ausnahmen sind nur zur Dupesvermeidung und nur dann erlaubt, wenn der Betreiber des hinzugefuegten Systems und dessen NEC bzw. REC ueber diese Massnahme informiert werden bevor sie begonnen wird. Seen-by-adding ist auch dann zulaessig, wenn der Betreiber des hinzugefuegten Systemes sich damit einverstanden erklaert hat (z.B. bei Ringstrukturen in der Echomailverteilung). Wenn die Ursache des seen-by-addings entfaellt, oder ein Node sein zuvor dafuer gegebenes Einverstaendnis widerruft, muss die Massnahme baldmoeglichst beendet werden. 5.2.4 Costsharing in R24 Die Formulierung und Umsetzung praktikabler CS-Richtlinien sind interne Angelegenheit der Netze sowie derjenigen, die Echomail austauschen. Finanzielle Vereinbarungen bezueglich der Lieferung von Echomail sind stets Privatsache. Streitigkeiten deswegen werden stets als "private offences" angesehen (s. 7.1.4). Eine regelmaessige nachvollziehbare Abrechnung durch einen CS-Verwalter unter Nutzung der Moeglichkeiten der modernen Gebuehrenerfassung (z.B. Einzel- Verbindungs-Nachweis) empfiehlt sich. Eine Teilnahmepflicht am netzinternen CS oder die Nodenummernvergabe in Abhaengigkeit davon sind nicht zulaessig (s.a. 2. und 5.2.2) Kostenlos und ohne Berechnung eines CS muss der direkte Uplink gemaess Nodeliste (Hub, Host) auf Wunsch dem Node zugaenglich machen: Netmail, Nodediff, FidoNews, GNews, REC-Liste. Offizielle Node-Echos des Netzes, der Region und der Zone (z.Zt. Nodes.024, Node_org.024, Coords.024, Enet.sysop) duerfen nicht dem Costsharing unter- liegen. 5.3 Routing aus und in FidoNet 5.3.1 Gates Das Gating und die Verbreitung von FidoNet-Echos beduerfen immer der vorherigen Zustimmung des jeweiligen Moderators des Echos. Werden Nachrichten anderer Netze nach FidoNet gegated, so muessen die Nach- richten auf FidoNet-Seite den FTS-Vorschriften entsprechen. Die Regeln des jeweiligen Echos muessen auch von den Teilnehmern der anderen Netze eingehalten werden. Vor Gating der Echos ist sicherzustellen, dass schreibende Teilnehmer anderer Netze per Netmail aus FidoNet heraus (z.B. bei Rulesverstoessen) zu erreichen sind, sofern der Moderator es nicht anders regelt. Netmails muessen in einem solchen Fall durch das Gate kostenlos befoerdert werden. Das absendende System/der User muessen anhand des Msg-Kopfes zweifelsfrei erkennbar sein. Realnames sind im FidoNet Pflicht; soweit allerdings aufgrund sonstiger Merkmale der Mail (BTX-Kennung, Internet-Domain) die Identitaet des Schreibers zweifelsfrei festgestellt werden kann, entfaellt bei technisch begruendeter Notwendigkeit die Realname-Pflicht, soweit der entsprechende Moderator es nicht anders regelt. FidoNet gegenueber verantwortlich ist der Betreiber des Gates auf FidoNet- Seite. Sofern in Zukunft ein Dokument fuer Gates auf Welt- Zonen- oder Regionsebene offizielle Gueltigkeit erlangt, sind dessen Regelungen sinngemaess anzuwenden. 5.3.2 Relays Fuer ein Relay gelten die Vorschriften von 5.3.1 dann, wenn dadurch mehrere eigenstaendige Systeme mit Echomail versorgt werden. 5.3.3 Mailrouting an/von Points Fuer geroutete Mails an/von Points gelten die gleichen Regelungen wie fuer Nodes, insbesondere das Prinzip der Nicht-Veroeffentlichung von "in-transit" Netmail (Pol. 4.07 / 2.1.6.1) und das Prinzip der Nicht-Veraenderung gerouteter Mail (Pol. 4.07 / 2.1.5, 9.9). 6. Der Net-Coordinators Council (NCC) 6.1 Definition Der Net-Coordinators Council (NCC) ist eine Institution, die dem RC24 Hilfe- stellung bei seiner Entscheidungsfindung gibt und demokratische Strukturen auf RC-Ebene etabliert. Er besteht aus den folgenden Vollmitgliedern, die gleichzeitig Stimmberechtigte sind: - alle NCs der gelisteten Netze der R24 - dem RC 24. Weitere Mitglieder mit beratender Funktion (*ECs, Server, Gates etc.) koennen vom RC ernannt werden. Sie sind ohne Stimmrecht. Fuer Diskussionen des NCC wird ein Echo mit Leserecht fuer alle Nodes in R24 genutzt (zur Zeit COORDS.024). Schreibrecht fuer eingeladene Gaeste erteilt der RC24. Die Mitglieder des NCC koennen zu allen Belangen des FidoNets Stellungnahmen abgeben. Der RC stimmt seine Entscheidungen soweit moeglich mit den Mitgliedern des NCC ab und begruendet und erlaeutert seine Entscheidungen. Bei Belangen, die in den Zustaendigkeitsbereich des RC fallen und die mehr als ein Netz innerhalb der R24, andere Regionen oder Zonen betreffen, sowie bei der Feststellung eines Ausschlusses aus Fido (7.5), muss der RC sich an die Entscheidungen des NCC halten. Dies gilt auch, wenn eine vom RC abge- lehnte Network-Policy durch die absolute Mehrheit der stimmberechtigten Mitglieder des NCC genehmigt wird (10.3.13). Bei inneren Angelegenheiten der Region, die in den Zustaendigkeitsbereich des RC fallen und die nur ein Netz betreffen, sowie bei Auseinandersetzungen zwischen Nodes (Complaints), muss der RC die Entscheidungen des NCC nicht beruecksichtigen. Ueber Antraege wird vom NCC offen im Echo abgestimmt. Sollten mehr als 10 %, mindestens aber fuenf der Vollmitglieder, eine Entscheidung des RC anfechten, so muss eine formale Abstimmung gemaess 6.2 erfolgen, und zwar auch dann, wenn es sich um eine nicht zustimmungspflichtige Angelegenheit handelt. Die Anfechtung hat keine aufschiebende Wirkung, es sei denn, durch die strittige Entscheidung wird in die grundlegende Organisationsstruktur der Region eingegriffen. Auch der RC24 selbst kann zu einem bestimmten Sachverhalt eine formale Abstimmung fordern. 6.2 Formale Abstimmung Der RC 24 leitet die Abstimmungen des NCC. Er hat den Antrag so zu formulieren, dass mit "Ja", "Nein" oder "Enthaltung" geantwortet werden kann. Aeussern mehr als 10 % der Vollmitglieder, mindestens jedoch fuenf Personen, innerhalb einer Woche Bedenken gegen die Formulierung des Antrags, so muss sie geaendert werden. Der Abstimmungszeitraum verschiebt sich entsprechend. Fuer eine formale Abstimmung ist ein Zeitraum von 3 Wochen vorzusehen, in dem die Stimmberechtigten sich einen Ueberblick des Meinungsbildes in ihrem Netz verschaffen sowie eine Netmail mit ihrer Antwort dem RC24 zukommen lassen. Der NCC beschliesst mit einfacher Mehrheit der abgegebenen Stimmen, soweit diese Policy nichts anders vorsieht. Nach Ablauf der Abstimmungsfrist wird das Ergebnis der Befragung im NCC-Echo veroeffentlicht. 7. Probleme und Problemloesungen im FidoNet 7.1 Beschwerden (Complaints) Ein Complaint ist eine formale Beschwerde wegen eines Fehlverhaltens. Es koennen verschiedene einem Complaint zugrunde liegende Vergehen unterschieden werden. 7.1.1 Echomail-Vergehen ("Echomail Offence") Oeffentliches, ueber das normale in diesem Echo uebliche Mass hinausgehendes, veraergerndes Verhalten (z.B. schwere Beleidigung) in einem Echo. Zustaendigkeit: NC, Appeal: RC/ZC/IC Moegliche Konsequenzen: Verwarnung, Entzug der Nodenummer auf Zeit/Dauer Die Kompetenzen des Moderators gemaess Echopol bleiben durch die Moeglichkeit zum formalen Complaint aufgrund von Echomailauseinandersetzungen unberuehrt. Es sollte stets zunaechst versucht werden, Auseinandersetzungen wegen Echomail- Nachrichten unter Beteiligung des Moderators und seiner Moeglichkeiten zu loesen. Formale Complaints gemaess 7.1.1 ohne vorherige Nutzung dieser Moeglichkeiten koennen unter Umstaenden als unbegruendet zurueckgewiesen werden. 7.1.2 Netmail-Vergehen ("Netmail Offence") Durch Schreiben von Netmails verursachtes veraergerndes Verhalten (z.B. Belaestigen von Fido-Teilnehmern per Netmail, "Bombing Runs"). Zustaendigkeit und moegliche Konsequenzen: siehe 7.1.1 7.1.3 Vergehen im Amt ("Administrative Offence") Veraergerndes Verhalten als Amtsinhaber in FidoNet durch - Missbrauch der Kompetenzen und Moeglichkeiten des Amtes - Vernachlaessigung der Amtspflichten - Verstoss gegen die Policies. Zustaendigkeit: *C der naechsthoeheren Stufe; Appeal: je eine Stufe hoeher. Moegliche Konsequenzen: Verwarnung/Zurechtweisung, Entzug des FidoNet-Amts, Entzug der Node-Nummer auf Zeit/Dauer 7.1.4 Privates Vergehen ("Private Offence") Streitigkeiten privater Natur, die ursaechlich mit FidoNet nichts zu tun haben (z.B. Costsharing, Kaufen-Verkaufen). Zustaendigkeit: Gerichte und sonstige streitentscheidende Stellen des Staates 7.1.5 Technisches Vergehen ("Technical Offence") Technische Probleme eines Systemes, die anderen Fido-Mitgliedern erhebliche unnoetige Arbeit und/oder Kosten verursachen, und die der verantwortliche Node auch nach wiederholten Hinweisen abzustellen nicht willens oder faehig ist. Zustaendigkeit: siehe 7.1.1 Moegliche Konsequenzen: Verwarnung, Entzug der Nodenummer und/oder Entzug eines FidoNet-Amts auf Zeit/Dauer 7.1.6 Allgemeines Vergehen ("General Offence") Streitigkeiten zwischen Nodes, die ihren Ursprung in FidoNet haben oder unter 7.1.4 aufgefuehrte Streitereien, die auf FidoNet-Ebene ausgetragen werden und die nicht unter die Punkte 7.1.1 bis 7.1.5 fallen. Zustaendigkeit und moegliche Konsequenzen: siehe 7.1.1 7.2 Offizialdelikte Neben Vergehen, die durch ein Complaint (7.1.1-6) ueberprueft und geahndet werden koennen, gibt es auch Faelle, in denen der jeweils zustaendige *C nach Kenntnisnahme des Sachverhalts auch ohne Vorliegen eines formalen Complaints selbststaendig taetig werden kann oder muss. Die Bearbeitung und Entscheidung eines solchen Offizialdeliktes folgt dabei den gleichen Regeln wie die Bearbeitung eines Complaints, lediglich mit der Ausnahme, dass ein offizielles Complaintschreiben eines Nodes nicht vorzuliegen braucht. Ein zustaendiger *C muss nach Kenntnisnahme der folgenden Sachverhalte oder eines entsprechenden Verdachtes taetig werden: - Wahlfaelschung, Wahlmanipulation - Grobe und absichtliche Verletzung der Pflicht zur Verschwiegenheit durch einen Wahlleiter oder Wahlkontrolleur - Verbreitung von Aeusserungen, Texten oder Aehnlichem ueber FidoNet, die unstrittig gegen geltendes Strafrecht verstossen (z.B. Hakenkreuze, Kinderpornographie). Fuehrt ein *C trotz nachweislicher Kenntnisnahme eines der obigen Sachverhalte oder des Verdachtes darauf eine Klaerung der Angelegenheit nicht oder nicht rechtzeitig herbei, so sind die Voraussetzungen zur Erstellung eines Complaints wegen einer "administrative offence" gemaess 7.1.3 gegeben. Ein zustaendiger *C kann nach eigenem Ermessen taetig werden bei eindeutigem Verstoessen gegen die Regelungen der Policy und RegPol (z.B. kein Mailer zur ZMH online). Gegen die Entscheidung eines *C kann bei der naechsthoeheren Instanz Berufung eingelegt werden. Diese Berufung hat bei Offizialdelikten im Gegensatz zum regulaeren Complaintverfahren aufschiebende Wirkung. 7.3 Vorgehensweise bei Bearbeitung eines formalen Complaints Geht bei einem *C ein formaler Complaint gemaess Policy ein, so hat er zunaechst seine Zustaendigkeit, die Zulaessigkeit des Complaints und die formale Korrektheit zu ueberpruefen. Die Zustaendigkeit ergibt sich aus den Punkten 7.1 ff sowie der allgemeinen Policy; die Zulaessigkeit eines Complaints ergibt sich aus den Punkten 7.1 ff. Ein Complaint muss aus formalen Gruenden abgelehnt werden, wenn - die Zustaendigkeit des Coordinators nicht gegeben ist - die Voraussetzung zum Erstellen eines Complaints nicht gegeben ist - die zeitlichen Beschraenkungen nicht eingehalten wurden - kein formaler Aufbau erfolgt ist - kein Einigungsversuch stattgefunden hat. Ein Beispiel fuer einen Complaint findet sich im Anhang (10.2). Erfuellt ein Complaint die erforderlichen Kriterien nicht, so ist dies dem Verfasser per Netmail mitzuteilen. Das Complaint wird in diesem Falle unbearbeitet an den Verfasser zurueckverwiesen. Erfuellt ein Complaint alle erforderlichen Kriterien, so wird die Beschwerde- mail dem Beschuldigten per Netmail mit der Bitte um Stellungnahme zugestellt; als Carbon Copy erhaelt der Beschwerdefuehrer diese Mail als Bestaetigung der Kenntnisnahme durch den Coordinator ebenfalls. Der Coordinator muss alle ihm auch danach bekanntwerdenden Sachverhalte, die auf die Entscheidung des Complaints Einfluss nehmen koennten, dem Beschul- digten per Netmail zur Stellungnahme zu Kenntnis zu bringen. Tut er dies nachweislich nicht, kann seine Entscheidung des Complaints aus formalen Gruenden bei der naechsthoeheren Instanz angefochten werden. Der *C hat sicherzustellen, dass alle seine im Zusammenhang mit dem Complaint- Verfahren stehenden Mails den Beschuldigten auch erreichen, vorzugsweise durch Absenden per Crash/Directmail. Nach Uebersendung der ersten offiziellen Bitte um Stellungnahme wird dem Beschuldigten eine Frist von 2 Wochen gegeben; sollte nach Ablauf dieser Frist keine Stellungnahme eingegangen sein, so wird der Complaint nach den vorliegenden Informationen entschieden. Darueber ist der Beschuldigte in einer Rechtsbehelfsbelehrung aufzuklaeren, wie auch ueber die Konsequenzen, die bei einer Entscheidung gegen ihn entstehen koennten. Wenn nach 2 Wochen keine Stellungnahme des Beschuldigten eingegangen ist, und auch nicht anderweitig eindeutig festgestellt werden konnte, dass der Beschuldigte die Beschwerdemail zu Kenntnis genommen hat, so hat der betreffende Coordinator durch geeignete Massnahmen zu pruefen, ob die Voraussetzungen fuer eine Verlaengerung der Frist gegeben sind (z.B. durch Nachfrage beim zustaendigen Hub/NC), bevor ein Entscheid des Complaints "nach Aktenlage" erfolgt. In begruendeten Ausnahmefaellen (Urlaub, Krankheit etc.) kann die Frist zur Stellungnahme dann um weitere 2 Wochen verlaengert werden. Sollten sich aufgrund der Stellungnahme des Beschuldigten neue Gesichtspunkte ergeben, so ist darueber zunaechst der Beschwerdefuehrer in Kenntnis zu setzen. Bleibt dieser bei seinem Complaint, so erfolgt innerhalb des vorgesehenen Zeitraumes die Entscheidung. Die Entscheidung muss uebersichtlich aufgebaut sein und die wesentlichen Gesichtspunkte auflisten, die Grundlage fuer die Entscheidung waren. Ein eventuelles Strafmass muss deutlich herausgestellt werden. Es ist eine Rechtsbehelfsbelehrung beizufuegen, an wen sich der Beklagte im Falle einer Berufung zu wenden hat. Die Mail mit der Entscheidung muss beiden Beteiligten Crash und Direct zugestellt werden, soweit technisch moeglich. Ein Beispiel findet sich im Anhang (10.2.3). 7.4 Allgemeine Richtlinien Drei durch Complaints im Zusammenhang mit 7.1.1, 7.1.2, 7.1.3, 7.1.5 oder 7.1.6 erhaltene Verwarnungen innerhalb eines Jahres bedeuten einen Entzug der Nodenummer fuer 3 Monate. Ist ein Complaint von allen Ebenen abgelehnt worden, darf in derselben Sache kein neuer Complaint vom selben Beschwerdefuehrer gegen denselben Beschul- digten eingereicht werden. Ein Complaint muss innerhalb 4 Wochen von der jeweiligen Instanz entschieden werden; in Ausnahmefaellen (z.B. Urlaub, Krankheit, Fristverlaengerung zur Stellungnahme des Beschuldigten) verlaengert sich diese Frist um weitere 2 Wochen. Wurde ein Complaint innerhalb dieser Zeit nicht vom zustaendigen *C entschieden, so liegt in der Regel eine "Administrative Offence" gemaess Punkt 7.1.2 dieser Policy vor, was das Verfassen eines Complaints gegen den betreffenden *C rechtfertigt. Complaints sind vom bearbeitenden *C dauerhaft vertraulich zu behandeln. Eine Weitergabe von Einzelheiten an Unbeteiligte ist nur in dem Umfang zulaessig, wie es fuer die Informationsgewinnung im Rahmen der Bearbeitung des Complaints erforderlich ist. Eine Weitergabe an Unbeteiligte oder Veroeffentlichung der mit dem Complaint in Zusammenhang stehenden Informationen durch den bearbeitenden *C ist nur dann zulaessig, wenn beide Parteien zustimmen. Eine fuer den Beschuldigten nachteilige Entscheidung ist zu veroeffentlichen, wenn er dies wuenscht. Wer Complaints verfasst, die als unbegruendet zurueckgewiesen werden, soll vom entscheidenden *C darauf hingewiesen werden, dass Verfassen von Complaints ohne ausreichenden Grund selbst zu einem Complaint mit dem Ziel des Ausschlusses aus Fido fuehren kann. Bevor ein Complaint gegen einen Node wegen seines Points entschieden wird, ist dem Node die Gelegenheit zu geben, sich von diesem Point zu trennen. Tut er dies, gilt der Complaint danach als hinfaellig, es sei denn, der Bossnode ist bereits durch Fehlverhalten seiner Points mit nachfolgenden Complaints auf- gefallen oder das Vergehen war so schwerwiegend, dass der Node deswegen sofort exkommuniziert werden muesste. Eine Berufung gegen eine Complaint-Entscheidung eines Coordinators ist bei der naechsthoeheren Instanz (NC->RC; RC->ZC; ZC->IC) innerhalb 2 Wochen moeglich. Nach 2 Wochen ist die Entscheidung unanfechtbar. Auch in diesem Zusammenhang gelten die Grundregeln des FidoNet gemaess Policy 4.07: - thou shalt not excessively annoy others (Du darfst andere nicht uebermaessig veraergern) - thou shalt not be too easily annoyed (Du darfst nicht zu leicht veraergert sein) 7.5 Ausschluss von Fido-Teilnehmern aus dem Netz Faellt ein Teilnehmer am FidoNet durch wiederholtes oder schwerwiegendes veraergerndes Verhalten auf, so kann er im Rahmen eines Complaint-Verfahrens gegen ihn selbst oder den verantwortlichen Node zeitlich befristet oder auf Dauer aus dem Netz ausgeschlossen werden und ihm kann jegliche weitere Kommunikation in FidoNet (auch als Point oder User) untersagt werden. Die Entscheidung, jemanden aus FidoNet auszuschliessen, darf nur vom NCC auf Vorschlag des RC oder eines NC durch formale Abstimmung mit absoluter Mehrheit der stimmberechtigten Mitglieder erfolgen. Sie muss sehr zurueckhaltend gehandhabt werden und darf als letztes Mittel nur dann angewandt werden, wenn und nachdem andere Mittel, insbesondere ein regulaeres Complaintverfahren, keine Abhilfe schaffen konnten. Wird einem so ausgeschlossenen Teilnehmer trotzdem fortdauernder Zugriff auf FidoNet gewaehrt, so kann dies als XAB angesehen werden. Der dafuer verantwortlichen Node wird in einem solchen Fall zunaechst vom verantwortlichen *C auf diesen Sachverhalt aufmerksam gemacht und aufgefordert, den Zugriff der ausgeschlossenen Person auf FidoNet zu unterbinden. Kommt der Node dieser Aufforderung nicht innerhalb 14 Tagen nach, kann ihm mittels formalem Complaint die Nodenummer entzogen werden. Wird eine Person erstmalig aus FidoNet ausgeschlossen, so darf die Zeitdauer des Ausschlusses ein Jahr nicht ueberschreiten. Ein Ausschluss auf Dauer ist erst dann moeglich, wenn die betreffende Person nach einem mindestens einjaehrigen Ausschluss wieder die Moeglichkeit zur Teilnahme am Fido hatte und erneut aufgrund eines Complaints auszuschliessen waere. Das Fuehren einer oeffentlichen Liste mit darin verzeichneten aus Fido ausgeschlossenen Personen ist untersagt. 7.6 Auseinandersetzungen von Nodes, Friedenspflicht Nodes muessen bei der Loesung fidointerner Probleme (das sind nur Streitfaelle, die in die Zustaendigkeit der Coordinatoren gemaess 7.1 fallen) folgendes beachten: FidoNet kann seine Probleme nur dann selbst loesen, wenn man die Moeglichkeiten dazu auch nutzt. Es steht zwar jedem FidoNet-Node ausdruecklich frei, auf normalem juristischem Weg sein angenommenes Recht gegenueber anderen FidoNet- Nodes zu erlangen, dabei muss er aber vor Beschreiten einer Moeglichkeit zur Loesung des Problemes ausserhalb von Fido zunaechst einen Loesungsversuch innerhalb von Fido unternehmen. Dies ist im Regelfall ein Complaint beim zustaendigen *C. Unternimmt ein FidoNet-Node zur Loesung seines fidointernen Problems einen juristischen Loesungsversuch, ohne dass ein formaler Complaint gegen den Beschuldigten erstellt und durch die Instanzen innerhalb der R24 entschieden wurde, so kann dies als XAB angesehen werden. Wird sein Complaint jedoch nicht innerhalb der vorgesehenen Fristen durch die Instanzen innerhalb R24 bearbeitet, so ist der Node an diese Regelung nicht laenger gebunden. Die o.g. Regelung gilt ebenfalls dann nicht, wenn durch die entstehende Verzoegerung der Erfolg eines juristischen Vorgehens gefaehrdet waere (z.B. Ueberschreiten einer Klagefrist). Die Vorgehensweise beim Verfassen eines formalen Complaints ergibt sich aus Absatz 10.2 dieser Policy. Streitigkeiten, die nicht in den Zustaendigkeitsbereich der Coordinatoren fallen (insbesondere rein private Auseinandersetzungen, vgl. 7.1.4), bleiben von vorstehenden Regelungen unberuehrt. 8. Sonstiges 8.1 Kommerz im FidoNet FidoNet versteht sich als Zusammenschluss von Hobby-Systemen ohne Gewinn- erzielungsabsicht. Kommerzielle Einfluesse sind nur da zu dulden, wo sie von Vorteil fuer FidoNet als Ganzes sind. Dabei sind strenge Masstaebe anzulegen. Kommerzielle Rufnummern sind Telefonnummern, bei denen der Inhaber der Tele- fonnummer einen Betrag fuer eingehende Anrufe erhaelt (z.B. 0190-Nummern). Solche Telefonnummern werden in der Fido-Nodeliste nicht gelistet. Kommerzielle Netmails sind Netmails, die im Zusammenhang mit geschaeftlicher und nachhaltig auf Gewinn ausgerichteter Taetigkeit stehen. Sie sind vom Absender auf eigene Kosten und moeglichst direktem Weg zu versenden; der Empfaenger muss mit der Uebermittlung einverstanden sein. Das Absenden kommerzieller Nachrichten ohne Aufforderung des Empfaengers ist complaintfaehig und kann als XAB angesehen werden. 8.2 Region-Independent AKAs Fuer die Vergabe von Region-Independent-AKAs (RIA) ist der RC zustaendig. RIAs koennen auf Antrag des jeweiligen zustaendigen Hosts an Nodes vergeben werden, deren Netmailflow seine Kapazitaeten ueberlastet. Darueberhinaus koennen in bestimmten anderen Faellen (z.B. EM-Server, Gates, organisatorische Systeme) RIA's vergeben werden. 8.3 User Fuer Mails, die von einem User geschrieben werden, ist das erste in der NL gelistete System, ueber das die Nachricht laeuft, gegenueber den anderen Teilnehmern an FidoNet verantwortlich. Durch entsprechende Massnahmen des jeweiligen Sysop ist dafuer Sorge zu tragen, dass jeglicher Missbrauch von FidoNet durch seine User unterbleibt. Wenn wiederholt Missbrauch von FidoNet durch User eines bestimmten Systemes erfolgt, kann dies als XAB des verantwortlichen Nodes betrachtet werden. Die juristische Verantwortlichkeit des Verfassers einer Nachricht bleibt von dieser Regelung unberuehrt. 8.4 Points Points sind eigenstaendige Systeme, die fido-technisch mit einer 4-D- Adresse eindeutig identifiziert werden koennen und ueber die natuerliche Personen am Fido-Mailverkehr teilnehmen. 8.4.1 Point-Mailboxen Das Anbieten von FidoNet mit Schreibzugriff fuer User ist fuer Mailboxen von Points nur mit Zustimmung des Boss-Systemes und unter dessen voller Verantwortung gegenueber FidoNet erlaubt. Nach Ablauf einer Frist von 3 Monaten sollte der Sysop einer Point-Mailbox im Interesse aller Beteiligten einen Nodeantrag stellen. 8.4.2 Point-Policy Weitergehende Regelungen bezueglich des Status, der Rechte und der Pflichten von Points bleiben einem zukuenftig durch die Nodes der R24 zu erarbeitenden und zu verabschiedenden separaten Dokument oder einer Aenderung dieser RegPol vorbehalten. 9. Aenderungen dieser Policy 9.1 Gueltigkeitsdauer der Region-Policy Diese Policy gilt so lange, wie nicht durch Vorgehensweise gemaess 9.2 und 9.3 eine neue Region-Policy in Kraft gesetzt wurde. Sollte sich herausstellen, dass einzelne Regelungen dieser Policy mit in Deutschland geltendem staatlichen Recht oder uebergeordnetem Fidorecht nicht vereinbar sind, so bleiben andere Bestimmungen und die RegPol als Ganzes davon unberuehrt: Sie gilt bis zur Verabschiedung einer neuen geaenderten RegPol weiter mit Ausnahme des beanstandeten Abschnitts. 9.2 Ersetzen / Aenderung der Region-Policy Wer diese Policy ersetzen oder aendern will, muss ein neues den Vorschriften der zu diesem Zeitpunkt weltweit gueltigen Policy (momentan Policy 4.07) entsprechendes Dokument vorlegen, ueber das in seiner Gesamtheit abgestimmt werden kann. Es koennen auch mehrere alternative Texte vorgelegt werden. Die Abstimmung kann sich jedoch nur auf einen kompletten Text in seiner Gesamtheit beziehen. Diese Regelung gilt nicht fuer technische Aktualisierungen des im Anhang aufgefuehrten Nodeantrages (vgl. 2, 10.1), die vom NCC mit einfacher Mehrheit der abgegebenen Stimmen beschlossen werden koennen. 9.3 Ablauf bei einer geplanten Aenderung der Region-Policy Jeder Node in R24 kann einen Vorschlag fuer eine neue Region-Policy machen. Dieser Vorschlag muss an den RC24 geschickt werden, der ihn innerhalb 3 Wochen im Region-Informationsecho (z.Zt. Node_org.024) zu veroeffentlichen hat, falls der Vorschlag von mindestens 200 Nodes oder von mindestens 10 NCs der gelisteten Netze der R24 unterstuetzt wird. Die Unterstuetzung ist vom Antragsteller nachzuweisen. Innerhalb von 8 Wochen nach Veroeffentlichung des Aenderungsentwurfes ist eine Abstimmung durchzufuehren. Die gueltige Policy muss alternativ zum neuen Vorschlag gestellt werden. In allen gelisteten Netzen stimmen alle dazu berechtigten (nicht PVT/DOWN oder dauernd HOLD im Zeitraum der Abstimmung gelisteten) Nodes ueber den Policy- Aenderungsentwurf ab, nachdem ihnen dieser zur Entscheidung (mit den Wahl- moeglichkeiten DAFUER/DAGEGEN/ENTHALTUNG) durch den NC vorgelegt wurde. Der Abstimmungszeitraum von 2 Wochen wird durch den amtierenden RC festgelegt. Die Stimmabgabe durch die Nodes hat per Netmail an den NC oder einen von ihm benannten Wahlleiter zu erfolgen. Entfallen mehr als 50 % der abgegebenen Stimmen auf die Moeglichkeit "DAFUER", so gilt der Aenderungsentwurf fuer die Policy als durch das Netz angenommen, andernfalls gilt er als abgelehnt. Steht die Mehrheitsmeinung eines Netzes auf diese Weise fest, informiert der NC (oder der von ihm benannte Wahlleiter) den RC24 nach Ende der Abstimmung per Netmail vom Gesamtergebnis und von der Verteilung der Stimmen auf die einzelnen Wahlmoeglichkeiten. Der RC24 wertet die eingegangenen Wahlmails der Netze aus und veroeffentlicht das Ergebnis in der NODE_ORG.024. Stimmen mehr als 50 % der gelisteten Netze durch repraesentative Stimmabgabe ihres NC (oder seines Vertreters in dieser Angelegenheit) dem Aenderungsent- wurf der RegPol zu und ergibt sich zusaetzlich nach Auswertung der einzelnen Node-Stimmen eine Mehrheit von ueber 50 % aller abgegebenen Stimmen fuer die Annahme des Aenderungsentwurfes, so ersetzt er diese RegPol und wird (vorbehaltlich der Zustimmung uebergeordneter Instanzen) fortan als neue offizielle Regionpolicy fuer R24 verwendet; erreicht er nicht die erforder- liche Mehrheit, so bleibt diese Policy in Kraft. Jeder Node kann pro Jahr nur einmal einen Vorschlag fuer eine neue Policy vorlegen. Ueber denselben Vorschlag kann nur einmal abgestimmt werden. 10. ANHANG 10.1 Nodeantrag ======================================================================== N O D E A N T R A G Ich beantrage hiermit die Vergabe einer Nodenummer im FidoNet der Region 24 (Bundesrepublik Deutschland) im Netzwerk XXXX. Die FidoNet-Policy sowie die Region-Policy 24 in der jeweils aktuellen Fassung habe ich gelesen, verstanden und werde mich entsprechend verhalten. Mit dem Absenden des Antrages erteile ich meine ausdrueckliche Erlaubnis, dass mein Name/Vorname, meine Modem-Telefonnummer, der Name meines Systems, sein Standort sowie die technischen Daten meines Modems in der Nodeliste entsprechend der unten gemachten Angaben gefuehrt werden duerfen. Ich erteile darueberhinaus meinem NC und ggf. Hub die ausdrueckliche Erlaubnis, meine personenbezogenen Daten zum Zwecke der Verwaltung unter Einhaltung der Datenschutzgesetze zu speichern. Durch Absenden dieses Nodeantrages erkenne ich die vorstehenden Regelungen an. TECHNISCHE UND PERSOENLICHE DATEN Vorname / Name .................: Standort (Gemeinde/Bundesland)..: Telefon (Voice) ................: System-Name ....................: Telefon (Modem oder ISDN-TA) ...: Anschrift (freiwillige Angabe)..: Alter (freiwillige Angabe)......: Bereits bestehende Echomail/File- links (freiwillige Angabe)......: Ist das System Continous-Mail-faehig (d.h. 24 h online)? ......: Ja / Nein Erlaubt das System Filerequests? ..............................: Ja / Nein Akzeptiert das System Mail von ungelisteten Systemen? .........: Ja / Nein Akzeptiert das Sytem gepackte Netmail (Archive)? ..............: Ja / Nein Wird ausser dem Mailer noch eine Mailbox betrieben? ...........: Ja / Nein Ist das System nur zu bestimmten Tageszeiten zu erreichen? Falls ja, bitte Uhrzeiten angeben! ...: Verwendete Mailer Software / Version ...............: Nodenummer .........................................: 2:24xx/ (Wird vom NC bzw Hub zugeteilt) Uplink .............................................: (Falls schon bekannt, bzw. gewuenschten Hub eintragen) ++ Technische Daten des Systems ++ [ ] V21 ITU-T V21 300 bps full duplex [ ] V22 ITU-T V22 1200 bps full duplex [ ] V22B ITU-T V22bis 2400 bps full duplex [ ] V32 ITU-T V32 9600 bps full duplex [ ] V32B ITU-T V32bis 14400 bps full duplex [ ] V34 ITU-T V34 28800 bps full duplex [ ] V42 ITU-T LAP-M error correction w/fallback to MNP 1-4 [ ] V42B ITU-T LAP-M data compression w/fallback to MNP 5 [ ] MNP Microcom Networking Protocol error correction [ ] H96 Hayes V9600 [ ] HST USR Courier HST at 9600 bps [ ] H14 USR Courier HST at 14400 bps [ ] H16 USR Courier HST at 16800 bps or greater [ ] PEP Packet Ensemble Protocol [ ] V32T V.32 Terbo mode [ ] VFC Rockwell's V.Fast Class [ ] ZYX ZyXEL [ ] ISDNA 19200 N 8 1, ITU-T V.110/ECMA 102, ISDN only [ ] ISDNB 38400 N 8 1, ITU-T V.110/ECMA 102, ISDN only [ ] ISDNC 64000, ISDN X 75, ISDN only [ ] Sonstiges im Klartext: - Zutreffendes bitte ankreuzen Den ausgefuellten Nodeantrag bitte per Crash an den NC oder seinen Beauftragten (im allgemeinen der Hub) schicken. Als Absenderadresse kann eine vorhandene eigene Node- oder Pointnummer verwendet werden. Ansonsten werden Nodeantraege unter einer temporaeren Adresse 2:24XX/9999 gestellt. Die fuer den Antrag benutzte Absenderadresse muss in jedem Fall bis zur Zuteilung einer endgueltigen Nodenummer in den angegebenen Online-Zeiten, mindestens jedoch zur ZMH, jedem anrufenden FTS-kompatiblen System durch einen FTS-kompatiblen Mailer praesentiert werden. Dadurch zeigt der Antragsteller seine Faehigkeit zum Betreiben eines FTS-kompatiblen Systems. Bis zur Erteilung der Nodenummer (oder der Ablehnung des Antrags) koennen bis zu 2 Wochen, in Ausnahmefaellen (Urlaub, Krankheit) auch mehr, vergehen. Bitte habe solange Geduld. ======================================================================== 10.2 Der formale Complaint 10.2.1 Vorbemerkungen Ein Complaint sollte niemals leichtgenommen werden. Abgesehen davon, dass man den bearbeitenden *Cs Aerger und Arbeit macht und ihre Zeit beansprucht, die sie anderweitig wesentlich nutzbringender einsetzen koennten, ist Sinn von FidoNet die gemeinsame Kommunikation und nicht das Streiten um irgend- welche Nebensaechlichkeiten. In diesem Zusammenhang sei auch ausdruecklich darauf hingewiesen, dass das Erstellen von ungerechtfertigten Complaints an sich schon XAB sein und einen Complaint nach sich ziehen kann. Einige Grundregeln sind beim Verfassen eines Complaints zu beachten: 1. Es muss zuvor ein Einigungsversuch mit dem Beschuldigten stattgefunden haben (per Netmail oder - besser noch - per voice). 2. Der Complaint darf hoechstens 60 Tage nach Bekanntwerden des Beschwerde- grundes und hoechstens 120 Tage nach dem betreffenden Vorkommnis verfasst werden. Ausnahmen hiervon sind lediglich eindeutige Gesetzesverstoesse, deret- wegen auch mehr als 120 Tage nach ihrem Vorkommen ein Complaint verfasst werden darf. 3. Der Complaint muss formalen Mindestanforderungen genuegen, d.h. es muss aus dem Text hervorgehen - dass es sich um einen Complaint handelt - wer beschuldigt wird - weswegen die Beschuldigung erhoben wird - gegen welchen Punkt der Fido-Policies verstossen worden sein soll - welche Beweise fuer das Fehlverhalten existieren - was der Beschwerdefuehrer zur Loesung des Problems vorschlaegt - wann und wie ein Einigungsversuch stattgefunden hat. (siehe 10.2.2). 4. Der Complaint muss an die richtige Person gerichtet sein, im Normalfall an den NC des Beschuldigten. Der RC ist zustaendig fuer Complaints gegen NCs und Region-Independent Nodes sowie im Fall einer Berufung gegen die Complaintentscheidung eines NC. Der ZC ist zustaendig fuer Complaints gegen den RC sowie im Falle einer Berufung gegen die Complaintentscheidung eines RC. 5. Bis zum RC24 kann die deutsche Sprache benutzt werden, bei Berufungen ueber die Ebene der R24 hinaus (ab ZC2) muss die englische Sprache verwendet werden. 10.2.2 Beispiel eines formalen Complaints -------------------------------------------------------------------- From: Georgia Beschwerdefuehrer, 2:24XX/Y PVT,CRA,DIR To : Hans Coordinator, 2:24XX/0 Betr: Complaint gegen Emil Beschuldigter -------------------------------------------------------------------- CC: Emil Beschuldigter Hans, hiermit fuehre ich eine offizielle Beschwerde gemaess Policy (Complaint) gegen den Node Emil Beschuldigter, 2:24XX/Z. Ich habe mich zuvor ueberzeugt, dass Du als NC 24XX fuer diese Beschwerde zustaendig bist. Sollte entgegen meiner Einschaetzung dies nicht zutreffen, bitte ich um umgehende Benachrichtigung, damit ich die Beschwerde korrekt adressieren kann. Ich habe zuvor in einer Netmail/einem Telefonat am ... versucht, mich mit Emil zu einigen, aber [....] Begruendung der Beschwerde: Er hat .. /am __.__. 19__ / seit XX Wochen [..] bla bla.... bla.. bla.. Er hat damit eindeutig gegen /die Regelung XYZ der Policy 4.07 /den Absatz XYZ der Region-Policy /gegen den Absatz XYZ der Echopol /gegen die FTS-Vorschrift ... /gegen... verstossen, die ich in der Folge quote: -------------------------------------------------------------------- [..] -------------------------------------------------------------------- Beweise fuer meine Behauptungen: /Zum Nachweis quote ich seine betreffende Mail: /Folgende Beweise fuer meine Behauptungen gegen Emil Beschuldigter habe ich beigefuegt: /Als Zeugen benenne ich folgende Nodes: /[...] Forderung: Ich verlange daher, dass Emil Beschuldigter /umgehend diese veraergernde Verhaltensweise sein laesst /sich sofort entschuldigt /bis zum .... auf meine Forderungen eingeht /wegen der Schwere des Vergehens mit sofortiger Wirkung die Nodenummer entzogen wird. /Sollte er nicht innerhalb ... Tagen auf meine Forderungen eingehen, beantrage ich fuer diesen Fall den Entzug seiner Nodenummer. /[...] Mit freundlichen Gruessen Georgia Beschwerdefuehrer 10.2.3 Beispiel eines Complaint-Bescheides From: Hans Coordinator, 2:24XX/0 PVT,CRA,DIR To : Georgia Beschwerdefuehrer, 2:24XX/Y Betr: Complaint gegen Emil Beschuldigter -------------------------------------------------------------------- CC: Emil Beschuldigter Georgia, Du hast am XX.YY.19ZZ einen formalen Complaint gemaess Policy hier eingereicht. Ich bin als Coordinator fuer die Bearbeitung zustaendig, der Complaint ist zulaessig, und der formale Aufbau war korrekt. Die zeitlichen Fristen wurden eingehalten. Es hat zuvor ein Einigungsversuch stattgefunden. In Deiner Mail wirfst Du dem Node Emil Beschuldigter vor, dass er ...[Beschwer- degrund]: --------------------------------------------------------------------------- GB>Er hat bla bla.... GB>bla.. GB>bla.. ---------------------------------------------------------------------------- Du verlangst/beantragst/begehrst..... In einer Mail vom XX.YY.19ZZ habe ich den Node Emil Beschuldigter um eine Stellungnahme gebeten. In seiner Antwort vom XX.YY.19ZZ schreibt er: ---------------------------------------------------------------------------- EB>Ich wollte doch nur bla bla... EB>bla... EB>bla... ---------------------------------------------------------------------------- Er verlangt/beantragt/begehrt..... Unter Beruecksichtigung aller Fakten stellt sich meines Erachtens die Situation folgendermassen dar: 1. Der Node Emil Beschuldigter hat ..... 2. Zur Entschuldigung/Rechtfertigung fuehrt er an, dass... 3. Auf einen Einigungsversuch von Deiner Seite aus ist er nicht eingegangen. 4. Allerdings trifft auch Dich ein Mitverschulden, weil.... 5. Du hast aufgrund der eindeutigen Regelungen der Policy und RegPol deswegen das Recht, veraergert zu sein, und daher.... 6. Gleichwohl handelt es sich aufgrund der geschilderten Umstaende... .... Demzufolge treffe ich folgende ENTSCHEIDUNG: 1. Der formale Complaint des Node Georgia Beschwerdefuehrer vom XX.YY.19ZZ ist begruendet/nicht begruendet. Ihm ist daher stattzugeben/nicht statt- zugeben. 2. Der Node Emil Beschuldigter hat gegen folgende Regelungen verstossen: - BlaBla (Policy 2.1) - BloBlo (RegPol 4.3) - BluBlu (Echopol 6.5) /hat gegen keine Regelungen verstossen. /hat nicht wissentlich... 3. Deshalb wird ihm mit sofortiger Wirkung die Nodenummer im Netz 24xx fuer die Dauer von ... Wochen/Monaten entzogen. /Es ergeben sich keine Konsequenzen. /Er hat sich umgehend zu entschuldigen, ansonsten wird... /Er hat die festgestellten Maengel bis zum .... abzustellen, ansonsten... /Im Wiederholungsfalle wird... /usw. Rechtsbehelf: Gegen diese Entscheidung kann innerhalb 2 Wochen beim naechsthoeheren zustaendigen Koordinator, in diesem Fall dem RC Johann Dosenkohl 24/0, Berufung eingelegt werden. Die Berufung hat keine aufschiebende Wirkung. Gruss, Hans Coordinator ----------------------------------------------------------------------- 10.3 Ausfuehrungsbestimmungen fuer die NC-Wahl in R24 10.3.1. Wahlleiter 10.3.1.1 Einleitung In der Verantwortung des Wahlleiters liegt die einwandfreie Durchfuehrung der Wahl von Anfang an bis zur korrekten und fristgerechten Ermittlung des Wahlergebnisses und dessen Bekanntgabe. Der Wahlleiter hat moeglichst objektiv den Willen der Waehler zu ermitteln; alles, was er waehrend der Wahl unternimmt, hat sich dem unterzuordnen und wird daran gemessen. Ein Node, der sich bereit erklaert, eine Wahl zu leiten, soll alle Handlungen unterlassen, die seinem Ansehen, dem ihm zustehenden Respekt und seiner Autoritaet bei der Leitung der Wahl schaden koennten. Das gilt auch fuer den Wahlkontrolleur, der dem Wahlleiter zur Seite gestellt wird. Ein Wahlleiter oder ein Wahlkontrolleur, der seine Pflicht zur Verschwiegenheit verletzt oder die Wahl bzw. das Wahlergebnis durch Aeusserungen oder Taten zu verfaelschen versucht, handelt extrem veraergernd (excessively annoying, XAB). 10.3.1.2 Voraussetzungen fuer die Uebernahme des Wahlleiter-Amtes Ein Wahlleiter darf bei der anstehenden Wahl nicht selbst Kandidat sein. Wahlleiter muessen ein CM-System betreiben und duerfen waehrend der gesamten Zeit ab Veroeffentlichung des Wahltermines bis zur Verkuendung des Wahl- ergebnisses nicht durchgaengig HOLD oder DOWN gelistet sein. Falls ein Wahlleiter in dieser Zeit HOLD oder DOWN gelistet wird, muss entweder der Wahlzeitraum entsprechend verlaengert werden, bis er wieder regulaer gelistet ist, oder ein neuer Wahlleiter eingesetzt werden. Die Entscheidung darueber trifft der RC. 10.3.1.3 Ernennung des Wahlleiters, Widerspruch gegen den Wahlleiter Der Wahlleiter wird vom RC24 aus den gelisteten Nodes des Netzes ernannt und sein Name im Sysop-Echo des Netzes bekanntgegeben. Wenn 10 % der Wahlberechtigten oder mehr es fordern, muss der Wahlleiter aus einem anderen Netzwerk kommen. Sollten sich 10 % der wahlberechtigten Nodes eines Netzes oder mehr gegen den ernannten Wahlleiter aussprechen, so haben sie dem RC einen anderen WL zur Ernennung vorzuschlagen, der auch bereit ist, das Amt zu uebernehmen. Grundlage fuer die Berechnung der zur Ablehnung des Wahlleiters noetigen Anzahl wahlberechtigter Nodes ist die zum Zeitpunkt der Ernennung durch den RC gueltige Nodelist (vgl. 10.3.3.1). In jedem Fall muessen alle Einsprueche innerhalb von 7 Tagen nach Bekanntgabe des Wahlleiters beim RC eingegangen sein. Der RC entscheidet ueber die Einsprueche binnen 7 Tagen. Werden nacheinander 3 Wahlleiter abgelehnt, so setzt der RC einen Wahlleiter und einen Wahlkontrolleur ein, die nicht mehr abgelehnt werden koennen. Der zeitliche Ablauf der Wahl beginnt mit der Ernennung eines neuen Wahlleiters vollstaendig von vorne. 10.3.2 Der Wahlkontrolleur Vom RC wird in Abstimmung mit dem NC eine Person benannt, die als Kontrolleur dem Wahlleiter zur Seite gestellt wird und den gesamten Ablauf der Wahl sowie die Ergebnisse ueberprueft. Der Wahlleiter setzt beginnend mit der Wahlausschreibung bis hin zur Veroeffentlichung des Ergebnisses den Kontrolleur ueber alle wichtigen Sachverhalte in Kenntnis; insbesondere stellt er ihm alle Wahlstimmen, Wahlvorschlaege usw. uneingeschraenkt zur Verfuegung. 10.3.3 Die Wahlberechtigten 10.3.3.1 Feststellung der Wahlberechtigten Der Wahlleiter benennt in seiner Wahlankuendigung diejenige Nodeliste, die zur Ermittlung der Wahlberechtigten zugrundegelegt wird. Es darf sich um die zum Zeitpunkt der offiziellen Wahlankuendigung aktuelle Nodeliste oder um eine hoechstens 2 Wochen aeltere handeln. Wahlberechtigt ist, wer in der vom Wahlleiter benannten Nodeliste im Netz- segment des betreffenden Netzes gelistet und nicht PVT oder DOWN gekenn- zeichnet ist. Nodes, die in der o.g. Nodeliste HOLD gelistet sind, koennen dann waehlen, wenn sie vor Beginn der eigentlichen Abstimmung wieder regulaer gelistet werden. 10.3.3.2 Multiline-Systeme Die Wahl wird nach dem Grundsatz "ein Nodesysop - eine Stimme" abgehalten, unabhaengig von der Anzahl der Node-Eintraege, die ein Sysop in einem Netz fuehrt. Multiline-Systeme haben bei Wahlen nur eine Stimme, es sei denn, auf den verschiedenen Lines eines Systemes sind unterschiedliche Sysops aufgefuehrt. {Die Listung verschiedener Sysops auf den Lines eines Multiline-Systems setzt voraus, dass sie eigenstaendig ihr System betreuen. Die Feststellung, ob ein eigenstaendig betreutes System vorliegt, faellt der NC bei der Listung.} 10.3.4 Kandidaten 10.3.4.1 Voraussetzungen fuer eine Kandidatur Kandidaten muessen in der vom Wahlleiter in der Wahlankuendigung festgelegten FidoNet-Nodeliste gelistet sein (vgl. 10.3.3.1). Jeder dort gelistete Node des Netzes kann sich zur Wahl stellen. Ausgenommen sind Personen, die in dieser Nodeliste nur PVT-Eintraege im entsprechenden Netzsegment haben oder DOWN gelistet sind. Nodes, die in dieser Nodeliste HOLD gelistet sind, koennen dann kandidieren, wenn sie vor Ablauf des Bewerbungszeitraumes fuer die Kandidatur wieder regulaer gelistet werden (vgl. 10.3.5.1). Bestimmte technische Systemanforderungen bestehen ansonsten nicht. Kandidaten unterrichten den Wahlleiter innerhalb des festgelegten Zeitraumes von ihrer Absicht zu kandidieren. Ein Wahlprogramm oder eine Absichtserklaerung kann - muss jedoch nicht - beigefuegt werden. Der Wahlleiter veroeffentlicht alle Bewerbungen zeitgerecht im festgelegten Echo (vgl. 10.3.5.2); darueberhinaus informiert er alle Wahlberechtigten per Netmail. 10.3.4.2 Wahlmoeglichkeit "Enthaltung" Bei jeder Wahl ist die Moeglichkeit zu geben, fuer "Enthaltung" zu stimmen; sie ist kein Kandidat im Sinne der nachfolgenden Regelungen. Sollte die Wahlmoeglichkeit "Enthaltung" im ersten Wahlgang die absolute Mehrheit der abgegebenen Stimmen erhalten, so ist die Wahl komplett zu wiederholen, das heisst mit der erneuten Kandidatensuche zu beginnen. Sollte auch bei einer kompletten Wiederholung der Wahl "Enthaltung" die absolute Mehrheit der Stimmen bekommen, so setzt der RC24 einen NC seiner Wahl ein; dieser muss Node des betreffenden Netzes sein. 10.3.4.3 Einsetzen des NCs, NC-Vertreter, Temporaerer NC Eine Einsetzung des NCs durch den RC erfolgt ausser im unter 10.3.4.2 genannten Fall auch dann, wenn - "Enthaltung" die einfache Mehrheit im zweiten Wahlgang erringt (vgl. 10.3.7.2), - nach einer Stichwahl der NC noch immer nicht feststeht (vgl. 10.3.7.3), - oder sich kein Kandidat fuer das NC-Amt findet (vgl. dazu 10.3.10). Kann der amtierende NC voruebergehend sein Amt nicht ausueben (z.B. durch Krankheit, Urlaub), so ist von ihm ein Vertreter zu benennen. Die Zustimmung des RCs zur Person des Vertreters ist erforderlich. Ist der NC selbst zur Benennung eines geeigneten Vertreters nicht in der Lage, so setzt der RC einen Node des betreffenden Netzes als Vertreter des NCs ein. Der Vertreter des NCs darf hoechstens fuer eine Dauer von 2 Monaten amtieren und lediglich die Compilierung des Networkfiles vornehmen. Sobald abzusehen ist, dass der urspruengliche NC sein Amt nicht mehr aufnehmen kann oder will, setzt der RC einen "Temporaeren NC" ein; in diesem Fall beauftragt der RC umgehend einen Wahlleiter mit der vorgezogenen Neuwahl des NC (vgl. 10.3.1 f.). Dies gilt ebenfalls fuer den Fall einer Amtsenthebung des NC wegen eines "Administrative Offence" (vgl. 7.1.3). Der Temporaere NC bleibt bis zum vollstaendigen Abschluss des Wahlverfahrens im Amt. Ueber die Compilierung des Networkfiles hinausgehende Rechte - z.B. Bearbeitung von Complaints - erhaelt ein Temp-NC stets nur nach ausdruecklicher Genehmigung durch den RC. 10.3.5 Ablauf der NC-Wahl 10.3.5.1 Grundsaetzliches Die Wahlen sind stets allgemein, frei, gleich, unmittelbar und geheim (vgl. 10.5 - Glossar). Wahlen finden ausserhalb der Haupturlaubszeiten (Juni - September) statt, ausser bei wichtigen Gruenden, die gegenueber dem RC24 zu rechtfertigen sind. Die Wahl beginnt mit der Einsetzung des Wahlleiters. Sie endet, wenn - der Wahlsieger bekannt ist - der RC einen NC eingesetzt hat (10.3.4.3) - das Netz aufgeloest worden ist (10.3.10). In den ersten 2 Wochen koennen die Kandidaten ihre Bewerbung einreichen und ihr Programm vorstellen. Die folgenden 2 Wochen dienen der Befragung der Kandidaten, und weitere 2 Wochen dienen der Stimmabgabe. 10.3.5.2 Benachrichtigung der wahlberechtigten Nodes Der Wahlleiter benachrichtigt alle wahlberechtigten Nodes des Netzes rechtzeitig vor der eigentlichen Abstimmung per Netmail von der Wahl, den Wahlterminen, dem Wahlrecht, der Moeglichkeit der Kandidatur, seiner Funktion als Wahlleiter und der Person des Wahlkontrolleurs. Abhaengig von den anfallenden Kosten kann dies auch als geroutete Netmail geschehen, obwohl crash/direct Netmail vorzuziehen ist. Ein "bombing run" zu diesem Zweck wird dann nicht als annoying angesehen, wenn er direkt ueber den Host des waehlenden Netzes geroutet wird. Dazu stimmt sich der Wahlleiter zuvor mit dem Host ab. Ein spezielles Echo kann aus Anlass einer Wahl eingerichtet und auch vom Wahlleiter fuer Informationen genutzt werden; die Pflicht, alle Wahlberech- tigten per Netmail ueber wichtige Details der Wahl zu informieren, bleibt davon aber unberuehrt. 10.3.5.3 Stimmabgabe Alle Stimmabgaben muessen auf das System des Wahlleiters erfolgen. Stimm-Mails muessen unmittelbar und direkt an das System des Wahlleiters geschickt werden. Sofern technische Gruende dies verhindern (z.B. ISDN-only Nodes) muss eine andere Zustellungsweise zuvor zwischen Wahlleiter und dem betreffenden Wahlberechtigten vereinbart werden. Eine Wahlstimme muss folgendes enthalten: - Den Namen des Kandidaten, fuer den gestimmt werden soll (bzw. statt des Namens "Ja" oder "Nein" bei nur einem Kandidaten) oder das Wort "Enthaltung" - Ein Passwort, das bei Veroeffentlichung des Wahlergebnisses eine anonyme Verifizierung aller Stimmen ermoeglicht. Alles Naehere, insbesondere ein ggf. zur automatischen Auswertung erforderliches spezielles Format der Stimm-Mails, legt der Wahlleiter fest. 10.3.6. Wahlergebnisse 10.3.6.1 Veroeffentlichung des Wahlergebnisses Das Wahlergebnis wird binnen 3 Tagen nach Ende des Abstimmungszeitraumes vom Wahlleiter veroeffentlicht, nachdem der Kontrolleur das Ergebnis ueberprueft und bestaetigt hat. Sollte es in dieser Zeit nicht moeglich sein, zu einem eindeutigen Ergebnis zu kommen, so muss der RC ueber die Gruende der Verzoegerung informiert und von ihm die Genehmigung zur Ueberschreitung dieser Frist eingeholt werden. Spaetestens 2 Wochen nach Ende des Abstimmungszeitraumes muss ein offiziell gueltiges Ergebnis durch Wahlleiter und Kontrolleur vorgelegt werden, ansonsten ist die Wahl ungueltig und muss komplett wiederholt werden. Verzoegert ein Wahlleiter oder ein Wahlkontrolleur vorsaetzlich die Veroeffent- lichung des Wahlergebnisses, so kann dies als XAB betrachtet werden. Die genaue Form der Veroeffentlichung liegt in der Verantwortlichkeit des Wahlleiters; es muss eindeutig ersichtlich sein, welche Stimmen (durch das dazugehoerigen Passwort) auf die einzelnen Kandidaten und die Moeglichkeit "Enthaltung" entfallen sind. Ausserdem muss eine Liste aller Nodes veroeffentlicht werden, die abgestimmt haben. Aus der Veroeffentlichung selbst darf kein Rueckschluss moeglich sein, wie ein bestimmter Node abgestimmt hat. Das Ergebnis muss im Node-Echo des Netzes veroeffentlicht werden. Darueberhinaus sind alle Kandidaten und Wahlberechtigten per NM vom Ergebnis zu unterrichten. Kein Node darf wegen seiner Stimmabgabe oder wegen Nichtwahl benachteiligt werden. 10.3.6.2 Ergebnis des ersten Wahlgangs / Wahlwiederholung Im ersten Wahlgang ist die absolute Mehrheit der abgegebenen Stimmen fuer den Wahlsieg erforderlich (ueber 50 % der abgegebenen Stimmen). Sollte keiner der Kandidaten die absolute Mehrheit im ersten Wahlgang erreichen, so findet ein zweiter Wahlgang (vgl. 10.3.7) oder eine komplette Wiederholung der Wahl (vgl. 10.3.4.2) statt. Der Wahlleiter teilt dem RC24 nach Abschluss des ersten Wahlgangs das Ergebnis und die daraus evt. resultierenden Konsequenzen mit. 10.3.7. Zweiter Wahlgang / Stichwahlen 10.3.7.1 Ablauf des zweiten Wahlgangs Diejenigen Kandidaten, die die besten beiden Ergebnisse im ersten Wahlgang erzielt haben, nehmen am zweiten Wahlgang teil. Der Wahlleiter benennt direkt im Anschluss an die Veroeffentlichung des Ergebnisses des ersten Wahlgangs diejenigen Kandidaten, die den zweiten Wahlgang bestreiten. Dies geschieht per Netmail an die Kandidaten und alle Stimmberechtigten sowie per Echomail im Node-Echo. Der zweite Wahlgang beginnt ohne erneute Vorstellung der Kandidaten und Diskussion (vgl. 10.3.5) innerhalb einer Woche und dauert zwei Wochen. 10.3.7.2 Ergebnis des zweiten Wahlgangs / Stichwahl Beim zweiten Wahlgang ist gewaehlt, wer die einfache Mehrheit der abgegebenen Stimmen erhaelt. Erhaelt die Moeglichkeit "Enthaltung" im zweiten Wahlgang die Mehrheit der abgegebenen Stimmen, so setzt der RC einen NC nach seiner Wahl aus den Nodes des betreffenden Netzes ein (10.3.4.2). Liegen mehrere Kandidaten mit der gleichen Stimmenanzahl auch im zweiten Wahlgang an der Spitze, so findet eine Stichwahl statt (10.3.7.3). 10.3.7.3 Stichwahl Eine Stichwahl laeuft formal wie ein 2. Wahlgang ab. (vgl. 10.3.7.1) Bei der Stichwahl ist gewaehlt, wer die einfache Mehrheit der abgegebenen Stimmen erhaelt. Erreicht auch bei der Stichwahl keiner der Kandidaten eine Mehrheit, oder erzielt die Moeglichkeit "Enthaltung" die meisten Stimmen, so waehlt der RC einen Node des Netzes aus und setzt ihn als NC ein (vgl. 10.3.4.2). 10.3.8 Wartefrist / Amtsuebernahme Steht das endgueltige Wahlergebnis fest, wird der Wahlsieger fuer den Ablauf einer 14-taegigen Wartefrist als temporaerer NC gelistet. In dieser Zeit sind Einsprueche durch die Wahlberechtigten (10.3.9) moeglich. Die 14 Tage koennen vom scheidenden und neuen NC sowie von den Hubs genutzt werden, um die notwendigen Umstellungen vorzunehmen. In dieser Zeit darf der neu gewaehlte NC ausser dem Zusammenstellen und der Weitergabe des Networkfiles keine weitergehenden Pflichten eines NC uebernehmen, sofern dies nicht technische Probleme zwingend erfordern. Complaints in dieser Wartefrist werden nur in dringenden Faellen direkt vom RC bearbeitet und ansonsten die Bearbeitung verschoben. Ein in dieser Zeit eingereichter Complaint gilt als fristwahrend. 10.3.9 Einsprueche gegen die Wahl / Complaints Fuer die Bearbeitung von Einspruechen, die in Zusammenhang mit der Wahl stehen (z.B. Einsprueche gegen das Wahlergebnis, die Termine oder den Verlauf der Wahl, die Person oder die Aktivitaeten des Wahlleiters und des Wahlkontrolleurs), ist der RC24 zustaendig. Einsprueche muessen binnen 14 Tagen nach Bekanntwerden des Einspruchsgrundes per Netmail vorgebracht und begruendet werden. Spaetestens 14 Tage nach Verkuendung des endgueltigen Wahlergebnisses laufen alle Einspruchsfristen ab. Die absichtliche Faelschung eines Wahlergebnisses oder von Wahlstimmen wird als XAB betrachtet. Zustaendig fuer die Bearbeitung eines Complaints ist in diesem Fall der RC24 mit Widerspruchsmoeglichkeit beim ZC2. 10.3.10 Verfahrensweise bei weniger als 2 Kandidaten Sollte sich nur ein Kandidat finden, nimmt dieser die Position des NC des betreffenden Netzes ein, ausser wenn mindestens 10 % der stimmberechtigten Nodes eine Abstimmung fordern. In diesem Fall stellt sich der Kandidat zur Abstimmung mit den Wahlmoeglich- keiten JA und NEIN. Er ist gewaehlt, wenn die Wahlmoeglichkeit JA die Mehrheit der abgegebenen Stimmen erreicht. Erreicht er nicht die erforderlich Mehrheit, so findet eine komplette Neuwahl statt. Steht auch nach dieser Neuwahl der NC nicht fest, setzt der RC24 einen NC seiner Wahl aus den Nodes des Netzes ein. Sollten sich keine Kandidaten fuer das Amt eines NC finden, so kann der RC24 entweder einen NC seiner Wahl einsetzen oder das Netz aufloesen. In letzterem Fall wird die Aufteilung des Netzgebietes in Zusammenarbeit zwischen dem RC24 und den NCs der umliegenden Netze vorgenommen. 10.3.11 Amtsperiode Die Amtsperiode eines gewaehlten NC in R24 betraegt maximal 24 Monate, beginnend mit der Verkuendung des Wahlergebnisses. Ein vom RC eingesetzter NC hat eine Amtszeit von maximal 12 Monaten. Der amtierende NC kann sich wieder fuer die naechste Amtsperiode bewerben, wird aber mit Ablauf seiner Amtszeit so behandelt, als waere er zurueckgetreten. Der scheidende NC hat kein Recht, seinen Nachfolger zu ernennen. 10.3.12 Abwahl des NC, vorgezogene Neuwahl Der NC eines Netzes kann jederzeit vor Ende seiner regulaeren Amtszeit abgewaehlt werden. Abwahlen finden durch komplette vorgezogene Neuwahl eines Nachfolgers gemaess Abschnitt 10.3.1 bis 10.3.11 dieser Policy statt (konstruktive Neuwahl). Um eine vorgezogene Neuwahl einzuleiten, ist der formlose schriftliche Antrag von 1/3 der stimmberechtigten Nodes des Netzes beim RC erforderlich; die Stimmen koennen auch gesammelt und durch einen Beauftragten der Nodes beim RC komplett abgegeben werden. Darueber hinaus muss zusaetzlich mindestens ein Kandidat benannt werden, der verbindlich bereit ist, sich zur Wahl als NC zu stellen. Vorzeitige Neuwahlen werden auch bei Amtsenthebung des NC wegen Nichterfuellung der Amtspflichten oder bei vorzeitiger Amtsaufgabe des NC faellig. Bei der vorgezogenen Neuwahl kann der momentane Amtsinhaber ebenfalls kandidieren. Solange die vorgezogene Neuwahl nicht abgeschlossen ist, darf der amtierende NC keine Aktivitaeten unternehmen, die die Wahl in irgendeiner Weise behindern. Er darf keine nur schwer rueckgaengig zu machenden Fakten schaffen. Saemtliche von ihm durchgefuehrten Aktivitaeten waehrend der vorgezogenen Neuwahl sind bis zu deren Abschluss als vorlaeufig zu betrachten. 10.3.13 Ergaenzungen/Besonderheiten Lokale Policies auf Network-Ebene (Network-Policies) koennen die Regelungen dieser RegPol ergaenzen, Rechte fuer Nodes erweitern und in einzelnen Punkten auf lokale Besonderheiten oder Wuensche Ruecksicht nehmen. Dabei duerfen aber die in dieser Region-Policy festgelegten Rechte der Nodes nicht eingeschraenkt werden. Network-Policies muessen vom RC24 genehmigt werden. Bei Ablehnung durch den RC ist die Genehmigung einer Network-Policy dennoch moeglich, wenn dies der NCC mit der absoluten Mehrheit seiner stimmberechtigten Mitglieder beschliesst. 10.3.14 Beispiele fuer die Stimmauswertung Die nachfolgenden Beispiele verdeutlichen, wie Ergebnisse im ersten und zweiten Wahlgang sowie in der Stichwahl bei einer NC- oder RC-Wahl gemaess Abschnitt 10.3 und 10.4 bewertet werden muessen. Die Zahlenbeispiele sind dabei bewusst "extrem" gewaehlt, um speziell die Faelle zu beleuchten, wo der "gesunde Menschenverstand" fuer eine Wahlauswertung moeglicherweise nicht ausreicht. Mit A, B und C sind bis zu 3 Kandidat(inn)en und die auf sie entfallenden Stimmen gemeint: ----------------------------- -------------------------------- E R G E B N I S: -----> K O N S E Q U E N Z: ----------------------------- -------------------------------- Jeweils Stimmen fuer: Enthalt. A B C im 1.WG im 2.WG Stichwahl ----------------------------- -------------------------------- 4 5 0 - A gew. A gew. A gew. - 5 4 - A gew. A gew. A gew. 2 4 3 - 2.WG A/B A gew. A gew. - 4 3 2 2.WG A/B A gew. A.gew. 3 4 2 - 2.WG A/B A gew. A gew. 3 4 1 1 2.WG A/B/C A gew. A gew. 4 2 2 1 2.WG A/B/C RC->NC RC->NC 5 2 2 - Neuwahl(*) RC->NC RC->NC 3 3 3 - 2.WG A/B Stichw. RC->NC Erlaeuterung: gew. = gewinnt; WG = Wahlgang; RC->NC = RC setzt NC ein. - = kein Kandidat vorhanden (*) sollte bei 2 Wahlen nacheinander "Enthaltung" die absolute Mehrheit der Stimmen erhalten, so setzt der RC einen NC ein. 10.3.15 Flussdiagramm: Ablauf einer NC-Wahl -------------------------------------------------------------- ZEIT| AKTION -------------------------------------------------------------- | 7 | Ernennung des Wahlleiters durch <-------- | den RC 24 (10.3.1) | T | | | A | |-> [Widerspruch gegen den WL?] -ja-- G | | E | nein | | --+--| | | | 2 | Wahlankuendigung durch den WL (10.3.5.2) | Festlegung der verbindlichen Nodeliste W | Anschreiben der Wahlberechtigten per NM | | O | | | Kandidatensuche C | | | |-> [Kandidaten vorhanden?] -nein-> RC setzt ein/ H | | Netz wird auf- | | geloest (10.3.10) E | | | ja N | | | | --+--| | | | 2 | | | Veroeffentlichung W | Kandidatenliste O | | C | |-> [Nur ein Kandidat?] -ja-> 1. Wahlgang H | | | E | | [>50 % JA-Stimmen?] -ja-> WAHLENDE N | Diskussion | | | | --+--| | nein | | | 2 | 1. Wahlgang | | | | W | | V | |-> [Enthaltung >50% ?] -ja-> Wahl wird komplett O | | wiederholt; | nein 2 mal nacheinander: C | | RC setzt ein, | | WAHLENDE H | | | |-> [Kandidat >50% ?] ---ja-> Gewinner steht fest, E | | WAHLENDE | nein N | | | | --+--| | | | 2 | | | 2. Wahlgang (10.3.7) W | | | | O | |-> [Mehrheit fuer Enthaltung?] -ja-> RC setzt ein, | | WAHLENDE C | nein | | H | | | |-> [Mehrheit fuer Kandidat?] ---ja-> Gewinner E | | steht fest, | nein WAHLENDE N | | | | --+--| | | | 2 | Stichwahl (10.3.7.3) | | W | | | |-> [Mehrheit fuer Enthaltung?] -ja-> RC setzt ein, O | | WAHLENDE | nein C | | | | H | |-> [Mehrheit fuer Kandidat?] ---ja-> Gewinner | | steht fest, E | nein WAHLENDE | | N | | | RC setzt ein, WAHLENDE. | --------------------------------------------------------------- 10.4 Ausfuehrungsbestimmungen zur RC-Wahl in R24 10.4.1 Durchfuehrung der Wahl Die Wahl des RC erfolgt in allgemeiner, freier, gleicher, unmittelbarer und geheimer Wahl durch die Nodes der R24. Die Vorschriften, die fuer NC-Wahlen gelten (Abschnitt 10.3 dieser Policy), finden insoweit auch fuer die RC-Wahl Anwendung, als hier nicht ausdruecklich andere Regeln beschrieben sind. 10.4.2 Wahlleiter der RC-Wahl Der ZC2 ernennt auf Vorschlag des amtierenden RC24 einen Wahlleiter. Dieser muss Node der Region 24 sein und darf nicht selbst bei der anstehenden Wahl kandidieren. Rechte und Pflichten eines Wahlleiters sowie technische Voraussetzungen fuer die Uebernahme dieses Amtes ergeben sich aus Abschnitt 10.3 dieser Policy. Lehnen binnen 2 Wochen mindestens 10 % der wahlberechtigten Nodes oder mindestens 10 % der NCs die Person des Wahlleiters ab, so ernennt der ZC2 einen neuen Wahlleiter; andernfalls gilt er als anerkannt und uebernimmt die weitere Organisation der Wahl. Bezueglich der Wahlbenachrichtigung per Netmail (vgl. 10.3.5.2) ist es bei der RC-Wahl ausreichend, lediglich die NCs der Netze - nicht alle Nodes einzeln - von der Wahl etc. in Kenntnis zu setzen. Die NCs muessen den Wahlleiter in einer Weise unterstuetzen, die die reibungs- lose Durchfuehrung der Wahl ermoeglicht. Alle offiziellen Mitteilungen des Wahlleiters, die sie per Netmail erhalten, muessen sie per Netmail (ggf. zusaetzlich per Echomail) allen wahlberechtigten Nodes des jeweiligen Netzes zugaenglich machen. Darueber hinaus hat der Wahlleiter selbst seine offiziellen Verlautbarungen in einem dafuer geeigneten regionsweit verfuegbaren Echo (z.Zt. NODE_ORG.024) zu veroeffentlichen. Der Wahlleiter informiert den ZC2 ueber die Wahlfristen, die Kandidaten, das Wahlergebnis und eventuelle Einsprueche, und stellt ihm auf Anforderung saemtliche Wahlmails zur Verfuegung. 10.4.3 Der Wahlkontrolleur Vom RC wird in Abstimmung mit dem ZC eine Person benannt, die als Kontrolleur dem Wahlleiter zur Seite gestellt wird. Rechte und Pflichten des Wahlkontrolleurs ergeben sich aus Abschnitt 10.3.2. 10.4.4 Temporaere Listung Steht der Gewinner der Wahl zweifelsfrei fest, so wird er fuer eine Einspruchsfrist von 14 Tagen temporaer gelistet. In dieser Zeit darf er ausser der Erstellung und Weitergabe des Regionfiles keine weitergehenden Pflichten des RC24 uebernehmen, sofern dies technische Probleme nicht zwingend erfordern. In dieser Zeit eingehende Complaints werden aufgeschoben; der Eingang ist fristwahrend. Diese 14-taegige Frist ist vom scheidenden und neuen RC sowie den NCs der Region dazu zu nutzen, notwendige Anpassungen an ihrem System vorzunehmen. 10.4.5 Uebergabe der Amtsgeschaefte Die Uebernahme/Uebergabe der Amtsgeschaefte zwischen altem und neuem RC muss zuegig erfolgen; in jedem Fall ist der ZC2 von der vollzogenen Uebergabe so rechtzeitig in Kenntnis zu setzen, dass er die notwendigen Anpassungen an seinem System vornehmen kann, ohne dass es zu Stoerungen (z.B. Nicht-Annahme des R24-Segmentes wegen Passwort-Fehler) kommt. 10.4.6 Amtsperiode des RC 24 Die Amtsperiode des RC24 betraegt maximal 12 Monate. 10.4.7 Abwahl des RC, vorgezogene Neuwahlen Der RC 24 kann jederzeit von den Nodes oder NCs der Region abgewaehlt werden, bevor seine regulaere Amtszeit beendet ist. Abwahlen finden durch komplette vorgezogene Neuwahl eines Nachfolgers gemaess Abschnitt 10.4.1 bis 10.4.6 dieser Policy statt (konstruktive Neuwahl). Um eine vorgezogene Neuwahl einzuleiten, ist die schriftliche Zustimmung von 1/5 der stimmberechtigten Nodes der Region oder von 1/3 der NCs der gelisteten Netze erforderlich. Darueber hinaus muss zusaetzlich mindestens ein Kandidat benannt werden, der verbindlich bereit ist, sich zur Wahl als RC zu stellen. Auch bei vorzeitiger Amtsniederlegung des RC oder bei Amtsenthebung wegen Nichterfuellung der Amtspflichten wird eine vorgezogene Neuwahl faellig. Bei der vorgezogenen Neuwahl kann der momentane Amtsinhaber ebenfalls wieder kandidieren. Solange die vorgezogene Neuwahl nicht abgeschlossen ist, darf der amtierende RC keine Aktivitaeten unternehmen, die das Verfahren in irgendeiner Weise behindern. Er darf keine nur schwer rueckgaengig zu machende Fakten schaffen. Saemtliche von ihm durchgefuehrten sonstigen Aktivitaeten waehrend der Wahl sind bis zu deren Abschluss als vorlaeufig zu betrachten. 10.4.8 Anpassung der Regelungen Sollte zonenweit ein Dokument, das die RC-Wahl beschreibt, die Zustimmung der Nodes finden und in Ergaenzung der allgemeinen Policy in Kraft treten, so erfolgt - falls erforderlich - eine Anpassung dieser Policy. 10.5 Glossar AB : Abkuerzung fuer "annoying behaviour" = veraergerndes Verhalten Absolute Mehrheit : mehr als 50 % der Stimmen Appeal : Formale Berufung gegen die Entscheidung eines Complaints CM-System : Continous Mail faehiges System - akzeptiert 24 h Mail Complaint : Offizielle formale Beschwerde eines Node Inbound-Netmail : Netmail an einen bestimmten Node eingehend "in-transit" Netmail : Geroutete Netmail, die sich von einem anderen System kommend voruebergehend auf einem System befindet und von dort aus an ein anderes System weitergeroutet wird. Das System, auf dem die Netmail sich befindet, ist weder ihr Ursprung noch ihr Ziel. I/O-Gate : Sozusagen der "Host der Region", d.h. alle Hosts der Netze tauschen der Einfachheit halber ueber ein zentrales System - das I/O-Gate - die Netmail aus. Frueher musste demgegenueber jeder Host jeden anderen anrufen, um die Mail der Netze auszutauschen. Das wird durch die Loesung mit dem I/O-Gate vermieden. Mitglied im FidoNet : Jeder, der in der aktuellen FidoNet-Nodelist aufge- fuehrt ist. Offence : Verstoss gegen eine Regel oder Gewohnheitsrecht Outbound-Netmail : Netmail von einem bestimmten Node abgehend Teilnehmer am FidoNet : Jeder, der unter Nutzung von FidoNet Echo - oder Netmail mit anderen kommuniziert. Wahlen: - Allgemeine Wahlen : Jeder hat eine Stimme, der in der vom Wahlleiter benannten Nodeliste im Netzsegment des jeweiligen Netzes gelistet ist. - Freie Wahlen : Jeder Node eines Netzes/einer Region hat das Recht zu kandidieren. - Gleiche Wahlen : Genau eine Stimme pro Person. - Unmittelbare W. : Direkte Wahl ohne Delegierte, Stimmen sind nicht ueber- tragbar. - Geheime Wahlen : Es darf nicht bekannt werden, wer fuer wen gestimmt hat. Einzige Personen, die Kenntnis von der Wahlent- scheidung haben duerfen (und aus verfahrenstechnischen Gruenden auch haben muessen) sind der Wahlleiter und der Wahlkontrolleur. XAB : Abkuerzung fuer "excessively annoying behaviour"; deutsche Uebersetzung: extrem veraergerndes Verhalten Dieses Verhalten kann im Falle eines formalen Complaints zum Ausschluss des betreffenden Systems aus Fido fuehren.