Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

IN-Info V. 2.11

1 view

Skip to first unread message

Vera und Heiko

unread,

Nov 18, 1991, 12:54:14 PM11/18/91

Information zum 'Individual Network' (IN) V. 2.11 (18.11.91 /hu)
****************************************************

Inhalt:

1 Einfuehrung
2 Allgemeine Grundidee
3 Vereinbarung mit dem deutschen EUnet
4 Finanzen
5 Leistungen
6 Routing
6.1 Allgemeines
6.2 Nameserver
6.3 Maps
6.3.1 Warum Domains in den Maps?
6.3.2 Auch ohne Domain-Angabe noch erreichbar!!!
6.3.3 'site =site.do.main.de' oder 'site.do.main.de =site' ?
6.4 Namenswahl
7 Domainverwaltung
7.1 Allgemeines
7.2 Serviceverwaltete Domain
7.2.1 Beratung
7.2.2 Netiquette/Guidelines
7.2.3 Sonstiges
7.3 Selbstverwaltete Domain
7.3.1 Finanzen
7.3.2 Nameserver
7.3.3 Preispolitik
7.3.4 Antragsbearbeitung
7.3.5 Beratung
7.4 Antrag auf Teilnahme an einer Domain
7.5 Antrag auf Teilnahme am IN
8 Beratung, Support:
9 Netiquette/Guidelines:
10 Network Managing:
11 Internet-Zugang/POPs:
12 Netzpolitik/Oeffentlichkeitsarbeit; teilnehmende Systeme
13 Frequently asked questions
14 Versions-History
15 Disclaimer

Anhaenge:

ANHANG A netdir-Service von unido
A.1 Beschreibung
A.2 Beispiel
ANHANG B Netiquette
ANHANG C Teilnahmeantrag
ANHANG D Muster fuer Teilnehmerliste
ANHANG E Darstellung der einzelnen Domains
E.1 gun.de
E.2 maus.de
E.3 open.de
E.4 swb.de

1 Einfuehrung

Vorweg ein Hinweis zum gesamten Text. Diese Zusammenstellung ist als Infor-
mationsquelle sowohl fuer Neulinge als auch fuer Leute, die schon laenger
dabei sind, gedacht. Da deshalb davon ausgegangen werden muss, dass der
Text nicht von jedem Leser in "einem Stueck" gelesen wird, haben wir ver-
sucht, jeden Abschnitt fuer sich verstaendlich zu halten. Das fuehrt je-
doch zwangslaeufig zu einer gewissen Redundanz, die besonders dann auf-
oder sogar missfaellt, wenn man den Text tatsaechlich hintereinanderweg
liest. Wir bitten in diesem Fall darueber hinwegzusehen.

Der folgende Text in der Einfuehrung ist fuer Neulinge auf dem Gebiet der
Domains und des Domain-Routings sowie fuer neue Teilnehmer bzw. "Kandidaten"
des IN gedacht. "Alte Hasen" koennen ihn demzufolge ueberspringen.

Warum ist es vorteilhaft, einer Domain anzugehoeren? Nun, der Hauptgrund,
warum sich mittlerweile deutschlandweit so viele Sites einer Domain ange-
schlossen haben, liegt darin, dass die Sites auf diese Weise weltweit ein-
deutige Namen besitzen und somit auch weltweit erreichbar sind. Bei den bei-
den grossen Domains, die in Deutschland verwendet werden ('.sub.org' und
'.de') wissen eben die grossen Mailserver (uunet, mcsun, unido), an welchen
Rechner entsprechende Mails weiterzuleiten sind.
Dabei ist es nicht notwendig, dass die einzelne kleinere Site bei ihnen
bekannt ist, sondern es genuegt fuer sie zu wissen, dass Mails mit der Do-
main '.de' an unido gehen, Mails mit der Domain '.in-berlin.de' an fub usw.
Bei uunet sind Bestrebungen im Gange, das weltweite Routing laengerfristig
vom "Map-Routing" auf "Domain-Routing" umzustellen, so dass Maps dann ir-
gendwann einmal nur noch lokale Bedeutung haben.
Die beiden Domains '.de' und 'sub.org', die in Deutschland verwendet werden,
unterscheiden sich prinzipiell darin, dass die '.de'-Domain direkt vom
deutschen Network Information Center (DE-NIC) vergeben und verwaltet wird,
'sub.org' jedoch eine Unterdomain der amerikanischen Domain '.org' ist.
Beide Zugehoerigkeiten haben Vor- und Nachteile.
Als '.de'-Site bzw. (Unter-)Domainverwalter ist man auf der einen Seite
natuerlich an die Vorgaben des EUnet gebunden und in gewisser Beziehung vom
EUnet abhaengig. Auf der anderen Seite kann man aber als EUnet-Kunde auch
berechtigterweise einige Forderungen stellen und hat auch Anspruch auf
Unterstuetzung und Beratung durch die Leute vom deutschen EUnet.

2 Allgemeine Grundidee

Am 4. Mai 1991 fand in Berlin ein Treffen mehrerer Leute mit dem Ziel statt,
eine weitere Verbesserung der Connectivity im Rahmen der internationalen
Netze, die Erweiterung des Dienstangebots und eine Verringerung der Teilnah-
mekosten zu erreichen.
Das Ergebnis dieses Treffens hat den Namen IN - Individual Network - bekom-
men. IN ist kein neues Netz im herkoemmlichen Sinne, sondern ein Dach fuer
bestehende Netze, die am EUnet ueber eine pauschale Privatpersonenregelung
teilnehmen.
IN soll nicht in Form eines Vereins, einer Firma oder etwas Aehnlichem in-
stitutionalisiert werden.
Im Rahmen von IN soll versucht werden, bestehende technische Regelungenan-
zugleichen, sowie zu gewaehrleisten, dass nicht in jedem Netz das Rad neu
erfunden werden muss.
Es sollte ein Verbund geschaffen werden, der es auch Teilnehmern ausserhalb
der Bereiche Berlin, Hanse und North ermoeglicht, einfach an den internatio-
nalen Verbuenden teilzunehmen, ohne sich auf ein Schlag selbst mit allen
Problemen (Gebuehren, Abrechnung, Domainverwaltung, etc.) beschaeftigen zu
muessen.

Das IN stellt einen freiwilligen Zusammenschluss privater de-Domains dar.
Gruendungsmitglieder sind hanse.de, in-berlin.de, maus.de und north.de.
Diese Netze haben sich aus Gruenden der Vereinfachung und der Vereinheitli-
chung der Tarife sowie des Leistungsangebotes auf privatem Sektor zu diesem
"Dachverband" oder "Interessensverbund" zusammengeschlossen.
Dieser Zusammenschluss ermoeglicht es, gegenueber dem deutschen EUnet als
*ein* InterEUnet-Teilnehmer aufzutreten. Aufgabe des IN soll sein, die Teil-
nahme an privaten de-Domains moeglichst preiswert zu realisieren und die
Gruendung neuer de-Do-mains auf der Basis der Privatpersonenregelung mit dem
deutschen EUnet zu erleichtern, sowie den Aufbau von privaten Internet-
Netzen zu unterstuetzen und fuer Privatpersonen von den Kosten her akzep-
tabel zu gestalten.

3 Vereinbarung mit dem deutschen EUnet

Mit dem deutschen EUnet wurde vereinbart, dass das IN 2.000,- DM im Monat
bezahlen muss zuzueglich der Teilnehmergebuehren. Dafuer kann das IN inter-
nationale und deutsche Mails ohne Volumenbeschraenkung erhalten, ebenso die
internationalen News.
Ferner darf das IN einen eigenen Nameserver aufsetzen und somit selber das
Routing fuer die teilnehmenden Sites bestimmen. *Ein* Rechner darf direkt
bei unido pollen, die anderen muessen sich ueber diesen oder andere Rechner
versorgen. Dieser Rechner ist zur Zeit horga.
Das IN (in Person von Frank Simon) hat beim deutschen EUnet einen Inter-
EUnet-Vertrag unterschrieben. Demzufolge bleibt neuen Domains, die am IN
teilnehmen, dieses Antragsverfahren erspart, da sie als Teilnehmer am IN
automatisch auch Teilnehmer am InterEUnet sind.

4 Finanzen

In Zukunft wird das IN alle anfallenden Gebuehren an das deutsche EUnet
ueberweisen, nicht mehr die einzelnen Domains.
Folgende Gebuehren fuer den Abrechnungsraum des IN wurden mit dem EUnet
vereinbart:

- Grundgebuehr 2000,- DM
(News all.all, Mails ohne Volumenbegrenzung,
keine generelle Internetbeschraenkung,
IN- und EUnet-Service)
- Gebuehr je UUCP-Site 5,- DM *)
- Gebuehr je Teilnehmer mit Internet-Zugang 20,- DM

