**********  HISTORY-FILE zum Entwurf der Region-Policy 24 *********


>>>>>>>    *** 21.01.96 V. 1.00  (Release)


- Regelungen ueber eine eigene ZMH fuer R24 wurden wieder entfernt, weil
sich kein Ende der anhaltenden zonenweiten Diskussion darueber abzeichnet, 
und der ZC trotz mehrfacher Aufforderung keine Entscheidung zu dieser An-
gelegenheit treffen will. Darueberhinaus wurden einige praktikable Vor-
schlaege gemacht, wie die bestehende Problematik auch ohne selektive Ver-
schiebung der ZMH nur in R24 geloest werden kann, so dass diese Proble-
matik nicht mehr notwendigerweise in eine RegionPolicy gehoeren muss.

- Neuregelung: Networkpolicies, die vom RC abgelehnt wurden, koennen mit 
absoluter Mehrheit der stimmberechtigten Mitglieder des NCC genehmigt 
werden, somit Einschraenkung willkuerlicher Entscheidungen.

- Neuformulierung des Punktes 7.5 Ausschluss von Fido-Teilnehmern aus 
dem Netz; Praezisierung der Formulierung. Absolute Mehrheit der NCC-
Mitglieder erforderlich fuer Ausschluss.

- Ueberarbeitung des Nodeantrages; verstaendlichere Formulierungen.

- Erneut Korrekturen von Orthographie und Zeichensetzung, diverse 
sinnwahrende Umformulierungen.

- Ansonsten: Auf zur Abstimmung... :)


(DN)


>>>>>>>    *** 18.01.96 V. 0.95 (nicht veroeffentlicht) 

- Aenderung der Richtlinien zur Aufspaltung eines Netzes: 2/3 Mehrheit 
nur noch der DIREKT betroffenen Nodes (AKA-Umstellung) erforderlich. 
Erfahrungen mit der Netzgruendung 2432 machten deutlich, dass die alte 
Regelung nicht praktikabel war. Einsprueche von nur indirekt betroffenen 
Nodes auch weiterhin moeglich. Kompromiss durch RC. 

- Umformulierung des Abschnittes ueber seen-by-adding

- Praezisierung der formalen Anforderungen eines Complaints (da zuvor 
missverstaendlich formuliert)

- Neuformulierung der Bedingungen von Policies auf Network-Ebene.

- umfangreiche orthographische Aenderungen/Korrekturen, sinnwahrende 
Ueberarbeitung vieler Formulierungen.


>>>>>>>    *** 13.12.95 V. 0.94

- komplette Neugliederung des Textes der besseren Uebersichtlichkeit 
halber 
- Einarbeitung der waehrend der Diskussion in node_org.024 und per 
Netmail ausgetauschten Argumente
- Kuerzung wo immer moeglich, Praezisierung der Formulierungen
- Ueberarbeitung der Kapitel Netmail/Echomail und Routing
- Umbenennung DFR -> NCC
- Hinzufuegen des Kapitels "ZMH in R24" aufgrund der neuen Telefontarif-
struktur ab 1.2.96
- etc.

Sonstiges: Diese Version ist als pre-release der zur Abstimmung 
vorgesehenen Version anzusehen; die Vorstellung der endgueltigen Version 
mit anschliessender Abstimmung aller Nodes der Region wie vorgesehen ist 
fuer Mitte/Ende Januar geplant. 


>>>>>>>    *** 13.11.95 V. 0.93

