From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: de.comm.gateways
Subject: Re: Gateway-TUeV (war: Hochgep
Date: 16 Apr 1992 05:40:24 +0200
Organization: University of Karlsruhe, FRG
NNTP-Posting-Host: smurf.smurf.sub.org

In de.comm.gateways, article <1992Apr15.201139.5950@arbi.informatik.uni-oldenburg.de>,
  Frank.Simon@arbi.informatik.uni-oldenburg.de (Frank 'Terra' Simon) writes:
< urlichs@smurf.sub.org (Matthias Urlichs) writes:
< 
< Da ich eh jetzt den Bus verpasst habe, kann ich auch antworten. :-)
< 
Selber schuld.  :-)  :-)

< Wenn du in der Definition der Richtlinien, die aus (a) folgern aufnimmst,
< dass ein Mechanismus existiert, der "wildes Spooling a la UseNet" erlaubt.
< Das heisst du musst bestimmte sehr detailierte Dinge 100%ig implementiert
< haben. Ja. Das bezweifle ich, dass es geht. Aus Erfahrung. :-)

Du gehst dabei aber wieder von Problemen aus, die damit auf der anderen
Seite der Gatewaymauer ;-) mit dem Mechanismus auftreten, der im Subnetz
implementiert wird. Genauer, wenn ein Subnetz-Posting in einer gegateten
Newsgroup abgesetzt und ins Ursprungsnetz zurueck soll. Nur:

< Schliesslich ist es schoen zu sagen: "Ist doch einfach. MsgID gemaess
< RFC". Aber du meinst, du willst das nur fuer Subnet Seite definieren ?
< Eine solche Forderung muss aber auch im Fremdnetz selbst umgesetzt und
< abgebildet werden. => Kruecken => Probleme bei Implementation, Probleme
< bei Benutzertransparenz. 
< 
Jawohl, ich will das nur fuer die Subnetzseite definieren.
Das mache ich absichtlich so, weil ich von den N Netzen, die so direkt oder
indirekt am Usenet haengen, eh keine Ahnung habe.

Ich gebe gerne zu, dass es mir herzlichst egal ist, ob das Fremdnetz mit
den Postings zurechtkommt, die wir hier verzapfen. Das ist Sache der Gate-
betreiber und der Gegebenheiten auf der "anderen" Seite.
Ich gehe umgekehrt davon aus, dass es Otto und Ottilie Normalsysop
im anderen Netz auch herzlichst egal ist, ob wir mit deren Artikeln
Probleme bekommen. Das ist Sache der Gatebetreiber und der Gegeben-
heiten auf "unserer" Seite.

Wenn die Gates mit einigen der Moeglichkeiten hier (Crosspostings, relativ
"wildes" Spoolen, etc.) Probleme haben, dann muessen sie diese Probleme
unter sich loesen (Beruecksichtigen nur der ersten aufgefuehrten News-
group, Erkennung von von anderen Gates bereits transportierten Artikeln,
etc.) oder sonst Moeglichkeiten finden, Probleme zu verhindern. Das koennte
zB so aussehen, dass Gate A eben nur Postings ins Zerberus importiert, die
von einem der in Mapschnipsel u.sub.[123] aufgefuehrten Systeme stammen,
und Gate B uebernimmt den Rest. Duplikatproblem geloest, _ohne_ dass
jeder Subnetz-Sysop, der die gegateten News fuehren will, aufpassen muss,
dass er wirklich nur mit den Systemen News austauscht, die ueber "seinen"
Gate laufen.


< Wir muessen damit leben, dass bestimmte Wuenschen sich widersprechen. Eine
< Aufgabe der Gateway-Koordination wird es also sein Prioritaeten zu setzen.

Meine persoenliche Prioritaetenliste ist ganz klar zu umreissen: es gibt
x Gates, y Systembetreuer und z Benutzer. Im Normalfall ist x < y < z.
Folglich ist die Aufgabe der Gates, den Benutzern und Sysops den Umgang
mit den gegateten Sachen moeglichst einfach zu machen und dafuer zu
sorgen, dass das Zielnetz (im Sinne von "Ziel einzelner Nachrichten",
nicht im Sinne von "das Netz, das eine Newsgroup/Area/etc. bidirektional
importiert") mit den Sachen aus dem Quellnetz keine Probleme bekommt.


< Ausserdem ist ja eh bekannt, dass ich kein Gateway betreibe, sondern nur
< eine verteilte Zerberus-Software fuer Unix. :-)
< 
Es war irgendwie schwierig, das nicht mitzukriegen. ;-)

Du solltest aber auch sehen, dass das eine Sichtweise bedingt oder zumindest
nahelegt, die mit dem Rest des Subnetzes nicht unbedingt uebereinstimmt.
Siehe Heiko oder mich. :-)


< Wenn zwei Netze sich miteinander vernetzen, dann bedingen sich die 
< Moeglichkeiten und Restriktionen der Netze gegenseitig. Du kannst das nicht
< so "isoliert" betrachten. 
< 
Als Gatebetreiber kann ich das nicht, das ist richtig.

Aber als Otto Normalsysop und noch mehr als Otto Normalbenutzer bleibt
mir nix anderes uebrig, als meine Betrachtung auf den Isolationismus
zu beschraenken. Schliesslich will ich die Nachrichten der anderen
Seite auf meiner Maschine lesen; im Zweifelsfall weil mich die Inhalte
interessieren, und nicht die sonstigen administrativen oder netztopo-
logischen Probleme.

