Date: Tue, 01 Sep 1992 02:26:00 CET
From: frank.simon@sol.zer.sub.org
Reply-To: frank.simon@sol.zer.sub.org
Distribution: world
Newsgroups: de.comm.gateways
Subject: Re: Stockende Gates :-/ III
Organization: Zerberus Network Area, Germany
Content-Length: 9777    
X-Gateway: UU uzercp [UZERCP V3.98]

Hallo,

v.ulle@a-link-h.zer writes:
>> >wenn sich auch alle Gateways daran halten!  Wenn sie es nicht
>> >taete, haettest Du jeden Tag die Freude, ca.  400 kB Dupes 
>> >lesen zu duerfen, die Dir dank der GateBau aber erspart 
>> >bleiben.
>> Stimmt. Es waren ja letztens nur 300 KB. :-)
>Ich weiss nicht, was Du mit dieser Polemik bezwecken willst.
Oh. Entschuldige - ich nehme da nur Anleihen. :-)

>Du
>weisst genau, durch wen diese Dupes entstanden sind und dass sie
>nichts mit angeblichen Fehlern der GateBau zu tun hatten. Auch
>Dein "Code of conduct" haette sie nicht verhindern koennen. 
Die Aussage ist schlicht und einfach falsch. Was bei dir mit den
News passiert ist, die dann via UZERCP wieder im Z-Netz gelandet
sind, kommt hier auch regelmaessig vor. (Auch wenn die UZERCP zwar
Mittler der Dupes, nicht jedoch Verursacher war). 
Das laesst sich eben bei einen Wildwuchs nicht vermeiden, dass sowas
mal vorkommt. 

Nur leite ich (und in einen anderen Fall auch die URANUS) den Kram
_nicht_ weiter. Du verstehst einfach den CoC nicht oder hast ihn
nicht gelesen. Wenn ich News von einen wilden Gateway bekommen wuerde
(z.B. zer.*), dann sind fuer mich ALLE Absender nicht berechtigt. 
Sie gehoeren nicht zu meinen Zustaendigkeitsbereich und damit wuerde
ich sie nicht weiterleiten. Die Praxis hat gezeigt, dass es so auch
funktioniert.

>Denn
>wenn jemand sich Nachrichten hernimmt, sie mit neuen Absendern
>und Message-Id's versieht und ins UseNet postet, kannst auch Du
>nichts verhindern! 
Nein. Und da ich keinen Computer bauen kann, der ueber "natuerliche
Intelligenz" das feststellt, bin ich aber noch lange nicht reinge-
fallen. 

Solange er seine Absender nicht alle auf sonst@sol.ccc.de aendert,
stoert mich das GARNICHT. DIe Nachrichten gehen NICHT weiter. Das
ist der Unterschied zwischen einen System, welches als _alleinige_
Basis Dupeerkennung kennt (GateBau) und einen System, welches
als 1. Massnahme auf Dupevermeidung setzt (und zwar bei mir und
nicht bei den anderen).

>Ich verstehe garnicht, warum es ueberhaupt eine Message-Id im
>Z-Netz gibt! Diese waere doch eigentlich garnicht noetig, oder?
Im Fido gibt es sie ja anscheinend bis heute nicht. Bezueglich
Z3.8 sind wir ja einer Meinung, nur ist es ein Unding (und da
waere ich mich als als Z-Netz-SysOp), dass einfach von der
GateKoo entschieden wird, dass im Zerberus jetzt ein neuer
Kompatibiliatsstandard zu gelten hat. 

>- nichts neues von ihm zum Thema Gateways gehoert habe. Er haelt
>sich bisher nur an den alten Konfliktpunkten auf, sagt aber
>nicht, wie er sich eine funktionierende Vernetzung aller Netze
>mit vielen verschiedenen Gateways vorstellt. 
Stimmt. Holger: Ab ins Kaemmerelei und lass de.comm.gateways
in Ruhe. :-)

>auseinandergesetzt hat. Aber auch das ist nicht der Fall. Du
>verstehst nun vielleicht, warum ich voreingenommen bin?!
Oh. Verstehen kann ich es schon, nur akzeptabel finde ich es
nur bedingt. 