*) bei Sites mit vielen Usern (Mailboxen) faellt der Betrag entsprechend
hoeher aus und ist im Einzelfall auszuhandeln.

Die Grundgebuehr wird auf alle beteiligten Sites (zur Zeit ca. 300) um-
gelegt.

Wir haben es durchgerechnet und kommen zur Zeit auf folgenden Tarif:
Jede Domain zahlt an das IN:

7,- DM * Anzahl der teilnehmenden Rechner
+ 5,- DM * Anzahl der nicht-Internet-User
+ 20,- DM * Anzahl der Internet-User
--------------------------------------------
= Kostenanteil der Domain am IN

Ziemlich theoretisch, aber im Normalfall der sog. "Ein-Mann-Site" bedeutet
das 12,- DM im Monat (7,- DM anteilige Grundgebuehr und 5,- DM fuer den
einen User).
Wie die einzelnen Domains dann das Geld aufbringen, bleibt den jeweiligen
Domains ueberlassen :-)

Zusaetzlich koennen ggf. anfallende Leitungskosten auf die Teilnehmer
verteilt werden.

Jede Domain sorgt nach wie vor innerhalb ihres Bereiches fuer die Finanz-
verwaltung und steht gegenueber dem IN fuer die korrekte Abfuehrung der
Gelder ein. An der "Finanzhoheit" der Domains aendert sich also nichts.
Jede Domain kann intern beschliessen, wie sie ihren Anteil an den 2000,- DM
Grundgebuehren, die an das EUnet gehen, aufbringt (gestaffelte Tarife, ein-
heitliche Tarife usw.); ebenso, wie mit den Leitungskosten verfahren wird.
Das heisst, dass die Domains ein Kontingent zugewiesen bekommen (z.B. bei
einer Domain mit 20 "Ein-Mann-Sites" 240,- DM) und dann selbst entscheiden
koennen, wie diese umgelegt werden. Beispielsweise koennte der Rechner, der
den Fernlink unterhaelt, noch die entstehenden DFUE-Kosten aufschlagen und
mit umlegen. Oder eine Domain hat bestimmte Zielsetzungen (z.B. Points zu
foerdern) und laesst Mailboxen ueberproportional die Kosten tragen, um
es fuer Points entsprechend guenstiger zu gestalten. Das IN mischt sich
da nicht ein und spricht auch keine Empfehlungen aus.

Jede Domain muss dem Kassenwart bis zum 20. jedes Monats eine vollstaendige,
aktuelle Liste aller teilnehmenden Rechner zuschicken, damit die Grundge-
buehr korrekt auf die einzelnen Domains verteilt werden kann. In dieser
Liste muessen auch die erforderlichen Angaben ueber Art und Anzahl der User
enthalten sein (Muster siehe Anhang D).

Auf Grundlage dieser Aufstellungen ermittelt der Kassenwart den Anteil der
einzelnen Domains an der Gesamtrechnung und teilt diesen (per EMail) dem
Abrechnungsbeauftragten der Domain mit. Entsprechend dieser "Rechnungsstel-
lung" zahlt dieser den fraglichen Betrag auf das IN-Konto ein. Der Kassen-
wart teilt dem EUnet quartalsweise den aktuellen Stand des IN mit.

Die einzelnen Domains muessen das Geld ueberweisen an:

Gereon Ziegelowski (amtierender Kassenwart)
Moltkestr. 5
D-4156 Willich 1

Tel.: +49 2154 2273

EMail: ger...@shadow.ish.de

Bankverbindung: Kreditinstitut: Sparkasse Krefeld
BLZ: 320 500 00
Kontonummer: 04975264

5 Leistungen

Das IN ist vom Ansatz her netzunabhaengig orientiert. Es ist also nicht nur
auf UUCP und Internetdienste beschraenkt. Im Augenblick gehoert auch noch
das MausNet zum Verbund. Eventuell wollen Teile des Zerberusnetzes sowie des
Fido-Netzes ebenfalls daran teilnehmen.
Das IN betreibt aber keine eigenen Gateways. Diese Initiativen sollen und
muessen weiter von einzelnen Personen oder Netzen kommen. Das IN hilft nur
bei dem Teil der Netzpolitik, der mit der internationalen Connectivity und
damit entstehenden Problemen zusammenhaengt.

Teilnehmer des IN koennen folgende Leistungen in Anspruch nehmen:

Mails: Ohne Volumenbeschraenkung und ohne zusaetzliche Kosten weltweit
News: all.all
Internet: Das IN ist InterEUnet-Teilnehmer. Demzufolge hat jeder Teilneh-
mer am IN das Recht, Internetdienste in Anspruch zu nehmen, so-
fern die entsprechenden technischen Voraussetzungen erfuellt
sind.
Das IN bietet solche Dienste zur Zeit nur ueber die sog. POPs an
(siehe 11). Die genauen technischen und finanziellen Absprachen
sind mit den Betreibern dieser POPs zu treffen.
Support: Bei technischen, administrativen und netzpolitischen Fragen
werden die entsprechenden Ansprechpartner der Domains oder des
IN nach besten Kraeften versuchen, zu helfen (siehe auch 8).

6 Routing

6.1 Allgemeines

Das Routen innerhalb der Domain uebernimmt der jeweilige Verwaltungsrechner.
Handelt es sich um eine serviceverwaltete Domain, so laufen die Mails aus
Gruenden der Verantwortlichkeit vorher ueber den Verwaltungsrechner der zu-
staendigen Domain.

6.2 Nameserver

Joerg Lehners (joerg....@arbi.informatik.uni-oldenburg.de) hat sich
freundlicherweise bereit erklaert, fuer das IN einen Nameserver aufzusetzen.
Zur Zeit sind dort folgende MX-Records eingetragen (MX-Records geben an,
wie die einzelnen Domains auf dem Internet geroutet werden):

; .boerde.de

noch nicht an uniol deligiert

; .ccc.de -> uniol

*.ccc.de. IN MX 10 arbi.Informatik.Uni-Oldenburg.DE.
*.ccc.de. IN MX 100 unido.Informatik.Uni-Dortmund.DE.

; .fido.de -> rwth-aachen

*.fido.de. IN MX 10 suntex.dfv.rwth-aachen.de.
*.fido.de. IN MX 20 slcdec.dfv.rwth-aachen.de.

; .gun.de

noch nicht an uniol deligiert

; .han.de

noch nicht an uniol deligiert

; .hanse.de -> unido

*.hanse.DE. IN MX 10 unido.Informatik.Uni-Dortmund.DE.
*.hanse.DE. IN MX 20 arbi.Informatik.Uni-Oldenburg.DE.

; .in-berlin.de -> fub

*.IN-Berlin.DE. IN MX 10 ki1.chemie.FU-Berlin.DE.
*.IN-Berlin.DE. IN MX 20 leibniz.math.FU-Berlin.DE.
*.IN-Berlin.DE. IN MX 195 unido.Informatik.Uni-Dortmund.DE.

; .ish.de -> fub

*.ish.DE. IN MX 10 ki1.chemie.FU-Berlin.DE.
*.ish.DE. IN MX 20 leibniz.math.FU-Berlin.DE.
*.ish.DE. IN MX 195 unido.Informatik.Uni-Dortmund.DE.

; .maus.de -> uniol

*.maus.DE. IN MX 10 arbi.Informatik.Uni-Oldenburg.DE.
*.maus.DE. IN MX 100 unido.Informatik.Uni-Dortmund.DE.

; .north.de -> uniol

*.north.DE. IN MX 10 arbi.Informatik.Uni-Oldenburg.DE.
*.north.DE. IN MX 100 unido.Informatik.Uni-Dortmund.DE.

; .open.de

noch nicht an uniol deligiert

; .owl.de -> mcshh

*.owl.de. IN MX 10 mcshh.Hanse.DE.
*.owl.de. IN MX 190 unido.Informatik.Uni-Dortmund.DE.
*.owl.de. IN MX 200 arbi.Informatik.Uni-Oldenburg.DE.

; .ruhr.de

noch nicht an uniol deligiert

; .swb.de -> unido

*.swb.DE. IN MX 10 unido.Informatik.Uni-Dortmund.DE.
*.swb.DE. IN MX 100 arbi.Informatik.Uni-Oldenburg.DE.

; .toppoint.de -> uniol

*.toppoint.de. IN MX 10 arbi.Informatik.Uni-Oldenburg.DE.
*.toppoint.de. IN MX 100 unido.Informatik.Uni-Dortmund.DE.

; .zer.de -> mcshh

*.zer.de. IN MX 10 mcshh.Hanse.DE.
*.zer.de. IN MX 190 unido.Informatik.Uni-Dortmund.DE.
*.zer.de. IN MX 200 arbi.Informatik.Uni-Oldenburg.DE.

6.3 Maps

