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

Hi,

[ Ich lass jetzt mal die Zerberus-Spezfika weg, sonst wird das zu lang.

  Die Diskussion geht um eindeutige IDs/Brettnamen/etc im Subnetz.
  Zerberus-IDs interessieren nicht, solange die Gates sich gegenseitig
  erkennen und, wenn sie keine 1:1-Rueckwandlung schaffen, das Zurueckgaten
  eben sein lassen. Anders geht es nicht. ]

In de.comm.gateways, article <1992Apr14.180659.7607@arbi.informatik.uni-oldenburg.de>,
  Frank.Simon@arbi.informatik.uni-oldenburg.de (Frank 'Terra' Simon) writes:

< [ Defizite in der Gatebau ] Also gab es drei Loesungen:
< a) Mit den Defiziten leben (wollte ich wg. der Benutzer nicht)
< b) Mit den leuten diskutieren. nach paar Monaten hat mensch dafuer aber
<    auch kein Nerv. Wenn durch diese Defizite einfach Dupes auftreten, 
<    dann muss dir Ursache beseitigt werden. Es lief aber darauf hinaus,
<    mich abklemmen zu wollen. 

Tja -- das soll vorkommen. Genau hierfuer brauchen wir dann eine
Schiedsstelle, die feststellt, welcher Gate sich an die Richtlinien
haelt, und die was dagegen tut. Das kann zB so aussehen, dass zu den
von dem nichtkonformen Gate abhaengigen Systemen Feeds von korrekt gegateten
News organisiert werden. Nach kurzer Zeit sitzt der nichtkonforme Gate-
Betreiber allein auf seiner Insel und kann sehen, wie er sein besagtes Ego
befriedigt. :-)

< Dazu: Inzwischen haben mind. die URANUS und die SOL das realisiert, was
< ich im CoC-Text vorgeschlagen habe. Wir haben daher jetzt dieselben
< Hierachienamen (znet.*) und kommen uns NICHT ins Gehege - obwohl wir
< verschiedene MsgID-Routinen verwenden. Wenn wir die vereinheitlichen 
< wuerden, wuerde ein weiterer Sicherheitsmechanismus da sein. 
< 
Dann macht mal...  ;-)

< Eine TUeV muss mit Testdaten arbeiten. Es gibt paar Dinge (ich erwaehne
< nur das mit der Laenge von Artikeln), die technisch korrekt, aber aus
< bestimmten Gruenden eben doch vereinheitlicht sein muessen. Das heisst 
< ein TUeV braeuchte ein Referenzsystem an dem sich alle anderen zu
< orientieren haetten. 
< 
Entweder das, oder eine einigermassen vollstaendige Spezifikation der
Kernfeatures und/oder Erfahrung mit dem Netz, in dem die Probleme auftauchen
(hier: Usenet/Subnetz), um Probleme dann zu loesen, wenn sie auftreten.

Ich bin nicht der Meinung, dass dazu ein Referenzsystem notwendig ist.

< >< Die GateBau und die bekannten Ansaetze gehen davon aus, dass Dupes 
< >< entstehen und das sie nur erkannt werden. Meine Wenigkeit ist ein
< >< Anhaenger des Prinzips "Dupe-Vermeidung vor Dupe-Erkennung".
< >Du gehst damit aber leider davon aus, dass ein jeder Gate 100% funktioniert
< >und nie News verliert. Ausserdem: Administrative Massnahmen schoen und gut,
< >aber fuer die Administration gibt es momentan zwei Gruende -- (a) Dupes
< >verbraten Uebertragungskapazitaet, (b) inkompatible Implementierungen fuehren
< >zu Schleifen und anderen unschoenen Effekten.
< Halt. Nein. Mit administrativen Massnahmen meine ich z.B. Zustaendig-
< keitsgebiete von Gateways. Wenn ich ein Artikel von einen System bekomme,
< fuer das ich mich nicht zustaendig fuehle, leite ich es nicht weiter. 
< Basta. Es geht garnicht erst ins Zielnetz um dort als Dupe erkannt zu
< werden. Das meinte ich mit Dupe-Vermeidung vor Dupe-Erkennung. 
< 
< Deinen ersten Satz verstehe ich nicht. Gerade ICH gehe davon aus, dass
< eben NICHT jedes Gateway 100% funktioniert.
Zwei Ansaetze:
a- Ein Gate funktioniert dann "richtig", wenn er ein paar Kernfeatures
   korrekt beherrscht. Siehe unten.
b- Ein Gate funktioniert dann richtig, wenn er keinerlei Nachrichten
   verliert, nie abstuerzt, nie ausser Betrieb ist, etc.pp.

Ich gehe davon aus, dass wir die Korrektheit nach (a) fordern sollten.
Du gehst davon aus, dass (a) nicht durchsetzbar ist. Ich behaupte: auf
der Subnetzseite sind besagte Kernfeatures trivial. Siehe unten.