Erneut Einarbeitung umfangreicher Kritik und konstruktiver Beitraege 
aus den Diskussionen und Umfragen im Node-Echo. 
Die Vielzahl der Aenderungen macht es unmoeglich, alle einzeln 
aufzufuehren. Zum direkten Vergleich sei nochmals an das Tool VCOMP 
erinnert, das direkten graphischen Vergleich zweier Files zulaesst, 
und im Archiv der Version 0.92, die hier (2:24/0) unter REGP092.ZIP 
frequested werden kann, enthalten ist.
Wichtigste Aenderungspunkte aufgrund umfangreicher Kritik seitens der 
Nodes waren der Entfall der sog. RP-Points, die Neuformulierung der 
Regelungen zum Netmailrouting und Cryptmail und viele weitere Praezisie-
rungen und Korrekturen, die nicht alle aufgrfuehrt werden koennen.
Sollte jemand einen bestimmten Punkt gehabt haben, der in frueheren 
Versionen seine Kritik hervorgerufen hat, so sollte er sich die Verson 0.93
diesbezueglich durchsehen; viel Kritik ist durch die Ueberarbeitung gegen-
standslos geworden.
Zusaetzlich beigefuegt wurde das Beispiel eines formalen Complaints, weil 
erfahrungsgemaess hier in der Praxis oftmals Unsicherheiten bestehen.
Darueberhinaus wurde deutlich straffer und kuerzer formuliert, was sich in 
einer Verminderung der Laenge trotz thematischer Erweiterung niederschlaegt.

Ausblick: es stehen noch Stellungnahmen des ZC2 wegen eines User-Flags 
fuer Crypt-Mail und einer Verschiebung der ZMH in R24 anlaesslich der neuen 
Telefontarifstruktur der Telekom aus; sobald diesbezueglich naeheres in
Erfahrung gebracht werden konnte erfolgt die Einarbeitung in eine neue 
Version. 

Weiterhin ist unter Magic REGPOL jeweils die aktuelle Version der Region-
Policy hier zum Frequest verfuegbar; diese Version 0.93 wird im File-Echo 
NODEDIFF zusaetzlich gehatcht. 

(DN)


>>>>>>>    *** 20.10.95 V. 0.92

Einarbeitung umfangreicher Argumente aus der nun langsam angelaufenen
Diskussion im Echo node_org.024, unter anderem von Peter Garben,
Carsten Hoenig, Peter Hampf, Helmut Hullen, Henning Moeller, Tobias Burchardt,
Eckhard Mueller, Martin Fischer, Hinrich Donner, Petra Fiene.
Und natuerlich auch vom bewaehrten Regpol-Development Team.. :)
(Man verzeihe mir, wenn ich den einen oder anderen in der Aufzaehlung
vergessen haben sollte. Alle Argumente im Echo und per NM wurden registriert,
und soweit machbar in das Konzept eingearbeitet.
Jedenfalls waren die bei mir eingegangenen Netmails und Aenderungsvorschlaege
bis ins Detail absolut umwerfend, und diese Beteiligung zeigt mir, dass
die Nodes motiviert und engagiert an einer Regpol mitarbeiten WOLLEN, wenn man
sie nur laesst. Dieser Sachverhalt gibt mir persoenlich und allen Beteiligten
unseres "RDT" auch die Motivation, mit der zeitlich sehr aufwendigen Arbeit an
der RegPol weiterzumachen.)

Es wurden umfangreiche Aenderungen an Formulierungen und Orthographie
vorgenommen, die von Hand garnicht mehr hier aufgezaehlt werden koennen.
Ich habe mich deshalb eines DIFF-Generators bedient. Wo das Ergebnis etwas
unuebersichtlich ist bitte ich um Verzeihung und Verstaendnis.
Zur besseren Uebersichtlichkeit habe ich dem Paket das tool "vcomp" beigefuegt,
welches einen einfachen und schnellen visuellen Vergleich der beiden Versionen
erlaubt.

Aufruf: vcomp file1 file2

Die wesentlichen Aenderungen folgen untenstehend. Das komplette Diff-File haette
65 KB Umfang gehabt.. =:)