Das Sammeln, Verwalten und Weiterleiten der Mapschnipsel wird von der zu-
staendigen Domain vorgenommen.

6.3.1 Warum Domains in den Maps?

Ohne Domain-Angabe erzeugt der Pathalias Pfade der Art

rechner!host!site!%s .

Dies wird auch durch einen Eintrag der Form 'site =site.do.main.de'
nicht beeinflusst. Dieser Eintrag bewirkt lediglich, dass 'site' zu-
saetzlich auch unter 'site.do.main.de' zu erreichen ist. Der erzeugte
Bangpfad enthaelt aber nach wie vor keinen Hinweis auf die Domain.

Gehoeren z.B. 'host' und 'site' der Domain do.main.de an und geben
auch domainisierte Maps ab, so aendert sich der Output des Pathalias
(sofern die Nachbarsites den Link *mit* Domain-Angabe geschrieben haben).
Nunmehr wird folgender Bangpfad generiert:

rechner!host.do.main.de!site.do.main.de!%s

Analog zu oben kann man jetzt durch den Eintrag der Zeile
'site =site.do.main.de' erreichen, dass der Rechner *zusaetzlich* auch
unter 'site' zu erreichen ist. Genau wie oben wird der vom Pathalias er-
zeugte Bangpfad auch hier nicht beeinflusst, d.h. im Pfad steht die Site
nach wie vor *mit* Domain.

Welchen Vorteil hat es nun, wenn der Pathalias Pfade mit Domain-Angabe
generiert? U. a. folgende:

- Die Mails koennen per Internet zugestellt werden. (!)
- Der generierte Sitename ist mit Sicherheit weltweit eindeutig
- Die Mails kommen auch dann an, wenn sie (zwischenzeitlich) ausserhalb
des Subnetzes geroutet werden.

Letzteres ist vor allem dann von Interesse, wenn die Mail ueber Rechner
laeuft, die ein hartes Rerouting durchfuehren (z.B. unido). Auch eine
Mail an Subnetz-Sites, deren Name auch ohne Angabe der Domain weltweit
eindeutig ist, kann von unido nicht geroutet werden.
Kennt unido eine Site entsprechenden Namens (z.B. in den USA), so werden
alle Mails, die eigentlich ueber den Subnetzrechner geroutet werden
sollen, an eben diese internationale Site geschickt und erreichen somit
weder die Subnetz-Site noch ggf. dahinter liegende Rechner.

6.3.2 Auch ohne Domain-Angabe noch erreichbar!!!

Entgegen anders lautenden Geruechten gilt:

* Mit einem entsprechenden Eintrag in der Map ist es auch weiterhin *
* moeglich, innerhalb des Subnetzes nur mit dem Sitenamen erreicht zu *
* werden. *

Voraussetzung ist, dass irgendwo in der Submap die folgende Zeile steht:

site =site.do.main.de

Diese Erreichbarkeit bezieht sich natuerlich nach wie vor nur auf das
Subnet.

Sollte 'site' in den USA registriert sein, so erreicht man einen User
*dieses* Rechners folgendermassen:

user%site@unido
@unido:user@site
@uunet.uu.net:user@site
us...@site.do.main (falls vorhanden :-)

(Anm: unido!uunet!site!user wird z.B. von fub auf die Subnetz-Site reroutet,
sofern wir das nicht explizit ausschliessen.)

6.3.3 'site =site.do.main.de' oder 'site.do.main.de =site' ?

Nach diversen Tests hat sich herausgestellt, dass es keine Rolle spielt,
ob 'site =site.do.main.de' oder 'site.do.main.de =site' gewaehlt wird

Der Pathalias wird auch nicht "verwirrt", wenn beide Formen gleichzeitig
auftauchen.

6.4 Namenswahl

Auch wenn die voll domainisierten Rechnernamen weltweit eindeutig sind, sollte
man sich ueberlegen, ob man fuer den "ersten" Namen nicht einen weltweit ein-
deutigen Namen waehlen will (und den dann in der internationalen Subnetmap
"registrieren" laesst). Eine Entscheidungshilfe hierbei kann der "netdir"-
Service von unido sein (Beschreibung siehe Anhang A).

7 Domainverwaltung

7.1 Allgemeines

Die interne Verwaltung bleibt weiterhin den einzelnen Domains ueberlassen.
Im Rahmen des IN gibt es aber eine Neuerung: Es wird unterschieden zwi-
schen

- serviceverwalteten Domains
(kleinere Domains, die zwar aufgrund ihrer geographischen Einordnung einen
eigenen Namen erhalten, deren technische Aufgaben jedoch von einer anderen
Domain mit uebernommen werden)
- Selbstverwaltete Domains
(groessere Domains, die eigenverantwortlich verwaltet werden)

(Genaueres siehe unter 7.2 und 7.3)

Diese Unterscheidung wurde gewaehlt, um in Zukunft Konstrukte der Art
'rechner.rhoen.in-berlin.de' zu vermeiden. Mit dem DE-NIC (Ruediger Volk)
wurde vereinbart, dass Domains der Art 'rhoen.de' vom IN oder unter Beru-
fung auf das IN beantragt werden koennen, so dass einer "geographisch kor-
rekten" Bezeichnung der Domains nichts mehr im Wege steht.
Bisher war es so, dass solche Domains nur eingerichtet wurden, wenn es
eine beantragende Organisation, einen Ansprechpartner fuer die Administra-
tion, einen Ansprechpartner fuer die Technik, einen Verantwortlichen fuer
die Begleichung der Rechnungen ... und und und ... gab.
Diese Huerde entfaellt, wenn man jetzt eine solche Domain als "service-
verwaltete" Domain des IN beantragt. Dann kann man naemlich angeben, dass
die Verwaltung und alle sonstigen Belange von der (groesseren) "selbst-
verwalteten" Domain xyz uebernommen werden (das muss natuerlich mit dieser
Domain abgesprochen sein :-).

Konkretes Beispiel:
So, wie es zur Zeit aussieht, ist 'rhoen.in-berlin.de' eine von der
selbstverwalteten Domain 'in-berlin.de' serviceverwaltete Domain. Alle
relevanten Aufgaben werden zur Zeit von in-berlin.de uebernommen (Ver-
waltung, Routing, Finanzen). Gleiches koennte mit der beantragten Domain
'rhoen.de' geschehen.
Natuerlich kann eine solche serviceverwaltete Domain auch zu einer
selbstverwalteten Domain avancieren, wenn die entsprechenden technischen
Voraussetzungen gegeben sind, das noetige Know-How vorhanden ist und
sich Verantwortliche finden, die fuer den ordnungsgemaessen Ablauf ge-
radestehen (korrekte Abfuehrung der Gebuehren, korrektes Routing, funk-
tionierende Verwaltung, Einhalten der Netiquette...).

7.2 Serviceverwaltete Domain

7.2.1 Beratung

Soweit moeglich sollen auftretende Fragen innerhalb der Domain geklaert
werden.

7.2.2 Netiquette/Guidelines

Die Art, wie inhaltliche Probleme geloest werden, sollen ebenfalls von den
einzelnen Domains selbst geklaert werden. Dies gilt, soweit es nicht auch an-
dere Domains betrifft. Es existiert eine Empfehlung (Mini-Netiquette) fuer
den Umgang der einzelnen Domains untereinander (siehe Anhang B), die natuer-
lich gemeinsam den Beduerfnissen angepasst werden kann.

7.2.3 Sonstiges

Alle anderen Dinge werden von einer selbstverwalteten Domain mit uebernommen.
Eine neue Domain bekommt erstmal den Status einer serviceverwalteten Domain,
bis durch die Anzahl der Rechner und die vorhandenen Moeglichkeiten, sowie
auf Wunsch der lokalen Domain diese sich selbst verwalten will.
Dabei sollte eine Mindestanzahl von 10 aktiven Rechnern als Richtlinie die-
nen, welche Unterdomains von der Groesse her selbstverwaltet werden koennen.

7.3 Selbstverwaltete Domain

7.3.1 Finanzen

Die selbstverwaltete Domain hat eine eigene Abrechnung, bezahlt ihren Anteil
auf ein Konto, sorgt selbst fuer das Verschicken von Mahnungen, etc. Sie
ueberweist ihren Anteil an den Gebuehren und den der von ihr serviceverwal-
teten Domains auf das IN-Konto.

7.3.2 Nameserver

Die Domain wird vollstaendig von der selbstv. Domain uebernommen. Technisch
bedeutet das, dass ein MX-Record auf den Verwaltungsrechner der Domain ein-
gerichtet wird.

7.3.3 Preispolitik

Wie der Anteil an den Gebuehren innerhalb der Domain umgelegt wird, wird
ebenfalls von der selbstverwalteten Domain bestimmt. Dies gilt bis zum
01.01.1992.
Bis dahin sollen die Anschlussgebuehren soweit moeglich vereinheitlicht wer-
den oder andere entsprechende Regelungen gefunden werden.

