Date: Sun, 30 Aug 1992 11:48:00 CET
From: v.ulle@a-link-h.comlink.de
Reply-To: v.ulle@a-link-h.comlink.de
Distribution: world
Newsgroups: de.comm.gateways
Subject: Re: Stockende Gates :-/ III
Organization: Aquila Jugendmailboxprojekt Langenhagen
Content-Length: 17107   
X-Gateway: UU uzercp [UZERCP V3.98]

Am Do, 27.08.92 um 03:58 schrieb FRANK.SIMON@SOL.ZER
im Brett /Z-NETZ/TELECOM/GATEWAY
unter dem Betreff 'Re: Stockende Gates :-/ III'.
Referenz-Id: 1233@SOL

> >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. 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. Denn
wenn jemand sich Nachrichten hernimmt, sie mit neuen Absendern
und Message-Id's versieht und ins UseNet postet, kannst auch Du
nichts verhindern! Es ist naemlich durch noch so pfiffige
Methoden (ausser durch Volltextvergleich) nicht zu erkennen, ob
eine Nachricht schonmal im Netz gepostet wurde, wenn Absender
und Id neu generiert werden.

> >> Das Ergebnis sind regelmaessige DUPE-Orgien im Z-Netz, 
> >> weil mit untauglichen Methoden gearbeitet wird.
> >> (Die ID alleine ist kein echtes Kriterium)
> >Die Id ist das einzige gueltige Kriterium fuer die Identitaet
> >einer Nachricht! 
> Nicht im Z-Netz. Dort wird von der Koordination immer wieder 
> festgestellt, dass die Grundlage Zerberus V3.8 ist. Und dort 
> ist nicht die ID alleiniges Kriterium, sondern auch Absender 
> und groesse der Nachricht.

Du hast den Empfaenger vergessen! (Sorry fuer diese Polemik)
Ich verstehe garnicht, warum es ueberhaupt eine Message-Id im
Z-Netz gibt! Diese waere doch eigentlich garnicht noetig, oder?

> >Wenn Du die Dupe-Erkennung anhand der
> >Message-Id als untauglich bezeichnest, disqualifizierst Du 
> Dich [..]
> Seit dem Holger zum Gate-Koordinator gewaehlt ist, versuchst du
> ihn in jeden Beitrag als inkompetent hinzustellen. Dabei hat
> er noch garkeine Chance gehabt seine Arbeit zu organisieren und
> aufzunehmen. 

Okay, vielleicht liegt es daran, dass ich bis heute - ausser
seiner Vorstellung zur Wahl, die 2 Wochen nach Wahlbeginn
eintraf, was fuer mich im Uebrigen der Anlass war, anzunehmen,
dass dieser Job ihn eigentlich garnicht besonders interessierte
- 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. Vielleicht will er
ja auch garkeine weitgreifende Vernetzung, sondern das Z-Netz
lieber unter sich lassen? Aber dann sollte das auch mal gesagt
werden! Denn dann kann man von vornherein allen Neu-Usern sagen,
dass sie - wenn sie auch in fremde Netze schreiben wollen -
nicht User im Z-Netz werden sollen, sondern lieber User im Maus-,
Fido-, Magic-, Seven- oder Usenet!

Ausserdem bin ich vielleicht auch deshalb etwas voreingenommen,
weil jemand Gateway-Beauftragter geworden ist, von dem ich in
drei Jahren _intensiver_ Gatewayarbeit noch nie etwas zum Thema
Gateways gehoert habe. Erst nachdem er sich zur Wahl stellte,
hoerte ich von ihm zum ersten Mal etwas zu diesem Thema. Es ist
wohl verstaendlich, dass ich dann an so eine Person ganz
besonders hohe Anforderungen stelle, die leider bisher nicht
erfuellt werden konnten. Zumindest erwarte ich von so einem
Menschen, dass er sich mit ALLEN Vorschlaegen zum GateBau (auch
mit den Vorschlaegen, die er selbst nicht teilt) intensiv
auseinandergesetzt hat. Aber auch das ist nicht der Fall. Du
verstehst nun vielleicht, warum ich voreingenommen bin?!

> >Nach Deinem Dafuerhalten braeuchten Nachrichten naemlich
> >garkeine Message-Id zur Dupe-Erkennung. 
> Wieso ?  Es gibt Methoden um Gateways zu betreiben, denen ist 
> total togal, wie die MsgID aussieht. :-)

