From: Frank.Simon@sol.ccc.de (Frank Simon)
Newsgroups: de.comm.gateways
Subject: Re: Gateway-TUeV (war: Hochgep
Date: 13 Apr 92 08:32:03 +0200
Article-I.D.: sol.3576
Organisation: Solar System, Ls 441, Oldenburg, Germany

Hallo, 

heiko@Harpo.Chemie.FU-Berlin.DE (Heiko Schlichting) writes:
>Frank.Simon@sol.ccc.de (Frank Simon) writes:
>>Nochmal die Aussage: Der bisherige Versuch eines Gateway-TUeVs ist wohl
>>   		     gescheitert. 
>Im Z-Netz... kein Grund, dass sowas im deutschsprachigen Teil des USENET
>scheitert. Meine Meinung. 
Klar. Meine Wenigkeit will auch nicht ausschliessen, dass du recht hast. 
Aber hier mal mehrere Argumente, warum ich dies bezweifle (lass mich ja
gern ueberzeugen). 

>Das ist bisher nicht mein Eindruck den ich vom Z-Netz gewonnen habe (ich
>bin nicht im Z-Netz und habe zugegebenermassen nur wenig Einblick, aber
>die Struktur erscheint mir eben anders. 
Richtig. Das ist sie. Aber fuer ein "Gateway-TUeV" eigentlich sogar eher
tragfaehiger. Was soll denn ein Gateway-TUeV erreichen ?  Leider ist das
hier noch nicht deutlich und in sich geschlossen dargestellt worden. Nehmen
wir an, dass dadurch erreicht werden soll, dass weniger Dupes erzeugt werden
(du hattest das in deinen Text mal erwaehnt). Dann bringt so eine 
"Institution" nur etwas, wenn sie auch die Kompetenz hat Verstoesse zu
ahnden. Das heisst Verwarnungen auszusprechenen und Gateways auszuschliessen.
Das ist schon so ein Punkt. Im Z-Netz gibt es Strukturen, die sowas er-
moeglichen. Systeme muessen in einer Liste gefuehrt werden, es gibt eine
Koordination die zu Ein- und Austragungen aufruft, etc. Dort haette sowas
potentiell klappen koennen. Ist es aber nicht. 
Und hier soll ein Gateway-TUeV im deutsprachigen UseNet eingefuehrt werden ?
Abgesehen davon, dass dieser Begriff schon verwirrend ist: Schliesslich 
schliesst das auch Systeme im Z-Netz, MausNet, etc ein.  Primaer ist es
aber so, dass im UseNet allgemeinen und mindestens auch im Subnet es keine
Instanz gibt, die zum austragen von Systemen aufrufen kann. Die vereinzelnten
Versuche durch Abstimmung Systeme auszuschliessen, sind gescheitert. Hier
herrscht nunmal das Prinzip "Schliess dich an und mache". Siehst du mein
Problem ?   Mehr als den Entzug einer "Domain" kann ich mir nicht vorstellen
und auch das klappt nur, wenn die Domain-Vergabestellen fuer Privatpersonen
(SubNet, IN, EUnet, etc) untereinander klarstellen, dass sie den Entzug
einer Domain gegenseitig akzeptieren. Aber selbst so etwas wuerde m.E. 
gegen den Geist der Subnet-Idee stehen. (Auf die ja auch IN und andere
aufbauen). Persoenlich bezweifle ich, dass alzuviele eine solche
"Wesensaenderung" mitmachen wuerden. 

>Das trifft zugegebenermassen
>nicht auf alle Gateways zu - aber auf sehr viele. Da gibt es Gateways,
>die schaffen es nicht, eine Adresse umzusetzen und machen daraus
>ein user@host.$UU7236 - andere machen einfach einen Backslash vor
>Grossbuchstaben - noch andere erzeugen Message-IDs, die mit dem
>Rechnernamen+Domain des Gateways enden.
Diese Kritik ist schon mal interessant. Das hat ja alles Gruende. Das
ist lange in der GateBau besprochen worden, weil eben mit technischen 
Restriktionen der Software umzugehen ist. Makros, die Darstellung von
Gross/Kleinbuchstaben, etc ist nunmal notwendig.

Nehmen wir als konkretes Beispiel fuer solche Probleme ruhig mal die
MessageID-Problematik. Es gibt drei Moeglichkeiten im Zerberus mit
diesen Problem umzugehen:

a) Alles stellt auf die neue Zerberus-Software mit neuen Netcallformat
   um. Da koennen MessageIDs so lang sein, dass mensch die MsgID aus
   der RFC-Welt 1:1 uebernehmen kann. Dieser Prozess dauert noch Jahre
   und erschlaegt erstmal nur das Problem Z-Netz/RFC und nicht die restliche
   Netzwelt.
b) Mensch bringt sich in den RFC-Prozess bei dem IETF an und laesst die
   MessageID auf 20 Zeichen (wie im Z-Netz) beschraenken. Auch dieser
   Prozess dauert Jahre und wuerde wohl scheitern. 