Zum Thema points: dieser sehr umstrittene Punkt bedarf weiterer Diskussion.
Durch die Beitraege in den verschiedenen Mails in der node_org.024 konnte ein
erstes Bild von der Meinung der Nodes gewonnen werden, gleichwohl bleibt die
Frage, ob dies repraesentativ ist. Ich erinnere in diesem Zusammenhang an den
in Node_org.024 geposteten Fragebogen, den zu beantworten und mir per NM zukom-
men zu lassen ich herzlichst erbitte. Er wird sicherlich eine entscheidende
Rolle bei der weiteren Bearbeitung dieses Themas sowie der Behandlung dieses
Punkts in der endgueltigen Version der RegPol spielen. Ich danke vor allem
Jens Mueller und Andy Kreuzer fuer ihre engagierte Diskussion bei dieser Pro-
blematik, die zur Bewertung der Situation und zur Reflektion des Sachverhalts
durch die Nodes sicherlich nicht unwesentlich beigetragen haben.

Da dieser wichtige Kritikpunkt zum jetzigen Zeitpunkt noch nicht ueberarbeitet
bzw. angepasst wurde, betrachte ich die V. 0.92 der RegPol als Uebergangsversion
bis ein klares und eindeutiges Bild ueber den Willen der Nodes zum Thema Points
vorliegt.

Ach ja: durch die Aenderungen und Straffungen hat der Umfang der RegPol 
erstmals ABgenommen.. :)


(DN)

---------------------------------------------------------------------------
Diff-File der geaenderten Text-Stellen 0.91 --> 0.92
(alte Version oben, neue Version unten, getrennt durch ---)


< Zusammenschluss FTS-kompatibler Systeme zu nicht-kommerziellem Zweck
< in der Bundesrepublik Deutschland.
---
> Zusammenschluss eigenstaendiger und eigenverantwortlicher FTS-kompatibler
> Systeme in der Bundesrepublik Deutschland.
> FidoNet dient der Kommunikation unter Hobby-Sysops. 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.



< verletzt, oder die Wahl bzw. das Wahlergebnis durch Aeusserungen oder Taten zu
< beeinflussen versucht, handelt extrem veraergernd (excessively annoying, XAB).
---
> verletzt oder die Wahl bzw. das Wahlergebnis durch Aeusserungen oder Taten zu
> verfaelschen versucht, handelt extrem veraergernd (excessively annoying, XAB).


< Stimmabgaben muessen CRASH und DIRECT geschickt werden, sofern
< nicht technische Gruende dagegen sprechen (z.B. ISDN-only Nodes).
---
> Stimmabgaben muessen unmittelbar an das System des Wahlleiters geschickt
> werden (d.h. nicht ueber andere Systeme geroutet), sofern nicht technische
> Gruende dagegen sprechen (z.B. ISDN-only Nodes). Fuer diesen Fall muss vorher
> eine Vereinbarung zwischen dem Wahlleiter und dem betreffenden Wahlberechtigten
> festgelegt werden.


< Das Wahlergebnis wird grundsaetzlich binnen 3 Tagen nach Ende des Abstimmungs-
< zeitraumes vom  Wahlleiter veroeffentlicht, sofern in dieser Zeit der
< Kontrolleur das Ergebnis ueberprueft und bestaetigt hat.
---
> Das Wahlergebnis wird binnen 3 Tagen nach Ende des Abstimmungszeitraumes vom
> Wahlleiter veroeffentlicht, sofern in dieser Zeit der Kontrolleur das Ergebnis
> ueberprueft und bestaetigt hat.
> Verzoegern ein Wahlleiter oder ein Wahlkontrolleur bewusst die Veroeffentli-
> chung des Wahlergebnisses, so ist dies als XAB zu betrachten.


< Moeglichkeit "Enthaltung" entfallen sind.
---
> Moeglichkeit "Enthaltung" entfallen sind. Ausserdem muss eine Liste aller
> Nodes veroeffentlicht werden, die abgestimmt haben.