Ich habe mich durchaus mit Deinen Vorschlaegen (Code of conduct
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.
Selbst bei unserem Uzercp-Gate. Dort werden alle oeffentlichen
Nachrichten ausgefiltert, die den Gateway an der SHLINK oder an
der BI-LINK passiert haben. Dies gibt doppelte Sicherheit gegen
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!
Die administrativen Loesungen sehe ich eher als Ergaenzung zur
technischen Loesung!

> >sein: Mit dem neuen ZConnect wird die von Dir gewuenschte
> >Dupeerkennung, die auch noch Absender und Nachrichtenlaenge
> >einbezieht und nur wenn alle drei uebereinstimmen, eine
> >Nachricht ausfiltert (bitte nicht lachen), endgueltig der
> Das ist TOETLICH. Wenn du z.B. eine X.400-Adresse als Absender
> hast, die aber ueber ein beliebiges RFC-Gateways zu deinen
> Zerberus-Gateway gekommen ist, kannst du nicht garantieren, 
> dass sie immer gleich aussieht. 

Eben!!! Deshalb predige ich ja auch seit Jahren, dass allein die
Message-Id zur Dupeerkennung genutzt werden darf! Sicher, Deine
Loesung wuerde das Problem auch erschlagen, aber ich finde nach
wie vor, dass technische Loesungen vor administrativen Loesungen
gehen sollten. Bedenke bitte, dass die ganzen RFC's rein
technische Loesungen sind!!! Auch dort hat man ausschliesslich
auf Technik gesetzt und sich nicht darauf verlassen, dass man
den Nachrichtenverkehr schon irgendwie auf administrativem Wege
zum Laufen kriegt. Ab einer gewissen Groesse versagen
administrative Loesungen naemlich erfahrungsgemaess, bzw. machen
viel mehr Arbeit, als die technischen Loesungen!

> >> Volker hatte natuerlich immer "keine Schuld", 
> >> es "lag immer an den Anderen"
> >Zum einen (fuer einfache Gemueter): Wenn eine Software
> >monatelang dupefrei arbeitet und an ihr nichts geaendert wird
> >und ploetzlich aus heiterem Himmel Dupes auftreten, wer ist 
> >dann wohl schuld?
> Software-technischer Bloedsinn. Du argumentierst hier damit, 
> dass du "Bananen-Software" einsetzt - reift beim Kunden. 

Wie??? Du verstehst auch alles so, wie Du es moechtest. ;-)
Gemeint war vielmehr, dass monatelanger, funktionierender
Betrieb im Zusammenspiel mit anderen Gates ein Beweis fuer
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
wollte ich damit sagen. Und die Erfahrung beweist dies: In
100%(!!!) aller Dupe-Faelle der letzten 2 Jahre lag die Schuld
an einem neuen Gateway, das inkonform war und einfach
unabgesprochen Nachrichten einspeiste, die zu Folgeproblemen
fuehrten.

> Es gibt keine fehlerfreie Software, genausowenig wie es eine 
> "optimale" oder "Software mit geringsten Aufwand" gibt. Wenn 
> deine Software monatelang Dupefrei laeuft, sagt das NIX aus. 
> (Meine tut das ja im Augenblick sogar laenger als deine - 
> trotzdem ist das kein Argument).

Es geht auch nicht um Fehlerfreiheit bei der Software, sondern
um die Schuldfrage beim Entstehen von Dupes! Wenn niemand etwas
aendert, werden auch weiterhin keine Dupes entstehen. Wenn dann
ploetzlich welche entstehen, liegt dies mit grosser Sicherheit
nicht an den bestehenden Systemen, sondern an jemandem, der
unabgesprochen etwas veraendert hat. Das liegt uebrigens auch
nicht in Deinem Interesse. Nach Deinem Werk ist naemlich gerade
die Absprache unter den Systemen sehr wichtig zur Dupe-Vermeidung.

> DIe GateBau geht nunmal davon aus, dass sie alle einsetzen und 
> das du die Moeglichkeit hast dies durchzusetzen. Dieses 
> Konzept in einen erklaerten Buergernetz, wo jeder autoritaerer 
> Beeinflussung auf Widerstand stoesst, war von vornerei zum 
> scheitern verurteilt.

Meinst Du?! Ich denke, dass sich auch in einem Buergernetz jeder
an gewisse Grundlagen halten muss. Sonst braeuchten wir keine
Koordination und keine Wahlurne. Die Frage ist nur, ob diese
Grundlagen einmal aufgestellt werden und dann bis zum juengsten
Gericht aufrecht erhalten werden, weil der Laden nicht in der
Lage ist, Verbesserungen durchzusetzen. Stattdessen wird dann
nur noch administrativ rumgedoktert, bis ein voellig
undurchschaubarer und unkoordinierbarer Sauhaufen entstanden ist
(aktueller Zustand), an dem keiner mehr Interesse hat.

Folge davon: In dem Haufen tummeln sich nur noch Dumpfbacken und
alle guten Leute, die etwas hoehere Ansprueche haben und ein
ueberschaubares und technisch gutes Konzept haben wollen,
wandern zu anderen Netzen ab.