c) Mensch schafft eine Kruecke und bildet die MsgID's ab. Auch wenn die
   MsgID-Routine gemaess GateBau eine Super-Denkleistung darstellt und 
   jeden Anspruch von Ingenieuren standhalten wuerde, ist sie mit Defiziten
   behaftet. Ausserdem klappt es nur, wenn ALLE diese MsgID-Routine ver-
   wenden. Das durchzussetze halte ich aus obengenannten Gruenden fuer 
   schwer.
   
>Warum haben wir hier die Gruppen "fido.ger.bla" und "fido.bla-ger"?
Vielleicht warum ihr cl.* und wir comlink.* haben ?  :-)  Sogar das
hat Gruende. :-)

Auch ich halte die Makros fuer ein "Uebel", aber es ist das kleinere. 

>Mal so gefragt: wenn Du davon nicht begeistert bist, Terra, welche
>Alternativen schlaegst Du denn vor? Den Wildwuchs so weitertreiben
>lassen? Dupes und Chaos ohne Ende? 
Aus dem (kreativen) Chaos erwaechst neue Gedanken und Entwicklungen. 
Das nur so nebenbei. Die gesamte RFC-Welt basiert auf Empfehlungen 
(eben den RFCs) keiner muss sie implementieren, die meisten tun es
nur teilweise, wenige "spielen" mit dem Netz und daraus erwachsen
neue Dienste und Empfehlungen. Was du jetzt als "Chaos" bezeichnest, 
sehe ich einfach anders. 

Das Problem der Dupes ?  Ja. Es gibt sie. Aber wie gehen wir damit um ?
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". Desweiteren
bin ich der Meinung, dass ICH als Benutzer an Informationen der diversen
Netze (das ganze ist eben nicht ein Meta-Netzwerk a la UseNet) will. 
Wenn ich dies will, dann muss ich aus diversen Gruenden mit einen Risiko
sinnlosen Traffics (recyclelte News, Dupes) leben. Sie koennen durch 
technische Defizite oder durch menschliches Versagen entstehen. Wir
koennen Dupoes nicht vermeiden, weil
a) es unmoeglich ist eine komplexe Software auf richtige Implementation
   zu testen, insbesondere ist es schwer festzustellen, dass
   die Software das tut, was sie soll.
   die Software nix tut, was sie nicht soll. 
b) Auch ein Gateway-TUeV kann nur mit Testdaten arbeiten. Da werden die
   Anwendungen nur schwer nachvollziehbar sein. Es gibt Gateways, die
   alles durchschleusen, was sie bekommen (Beispiel: EARN/UUCP)
   Es gibt Systeme die nur einen eingeschraenkten Raum versorgen, weil
   diese an einer Domain teilnehmen (Beispiel: bi-link)
   Es gibt Systeme die auf einen "artfremden" Systemen an einen Netz
   teilnehmen (Beispiel: Sol). 


Desweiteren halte ich die Benutertransparenz fuer fast wichtiger, als
paar Dupes. Wenn ich eine Mail im Zerberus bekomme, will ich darauf
ANTWORTEN machen koennen. Wenn ich ein Artikel in einer de-Gruppe lese,
will ich darauf Reply oder Follow-Up machen koennen OHNE jetzt den Header
patchen zu muessen um eien netzspezifische Adressierung zu verwenden
oder aehnliche Scherze. Das hat fuer mich hoehere Prioritaet. Wer den
Mischmasch bei der Benutzung einiger Gateways kennt (teile des Headers
im Body vom Benutzer einzugeben, etc) kennt, der ahnt evntl. was ich meine.

>Wohl kaum... was bleibt da anderes
>als eine Kontrollinstanz, wenn die Selbstkontrolle nicht stattfindet?
Meiner Meinung nach sollte durch administrative Massnahmen zusammen
mit technischen Empfehlungen die Wahrscheinlichkeit zum eintreten von
Dupes und anderen Probleme (Informationsdefizite ueber Nettiqette des
anderen Netzes, etc) veringert werden. Das ganze habe ich ja schon im ...
*ueberleg* ... vor paar Wochen wenigstens in //GATEBAU in einen groesseren
Text (Code of Conduct for Gateways) genauer dargelegt. 

Terra
-- 
-------------------------------------------------------------------------------
!   Frank Simon (Terra), Ammerlaender Heerstr. 389, D-2900 Oldenburg, FRG     !
!  terra@sol.ccc.de, terra@sol.zer, ext/simon@kmx.gmd.dbp.de, +49 441 76206   !
!	       "Gelesen, Gemerkt, Vergessen" (Joerg Lehners)                  !
-------------------------------------------------------------------------------