< ersten Wahlergebnisses per Netmail an die Kandidaten und alle Stimmberechtigten
< sowie Veroeffentlichung im Node-Echo diejenigen Kandidaten des ersten Wahlgangs,
< die das beste und zweitbeste Ergebnis erzielt haben (unter Nicht-Beruecksichti-
< gung der Wahlmoeglichkeit "Enthaltung"), und sammelt erneut innerhalb 2 Wochen
< die Stimmen der Nodes in Analogie zum ersten Wahlgang.
---
> Ergebnisses des ersten Wahlgangs per Netmail an die Kandidaten und alle Stimm-
> berechtigten sowie Veroeffentlichung im Node-Echo diejenigen Kandidaten, die
> das beste und zweitbeste Ergebnis erzielt haben (unter Nicht-Beruecksichti-
> gung der Wahlmoeglichkeit "Enthaltung").
> 
> Diese Kandidaten bestreiten den zweiten Wahlgang.
> 
> Der Wahlleiter sammelt erneut innerhalb 2 Wochen die Stimmen der Nodes in
> Analogie zum ersten Wahlgang.
> 



> 3.10 Verfahrensweise bei weniger als 2 Kandidaten

> Sollte sich nur ein Kandidat finden, nimmt dieser die Position des NC des
> betreffenden Netzes ein, es sei denn, mindestens 10 % der Nodes fordern eine
> Abstimmung.
> 
> In diesem Fall stellt sich der Kandidat zur Abstimmung gegen die
> Wahlmoeglichkeit Enthaltung.
> 
> Sofern diese Person gerade zuvor wegen mangelnder Erfuellung der Pflichten
> ihres Amtes enthoben oder durch die Nodes abgewaehlt worden ist (3.12, 13.2.3)
> existiert formal die Situation, dass keine Kandidaten vorhanden sind.


< 3.11 Amtsdauer
> Die Amtsperiode eines NC in R24 betraegt maximal 2 Jahre, beginnend mit der
> Verkuendung des Wahlergebnisses.

> {Netz-Policies koennen die Regelungen dieser RegPol ergaenzen und
> bezueglich lokaler Besonderheiten praezisieren. Dabei duerfen aber keinesfalls
> die in dieser RegPol festgelegten demokratischen Rechte der Nodes
> eingeschraenkt werden.}


< Wo immer moeglich ist bei Netmail auf ein klares HUB-HOST-Routing zu
< achten. Falls praktikabel und zuverlaessig koennen NM-Wege den
< existierenden Echomail-Wegen folgen. Die ausdrueckliche schriftliche
< Zustimmung aller dadurch betroffenen Netmail-Verantwortlichen (HUB,
< HOST, I/O-GATE) und ggf. der betroffenen Nodes ist zuvor einzuholen.
---
> Wo immer moeglich ist bei INBOUND-Netmail fuer andere Nodes auf ein klares
> HOST-HUB-Routing zu achten.
> Falls sich in Einzelfaellen vorteilhaftere Moeglichkeiten fuer ein Netmail-
> Routing ergeben, insbesondere hinsichtlich der Kosten, der Laufzeit der
> gerouteten Mails und der Zuverlaessigkeit, koennen diese in Absprache mit dem
> NC als Netmailverantwortlichem des Netzes und mit dem Einverstaendnis der
> Nodes, denen durch dieses Routing erhoehte Kosten entstehen koennten, genutzt
> werden.


< Netmails von Moderatoren in Wahrnehmung ihrer Aufgabe muessen durch das Gate
< kostenlos befoerdert werden; kann oder will ein Gate diese Auflage nicht
< erfuellen, so darf auch kein Gating von Echomail mit Schreibmoeglichkeit der
< User auf Gate-Seite erfolgen.
---
> Netmails muessen durch das Gate kostenlos befoerdert werden; kann oder will
> ein Gate diese Auflage nicht erfuellen, so darf auch kein Gating von Echomail
> mit Schreibmoeglichkeit der User auf Gate-Seite erfolgen.



