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 -- ----------------------------------------------------------------------------- ! 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 ! ! Es gibt 2 absolute Wahrheiten: OSI ist Fortschritt, die Erde eine Scheibe ! -----------------------------------------------------------------------------