Aber: Wenn (b) nicht gewaehrleistet ist (Hinweis: es ist nicht), dann braucht
das arme Subnetzsystem, dass sich nicht in Abhaengigkeit von einem Gate
begeben will, einen redundanten Feed. Dass bedeutet potentiell mehrere
Gates, das bedeutet Korrektheit nach (a).

Meiner Meinung nach ist (a) (im Gegensatz zu (b)) eine verdammt triviale 
Forderung, und ich als Programmierer eines solchen Gates wuerde mich ehrlich
gesagt schaemen, wenn ich das nicht in Uebereinstimmung mit anderen Gates
regeln koennte.

< >Ich bin aber nicht gewillt, den administrativen Aufwand in Kauf zu nehmen,
< >von dem 90% durch technische Massnahmen (eben Kompatibilitaet zwischen
< >den Gates -- auf beiden Seiten) vermeidbar sind.
< Das ist die Theorie. Die Praxis zeigt, dass es bei der Theorie bleibt.
< Wenn 5 Leute an 5 Gateways programmieren gemaess GateBau-Spezifikation
< gibt es trotzdem 3-4 Ergebnisse. 
< 
Stimmt. Nur muessen sich die Leute dann eben zusammensetzen und sich,
statt sich in die Schmollecke ihrer eigenen Gateway-Zustaendigkeitsinsel
zurueckzuziehen, zusammenraufen und zu einem gemeinsamen Standard durch-
ringen. Angesichts der erwaehnten Minimalforderungen auf Usenet-Seite
(das GateBau-Dokument ist um _einiges_ komplexer!) sollte das doch
wirklich keine Schwierigkeiten machen!

< Hier steht, dass du komplexe Software nicht auf richtige
< Implementierung testen kannst. Das ist Fakt. Mit was willst du das den
< Verfizieren ?  wp-Semantik ? Fixpunktsatz ?  Dann guck nochmal ins
< Script was da zu "Praxisbezug" steht. :-)
< 
Es geht mir nicht um die komplexe Software, sondern um die unten erwaehnten 
Core-Features wie ID-Generierung und Brettnamensumsetzung. Die kann ich
sehr wohl testen oder sonstwie verifizieren. Was die Gates dann noch machen,
ist mir aus einem einfachen Grund egal: das evtl.  entstehende Chaos ist
lokal begrenzt und kann das Netz wegen des weiterhin gegebenen Funktio-
nierens der Core-Features nicht mit Dupes voll.

< [ Divergenz von Implementierungen und Schreiben einer guten Spezifikation ]
< 
< Nur: Das ist viel Arbeit. Arbeit die sich schon eine Gruppe von Leuten
<      gemacht hat. Arbeit die leider doch zu Problemen vielschichtiger
<      Art gefuehrt hat. Diese Realitaet moege ich nicht uebersehen. :-)

Die Probleme traten auf der Zerberusseite auf. Wir streiten uns hier um die
Subnetzseite. Mich betreffen die Zerberus-Details nur insofern, als (und hier
kommen die bereits angekuendigten "Core Features" ;-) :
- die "Werke" anderer Gates korrekt erkannt werden und
  - entweder korrekt zurueckgewandelt 
  - oder gar nicht erst zurueckgegatet werden (was sicher einfacher ist...)
- auf der Subnetzseite pro Fremdnachricht eindeutige IDs generiert werden
  und generierte Adressen (die nicht mal eindeutig sein muessen) ueberall
  auf dem Subnetz funktionieren.
- und oeffentliche Nachrichten/Postings in uebereinstimmende Newsgroups/
  Areas/Bretter gegatet werden.

Sobald das gewaehrleistet ist -- und das duerfte im Subnetz/Usenet nun
wirklich keine Schwierigkeiten machen -- ist folgendes..:

< >Form, so dass ich auf dem Subnetz beide in einer Hierarchie fuehren kann und
< >mir nicht jedesmal ueberlegen muss, welcher Satz Gruppen jetzt wo zu finden
< >und ueber welchen Gate zu erreichen ist.
< Der Benutzer soll sich das nicht denken. Klar. Aber der Betreiber. Der
< Betreiber eines Subnet-Systems der znet.* und comlink.* News will, soll
< gefaelligst die wenige Arbeit machen in seinen sys-File und paths-Datei
< vernueftige Eintraege zu machen, damit er die News nicht "ueberall"
< hinspoolt oder sich von ueberallher holt. Das kann er im UseNet machen.
< Wenn er aber maus.*, fido.* und zer.* will, dann geht das eben nicht. 
< DIESEN Minimalaufwand verlange ich vom Systembetreiber. ER will die
< Informationen aus dem anderen Netz. 

...auf der Subnetzseite(!) absolut unnoetiger Aufwand, der die Zuverlaessig-
keit der gegateten News senkt (siehe Korrektheit nach (b), oben, und deren
Unerreichbarkeit).