7.3.4 Antragsbearbeitung

Die selbstverwalteten Domains verschicken Antraege zur Teilnahme und sam-
meln diese.

7.3.5 Beratung

Die selbstverwalteten Domains beraten und informieren die serviceverwalteten
Domains in Hinblick auf Wissenerweiterung der lokalen Domains. (Damit diese
vom Know-How her die Moeglichkeit erhalten, spaeter ihre Domain selbst zu
verwalten.)

7.4 Antrag auf Teilnahme an einer Domain

Die Antragstellung auf Aufnahme in eine bestimmte Domain findet nach wie vor
innerhalb der zustaendigen selbstverwalteten Domain statt. Dies soll in allen
Domains schriftlich erfolgen, die entsprechenden Formulare sollten verein-
heitlicht werden. Ein vom IN entwickeltes Formular, das verbindlich fuer
alle Domains ist, wird es (vermutlich) nicht geben.

7.5 Antrag auf Teilnahme am IN

Will eine gesamte Domain dem IN beitreten, so sollte der entsprechende Do-
main-Verantwortliche einen der unter 12 (Netzpolitik/Oeffentlichkeitsarbeit;
teilnehmende Systeme) aufgefuehrten Kontaktpartner ansprechen oder an
'i...@methan.chemie.fu-berlin.de' schreiben.
In dieser Mailingliste sind alle Verantwortlichen der (bisher existierenden)
selbstverwalteten Domains vertreten.
Der Beitritt einer Domain findet nach der folgenden Regelung statt:

- serviceverwaltete Domains
sind unproblematisch, da sie von der zustaendigen selbstverwalteten Domain
mit verwaltet werden

- selbstverwaltete Domains
Jede Domain, die als selbstverwaltet neu aufgenommen werden moechte, muss
folgende Antraege beim DE-NIC, deutschen EUnet oder beim IN einreichen:
- Antrag auf Erteilung einer *.de-Domain
(per E-Mail an das DE-NIC (Ruediger Volk) mit Verweis aufs IN)
- Beitrittserklaerung zum IN
(schriftlich an den Kassenwart des IN)
Das entsprechende Formular findet sich in Anhang C
Die bereits teilnehmenden Domains reichen dieses Formular nach, sobald
die notwendigen Voraussetzungen erfuellt sind.
- Ggf. Kuendigung einer bereits bestehenden Vereinbarung mit dem deut-
schen EUnet.

- jede Domain
sollte sich selbst innerhalb der Mailingliste i...@methan.chemie.fu-berlin.de
darstellen (Entwicklung, Art und Zahl der Systeme...). Schon im IN ver-
tretene Domains sollten das baldmoeglichst nachholen. Solche Infotexte
koennen dann gespeichert werden, um bei Bedarf zur Verfuegung zu stehen.
(siehe auch Anhang E)

Damit sollte es dann aber auch genug der laestigen Formalitaeten sein...
Der erste Antrag dient zur Festschreibung der Domain, die Beitrittserklaerung
ist notwendig, da irgendwo festgeschrieben werden muss, welche Rechte (Bezug
von News und Mails, Internetanbindung bei entsprechenden Voraussetzungen,...)
und welche Pflichten (Beitragzahlungen, Einhaltung der Netiquette...) die
Domains haben. Und das sollte halt auch tunlichst ein Verantwortlicher der
Domain gegenzeichnen :-)

8 Beratung, Support:

Soweit moeglich, soll eine Beratung innerhalb der Domain erfolgen, da
die entsprechenden Probleme dort meistens aus der Praxis bekannt sind.
Das trifft sowohl auf serviceverwaltete Domains zu (warum sollte z.B.
ein Fulderaner Problem von Leuten aus in-berlin.de geklaert werden,
wenn es auch Ansprechpartner in rhoen.de gibt) als auch - natuerlich -
auf selbstverwaltete Domains. Bei Fragen genereller Art, die u. U. in
die Zustaendigkeit des IN fallen, erfolgt selbstverstaendlich auch eine
Beratung von Seiten des IN.
Sollten Probleme auf diese Art und Weise nicht geklaert werden koennen,
so bleibt als letzte Moeglichkeit (und nur in Ausnahmefaellen!), das
Postmasterteam in Dortmund telefonisch oder via EMail um Hilfe zu bitten.

9 Netiquette/Guidelines:

Jede Domain kann sich ihre eigenen Richtlinien erstellen - soweit nicht
andere Domains davon betroffen sind. Das IN hat ein uebergreifendes Neti-
quette erstellt, in dem prinzipielle Verhaltensregeln insbesondere fuer
Domainverwaltungsrechner und fuer den Umgang der Domains miteinander auf-
gestellt sind (siehe Anhang B).

Die jeweiligen Domains sind gehalten, sich
a) an diese Uebereinkuenfte zu halten und
b) in ihre eigenen Regeln keine zuwiderlaufenden Bestimmungen aufzunehmen.

10 Network Managment

Das IN betreibt selber kein Netz und auch keine Links. In Zusammenarbeit
mit den fuer die Technik zustaendigen Leuten der einzelnen Domains be-
mueht es sich jedoch, die Versorgung mit News und Mails sicherzustellen.
Die Verwendung ineffektiver Links soll weitestgehend reduziert werden;
die Verwendung nicht zulaessiger Links soll vermieden werden.

11 Internet-Zugang/POPs:

Das deutsche EUnet moechte in Zusammenarbeit mit engagierten Betreibern
sogenannte "Points of Presence" (POPs) errichten. Das sind gewissermassen
dezentrale Backbones, die in Ballungsgebieten angesiedelt sind. Diese POPs
sollen im Rahmen einer Dezentralisierung die Aufgabe erfuellen, den zentra-
len Netzknoten (unido) zu entlasten und gleichzeitig eine Verbilligung des
Netzzugangs in diesen Ballungsraeumen ermoeglichen.
Bisher haben sich zwei Sites (Firmen) gefunden, die als POP fungieren wol-
len: tmpmbx in Berlin und mcshh in Hamburg. Beide werden via ISDN Internet-
verbindungen zu unido unterhalten, so dass sie entsprechende Internetdienste
(telnet, ftp, irc,...) zur Verfuegung stellen koennen. Diese Dienste koennen
sowohl Firmen als auch die Teilnehmer des IN nutzen, wobei die Gebuehren
fuer die Benutzung der Internetleitungen mit den Betreibern der POPs abge-
klaert werden muessen.

12 Netzpolitik/Oeffentlichkeitsarbeit; teilnehmende Systeme

Das IN vertritt die Interessen seiner Domains nach aussen. Es erstellt
Informationsmaterial, was im Bedarfsfall angefordert/verschickt werden
kann (ist in Vorbereitung) bzw. benennt Ansprechpartner. Bisher sind
das:

- IN : i...@methan.chemie.fu-berlin.de (IN-Administration)

- boerde.de : he...@ivcmd.boerde.de (Hergo Papke)
- ccc.de : te...@sol.ccc.de (Frank Simon)
- fido.de : m...@dfv.rwth-aachen.de (Martin Junius)
- gun.de : and...@easix.gun.de (Andreas Baess)
- han.de : fi...@hiss.han.de (Axel Zinser)
- hanse.de : t...@mcshh.hanse.de (Thomas Wieske)
- in-berlin.de : ad...@methan.chemie.fu-berlin.de
(Vera Heinau, Heiko Schlichting)
tre...@tmpmbx.in-berlin.de (Ralf Moritz)
- ish.de : postm...@ish.de (Ralf Huelsmann, Jan Richert)
- maus.de : juergen...@hb.maus.de (Juergen Conradi)
- north.de : lo...@olis.north.de (Ulrich Tiemann)
- open.de : bo...@juqi.ruhr.de (Bodo Rueskamp)
bs.open.de : uw...@yedik.bs.open.de
do.open.de : su...@sunnies.do.open.de
en.open.de : ra...@reswi.en.open.de
ki.open.de : wi...@freesid.ki.open.de
ms.open.de : ro...@larry.ms.open.de
w.open.de : and...@xenox.w.open.de
- owl.de : m.hus...@bi-link.owl.de (Martin Husemann)
- ruhr.de : bo...@juqi.ruhr.de (Bodo Rueskamp)
- swb.de : c...@brewhq.swb.de (Christian Balzer)
- toppoint.de : vors...@tpki.toppoint.de
- zer.de : m.hus...@bi-link.owl.de (Martin Husemann)

13 Frequently asked questions

- bei einem der naechsten Updates vorgesehen -

14 Versions-History

V. 2.11 (18. November 91)

neu: - Abschnitt 12 (Ansprechpartner): Daten der neuen Domains ergaenzt
neu: - Anhang E (Selbstdarstellungen): swb.de ergaenzt