> 9.2 Relays
> 
> Fuer ein Relay gelten die Vorschriften von 9.1 dann, wenn durch das Relay
> mehrere Mailboxen mit Echomail versorgt werden.
> Relays, die lediglich fuer die lokalen Beduerfnisse eines Nodes eingesetzt
> werden, benoetigen keine Genehmigungen.
> 


< Missbrauch der FidoNet-Echos durch User fuer extremistisch-politische,
< kriminelle oder anderweitig strafrechtlich relevante Messages verhindert wird.
---
> Missbrauch von FidoNet-Echos durch User fuer extremistisch-politische,
> kriminelle oder anderweitig strafrechtlich relevante Messages so weit wie
> moeglich verhindert werden kann.
> Wenn wiederholt entsprechende Nachrichten ueber dasselbe System in FidoNet
> gelangen, wird dies als XAB betrachtet.
> Die strafrechtliche Verantwortlichkeit des Verfassers bleibt davon unberuehrt.



< Nachrichten an, so muss er per direct-mail empfangene verschluesselte
---
> Nachrichten an, so sollte er per direct-mail empfangene verschluesselte


> Ist ein Node nicht damit einverstanden, verschluesselte Netmail an seine
> direkten Downlinks im Sinne des obigen Absatzes zuzustellen, so muss er dies
> seinem Downlink ausdruecklich mitteilen, damit dieser sich anderweitig um
> eine Moeglichkeit bemuehen kann, die Netmail vertraulich zu erhalten.


< oder User kann eine Verschluesselung regelmaessig keine Grundlage fuer eine
< Beschwerde sein.
---
> oder User kann die Verschluesselung an sich im einmaligen Fall keine Grundlage
> fuer eine Beschwerde sein.
> In diesem Fall ist der Absender der Mail darauf hinzuweisen, dass
> verschluesselte Mails nicht an den direkten Downlink weitergeleitet werden,
> und er sich eine andere Moeglichkeit zur Zustellung suchen muss.


> 13.2.3 Vergehen im Amt ("Administrative  Offence")

> Veraergerndes Verhalten als Amtsinhaber in FidoNet durch
> - Missbrauch der Amtsgewalt
> - Vernachlaessigung der Amtspflichten
> - Verstoss gegen die Policies.


< Verfasser per Netmail mitzuteilen. Ein Complaint ist dann aus den gleichen
< Gruenden fuer diesen Verfasser nicht mehr moeglich.
---
> Verfasser per Netmail mitzuteilen. Das Complaint wird in diesem Falle
> unbearbeitet an den Verfasser zurueckverwiesen.



> 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.


< hang stehender formeller Mails darf nur mit Zustimmung aller Betroffenen
---
> hang stehender formeller Mails darf nur mit ausdruecklicher Zustimmung des
> Beschuldigten erfolgen. Veroeffentlicht dieser seinerseits Mails aus dem Com-
> plaintverfahren, so ist von seinem mutmasslichen Einverstaendnis auszugehen,
> und eine Veroeffentlichung von Mails durch die anderen Beteiligten kann


>>>>>>>    *** 8.10.1995 V. 0.91

Einarbeitung einiger konkreter Einwaende auf dem *C-Treffen in Frankfurt
vom 7.10. in die aktuelle Fassung:

1. Seite 5, 1.1, Absatz 6, Satz 3: 
streiche "moeglichst vielen Nodes"
setze "moeglichst vielen seiner Nodes"

2. Seite 5, 1.1, Absatz 9, Satz 3:
streiche "allerdings"

3.  Seite 6, 1.4, Absatz 2, Satz 2:
streiche "alle betroffenen NCs zustimmen"
setze "alle betroffenen NCs in Abstimmung mit ihren Nodes zustimmen"