>for gateways) beschaeftigt. Deine administrativen Loesungen
>halte ich auch fuer durchaus zweckmaessig. Ich finde nur, dass
>man nicht ALLEIN auf diese Loesungen zurueckgreifen sollte,
>sondern sie kombiniert mit den technischen Loesungsansaetzen der
>GateBau einsetzen sollte. Das geschieht ja auch schon zum Teil.
Unterschrieben. Ich zitiere aus dem CoC:

5)[..]
    b) Die GateBau'90 (sobald schriftlich niedergelegt: GateBau '91) ist eine 
       Empfehlung zur Implementation von Gateways, soweit sie nicht 5a wider-
       spricht. Nur Gateways die GateBau-Konform sind, duerfen einzelne
       Newsgruppen/Bretter oder ganze Hierachien (wo dies durch das dort 
       uebliche Verfahren erlaubt wurde) "gaten". Sonst gelten die Regeln
       in (1)

>Dupes. Trotzdem finde ich, sollte man die technischen Loesungen
>zu allererst einfordern und sich nicht mit kleineren Loesungen
>zufrieden geben. Das beste ist grade gut genug fuer die Zukunft!
Ok. Da ist eben unsere Differenz. Damit die Gateway-Programmierer/Betreiber 
nicht so eingeengt werden, wenn sie mal neue (z.B. ergonomische) 
Ansaetze ausprobieren wollen, sollten die administrativen Regeln erstmal
eingefordert werden. Sie lassen sich auch durch Testdaten durch eine
GateKoo schneller auf korrekte Funktionalitaet pruegeln (es gibt
nur endlich viele Faelle). 

>Die administrativen Loesungen sehe ich eher als Ergaenzung zur
>technischen Loesung!
Ja. :-)

>gehen sollten. Bedenke bitte, dass die ganzen RFC's rein
>technische Loesungen sind!!! 
Oh. Es werden aber in der RFC-Welt verdammt viele Fragen administrativ
erschlagen. Meistens steht dann in solchen Text dann ein Verweis
auf ein RFC. 

>zum Laufen kriegt. Ab einer gewissen Groesse versagen
>administrative Loesungen naemlich erfahrungsgemaess, bzw. machen
>viel mehr Arbeit, als die technischen Loesungen!
Sie machen mehr Arbeit - aber da wo sie hingehoert. Beim SysOp 
der einzelnen Site (er muss sich anmelden, seine Userleins informieren,
etc). Der Gateway-Betreiber hat Tabellen zu verwalten - dass muss
er jetzt aber auch. 

Und technische Loesungen werden haeufig vom "menschlichen" Versagen
erschlagen. Der Beweis, dass ein Programm das tut was es soll und
das es nicht tut, was er nicht soll ist verdammt schwer (wie dir
jeder Informatiker bestaetigen kann). Die GateBau ist inzwischen
so komplex, dass eine Beweisfuehrung (z.B. durch Sourceanalyse)
nicht mehr moeglich ist. Du kannst ein Gateway also nur noch mit
Testdaten ueberpruefen. Und da kannst du die CoC-Funktionalitaet
leichter ueberpruefen, weil dort weit aus weniger Faelle zu
beachten sind, als bei einen Test der GateBau-Funktionalitaet. 

Der Status der Gateway-Zulassung sollte naemlich beibehalten werden
und die muss ja durch eine Koordination _auch_in_der_Praxis_
gemacht werden.

>weitgehende Fehlerfreiheit bei allen Gates ist. Wenn dann
>ploetzlich Dupes auftreten, ohne dass die bestehenden Gates
>etwas geaendert haben, liegt die Schuld dafuer mit 99.99
>prozentiger Sicherheit nicht an den bestehenden Gates! 
Das werde ich beim naechsten Dupe-Katatrophe der SOL (die
CoC verhindern moege :-) ) unter die Nase reiben. :-)

>nicht in Deinem Interesse. Nach Deinem Werk ist naemlich gerade
>die Absprache unter den Systemen sehr wichtig zur Dupe-Vermeidung.
Unter den Gateways ?  Wieso ?

Die Gateway-Software wird abgenommen. Sie wird eingestuft als