V. 2.10 (01. Oktober 91)

geaendert: - Abschnitt 4 (Finanzen): Tarifbeispiele den momentanen Gegeben-
heiten angepasst.
neu: - Abschnitt 6.2 (Nameserver): Daten der neuen Domains ergaenzt
(soweit vorhanden)
neu: - Abschnitt 12 (Ansprechpartner): Daten der neuen Domains ergaenzt
neu: - Anhang E (Selbstdarstellungen): gun.de und open.de ergaenzt

V. 2.01 (12. August 91)

geaendert: - Abschnitt 6.2 (Nameserver): unido.informatik.uni-oldenburg.de
-> unido.informatik.uni-dortmund.de
neu: - Abschnitt 6.2 (Nameserver): Daten fuer swb.de ergaenzt

V. 2.00 (1. August 91)

*ERSTE OFFIZIELLE RELEASE*

geaendert: - Aufgrund der Intervention von Axel Pawlik (deutsches EUnet)
"unido" an allen relevanten Stellen ausgetauscht gegen
"DE-NIC" bzw. "deutsches EUnet"
- Beispiel "boerde.de" geaendert in "rhoen.de"
neu: - Nameserverdaten fuer ish.de
- neu aufgenommene Domain owl.de
- neu aufgenommene Domain swb.de
- Versions-History

V. 1.10 (23. Juli 91)

(verteilt an i...@methan.chemie.fu-berlin.de und die Leute vom deutschen
EUnet)

geaendert: - Korrekturen und Ergaenzungen von Frank Simon eingearbeitet
neu: - Daten des Kassenwarts
- neu aufgenommene Domain ish.de
- IN-Netiquette, Punkt Mailforwarder

V. 1.03 (13. Juli 91)

*erste Beta-Release* (verteilt an i...@methan.chemie.fu-berlin.de)

geaendert: - IN-Netiquette ueberarbeitet

V. 1.02 (11. Juli 91)

(interne Version)

neu: - IN-Netiquette

V. 1.01 (10. Juli 91)

Erste (interne) Version; vollstaendig neu ueberarbeitete Fassung

V. 1.00 (5. Juli 91)

Identisch mit in-berlin-Info V. 3.10

15 Disclaimer

Um irgendwelchen Irrtuemern oder Fehlinterpretationen vorzubeugen:
Das IN hat nichts mit irgendwelchen Universitaeten zu tun, nutzt keine Re-
sourcen der Universitaeten und stellt erst recht keine Dienstleistung der-
selben dar.

Vera Heinau, Heiko Schlichting (ad...@methan.chemie.fu-berlin.de)

- * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * -

A N H A E N G E

- * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * -

ANHANG A netdir-Service von unido

A.1 Beschreibung

Man kann bei unido anfragen, ob ein bestimmter Rechner dort bekannt ist
oder nicht. Grundlage bildet bei unido die worldmap. D.h.: Sollte die
Anfrage negativ ausfallen, so gibt es zur Zeit (!) keinen Rechner des
entsprechenden Namens.
Die Anfrage wird automatisch von einem Programm beantwortet, deswegen
muss sie standardisiert gestellt werden. Man schickt einfach eine Mail
an unido mit folgenden Angaben:

To: net...@unido.informatik.uni-dortmund.de
Subject: xyz , wobei 'xyz' der gesuchte Rechnername ist

Body: wird ignoriert
Reply-To: wird ignoriert

unido schickt dann eine Antwort mit dem Subject 'Info on xyz'

Man kann auch mehrere Informationen gleichzeitig anfordern, indem man
im Subject alle gesuchten Rechner, getrennt durch Space, angibt.

Unten folgt eine Beispiel-Anfrage, um zu zeigen, wie die Antwort in
folgenden Faellen aussieht:

- Site bei unido nicht bekannt (Beispiel: zikzak)
- Site bei unido bekannt, jedoch kein Mailpfad (Beispiel: neon)
- Site bei unido bekannt, Mailpfad ebenso (Beispiel: utopia)
- Site bei unido registriert (Beispiel: fub)

(ich bitte die 3 oben angefuehrten in-berlin-Sites um Nachsicht, dass
ich ihre Namen verwendet habe. Aber da keine zu schuetzenden Daten ueber-
tragen wurden, hoffe ich, dass nichts dagegen einzuwenden ist. Und die
Beispiele waren wirklich zu schoen :-)

A.2 Beispiel

Beispiel-Anfrage netdir-service unido (Antwort)
************************************************

Return-Path: <unido!netdir>
Date: Sun, 2 Dec 90 20:14:59 +0100
To: methan.chemie.fu-berlin.de!heinau (Vera Heinau)
Subject: Info on zikzak neon utopia fub

Copyright (c) Sun Dec 2 19:14:44 GMT 1990 EUUG/EUnet; information
may not be used for commercial purposes or to the detriment of EUnet.

Couldn't find path to zikzak

UUCP map data for site zikzak:
Not available

Couldn't find path to neon

UUCP map data for site neon:

System name : neon, .micscand.se
Organization : Micro Scandia Industriautomation AB
Contact person : Lars Nordberg
Electronic Address : la...@micscand.se
Telephone : +46 31 830 130
Postal Address : Box 35041, S-400 24 Gothenburg, Sweden
Longitude/Latitude : 57 43 N 12 00 E
Last editor & date : la...@micscand.se 860626

Connect list etc. :

chalmers micscand.se, .micscand.se

path to utopia: mcsun!uunet!mimsy!rutgers!mit-eddie!bu.edu!utopia

UUCP map data for site utopia:

System name : utopia
System type : IBM PC/AT; Microport System V/AT 2.3
Organization : Casual Computer
Contact person : Eliot Moore
Electronic Address : utopia!root
Telephone : +1 818 901 0422
Postal Address : POB 7670 Van Nuys CA 91409
Longitude/Latitude : 34 00 N / 118 28 W
Remarks : System based in Santa Monica
Usenet (news) links:
Last editor & date :

Connect list etc. :

utopia buita(DAILY)

path to fub: fub

UUCP map data for site fub:

System name : fub
System type :
Organization : Freie Universitaet Berlin, FB Chemie, Institut f. Organische Chemie
Contact person : Heiko Schlichting, Vera Heinau
Electronic Address : postm...@fub.uucp, he...@fub.uucp, hei...@fub.uucp
Telephone : +49 30 838 2677
Remarks : Telefax: +49 30 838 5163
Postal Address : Takustr. 3, D-W-1000 Berlin 33, Germany
Longitude/Latitude : 52 31 N / 13 24 E city
Last editor & date : i...@unido.uucp; 900803

Connect list etc. :

fub unido(HOURLY), aball(LOCAL)

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

ANHANG B Netiquette

User
****
Fuer das Verhalten der User beim Posten und Mailen sei an dieser Stelle
auf die regelmaessig in sub.newusers erscheinenden Postings verwiesen.
Sollten diese Artikel bei einzelnen Sites schon expired sein, so kann man
sich die Texte (u.a.) von ftp.fu-berlin.de holen oder eine entsprechende
Mail an ad...@methan.chemie.fu-berlin.de schreiben.
das IN gibt keine Netiquette fuer die regionalen Domains vor, sondern gibt
nur Empfehlungen fuer das Zusammenleben der Domains innerhalb des IN.

Antraege zur Teilnahme an einer Domain
**************************************
Diese Antraege sind schriftlich bei den Domainverwaltern zu stellen. Die
eingegangenen Antrage sind von diesen aufzubewahren.

Weitergabe von News
*******************
Die ueber das IN bezogenen News (Ausnahme: sub.all) duerfen nur an Sites
weitergegeben werden, die dafuer auch bei beim deutschen EUnet bezahlen.

Mailforwarder
*************
Es ist nicht zulaessig, auf Sites, die dem IN angehoeren, Mailforwarder
fuer Sites oder User einzurichten, die *NICHT* dem IN angehoeren.

Firmen, Universitaeten, oeffentliche Einrichtungen
**************************************************
Firmen, Universitaeten und oeffentliche Einrichtungen duerfen vom IN nicht
aufgenommen werden. Ein voruebergehender Anschluss zu Testzwecken mit dem
Fernziel, dass diese Teilnehmer selbst einen Vertrag mit dem deutschen EUnet abschliessen,
ist gestattet.

Ausgeschlossene Sites
*********************
Sites (Teilnehmer), die von einer Domain ausgeschlossen wurden, koennen nur
in Ausnahmefaellen von einer anderen, dem IN angehoerenden, Domain aufgenom-
men werden.

Abwerbung
*********
Die gezielte Abwerbung von Sites aus einer anderen Domain sollte unterbleiben.