4. Seite 7, 2, Absatz 5, Satz 2:
streiche "Die Voice-Telefonnummer"
setze "Eine Voice-Telefonnummer, unter der er erreichbar ist"

5. Seite 7, 2, Absatz 5, Satz 8:
streiche "Typ des Mailers"
setze "Typ des Mailers (incl. Versionsnummer)"

6. Seite 8, 2, Absatz 1, Satz 1:
streiche "vom DFR"
setze "vom Deutschen FidoNet Rat (DFR)"

7. Seite 20, 10.2.2, Absatz 1 - 4:
neu formuliert:

"10.2.2 Points aus administrativer Sicht/Vorbemerkungen

{Points sind bis heute formal gesehen User mit spezifischer Point-Software, und
somit keine Mitglieder im FidoNet.

Sie sind als Teilnehmer und Nutzer des Mediums FidoNet nach Policy 4.07
zunaechst ohne weitergehende formale Mitbestimmungsrechte.

Dieser Status erklaert sich aus den Unterschieden in Zone 1, aus der die
momentan gueltige Policy 4.07 stammt, und der Zone 2: Waehrend in Amerika
Points recht selten sind, im Allgemeinen nach einigen Monaten Point-
dasein der/die Betreffende zur Nodewerdung aufgefordert wird, und anstatt
der Points sogenannte QWK-Reader sehr verbreitet sind, stellt sich die
Problematik in Zone 2 gaenzlich anders dar: hier sind Points, die ueber Jahre
bereits am Fido teilnehmen, keine Besonderheit, sondern Selbstverstaendlich-
keit, und nehmen gegenueber den QWK-Readern oder Usern eine qualitativ andere
Stellung ein.

                                    
                                  Seite 21


Points stellen fuer FidoNet die in Nachrichtenbereichen oftmals aktivsten und
fachkompetentesten Teilnehmer dar. Darueber hinaus kommt Fido in seiner
Gesamtheit die Arbeit von Points zugute, die als Moderatoren der Fido-Echos
oder als Autoren von Fido-Software aktiv sind."

[Fortsetzung wie Vorversion]


8. Seite 21, 10.2.3:
Verantwortlichkeit, Wahl der Pointlistkeeper, neu formuliert:

"Auf Netzebene sind die Netz-Pointlistkeeper fuer die Erstellung der jeweiligen
Pointliste verantwortlich. Sie werden von allen gelisteten RegPol-Points
gewaehlt.

Fuer die regionenweite Pointliste ist der Regionen-Pointlistkeeper verantwort-
lich; er wird von den Pointlistkeepern der Netze gewaehlt."

[Fortsetzung wie Vorversion]


9. Seiten 25 - 27, 13 - 13.2.6:

Ersetzen der englischen Begriffe durch die entsprechende deutsche Uebersetzung
zB. Echomail-Vergehen ("Echomail-Offence")
                                          
 
Sowie Anpassung von Seitenlayout, Inhaltsverzeichnis und Nummerierung.



>>>>>>>    *** 5.10.1995  V. 0.90

Erstes oeffentliches Proposal, das durch eine Arbeitsgruppe zur Entwicklung 
einer Region-Policy 24 nichtoeffentlich erarbeitet wurde.

Vorstellung auf einer *C-Con in Frankfurt am 7.10.1995, am gleichen Tage
Freigabe zum oeffentlichen Frequest und zur Diskussion in NODE_ORG.024.

Grundlage aller weiterhin zukuenftig erfolgenden Aenderungen, und unter 

REGP090.024

hier zu frequesten.

Unter dem Magic REGPOL erhaelt man jeweils die aktuelle Version des RegPol-
Proposals.
Unter dem Magic REGPOLECHO erhaelt man ein Archiv, das alle Mails des nicht-
oeffentlichen Echos der RegPol-Entwicklungsgruppe im *.MSG-Format enthaelt
(1.2 MB)

/410 USR V34+
/411 USR HST DS
/412 Elink X75

(DN)




