From: Frank.Simon@arbi.informatik.uni-oldenburg.de (Frank 'Terra' Simon)
Subject: Re: Gateway-TUeV (war: Hochgep
Organization: University of Oldenburg, Germany
Date: Thu, 16 Apr 1992 19:49:49 GMT

Hallo, 

Heiko ist ja jetzt in Cuxhaven. Wir sind also erstmal unter uns. :-)

urlichs@smurf.sub.org (Matthias Urlichs) writes:
>In de.comm.gateways, article <1992Apr15.201139.5950@arbi.informatik.uni-oldenburg.de>,
>  Frank.Simon@arbi.informatik.uni-oldenburg.de (Frank 'Terra' Simon) writes:

>< 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.
Gut. Das ist eine Moeglichkeit. Sie gefaellt mir auch besser, als die
Vorstellungen von Heiko. Sage ich ganz offen. Und sowas halte ich auch 
fuer machbar, allerdings nicht im vollen Umfang. :-)

>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-
Alternative: Sie bieten diesen Dienst nicht an und sagen, ihr habt das
nicht zu tun. Wer das doch tut, kriegt eben keine News aus den Fremd-
netzen. :-)
(Dies war ironisch gemeint. Genauso diese Situation will ich vermeiden).

>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.
Danke, Danke. :-)  Das ist die Idee der Zustaendigkeitsbereiche, die ich
seit Jahr und Tag predige. Aber auf mich hoert ja keiner. :-))))
Allerdings sehe ich die Arbeitsbereiche von Gateways ein wenig einge-
schraenkter, um (erstmal) den anonymen Subnet-System nichtzulassen. Der soll 
sich erstmal anmelden und Informationen bekommen. Es gibt paar Probleme, die 
mir einfach ignoriert werden:

Im Z-Netz gibt es eine Koordination, die z.B. die Einhaltung der dortigen
Nettiqette ueberwacht. Das gilt natuerlich fuer die /Z-NETZ/-Bretter. 
Wenn diese Bretter nun im Subnet als zer.* auftauchen und jemand postet
darin ... dann unterliegt er nach meinen Verstaendnis der Z-Netz-Nettiqette
und nicht der UseNet- oder erst recht nicht der Subnet-Nettiqette. 
Wenn nun die Koordination im Rahmen von widerholten Verstoessen den Austrag
dieses Systems verlangt bzw. das abklemmen, dann muss dem irgendwie Folge
geleistet werden. Andersfall wuerden sich die Z-Netz-Leute wohl von uns
abklemmen. Um solche Probleme aus den Weg zu gehen, brauchst du irgendwann
auch eine netzunabhaengige Nettiqette und damit allgemein gueltige
Vorstellung, wie du mit diesem Medium umzugehen hast. Auch das ist heute
noch nicht machbar, weil das ein langsamer Prozess ist.

>< 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
Oder anders gesagt: Aufwand entspricht x > y > z. :-)  Da sind wir ja
einer Meinung. :-)

>< 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.
Du darfst aber auch nicht uebersehen, dass ich diese Sichtweise nicht global
vertrete. Vertreten tue ich Loesungen, die euren gleichen. Nur hier und
heute will ich Loesungen haben, die Funktionieren und soweit wie moeglich
dem Benutzer entgegenkommen. Daher habe ich ja den CoC-text verzapft. 
Wenn sich die Gateways daran halten (und da sind prinzipielle Anforderungen,
die keine riesigen technischen Detailpapier verlangen), dann kann im 
erstem Schritt im UseNet so gearbeitet werden, wie mensch es gewoehnt
hat. Zu beziehen waeren Gruppen durch "wildes Spooling", etc. Nur wenn
jemand posten will, muss sich der SysOp an ein Gateway wenden, damit dieser
ihn eintraegt, ihm eine Fremdnetzadresse zuweisst, uns seine Artikel
und E-Mails weiterleitet. Wie das Gateways das jetzt genau im Detail
macht, interessiert nicht den Benutzer und nicht den SysAdmin. Und einer
Gateway-Koordination braucht das auch nicht interessieren. 

Das ist uebrigens das, was ich mit "kleiner Einschraenkung der Moeglichkeiten
des UseNet" meinte, die allen sehr viel Arbeit bei der Implementaion von 
Details, Abnahme von Gateways und DIskussion dieser Art vermeiden hilft. 
Nur daher habe ich das nochmal geschrieben. :-)

>Siehe Heiko oder mich. :-)
Na. Wenn ich deinen Text so lese, sind unsere Positionen sehr nah bei-
einander.  :-)

>Seite auf meiner Maschine lesen; im Zweifelsfall weil mich die Inhalte
>interessieren, und nicht die sonstigen administrativen oder netztopo-
>logischen Probleme.
Das "mich" bezogen auf dich als Benutzer, unterschreibe ich ja. Nur
das "mich" bezogen auf dich als SysOp, halte ich fuer paar Jaehrchen
verfrueht. :-)

>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. 
Genau. Es gibt Dinge, die muss mensch ermoeglichen. z.B. Crossposten.
Es laesst sich eben nicht machen, dass dem Benutzer zu verbieten. Den
interessiert das nicht. Wenn ich das aber zulasse, entstehen aus diversen
Gruenden durch Crosspostings Dupes im Z-Netz. (Nicht im Subnet !). Also
suche ich eine Loesung, dass mensch die GateBau anpasst oder aber mensch
sucht eine andere Loesung. Wenn a) scheitert, kommt b). :-)
Aber das ist schon durchgekaut ...