Ausserdem bedingen sich die Moeglichkeiten und Restriktionen durchaus nicht
gegenseitig. Die Restriktionen der einen Seite behindern die Moeglichkeiten
auf der jeweils anderen. Und auch das nur dann, wenn die fuer diese gegen-
seitige Behinderung verantwortlichen Gates die Verantwortung fuer das Managen
der Probleme auf den Rest der beteiligten Netze abwaelzen, anstatt sie
selber zu loesen.
Mag durchaus sein, dass ich das jetzt zu eng sehe und/oder mir die Sache
zu einfach mache. Genau das ist aber der Punkt -- die Moeglichkeiten der
Netze (im Subnetz: Quervernetzung, Crossposten) werden genutzt, ob die
Gates sie nun unterstuetzen oder nicht. Das hat viele Gruende -- es
funktioniert mit allen anderen im Subnetz vorhandenen News schliesslich
hervorragend, Quervernetzung erhoeht die Uebertragungssicherheit,
Crossposten verringert den Speicherplatz und den Aufwand beim Lesen, ...

Bei Nichtunterstuetzung, d.h. Unfaehigkeit der Gates (aus welchen Gruenden
auch immer!), die Restriktionen der anderen Seite im Gate angemessen zu
beruecksichtigen, kommen dann die Probleme auf. Die Frage lautet: Waelzen wir
die Loesung dieser Probleme auf die Gatebetreiber, die Sysops oder die
Benutzer ab? ;-)

< >Sobald das gewaehrleistet ist -- und das duerfte im Subnetz/Usenet nun
< >wirklich keine Schwierigkeiten machen -- ist folgendes..:
< >...auf der Subnetzseite(!) absolut unnoetiger Aufwand, der die Zuverlaessig-
< >keit der gegateten News senkt (siehe Korrektheit nach (b), oben, und deren
< >Unerreichbarkeit).
< Aber dieser "unoetige Aufwand" erspart einen eben genau eine Menge Arbeit !
< Und zwar auf beiden Seiten !
< 
Ich kann irgendwie immer noch nicht erkennen, welche Arbeit ich mir auf der
Subnetzseite damit einsparen kann..? Klaer mich mal auf...

< >einen Kamm scheren kannst. Die Glaubensdiskussion laesst sich nicht durch
< >ein Zurueckziehen auf den kleinsten gemeinsamen Nenner abwenden, sondern
< >nur dadurch, dass man den Benutzern klarmacht, dass sie mit der Tatsache,
< >dass das andere Netz eben "anders" ist, ganz einfach leben muessen.
< Du willst also den SysAdmins arbeit ersparen und dafuer die Benutzer
< "bluten" lassen. Das sehe ich nicht ein. Die Netze sind fuer die Benutzer
< da. Nicht fuer die SysOps. (Auch wenn in einigen Netzen viele das nicht
< begreifen). 
< 
Will ich nicht. Aber "Mein Netz ist besser als deines" wirst du nicht
dadurch wegbekommen, dass du auf beiden Seiten identische Adressen erlaubst
oder den Sysadmins zusaetzliche Arbeit aufhalst.

Das Problem mit den unterschiedlichen Adressen existiert nun mal. Ich habe
bereits geschrieben, dass es Aufgabe der Gates ist, die Adressen in ein
(aus Sicht des anderen Netzes) vernuenftiges Format zu wandeln. Mehr
ist nicht drin -- Systemadressen der Form bla.zer oder 1:2/3.4 sind
im Usenet nunmal nicht drin. An der Erkenntnis fuehrt auch kein Weg
vorbei. Der Gate kuemmert sich um das Funktionieren der vom System
vorgegebenen Adressen im jeweils anderen Netz und der Benutzer muss wohl
oder uebel Doku lesen (GATOR) oder mit anderen Netzadressen vergleichen,
wenn er zB eine Zerberusadresse per Telefon oder im Text einer Nachricht
mitbekommt.  Gegen diese Problematik laesst sich momentan nichts unter-
nehmen; zumindest nicht bei der Programmierung eines Gates.

Es geht mir hier um zweierlei. Einmal die rein physikalische Tatsache,
dass einzelne Nachrichten vom Netz A ins Netz B wandern. Die Nachricht,
inkl der Art der Weiterleitung, hat sich dabei so vollstaendig wie irgend
moeglich an das System dem Netz B anzupassen. Das ist Sache der Gates.

Zum anderen geht es darum, dass die "Kultur" in /Z-NETZ/... eben eine
andere ist als in de.* und dass sich diese Netzkultur nicht nur deshalb
aendern kann, weil das Teil ploetzlich auch zer.z-netz.* heisst.
Mit diesen Unterschieden vernuenftig umzugehen ist Sache der Benutzer,
fuer die der ganze Kram schliesslich da ist.

// Vorsicht, den naechsten Absatz bitte nicht als Flame auffassen! //

Es ist dem Sysop nicht damit gedient, wenn er zwar physikalisch eine
B-Netz-Nachricht hat, diese aber trotzdem wie eine A-Netz-Nachricht
behandeln muss (restriktive Weiterleitung im B-Netz, "nur damit irgend-
welche Gates das A-Netz nicht mit Dupes vollmuellen", ist keine Antwort.
Zumindest keine, mit der ich leben kann). Es ist umgekehrt dem Benutzer
nicht damit gedient, wenn er in seinem B-System zusetzlich zu der ge-
wohnten B-Umgebung und der ungewohnten A-Netzkultur auch noch Teile
der ihm unbekannten A-Umgebung lernen muss, nur weil (um es jetzt hart
auszudruecken) jemand, der es eigentlich besser wissen sollte, zwischen
A- und B-Netz die Netzadressen vereinheitlichen will. Ich erinnere mich
da an jemanden, der versuchte, die .zer-Domain im Subnetz einzufuehren... ;-)

-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/