< >generieren, auf die jeder von ueberallher antworten kann.
< Ja. Bei uns im Subnet. Diese komischen Makros entstehen aber im Zerberus.
< Und da beobachte ich eben eine "einseitige" Sichtweise. Was fuer das
< Subnet und deren Benutzer gelten soll, muss so genauso fuer die Benutzer
< im Zerberus gelten. SONST hast du naemlich eine Glaubensdiskussion am
< Hals, die deinen Befuerchtungen ueber "Mein Gateway ist besser als deins"
< noch um Laengen schlaegt.
< 
Es gibt im Subnetz und im Zerberus nun mal unterschiedliche technische,
administrative und sonstige Gegeben- und Gewohnheiten, die du nicht ueber
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.

Wenn im Haus neben mir ein Mensch mit schwarzer Hautfarbe lebt, dann malen
wir uns auch nicht beide hellbraun an und reden Esperanto, sondern wir
erkennen und akzeptieren, dass wir nunmal unterschiedlich aussehen, und
suchen uns eine gemeinsame Verstaendigungsbasis. Diese Basis sieht not-
wendigerweise anders aus, wenn er in Deutschland lebt, als wenn ich in
Aethiopien wohnen wuerde.

Auf den Netzen sollte es eigentlich auch nicht anders sein.

<  [ Adressformen ]
< a) Du fuehlst dich als netzwerkunabhaengiges System: Dann hat das 
<    Gateway ISO-Domain-Adressen zu generieren. Dafuer brauchst du keine
<    Gateway-Spezifikation. Wie sowas auszusehen hat, ist schon ganz
<    woanders definiert. 
< b) Du willst als neues System an einen anderen Netz teilnehmen (z.B.
<    Zerberus). Dann hast du die dort ueblichen Adressen oder ISO-
<    Domain-Adressen zu erzeugen. 
c) Ich bin ein System im Subnetz und will, dass sich gefaelligst die Gates 
   (deren Aufgabe das sowieso ist) darum kuemmern, dass die dort ueblichen
   Adressen einigermassen korrekt in hier uebliche Adressen umgesetzt
   werden, und dass die Gates sicherstellen, dass hier uebliche administra-
   tive Massnahmen sich nicht mit den Gates ins Gehege kommen.
   Genauer: jeder kann jedem beliebige News fuettern, solange sich die
   beiden Partner darueber einig sind -- es ist bei subnetz-originaeren
   Postings fuer deren Weiterleitung a priori total irrelevant, ueber
   welche Systeme sie gewandert sind, und dasselbe sollte auch fuer
   gegatete Artikel gelten.

< >Willst du in diesem Dokument wirklich
< >N verschiedene Gates einzeln auffuehren, jeder mit einem anderen Adressformat
< >und anderen Namen fuer die Bretter/Newsgroups/was-auch-immer?
< Eben nicht. Gerade nicht. Genauso. Der Benutzer soll aber auch nicht 
< explizit Mails an blahdroehnfasel@gateway.suelz schicken muessen. Das
< interessiert ihn nicht.  
Es geht mir hier in keinster Weise um die Adressformate. Es geht mir um eine
einfache Praemisse: Benutzer A ist im Subnetz, hat von der tollen Area/News-
group/whatever "bla.suelz.fasel" im Zerberus gehoert und will dort an der
Diskussion teilnehmen.
Momentan ist der Status so, dass je nachdem welcher Gate den Krempel
verarbeitet, im Subnetz der Name der gegateten Newsgroup anders lautet,
die administrativen Details (an wen ich diese gegateten News schicken
darf, ohne Kollisionen zu befuerchten) sich beissen, usw. usf.

Dieser Zustand ist auf Dauer unhaltbar.

Dass die diversen Gates unterschiedliche Adressen generieren, interessiert
mich in erster Linie ueberhaupt nicht, solange gewaehrleistet ist, dass
jeder Subnetzler auf jede dieser Adressen korrekt antworten kann.
Dass deine Adresse im Zerberus anders lautet als im Subnetz anders lautet als
im Fido, ist beim momentanen technischen Stand dieser Netze wohl
unvermeidlich. Aber ein normaler Benutzer oder Sysop, der eh in einem 
dieser Netze "verankert" ist und der nur die Dienste von Gates nutzen will,
interessiert das ueberhaupt nicht. Der hat seine Adresse und "sein" Netz,
und die Gates sollen das entsprechend wandeln, wenn es technisch notwendig
ist -- dazu sind sie schliesslich da. (Wenn beide Seiten die im Internet
ueblichen Domainadressen verstehen, umso besser -- dann funktioniert die
Adressierung auch ohne Gateway-Hack. Aber wir sind noch nicht soweit und
folglich bringt es nichts, die Loesung von Problemen auf die lange Bank zu
schieben, die mit der Problematik "identische Adressen in unterschiedlichen
Netzen" nix zu tun haben.)

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