Gegenbeispiel: Die erstaunlich schnelle und konsequente
Durchsetzung von ZMAP. Diese war fuer die einzelnen Systeme mit
ERHEBLICH groesseren Folgen versehen, als es eine Durchsetzung
der GateBau sein wuerde. Ich verstehe z.B. nicht, wieso sich
ZMAP so schnell durchsetzen konnte, waehrend es die GateBau
nicht tat. Ich glaube, dies liegt in erster Linie daran, dass
ich nicht konsequent genug durchgegriffen habe, als ich noch die
Moeglichkeit dazu hatte.  Bei ZMAP wuerde naemlich mit eiserner
Faust durchgegriffen! Und ganz entgegen Deiner Theorie vom
anitautoritaeren Buergernetz!!!

> >Wenn sich jemand 600k Nachrichten aus dem Z-Netz nimmt, diese
> >mit neuen (ungueltigen) Adressen und neuen (ungueltigen)
> >Message-Id's versieht und dann in ein beliebiges Netz 
> >einspeist, kommt es zu Dupes. 
> Solange du "Dupeerkennung" vor "Dupevermeidung" betreibst: Ja.

Wie gesagt: Auch mit Deinem System waere hier eine Vermeidung
nicht moeglich gewesen, wenn jemand im Umkreis Deines Gates
sowas einspeist.

> Du koenntest soviel News mit falschen MsgID und ungueltigen 
> Adressen versehen wie du wolltest, und sie zu mir spoolen. 
> 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). Sowas ist bei einem lokalen Gate
durchfuehrbar, aber nicht bei einem netzweit arbeitetenden Gate.
Bei Gateways bin ich KEIN Freund von lokalen Inselloesungen, die
nur einer kleinen Gruppe zugute kommen!

> >nie an den anderen". Auch eine Philosophie, wenn man zu faul
> >ist, die wahren Ursachen zu suchen.
> Eine Schuldzuweisung an Volker Ulle ist genauso falsch wie 
> deine pauschale Schuldzuweisungen an andere. Deine letzten 
> beiden Schuldzuweisungen (erst nach Muenchen und jetzt nach 
> smurf) waren beide falsch. 

So? Die nach Muenchen war Deiner Meinung nach falsch?
Komischerweise wurde in Muenchen selbst eingestanden, dass die
Dupes durch ein unerlaubtes Einspeisen von Nachrichten eines
Points der LINK-M zustande kamen. Wodurch kamen die Dupes denn
Deiner Meinung nach zustande??? Das wuerde mich aber wirklich
interessieren! Was die Sache mit der Smurf betrifft, ging es da
nicht um Dupes, sondern um das genaue Gegenteil: Naemlich um
verloren gegangene Nachrichten! Ich weiss nicht, wieso Du das
beides in einen Topf wirfst? Und das hatte mit einem einfachen
Fehler in der BSMTP-Software zu tun, die zur Zeit noch im
Teststadium ist, sowie mit Fehlern beim Routing von Mails HINTER
der smurf. Ich kann ja nun nicht hellsehen und feststellen, ob
der Fehler bei smurf oder dahinter auftritt. Ich weiss nicht,
wieso Du hier von pauschalen Schuldzuweisungen sprichst. Ich
habe sehr deutlich differenziert und nicht unrecht gehabt.

> Holgers EINDRUCK allerdings entsteht auf Grund deines 
> Verhaltens wirklich recht einfach. Und nur die Tatsache, dass 
> mensch dich als Mensch kennt verhindert, dass ich glaube das 
> daran was wahres dran sein koennte. :-)

Hmmm... Ich verstehe nicht, wodurch der Eindruck entstehen
koennte, ich wolle etwas sabotieren. Holger hat mir auch bis
heute keine Zitate dafuer geliefert, die ich gerne gehabt
haette. Ich stehe im Gegenteil seit langer Zeit mit einer
grossen Zahl von Leuten auf beiden Seiten des Gates staendig in
Kontakt, um Probleme und Verluste zu verhindern. Es gibt nur
einige Leute, die davon nichts wissen wollen und mich ueberhaupt
nicht dabei unterstuetzen. Wenn ich nicht Interesse an einem
funktionierenden Betrieb haette, waere ich wohl kaum so
daemlich, mir diese Arbeit zu machen.

> 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. Es ist kein Geheimnis, dass zu der Zeit aus
unterschiedlichsten Ursachen heraus der Gatewaybetrieb noch
recht instabil war. Es war die Entwicklungszeit, in der noch
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.

> Seitdem wir hier das Gateway auch fuer Uni-Projekte (i.E. 
> PLUTO, etc) brauchen, sind wir auf die Zuverlaessigkeit noch 
> mehr angewiesen.