>hervorragend, Quervernetzung erhoeht die Uebertragungssicherheit,
>Crossposten verringert den Speicherplatz und den Aufwand beim Lesen, ...
Yep. Und vergroessert das Chaos. :-)

>Ich kann irgendwie immer noch nicht erkennen, welche Arbeit ich mir auf der
>Subnetzseite damit einsparen kann..? Klaer mich mal auf...
Oben getan ...

>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.
Doch. Eines Tages. Irgendwann. Meine Meinung nach, geht es bei Netzen
um die Information und nicht um die Netze. 10 Bretter ueber Politik
in 10 Netzen ist bloed. Auf zum Informations- und Kommunikationsnetzwerk 
als Meganetzwerk. Protokollunabhaengig. Nur noch organisatorische oder 
regionale Domains. Alles andere sollte abgeschafft werden. *traeum* ... aber 
das dauert eben paar Jaehrchen, bis die Eigenstaendigkeit von Mailbox-Netzen 
sich auf Grund des Drucks von Benutzern aufloesst. 

>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,
In einer Welt, die mit ISO-Domain-Adresse klarkommt, sollte es machbar
sein, dass der Benutzer keine GATOR braucht. (Michael: Wir machen dich
arbeitslos). 

>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.
Aber der Benutzer im Netz A benutzt die Methoden die im Netz A ueblich
sind. Da sind wir uns doch einig ? (Siehe deinen Crosspostingargument). 
Es ist Aufgabe des Gateways das vernueftig umzusetzen. 

>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.
Klar. Das sind inhaltliche Sachen. Nettiqette, etc. Dafuer braucht
mensch aber Informationen. Da sehe ich den Gateway- und den System-
betreiber in der Pflicht, diese Informationen zu liefern.

>// Vorsicht, den naechsten Absatz bitte nicht als Flame auffassen! //
Kann es sein, dass du in letzter Zeit in C++ programmierst ?

Den naechsten Absatz habe ich mir dreimal durchgelesen. Ich habe die
Flame nicht entdecken koennen. :-)

>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.
Nein. Aber erstmal eine Loesung. Nur eine, die nicht so gut ist und nur
eine Uebergangsloesung sein kann. 

>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... ;-)
Ah. Gut. Dann dazu: 

Meine Wenigkeit hat nicht versucht die .zer-Domain-Adresse im Subnet
einzufuehren. Nur im NorthNet und da ist es im Mapschnipsel rausgegangen.
War ein Fehler. Spaeter habe ich das nur auf die Systeme begrenzt, die sich
in den "Zustaendigkeitsbereich" meines `Gateways' befinden. Der Grund
ist einfach: Ueber UniOl laufen viele Mails. z.B. alle Mails aus dem
EARN/Bitnet ins Subnet. Also auch die Mails an .zer.sub.org. Haette ich
nun Joerg Lehners gebeten einfach .zer.sub.org auf die Sol umzubiegen, 
dann waere das wirklich daneben gegangen. Den schliesslich sollen nur
die Mails von UniOl und Sol ueber die Sol ins Z-netz gehen. Alles andere
ja gerade nicht. Also eine Trennung zwischen den "offizielen" Domains
und der hiesigen Domain. Es hat sich (wg. Benutzertranparenz) angeboten
dafuer .zer zu nehmen. Den schliesslich sind UNIOL und SOL Zerberus-
Systeme (mit allen Rechten und Pflichten) und haben auch eine Zerberus-
Adresse (uniol.zer, sol.zer). Und wenn ein Benutzer in einer Zerberus-
Gruppe liesst, dass er eine Mail an blah@droehn.zer schicken soll, dann
klappt das. 

Aber ... das ist nicht meine globale Loesung fuer das Problem. Es gibt nur
keine komplette fertige Loesung, die eine solche Teilnahme wie UNIOL/SOL
sie im Augenblick noch haben zu realisieren. Es ist eine Uebergangsloesung
fuer paar Monate oder maximal ein Jahr. Bis dahin hoffe ich, dass sich
die Gateway-Problematik soweit aufgeloesst hat, dass mensch sowas nicht
braucht. 

Aber wenigstens brauchen unsere Leute hier keine GATOR und der Postmaster
wird auch selten mit Fragen belaestigt. :-)   
Wenn es hier Probleme gibt (z.B. mit ComLink), dann sind sie inhalt-
licher Art. Wenn z.B. die Uni-Bibliothek ankommt und oeffentliche
Terminals fuer ComLink aufstellen will. *sigh*

So. Aber jetzt: FROHE OSTERN !   Lasst uns naechste Woche weiter-
diskutieren. 

Terra
-- 
-------------------------------------------------------------------
! Nickname: Terra                        UUCP: terra@sol.north.de !
! Realname: Frank Simon                  Geo: geod: chaos-team    !
! Tel.    : +49 441 76206                   EARN: CHAMNT@DOLUNI1  !
!       Sozusagen das Control-Y des Lebens (Peter Bruells)        !
-------------------------------------------------------------------