GateBau '93 - Hannover
Vom 1.1. bis 3.1. fand in Hannover-Langenhagen die GateBau '93 statt.
Trotz mehrfacher Kritik an den Termin, war es am 1. Tag schon recht
voll. Was allerdings die vorbereitende Arbeit nicht einfacher machte.
Schon ein paar Punkte fielen de Fakto aus oder wurden am naechsten
Tag nachgeholt. Auf jeden Fall einigte mensch sich auf eine Tages-
ordnung, die auch weitgehend am Samstag eingehalten wurde:
1. Selbstverstaendnis
2. Paradigmen-Diskussion (Grundlegende Konzepte)
3. Meta-Mail-Diskussion
4. Netzspezifische Arbeitsgruppen
4.1. RFC
4.2. ZConnect/Netcall3.8
4.3. Maus
4.4. Fido
4.5. Seven
4.x. weitere
5. Zusammenfassung
Am Sonntag sollten dann Protokollgruppen die Beschluesse der einzelnen
Arbeitsgruppen zusammenschreiben und ein GateBau-Protokoll entwerfen.
Am Samstag verdoppelte sich die Teilnehmerzahl nochmal. Vor dem Punkt
1 durfte ich dann noch meinen "Internet-Vortrag" nachholen. Allerdings
habe ich da nur wenig zur Internet-Technik gesagt, sondern mehr zu
Entscheidungsprozessen, Standards und diversen Netzbegriffen. Die
Erfahrung hat gezeigt, dass besonders die GateBau sich alles andere
als korrekt ausdrueckt. Zwar steht es jeder Organisation frei, ihre
eigenen Begriffe zu erfinden. Sogar, wenn sie schon anders belegt sind,
aber es erschwert die Zusammenarbeit, aber auch die Literaturstudie,
doch deutlich. Auch sollte mensch schon wissen, was es ausser Direkter
Vermittlung und Maps noch fuer Routingmechanismen gibt. :-)
Was wollen wir ?
----------------
In der Selbstverstaendnis-Diskussion ging es erstmal darum, ob die GateBau
sich rein technisch sieht, oder ob sie auch ueber administrative Bereiche
des Betriebes Empfehlungen aussprechen will. Nach einer kontroversen
Diskussion musste erstmal (anscheinend erneut) festgestellt werden, dass
die GateBau eh nix beschliessen darf, sondern eben nur - wie schon gesagt -
Empfehlungen aussprechen darf. Wenn mensch das so sieht, dann dann darf
die GateBau (allgemeiner Teil) sich gar nicht mit administrativen Fragen
(ausser wo technisch notwendig) beschaeftigen. Dies gehoert in die
eigentlichen (logischen) Netze und ihren Entscheidungsprozesse. An
dieser Stelle gab es auch Kritik von Michael Keukert in Richtung von
Personen wie Kerstin Freund, Heiko Schlichting, meiner Wenigkeit, u.a.
Diese Personen seien frueher oder auch diesmal wiederholt nicht
anwesend, obwohl es ja um die Belange der Netze geht, fuer die sie
sich zustaendig fuehlen.
Wie ich finde, ein wenig kurzsichtig, weil administrative Loesungen
(Zustaendigkeitsbereiche) oder Vorgaben (z.B. Transitverbot) ohne weiteres
technische Loesungen einfacher gestalten koennen. Das macht dem Programmierer
weniger Arbeit und macht das schlussfertige Programm auch weniger fehleran-
faellig. Was nuetzt eine 100-Seiten-Spezifikation, wenn ihre Implementation
(auf Grund der Komplexitaet) aus vielen Fehlern besteht. Und bei Gateways
ist es sehr schwer, das gesamte Programm mit allen Features auf Grund
von Beweisen oder Tests auf seine Funktionsfaehigkeit zu untersuchen. Die
Praxis sagt: Gateway-Software ist Bananen-Software: Sie reift im Netz,
um die zum Testen erforderlichen Betriebsjahre zuegig zu erreichen.
Daher sollte z.B. durch redundante Sicherheitsmechanismen die Belastungen
des Netzen (z.B. durch Dupes) gering gehalten werden. Sonst gibt es
nur Vernetzungsfrust.
In der Paradigmendiskussion ging es um grundsaetzliche Konzepte. Bis
jetzt kann mensch als Grundkonzept "Transparenz" in der GateBau sehen.
Eine Nachricht sollte moeglichst technisch-transparent durch ein
Netz geleitet werden. Entsprechende Massnahmen waren zu ergreifen, wie
z.B. Informationen im Body aufbewahren, etc.
Ein anderes Grundkonzept (in CoC beschrieben) hatte ein anderen Ansatz.
Es betrachtet einen Gateway erstmal nicht als Protokollwandler (Relay),
sondern erstmal als Hilfsmittel, um logische Netze zu verbinden (Internet,
Z-Netz). Ein Gatewaybetreiber muss darauf achten, dass die diversen
Nettiqetten im jeweils anderen Netz bekannt sind, Bretter eingerichtet
werden, als Nadeloehr hat es die Finanzierung zu sichern, etc. Daraus
ergibt sich das Konzept von "Zustaendigkeitsbereichen". Ein Gateway
leitet nur Bretter/News von Systemen weiter, fuer die es sich zustaendig
fuehlt. Erst aus diesen (und weiteren) Anforderungen ergibt sich, welche
technischen Massnahmen erforderlich sind.
Nun gibt es im Z-Netz beide Konzepte: CoC und GateBau. Es koennen aber
nicht zwei Paradigmen nebeneinander existieren. Auch in diesen Fall
gibt es eine Wechselwirkung zwischen Gateways, die so ihre Probleme
(Dupes, falsche Adressen, etc) zur Folge hat.
Es musste also um eine Vereinheitlichung gehen. Volker Ulle hatte schon
vorher die Idee des Baukastenprinzips eingebracht. Beim Essen war darueber
philosophiert worden und folgende Unterscheidung vorgeschlagen worden:
Art Ziel Anforderungen
n Fremdsysteme an ein Es muessen Zustaendigkeits- und Ver-
Netz anschliessen teilungsbereiche geschaffen werden
n+1 Fremdsysteme an ein Es muss ein Zustaendigkeitsbereich ge-
Netz anschliessen schaffen werden, die Verteilung geschieht
wilde Verteilung wild. Daraus folgt: Einheitliche Message-
ID (nach GateBau), einheitliche Brettnamen
n+2 gemischte Verteilung Es muss ein Zustaendigkeitsbereich ge-
eines Netzes schaffen werden, die Verteilung geschieht
wild. Daraus folgt: Einheitliche Message-
ID (nach GateBau), einheitliche Brettnamen
Datenabgleich
n+3 Transit 100% Transparenz
Natuerlich kann nicht jede dieser "Schichten" einzeln gesehen werden.
Das ganze klappt nur als Gesamtkonzept. Wenn z.B. ein n+2 oder n+3-Gateway
kein Zustaendigkeitsbereich kennt, kann es n- und n+1-Gateways nicht
geben. Dies ist die derzeitige Situation und es gibt da manchmal Dupes.
Nun waere eine Moeglichkeit einfach nur n+2 und n+3 Gateways zu erlauben.
Es gibt aber auf Grund der Komplexitaet der Anforderungen an solche
Gateways wieder andere Probleme, wie z.B. beim Datenabgleich bei vielen
Gateways. Wenn mensch aber alle Gateways zulaesst, dann sollten n-Gateways
GateBau-konforme MsgID erzeugen, auch wenn es fuer ihre Arbeit nicht noetig
ist.
Dann ging es erstmal lustig zu. Martin Husemann forderte erstmal,
dass n+3-Gateways ausgeschlossen werden. Denn es sei keine 100%ige
Transparenz erreichbar (womit er Recht hat) und ausserdem wuerden
die meisten Netze Transit eh verbieten (womit er teilweise recht
hat). Es ging dann naemlich die Diskussion los, dass einige Netze
Transit ohne weiteres erlauben bzw. in Einzelfaellen (ein Netz
kann ein anderes Netz nur ueber ein Drittnetz erreichen) zulassen.
Desweiteren wurde das Problem Probleme des Datenabgleichs bei den
heutigen Gateways angesprochen. Schon heute muessen mehrere Gateways
ueber /T-NETZ/MAKROS ihre Daten abgleichen. Bei 10 oder 50 Gateways
(und dahin geht die Entwicklung, weil in jeder Region Gateways stehen
werden) ist das aber ein nicht mehr zu loesendes verwaltungstechnisches
Problem.
Andere meinten wieder, sie braeuchten keine Zustaendigkeitsbereiche.
Sie wuerden z.B. Maus und Fido vernetzen und haben keine Lust, sich
weitere Arbeit zu machen. Meine Meinung war dazu aehnlich: Ich
habe hier meine Funktionalitaet erreicht (Internet-Systeme nehmen
am Z-Netz teil, ohne dass Benutzer/SysOps von dem Unterschied merken)
und es waere witzlos, wochenlang sich hinsetzen zu muessen, um "GateBau-
Konform" zu sein.
Ausserdem vergraulen schon jetzt die vielen Anforderungen einen Haufen
Programmierer Gateway-Software zu schreiben. Der sich normalerweise daraus
ergebene Fortschritt kommt zum erliegen. Gleichzeitig ist der Gateway-
Bereich der erste fast vollstaendig reglementierte Bereich in den Netzwerken.
Fuer anarchistische oder basisdemokratische Netze eigentlich kaum wuenschens-
wert.
Auf jeden Fall konnte mensch sich nicht auf ein solches Modell fuer die
allgemeine GateBau festlegen. Mensch sagte einfach: Das Z-Netz soll
da vorpreschen und die anderen werden - wenn sie es brauchen - nach-
ziehen. Es geht also immer staerker auf eine Trennung zwischen
Netzen/Protokollen zu. Wirklich Neues im allgemeine Teil kommt kaum noch
dazu. Meistens wird nur das besprochen, was seit geraumer Zeit schon
paar Gate-Gurus unter sich abgemacht haben. Dies zeigten auch andere
Diskussionen des Tages.
Persoenlich bin ich sogar der Meinung: Die GateBau hat als netzuebergreifende
Organisation alle erreichbaren Ziele erreicht. Eine Weiterentwicklung kann
mensch im Endeffekt nur noch auf Netzwerkebene erreichen. Die GateBau sollte
in Zukunft als reine Informations- und Erfahrungsboerse verwendet werden.
Wie waere es mit dem naechsten CCC-Congress ?
Meta-Mail (not metamail)
------------------------
Im 3. Punkt der Tagesordnung wurde ueber Meta-Mail geredet. Es wurden
zusaetzliche Felder eingefuehrt (Envelope-Adressen), sowie je eine
Stunde ueber die References und die X-Gateway-Zeile gesprochen. Volker
Ulle praegte da wohl die Feststellung des Tages. Im Vorfeld hatten
sich Volker und Martin, besonders auf Hinweise durch Matthias Urlichs
auf ein bestimmtes Format und Sinn der X-Gateway-Zeile festgelegt. In
der Diskussion wurde nun das ganze wieder "rueckentwickelt" zu dem
urspruenglich von Martin/Volker angedachten Format. Als das dann auffiel,
wurde wieder alles umgeworfen und es kam schlussendlich doch der ur-
spruengliche Vorschlag zum Tragen. Die Meta-Mail an sich ist kein
dummer Gedanke (wenn mensch ignoriert, dass mensch dafuer auch haette
ASN.1 nehmen koennen. :-) ). Fuer jedes Netzprotokoll wird festgelegt,
wie es auf Meta-Mail (und zurueck) abgebildet wird. Die Abbildung
zwischen zwei Netzprotokollen ergibt sich dann aus der Abbildung:
Protokoll_1 -> Meta-Mail -> Protokoll_2 und zurueck. Auf die Art
mussten nicht unendliche viele Arbeitsgruppen (RFC/Netcall3.8, RFC/ZConnect,
Maus/Netcall3.8, etc) tagen, sondern die paar Arbeitsgruppen konnten
sich parallel (an verschiedene Tische) setzen und sich etwas ueberlegen.
Das eingemachte ...
-------------------
Es ging dann in die netzspezifischen Arbeitsgruppen. Da mich Holger
Petersen zu seinen Vertreter auf der GateBau benannt hatte, musste
ich nun a) Gate-Koordinator im Auftrag auf der GateBau sein und damit
irgendwie versuchen, die potentiellen Interessen des Z-Netzes deutlich
zu machen (was irgendwie an sich schon unmoeglich war), und gleichzeitig
meine Interessen als Verfechter der CoC-Ideen zu vertreten. Waehrend
der allgemeinen Veranstaltung war es fast unmoeglich, dies deutlich
zu machen. In der Arbeitsgruppe "Zerberus" (=auf Zerberus-basierende
Netze mit den Protokollen Netcall3.8 und ZConnect) wurde dann so neben-
bei am Tisch alles konstruktiv in relativ kurzer Zeit besprochen. Erst
diese Stunde waren jener Teil, fuer die sich die Fahrtkosten nach
Hannover gelohnt haben.
Schon auf der GateBau war festgestellt worden, dass 100%ige Transparenz
nicht zu erreichen ist. Nicht nur das: Viele Gatewayprogrammierer haben
einfach gesagt, dass sie keine Lust mehr haben, immer und immer weiter
ihre Software entwickeln zu muessen. Besonders, da es immer Leute gibt,
die sich daran nicht halten. Die ersten Gatewaybetreiber haben sich
einfach schon um andere Aufgaben (Finanzierung, Mail-Gateway fuer eine
Domain, etc) zu kuemmern. Insbesondere hat die GateBau Probleme,
vernueftige (hier: praktikable und benutzergerechte) Loesungen fuer
RFC->Netcall3.8 zu finden. Bevor es jetzt einen Aufschrei im Z-Netz
gibt: das ist erstmal ein Fakt. Das mensch diese Abbildung braucht,
ist unbestritten.
Daher wurde erstmal grundsaetzlich festgestellt, dass eine Protokoll-
wandlung auf ein Protokoll mit eingeschraenkten Moeglichkeiten eigentlich
das Problem eines Netzes ist. Das Z-Netz hat sich ueberlegt, in Zukunft
sein "logisches Netz" auf ein "protokollunabhaengiges logisches Netz"
auszuweiten (Bekannt als Z-Brett-Netz).
Das heisst, dass in einen Netzwerk mehrere Protokoll existieren. Das ist
heute schon der Fall (Netcall3.8, ZConnect, UUCP). Das wird sich durch
einen Beschluss "Z-Brett-Netz" nur verstaerken.
Die meisten Gateways sind inzwischen von ZConnect-Servern "umzingelt".
Daher ist es fuer die Gatewaybetreiber das Einfachste, die (recht triviale)
Abbildung RFC->ZConnect zu machen. Dafuer muessen keine Makrolisten,
MsgID-Probleme, Adressierungsprobleme oder aehnliches bedacht werden. Die
Umsetzung MUSS im Z-Netz geschehen. Auch dies ist nix weiter als eine
Feststellung, weil ZConnect nunmal mit Netcall3.8 klarkommen muss (und
sei es nur wg. den Points). Es wird daher empfohlen, dass Gateways
zu ZConnect-Servern betrieben werden und ZConnect oder UUCP (ein ent-
sprechendes Modul gibt es fuer Zerberus) verwenden.
Ein nicht unerheblicher Grund fuer diese Empfehlung ist sicher auch der
Frust der Gatewaybetreiber, haeufig fuer etwas Pruegel einzustecken, weil
ein Netz mit altertuemlichen Protokollen lebt.
Natuerlich kann das nicht die einzige Empfehlung der Arbeitsgruppe sein.
Es kann ja nicht angehen, dass die GateBau oder ein Netz (auch nicht
das Z-Netz) seine Gateways zu irgendwas ZWINGEN kann. Abgesehen davon
stoesst das schon auf technische Probleme. Daher wurden Regeln fuer
Uebergangszeiten festgeschrieben, um kurzfristig die derzeitige Situation
zu verbessen:
1. Alle Gateways machen CRC32 und erzeugen eine MsgID-Zeile nach GateBau.
Die MsgID-Routine wird ueberarbeitet, damit auch Splitting technisch
moeglich ist (Anmerkung: Im Z-Netz ist Splitting ausgeschlossen, in
anderen Zerberus-based-Networks aber nicht umbedingt). Gesplittet
wird maximal 10000 Bytes und zwar am vorherigen Zeilenende.
2. Gateways fuehren ebenfalls Zustaendigkeitsbereiche ein. Es werden
also in Zukunft nur noch Postings (News, Bretter) von angemeldeten
Systemen weitergeleitet.
Beispiel:
Internet-Rechner A bezieht zer.* und will darin schreiben.
Dafuer muss sich Internet-Rechner A an Gateway B wenden und
sich anmelden. In Zukunft leitet nur Gateway B die Postings
von Rechner A weiter. Gateway C laesst die Nachrichten von
Rechner A in Ruhe und leitet sie nicht weiter. Ausnahme:
Gateway B und Gateway C "teilen" sich einen Zustaendigkeits-
bereich. Der dafuer notwendige Datenabgleich findet nur
zwischen wenigen Gateways statt und ist damit "sicherbar".
Die derzeitigen GateBau-Systeme werden dafuer wohl eine leicht
abgewandelte Form der "ORG-Liste" verwenden. Diese wird eh
erhoben und erfuellt eigentlich die oben genannten Anforderungen.
(Zitat Martin Husemann: Implementierungsaufwand, ca. 30 Minuten)
3. Die Zustaendigkeitsbereiche werden in Abhaengigkeit von Hierachien
verwaltet. Ein Gateway kann also fuer zer.* und cl.* verschiedene
Zustaendigkeitsbereiche haben und z.B. fuer de.comm.gateways die
total aufgeben (um Bretter zu vernetzten). Im letzteren Fall
muss bestmoegliche Transparenz nach GateBau erfuellt werden.
Wenn diese Punkte befolgt werden, sind wesentliche Punkte erfuellt:
- Ein Gateway mit eingeschraenkter Funktionalitaet oder Arbeits-
bereichen (z.B. lokale bzw. regionale Gateways) kann mit
recht wenig ProgrammierAufwand geschaffen werden.
- Die Kombination von Zustaendigkeitsbereichen und Anforderungen an
die MsgID (Punkt 1) haben ein System der redundanten Sicherheit
zur Folge, wie mensch es haeufig bei komplexes Systemen antrifft.
Also: Versagt die Implementierung des Zustaendigkeitsbereichs oder
"flutscht" doch mal ein Artikel durch, so gibt es immer noch
die einheitliche MsgID zur Dupe-Erkennung. Laeuft die MsgID-
Routine falsch, muss das noch lange nicht zu Dupes fuehren:
Die Artikel werden ja nur von einen Gateway weitergeleitet.
Erst das Versagen BEIDER Mechanismen fuehrt zu einen Dupe.
- Ebenfalls ist ein zukunftorientiertes Denken angesagt. Eine
Migration zur RFC-Welt wird gefoerdert, aber stellt kein Pflicht
da.
Allerdings ist das noch nicht der Weisheit letzter Schluss. Anders als wohl
gedacht, sind noch weitere Probleme aufgefallen und besprochen worden. Zu
weiteren Ergebnissen ist mensch aber noch nicht gekommen. Diese Probleme
(z.B. wie sich ZConnect -> Netcall3.8 -> ZConnect verhalten soll oder
wie genau die neeue MsgID-Routine aussieht), wird auf einer Maillingliste
besprochen werden.
Mein Eindruck von der GateBau nochmal zusammengefasst:
Die Existenz der allgemeinen GateBau stellt sich fuer mich immer mehr in
Frage. Die netzspezifischen Arbeitsgruppen konnten viel schneller zu
Loesungen kommen. Alle allgemein zu klaerenden Fragen sind auf den
letzten GateBau-Veranstaltungen besprochen worden. Die GateBau sollte in
Zukunft sich auf Erfahrungsaustausch und Infrastruktur fuer netzspezifische
Arbeitsgruppen beschraenken. Das wuerde der praktischen Arbeit der GateBau,
wie sie auch in Hannover zu erleben war, naeher kommen.
Den Part des "Erfahrungsaustausches" koennte mensch auch verkleinern, in
dem mensch diesen auch als solchen definiert. Der Informations- und Ent-
scheidungsfluss muss auch zwischen den GateBaus gewaehrleistet werden.
Derzeit wird z.B. ueber eine Maillinglist noch an Details z.B. der neuen
MsgID-Routine gefeilt. Dies ist auch besser, als in 3 Tagen alle Probleme
mit Gewalt loesen zu wollen.
Terra
------------------------------------------------------------------------------