Gateway der Kat. 1 (CoC-Funktionalitaet) - dann darf sie nur
(ne nachdem ob 1 oder 2-Weg-Gateway und was Ursprungs/Zielnetz ist)
nur in einen Zustaendigkeitsgebiet arbeiten. Aber eine Absprache
ZWISCHEN Gateways ist nicht notwendig. Mit URANUS und KRISKI 
habe ich seit Ewigkeiten nicht mehr gesprochen - zuletzt eigentlich
als wir mal quantifiziert haben, wie unsere Gateways eigentlich
arbeiten. (Und woraus der CoC-text von mir dann geschrieben wurde).

Gateway der Kat. 2 (GateBau-Funktionalitaet) - dann darf sie 
alles und muss ja auch Informationen mit anderen Gateways der
Kat. 2 austauschen. 

>an gewisse Grundlagen halten muss. Sonst braeuchten wir keine
>Koordination und keine Wahlurne. 
Ok. Sagen wir es so: Im Z-Netz haben die Leute eine Abneigung
gegen zentrale Instanzen. Ob das jetzt gut oder schlecht ist, 
moechte ich nicht bewerten. Auf jeden Fall machen sie den
Koordinations-Job im Z-Netz alles andere als zu einen angenehmen
Job. Das weisst du ja aus eigener Erfahrung.

>Wie gesagt: Auch mit Deinem System waere hier eine Vermeidung
>nicht moeglich gewesen, wenn jemand im Umkreis Deines Gates
>sowas einspeist.
Ah. Da ist der Denkfehler. Ich schaffe mir ja ein Zustaendigkeits-
bereich. Das tue ich ja nicht, indem ich sage, dass in diesen
kein anderes Gateway existieren darf oder das in diesen Bereich
"von aussen" keine Nachrichten kommen duerfen. (Das wir das hier
tun, hat andere Gruende). Beim Gateway wird ja erst geprueft,
ob ein Posting ins Z-Netz darf oder nicht. Dort mache ich den
Check, wer der Absender ist und ab geht die Post (oder eben
nicht). 

Es muss nur sichergestellt werden, dass ein System sich nur
bei einen Gateway eintraegt. Da aber (bei mir) der Gateway-
Betreiber einen neuen System u.A. ueber die Geflogenheiten
des Ursprungnetzes (Netiqette, etc) zu informieren hat, 
gehoert dazu auch dem Systembetreiber mitzuteilen, dass er
sich nicht irgendwo anders anmelden soll (ohne sich vorher
abzumelden). Tut er es doch, wird das System nach der
"ueblichen" Netiqette des Ursprungnetzes behandelt - also
z.B. im Z-Netz nach Verwarnung ausgeschlossen.

>> Deswegen entstehen hier noch lange keine Dupes.
>...aber nur dann, wenn Du alle User registrierst, die Deinen
>Gate benutzen duerfen, oder alle Nachrichten von Hand
>durchsiehst (Zensur). 
User ?  Meinst du wirklich, dass ich hier USER eintrage ?  
Nie getan - ich trage Systeme ein. Die Liste ist sehr kurz.

>> Die Uebertragungssicherheit z.B. in OL ist hier bei uns erst 
>> durch die Software auf SOL und spaeter durch OLIS erreicht 
>> worden. Versuche sich vorher rauf die Einspielungen von 
>> UZERCP und anderer zu verlassen war immer ein Vagabundspiel. 
>Tja, Du beziehst Dich jetzt auf die Probleme in der Anfangszeit
>um 1989/90 herum. 
Das mag sein. Seit dem wir unsere eigene Loesung haben (Ende
1990) haben wir uns ja um die Stabilitaet der "anderen" 
Loesungen keine Gedanken mehr gemacht. Allerdings hatten wir
Anfang 1991 mal noch eine Phase, wo wir die News wieder von 
der FU Berlin bezogen haben. Dort hatten wir dann (damals)
auch noch den Fido-Effekt (alle 2-3 ein Schwung an News).

>viel getestet und programmiert wurde. Ich erinnere mich aber
>auch lebhaft an die Probleme, die Du auf der SOL am Anfang
>hattest. Ich glaube nicht, dass es fair ist, die
>Unzuverlaessigkeit von Software oder Gateways heutzutage an
>Situationen festzumachen, die Jahre zurueckliegen, als noch
>experimentiert wurde.
Ja. Hast Recht. Das war ein Schnellschuss. Bitte ignoriert