Unterdomains
************
Unterdomains koennen nur von administrativen Zusammenschluessen verwendet wer-
den, wie z.B: Mailboxen. Der Verwaltungsrechner der Unterdomain ist selbst zu-
saetzlich als Rechner der Domain erreichbar.
Beispiel:
.phone.north.de (Atari Lan von Dirk Rode)
dazu edison.north.de (=edison.phone.north.de = Verwaltet
.phone.north.de)
oder
.isc.north.de (Mailbox aus mehreren Rechnern in OL)
dazu olis.north.de (=olis.isc.north.de = verwaltet die Rechner)

Regionale Subdomains
********************
Regionale Subdomains (wie z.B. .owl.north.de) gibt es in Zukunft nur fuer
Uebergangszeiten, bis eine eigene Domain beantragt ist. Bestehende Subdomains
dieser Art sollen aufgeloesst werden.

Verwaltungsrechner
******************
Der Verwaltungsrechner einer Domain ist auch unter seiner Domain erreichbar.
Beispiel:
Der Rechner Sol ist Verwaltungsrechner fuer .north.de
Das heisst sol.north.de ist auch als north.de erreichbar.
postm...@north.de ist daher eine sinnvolle Adresse.

News, Controlmessages
**********************
Die wesentlichen Aussenweltverbindungen einer Domain haben dafuer zu sorgen,
dass keine Controlmessages (insbesondere sendsys, checkgroups) nach aussen
und in die Welt gelangen. Dazu gibt es Patches fuer bnews oder die Moeglich-
keit die Gruppe "control" gar nicht weiterzuspoolen.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

ANHANG C Teilnahmeantrag

IIIII
I
I
I
N N Individual Network
IIINI N
N N N
N N N
N NN
N N

Antrag zur Teilnahme
--------------------
Hiermit beantrage ich fuer die untenstehende Domain die Teilnahme am
Individual Network (IN). Durch die Teilnahme sind wir verpflichtet,
uns an die Netiquette des IN zu halten, sowie unseren Anteil an
den Kosten fuer die Privatpersonenregelung mit dem EUnet zu bezahlen.
Weiterhin verpflichten wir uns, keine Universitaeten oder Firmen in
unserer Domain anzuschliessen. Dafuer erhalten wir das Recht, alle
Dienstleistungen des EUnet und des IN, insbesondere volumenunabhaengige
Mailgebuehren und internationale News, DNS-Dienste, auf Wunsch und bei
technischer Moeglichkeit auch Internetdienste, in Anspruch zu nehmen.

Der Schluessel fuer die Kosten wird monatlich bestimmt.
Die "Rechnungsstellung" erfolgt per EMail durch den amtierenden Kassenwart.
Die Beitraege sind unverzueglich nach Erhalt dieser "Rechnungen" auf das
Konto des IN einzuzahlen.
Wir verpflichten uns ferner, zum 20. eines jeden Monats dem Kassenwart des
IN eine aktuelle Liste der bei uns teilnehmenden Rechner mit Angaben ueber
Art und Anzahl der User zuzuschicken.
Ein entsprechendes Muster findet sich im IN-Info (Anhang D)

=======================================================================

Administrativer Kontakt (Name, Telefon, E-Mail) (Finanzen, etc)

________________________________________________________________

Technischer Kontakt (Name, Telefon, E-Mail) (Routing, etc)

________________________________________________________________

Domain- und Netzname (z.B. .north.de, NorthNet)

________________________________________________________________

Domain-Routing: ________________________________________________

Vertretung in IN-Maillinglist (E-Mail): ________________________

Bisher EUnet- oder InterEUnet-Mitglied gewesen?

( ) ja ( ) nein

Gewuenschte de-Domain schon bei beim DE-NIC beantragt?

( ) ja ( ) nein

Anzahl der Systeme in der Domain _________________

Anmerkungen:

________________________________________________________________

Weiteres Informationsmaterial ist von dem naechsten IN-Knoten oder
bei i...@methan.chemie.fu-berlin.de anzufordern.

Der Antrag ist zu richten an:

Gereon Ziegelowski
Moltkestr.5
D-4156 Willich 1

Ort, Datum Unterschrift

------------- ---------------

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

ANHANG D Muster fuer Teilnehmerliste

D.1 Leerformular

Teilnehmende Systeme der Domain ___________________________________________

lfd.| | | | Teilnehmer |
Nr.| Sitename |z| verwaltet von | UUCP | Internet | Bemerkungen
==============================================================================
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
==============================================================================
| | | | | |
==============================================================================

z: Zahlender Rechner (+/-):
Zweitrechner des selben Teilnehmers zahlen z. B. keine doppelte Gebuehr,
ebenso Sites, die laengere Zeit offline sind oder noch nicht am Netz-
verkehr teilnehmen.

Teilnehmer: Jeder Teilnehmer zaehlt als UUCP-Teilnehmer *ODER* als Internet-
Teilnehmer, d.h. in der Aufstellung ist bei nur bei Mailboxen
anzugeben, fuer wieviele Teilnehmer Internet-Gebuehren gezahlt
werden und fuer wie viele UUCP-Gebuehren - "normale" Sites geben
hier an, ob sie UUCP- oder Internet-Teilnehmer sind.

D.2 Beispiel

Teilnehmende Systeme der Domain in-berlin.de

lfd.| | | | Teilnehmer |
Nr.| Sitename |z| verwaltet von | UUCP | Internet | Bemerkungen
==============================================================================
01 | dobag.in-berlin.de |+| in-berlin.de | 1 | 0 |
02 | tmpbag.in-berlin.de |-| in-berlin.de | - | - | = dobag
03 | tmpmbx.in-berlin.de |+| in-berlin.de | 0 | 1 | POP
04 | netmbx.in-berlin.de |+| in-berlin.de | 3 | 4 | Mailbox
05 | akki.in-berlin.de |-| in-berlin.de | - | - | ab 01.08.91
06 | zorbius.in-berlin.de |-| in-berlin.de | - | - | offline
| | | | | |
| | | | | |
==============================================================================
06 | (3 zahlende) | | | 4 | 5 |
==============================================================================

z: Zahlender Rechner (+/-):
Zweitrechner des selben Teilnehmers zahlen z. B. keine doppelte Gebuehr,
ebenso Sites, die laengere Zeit offline sind oder noch nicht am Netz-
verkehr teilnehmen.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

ANHANG E Darstellung der einzelnen Domains

E.1 gun.de

Historie:
=========
Die Domain GUN.de besteht seit Mitte 1990. GUN ist eine Abkuerzung
und steht fuer Gemeinschaft der Unix Anwender Niederrhein. Allerdings
beschraenkt sich der Teilnehmerkreis schon seit einiger Zeit nicht
mehr nur auf Rechner die mit Unix betrieben werden und auch das Gebiet
reicht inzwischen von Koeln bis Duisburg.

Ziele:
======
Die Domain wurde damals gegruendet um am EUnet im Rahmen der damals
gueltigen Privatpersonenregelung (PPR) teilnehmen zu koennen. Ziel
ist es die Region zuverlaessig, schnell und moeglichst preiswert
mit Mail und News versorgen zu koennen sowie neue Teilnehmer bei der
ihrem Netzanschluss zu unterstuetzen.

Hard-/Software:
===============
In der Palette der Hardware-/Softwareplattformen ist inzwischen
wirklich (fast) alles vertreten was auf dem Markt angeboten wird,
sodass sich fuer jeden inzwischen ein kompetenter Ansprechpartner
findet.

Modems/Links:
=============
Derzeit bestehen zwischen den Teilnehmern ausschliesslich
uucp-Verbindungen ueber V32/V32bis/PEP Modems, eine Internet-Anbindung
ueber Standleitungen und/oder ISDN ist bis Mitte 1992 in Planung.

Ansprechpartner:
================
Wer an der Domain teilnehmen moechte kann sich an folgende Personen wenden:

Andreas Baess (and...@easix.GUN.de) Tel. 0211/4954-246 tagsueber
02131/605652 abends
Rainer Bieniek (rai...@flyer.GUN.de) Tel. 0203/4060004 Anrufbeantworter
Sascha Wildner (swil...@channelz.GUN.de) Tel. 0223/15571

--
Andreas Baess <and...@easix.GUN.de> {tmpmbx,mcshh,smurf,unido}!easix!andreas

E.2 maus.de

Wir im MausNet

Obwohl das MausNet technisch gesehen recht jung ist - die Netzprotokolle
sind gerade mal zwei Jahre alt - gehen die Urspruenge der Software in das
Jahr 1985 zurueck. Maus, der Name stand damals fuer Muenster Apple User
Service, ist damit eines der aeltesten bundesdeutschen Systeme.