Ich glaube, dass auch die Zuverlaessigkeit von SHLINK und UZERCP
(neuderdings auch der GateBaukonforme APC-Gate) sehr hoch ist -
gemessen an der Zahl von Nachrichten, die die beiden Gates
taeglich fuer Z-Netz, CL und APC transportieren. Dies ist ein
vielfaches von dem, was taeglich von jedem anderen System im
SubNetz oder Z-Netz an verschiedenen Nachrichten transportiert
wird, denn ueber diese Gates geht das komplette Z-Netz, CL, APC
und DNet, sowie taeglich ueber 200 private Nachrichten in alle
Welt. Davon kommt nur sehr selten mal eine nicht an. Und das
ganze funktioniert zwischen den genannten Gates ABSOLUT
dupefrei. Ohne jegliche Absprachen. Nur durch die GateBau.

> Also ... die Diskussion um RFC/ZConnect hat gezeigt, dass viele
> kompetente Leute sich nicht bedingungslos hinter ZConnect 
> stellen. Ebenso hat das Verhalten im Z-Netz sicher nicht dazu 
> beigetragen im Internet den Eindruck zu erzeugen, dass es bei 
> euch sonderlich "ernst" zur Sache geht. 

Ich glaube, es ist kein Geheimnis, dass die Art der Diskussion
im Z-Netz mehr als nur zu wuenschen uebrig laesst. Das war mal
anders. Ich habe mich dazu ja auch schon vielfach geaeussert.

> >die GateBau darstellt. Du koenntest ja z.B. die RFC neu 
> >erfinden?!
> >Ich bin mir nur nicht sicher, ob sich Dein Vorschlag
> >international durchsetzen wird.
> HALT. ZCONNECT (!) und GateBau (!) sind nicht international 
> durchgesetzt.

Das habe ich auch nicht gesagt und ist ja auch garnicht noetig,
weil sich sowohl ZConnect, als auch GateBau vollstaendig auf das
RFC-Format als Grundlage stuetzen. Und das IST international
durchgesetzt!

> Erzeuge hier nicht einen Eindruck, der nicht 
> wahr ist. Ihrr habt euren "Standard" m.W. nicht in den RFC-
> Prozess eingebracht und ihr benutzt definiert keinen Standard, 
> der RFC- oder OSI-konform ist.

Huch?!? Wir muessen da auch nichts einbringen, weil wir nichts
neues erfunden haben! Wir stuetzen uns ausschliesslich auf
bestehende RFC-Regelungen und beschreiben, wie man sowohl die
Z-Netz-Headerinfos weitgehend dem RFC angleichen, als auch das
RFC soweit wie moeglich in Z-Netz-Format umsetzen kann. Nach
aussen (zum RFC) hin, ist sowohl GateBau, als auch ZConnect 100%
transparent; d.h. 100% RFC-konform.  Nach innen (zum Z-Netz) hin
ist eine RFC-Konformitaet nicht moeglich und nicht noetig. Das
Z-Netz interessiert sowieso niemanden im RFC-Bereich. Es geht ja
auch darum, das Z-Netz auf RFC-Kurs zu bringen und nicht
umgekehrt! Aber trotz alledem haben wir auch die
Zusatz-Informationen im Z-Netz soweit wie moeglich den gaengigen
Bezeichnungen im RFC angepasst. Unsere ganze Adresskonvertierung
lehnt sich zu 100% an RFC-Standards an. Ich weiss nicht, wie Du
zu Deiner Aussage kommst.

> Ihr habt eine Uebermenge oberhalb von X.400, alten 
> Netcallformat, RFC, etc gebildet und nennt das ZCONNECT. 

Das musst Du nicht mir sagen. ICH habe zum ZConnect nicht mit
einer Zeile beigetragen! Ich habe mich auch an der Diskussion
nicht beteiligt, weil ich dazu damals keine Zeit hatte. Dennoch
bin ich der Meinung, dass ZConnect zur Zeit die beste
Uebergangsloesung darstellt. Weil es naemlich keine andere
Loesung gibt!!! Deshalb ist es die beste aller moeglichen.

Es ist sehr einfach, immer auf den Vorschlaegen der Leute
rumzuhacken, die Zeit und Arbeit investieren. Nur sehr selten
macht mal jemand, der staendig kritisiert, auch konstruktive
Vorschlaege... Ich meine damit nicht Dich, Frank! Aber diese
Aussage gilt fuer viele andere, die sich ueber Deine Kritik
haemisch freuen werden, nur weil sie es nicht ertragen koennen,
dass es Leute gibt, die konstruktiv sind und Dinge vorantreiben.

Irgendjemand hat in seiner Signature mal den Spruch gehabt: "Die
Zahl unserer Neider ist der Beweis fuer die Qualitaet unserer
Arbeit" (oder so aehnlich). Das trifft bei ZConnect und GateBau
in Perfektion zu.

Gruss,   Volker

## CrossPoint v1.94 ##