Die Keimzelle der Maus-Programmierer und -Benutzer aus Muenster verteilte
sich dann mit der Zeit ueber die Bundesrepublik und trug so zur Verbreitung
der Software bei. Lange Zeit galt Maus und das MausNet aber als Geheimtip,
insbesondere bei den Atari ST Benutzern, kann das MausNet doch einen
Grossteil der ST-Prominenz zu den aktiven Benutzern beziehungsweise zu den
Sysops zaehlen. Interessant ist in diesem Zusammenhang die Tatsache, dass
die original Maus-Software ausschliesslich auf MS-DOS Systemen laeuft und
es erst seit kurzem ein kompatibles Programm auf ST Basis gibt.

Seit den ersten Tagen ist die Benutzerfuehrung der Maus-Software ziemlich
dieselbe. Maus setzt auf ein Menusystem - auch dies ein Grund warum der
GeoNet-kompatible 'Nachbau' fuer den Atari ST nicht bei allen Sysops auf
Gegenliebe stoesst. Die Maus-Oberflaeche hat aber inzwischen
Wiedererkennungswert und hebt sich erfreulich bestaendig vom sonstigen
Mailbox-Mischmasch ab. Die Maus-Software ist 'aus einem Guss' und durch und
durch deutschsprachig - kein Vergleich also zu den zusammengestueckelten
Fido-Systemen, die sich nicht einmal entscheiden koennen ob sie nun komplett
englischsprachig oder vielleicht doch ein bischen deutschsprachig sein
wollen.

Die Interna der Software haben sich insbesondere seit der Einfuehrung der
Netzprotokolle im Fruehjahr '89 stetig weiterentwickelt. Zur Zeit gibt es
aber leider einige auf absehbare Zeit aergerliche Einschraenkungen. So ist
die Gesamtzahl der Systeme im Netzverbund auf 255 limitiert (wobei das
durchaus auch ein Vorteil sein koennte) und die Mausadresse kann zur Zeit
nur drei Zeichen lang sein (also beispielsweise nur maximal 10 Maeuse in
Hamburg: HH bis HH9). Die Namen der Newsgroups (im Maus-Jargon Gruppen
genannt) ist auf 10 Zeichen beschraenkt und es gibt keine Hierarchie wie
z.B. bei der Zerberus-Software. Aber zumindest das wird demnaechst
geaendert. Fuer die Zukunft ist aber eine RADIKALE Softwareaenderung geplant,
nach dem Motto 'Lieber ein Ende mit Schrecken (Umstellung und zwei Wochen
Chaos) als ein Schrecken ohne Ende (auch Abwaertskompatibilitaet genannt)'.

Von Aenderungen der Interna so unabhaengig wie es eben nur geht ist *DIE*
normierte Schnittstelle der Maus nach aussen hin: der MausTausch. In
seiner urspruenglichen Form als Schnittstelle zu User-Frontends (in etwa
mit Fido- oder eher Zerberus-Points zu vergleichen) ist der MausTausch in
erweiterter Form auch fuer Gateways und sogenannte 'Fremdboxen' ausgelegt.
In jedem Fall handelt es sich um einen Datenaustausch auf reiner Textbasis
(und damit unabhaengig von Byte-Folgen und aehnlichen Huerden in der
Rechner/Rechner Kommunikation). Points in dem Sinne, wie es sie im FidoNet
(oder annaehernd auch im Z-Netz) gibt, kennt das MausNet aber nicht. Der
MausTausch ist auf jeden Fall an einen gueltigen Online-Account im System
gekoppelt. Von der Maus-Philosophie her sind online-User und MausTauscher
auch gleichgestellt - eine besondere Wertigkeit oder gar Pflichten wie sie
die Points im FidoNet haben gibt es nicht.

Philosophisch ist die Maus sowieso im Vergleich zu anderen Netzwerken sehr
liberal. So gibt es keine unterscheidlichen Userlevel sondern nur GAST
(ein Benutzer, der seinen Namen nicht angibt) und User (jemand, der seinen
Namen (und nur den) dem System bekanntmacht). Selbst der SysOp tritt
oeffentlich als normaler Benutzer auf - Mails mit dem Absender 'Sysop'
koenen nur privat versandt werden, und auch dann steht der Realname des
jeweiligen Sysop dahinter ('Sysop Michael Keukert @ AC2'). Oeffentliche
Nachrichten von 'Sysop', 'Root' oder 'Postmaster' gibt es zum Glueck nicht.

A propos Sysop: Wer sich mit dem Gedanken traegt, eine eigene Maus zu
eroeffnen, der verfasst eine kurze Selbstdarstellung inclusive einiger
Angaben ueber die geplante, neue Maus. Diese wird dann den uebrigen Sysops
uebermittelt und diese entscheiden dann per Mehrheitsbeschluss ob man den
potentiellen Kollegen aufnehmen will. Diese normalerweise recht einfache
aber dennoch vorhandene Huerde ist mit verantwortlich dafuer dass das MausNet
noch ueberschaubar ist. Hier ist es eben nicht einfach mit dem Kauf der
Software (wie im Z-Netz) oder der erfolgreichen Installation (wie im Fido)
getan. Dieses Verfahren hat sich bewaehrt, wird aber leider mit zunehmender
Netzgroesse nicht mehr lange durchfuehrbar sein.

Das MausNet hatte einen der ersten beiden bundesdeutschen Gateways
ueberhaupt. Ob es *DER* erste war, laesst sich leider nicht mehr genau
nachpruefen - das ist aber auch ziemlich unerheblich. Seit damals gilt die
Grundregel der Gegenseitigkeit: ein Gateway muss immer in zwei Richtungen
funktionieren - ansonsten wird eine der beiden Seiten ausgenutzt. So wurde
bisher das Ansinnen auf einen MagicNet-Gateway immer wieder abgelehnt weil
die MagicNet-Politik den Export von Magic-Gruppen in andere Netze
untersagte. Dies ist seit kurzem nicht mehr der Fall und derzeit wird
folgerichtig auch an einem Gateway gearbeitet.

Zur Zeit existieren Gateways (in der Reihenfolge ihrer Entstehung) zum
FidoNet, Z-Netz, UseNet, Bitnet/EARN und GEnie, ein Gateway zum MagicNet
ist wie gesagt in Vorbereitung. Die gegenseitige Vernetzung der einzelnen
Newsgroups bitte ich dem jeweils aktuellen GATOR zu entnehmen.

Worauf die Sysop-Gemeinde aber sehr allergisch reagiert ist die
unabgesprochene und damit auch unerlaubte Weitergabe von MausGruppen durch
andere Netze - dies fuehrte vor einiger Zeit auch zu Aerger mit dem Z-Netz.
Darueberhinaus gibt es einige Gruppen, die per Definitionem nicht an andere
Netze weitergegeben werden. Dazu gehoeren neben den Sysop-Gruppen z.B. noch
die Gruppen MAUS und ATARI ST. Erstere weil sie der Diskussion im- und
uebers Netz dient (Maus durfte ja z.B. auch nicht NORTH importieren),
letztere um die Gruppe ueberschaubar zu halten und um noch Anreize zum
stoebern im Netz selber zu halten und nicht Ausverkauf zu betreiben.

Mit z.Zt. (6/91) etwas ueber 40 Installationen ist das MausNet wohl eher
ein kleineres bundesdeutsches Netzwerk, vom Niveau und der Aktivitaet der
Benutzer aber sicherlich unter den Ersten einzuordnen. Wir freuen uns auf
Deine Beteiligung, sei es unmittelbar oder gut-nachbarschaftlich ueber
Gateways hinweg.

Fuer ANHANG E.2 gilt:

(Juergen Conradi @ hb.maus.de - GateWay Bremen)

(Beliebige Verwendung mit Quellenangabe non-kommerziell zu Zwecken des IN.
Fuer jede weitere Verwendung, insbesondere aber nicht ausschliesslich der
Abdruck in Printmedien, ist die Erlaubnis des Autors einzuholen. Davon
ausgenommen ist die kostenlose Verteilung in Mailboxnetzen, die nicht nur
erlaubt sondern ausdruecklich erwuenscht ist.)

E.3 open.de

Ungefaehr in der Mitte des Jahres 1990 schlossen sich einige wagemutige
Menschen im Ruhrgebiet und in Hannover zusammen, um ihre (Internat.) Mails
und News nun via dem als boesen Raubritter verschrienen Unido transportieren
zu lassen, sie vereinbarten also (nach dem Vorbild des Hanse/NorthNet, und
basierend auf den Verhandlungen des Subnet e.V.) eine Regelung, die spaeter
von einigen Werbeleuten zu PPR abgekuerzt wurde.

Zu diesem Zweck besorgte man sich damals jeweils eine De-Domain (han.de/ruhr.de)

Da jene Menschen sich der 'Spannungen' zwischen Unido und dem 'Subnet' wohl
bewusst waren, waren sie ueber das folgende ohne Diskussion einer Meinung:

o 'wir' wollen durch unser Verhalten nicht zu einer weiteren Eskalation
zwischen Subnet und Dnet beitragen.
o wir wollen niemanden ueberzeugen oder gar missionieren, dass unsere Loesung
auch fuer Ihn gut ist, nur weil wir sie fuer UNS gewaehlt haben
o Werbung ist im Subnet verpoent, also wollen wir fuer uns darin auch keine
Werbung machen
o Wir wollen niemanden 'ueberreden' (schaerfer: 'ueberrumpeln'), dass er
mitmacht.
o Wenn jedoch jemand mitmacht, ist er Willkomen, wir wollen auch niemanden
daran hindern, oder gar Steine in den Weg legen.
o Keine der (bisher) bei uns angeschlossenen Subnet-Only-Sites soll es
durch unsere Unido-Vereinbarung (Mail-maessig) schlechter gehen, als
vorher. Wir ueben also KEINEN 'indirekten' Druck aus, um jemand zur
Teilnahem an der PPR zu bewegen, sondern halten auch weiterhin
(kostspielige) Subnet-Fernlinks aufrecht, auch wenn wir sie selbst nicht
unbedingt mehr brauchen.
o Wir begeben uns nicht in eine voellige Abhaengigkeit von Unido.
o Wir wollen versuchen, durch unser Verhalten die Bestrebungen des Subnetzes
(wer immer das ist/war) eine Unido-unabhaengige Loesung fuer Int. Mail/News
zu schaffen, moeglichst nicht/wenig zu blockieren/behindern.
o Wir brauchen keine 'eigene' Netiquette, da wir kein eigenes Netz sind.
Vielmehr sind fuer uns die schon vorhandenen Netiquette genausviel(-wenig)
bindend, wie fuer andere Netzteilnehmer.
o 'Unsere' Teilnahmebedingungen beschraenken sich im wesentlichen auf die
Einhaltung der mit Unido abgemachten Bedingungen, sowie die finanzielle
Abrechnung. Eine 'Gesinnungspruefung' findet nicht statt.

... und noch ein paar andere 'Kleinigkeiten' die mir auf Anhieb nicht einfallen.

Abgesehen von einigen kleineren Problemen (in der Anfangsphase) funktionierte
dieses Gebilde recht gut, und es wuchs im Stillen langsam nur aufgrund von
Mundpropaganda, aber ohne aktives dazutun.

Es funktionierte fuer die Beteiligten einfach so, wie es sollte, ohne dass
nach aussen dadurch viel Wirbel gemacht wurde.

Einen Namen fuer dieses 'wir' fand' man auch, und zwar UHL - Unido-Horga-Link,
jedoch stiess diese Abkuerzung bei einigen Aestheten auf permanente Kritik.

Viele Monate gehen ins Land, und wir befinden uns nun in der ersten
Jahreshaelfte des Jahres 1991.

Viele Veraenderungen sind ins Land gegangen, und auch das Netz ist nicht
mehr das, was es einmal war.

Und so ist das nun etwas verstaubt wirkende UHL den Anforderungen der
neuen Zeit leider nicht mehr gewachsen.

Ein Thronfolger muss also her !

Es wurden nun alle Hebel in Bewegung gesetzt, und keine Anstrengung war zu
anstrengend, und keine Gefahr zu gefaehrlich, auf dieser Suche.

Schliesslich fand man bei einem mitternaechtlichem Hochgeschwindigkeitsbrain-
storming auf der A42 zwischen Duisburg und Dortmund die rettende Loesung.

Das OPeN ward geboren.

Sowohl dieser Name, als auch die schnell dafuer gefundene Langbedeutung:
"Open Personal Network " (von einem GNU-Fan) erfreuten sich nun fortan
unter den Teilnehmern desselben, einer staendig steigenden Beliebtheit,
und auch die Marketingexperten waren nun aufgrund des zeitgemaess steigenden
'WIR'-Gefuehls zufrieden, und die Aestheten waren begeistert, weil sowohl
Kurz- als auch Langform gleichzeitig huebsch wie nichtssagend ist, und damit
der Phantasie des Lesers Raum fuer vielfaeltige Assoziationen gelassen wird.

Und die Zeit verging, und es funktionierte noch alles so gut, wie vorher.

Nun begab sich aber irgendwann, dass die OPeN-Leutchen wohlwar ein
reiselustiges Grueppchen sind, denn einige Mutige zogen in ferne Laender.
Jene wollten aber auch in der Ferne nicht die heimatlichen Banden abreissen
lassen (die Marketingleute hatten das 'Wir'-Gefuehl anscheinend richtig
dosiert), und blieben also weiter im OPeN.

Und so konnten sie aber nicht mehr unter den Maenteln von 'han.de/ruhr.de'
bleiben, sondern mussten sich eigene Maentel besorgen.

Nun also frisch ans Werk, eine Audienz beim DE-Domain-Gott beantragt, und
schnell mal ein paar Maentel 'besorgt'.

Nur leider war dieser Netz-Gott so sehr mit der Bekaempfung von boesen
Daemonen beansprucht (die aber nur er bekaempfen konnte, so sagte er),
dass er der DE-Gott-Aufgabe, obschon seiner Budda-aehnlichen Statur, nicht
mehr nachkommen konnte, zumal auch wegen der gleichen Sache wieder viele
andere um Audienz bei ihm Schlange standen.

Also, schwuppdiwupp, wurde ein allgemeiner Mantel erdacht, benannt nach dem
gleichnamigen Grueppchen, und so war 'open.de' geboren.

Nun also konnten endlich alle ausgewanderten tapferen Recken ihren 'eigenen'
Mantel bekommen, ohne vergeblich vielbeschaeftigte Goetter beknieen zu muessen.
Sie nannten sich dann halt nicht 'stadt.de' sondern 'stadt.open.de', aber diese
zusaetzlichen 5 Tastendruecke Mehrarbeit nahen sie ob der nun unkomplizierten
und fast verzoegerungsfreien Verteilung freudestrahlend auf sich.

Nun also waren wieder alle Gluecklich, und die Tage gehen ins Land.

Alle ? Nein nicht ganz.....

Was war das ? Einige wurden nun aufgeschreckt durch so neumodischen Kram
wie 'Internet' und 'volumenunabhaengig', und so.

(Fortsetzung folgt ...vielleicht .... in diesem Kino)

Andreas Frackowiak (z...@ruhr.de)

E.4 swb.de

Graphical representation of the BrewNet:

0-g
/
B-0-b-0-h
|
F-0-!f | i
\ 2 /
2 | 2-!e-0-E
\|/
l-1-a-1-C
/|\
1 1 1-A
/ |
c-0-d-0-D
/ \
j-0 0-k

Key:
a=brewas($) A=cbmger/cbmehq (CBMnet/ADSP and outbound overseas Email)
b=brewak($) B=horga.ruhr.de (Zerebus feed, InterEUnet Email)
c=brewhq C=incom.incom.de (News, swb.sub.org Email)
d=brewhr($) D=hotb.radig.de (Weiterstadt newsfeed)
e=drages4(!) E=buchonia.rhoen.in-berlin.de (Fulda newsfeed)
f=brewmk F=easix.GUN.de (Kaarst newsfeed)
g=befido(+)
h=mailmak(+)
i=eck(*+)
j=atkins(+)
k=morty(*+)
l=venus(*+)
Phone costs: 0=local call, 1 & 2=long distance call
$ = TB2500 site; * = being connected
+ = Domain (swb.de), but not Brewery member
! = temporary offline/unused connection

("Public" News like sub.all are feed for local usage through horga,
incom, buchonia, easix and hotb respectivly.)

Hier endet die praegnante und englische Beschreibung. ;-)

Die Domain swb.de ist die Domain der Software Brewery, einer
Vereinigung von Programmieren verschiedenster Professionalitaet (aber
alle privat ;-). Der ueberwiegend in dieser Domain vertretene Rechner
laesst sich aus meiner Signature erkennen. ;-)
Wie sich aus der Map unschwer erkennen laesst, sind wir recht flaechig
ueber die Alt-Republik verteilt und nehmen auch Teilnehmer in die Domain
auf, welche dies aus rein mail/newstechnischen Gruenden wuenschen.
Dabei sind wir natuerlich nicht auf einen gewissen Rechnertyp
festgelegt, allerdings duerfte der Support was AmigaUUCP und Amiga-CNews
angeht in dieser, unserer Domain ueberdurchschnittlich gut sein.
Wir sind bisher in der gluecklichen Lage, auf die Eintreibung von
(internen) Leitungs- oder gar Adminstrationskosten verzichten zu
koennen.
Fuer diejenigen, welche den (inzwischen sehr preiswerten) Schritt ins IN
fuerchten, bieten wir die Domain swb.sub.org (mit der bekannten
Volumengebuehr fuer int. Mail) als Uebergangs- oder Dauerloesung an.

Proesterken,

Christian Balzer (C...@brewhq.swb.de)

0 new messages