🚀 go-pugleaf

Information zum 'Individual Network' (IN)    V. 3.01 (Gueltig ab 1.7.1992)
*************************************************************************

				Inhalt
				------

 1. Vorwort
	1.1. Einfuehrung
 	1.2. Allgemeine Grundidee
	1.3. Die Ziele des IN

 2. Wir im IN
	2.1. Leistungen und Nutzungsmoeglichkeiten des IN
	2.2. Domainkosten
	2.3. Teilnahme am Individual Network (IN): Domain
	2.4. Teilnahme am Individual Network (IN): IP

 3. Technische Informationen
	3.1. Routing
	3.2. Nameserver
	3.3. Maps
	3.4. Namenswahl der Domain

4. Administrative Informationen
	4.1. Beratung
	4.2. Netiqette/Guidelines
	4.3. Preispolitik
	4.4. Support
	4.5. Network Managment
	4.6. Netzpolitik, Oeffentlichkeitsarbeit & praktische Arbeit
	4.7. Entscheidungsfindung im IN
	4.8. Disclaimer


 ANHANG A	Domainantrag fuer das DE-NIC
 ANHANG B	Formulare fuer DNS
 ANHANG C	Teilnahmeantrag
 ANHANG D	IN-Netiquette
 ANHANG E	Liste fuer monatliche Kassenwartmeldungen
 ANHANG F	Satzung des IN eV
 ANHANG G  	Antrag fuer ein Class-C-Netz
 ANHANG H 	Acceptable Use Policy 

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

1. Vorwort
----------

1.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.

Ausserdem beachtet, dass sich in den naechsten Monaten noch einiges
an dem Text hier aendern wird.

Warum ist es vorteilhaft, einer Domain anzugehoeren? 

Nun, der Hauptgrund, warum sich mittlerweile deutschlandweit so viele Sites 
einer Domain angeschlossen haben, liegt darin, dass die Sites auf diese Weise 
weltweit eindeutige 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.uu.net, 
mcsun.eu.net, mail.germany.eu.net) 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 mail.germany.eu.net gehen, Mails mit der Domain '.in-berlin.de' 
an fub usw.  Bei uunet.uu.net sind Bestrebungen im Gange, das weltweite 
Routing laengerfristig vom "Map-Routing" auf "Domain-Routing" umzustellen, so 
dass Maps dann irgendwann 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. Wir wollen natuerlich
hier fuer das Individual Network "Werbung" machen, welches de-Domains
von Privatpersonen (Regional oder Organisatorisch) anschliesst. Fuer
Informationen ueber die Alternative (.sub.org), wende mensch sich an
Matthias Urlichs (urlichs@smurf.sub.org).

Als '.de'-Site bzw. (Unter-)Domainverwalter ist man auf der einen Seite 
natuerlich an die Vorgaben der Provider gebunden und in gewisser Beziehung 
von diesen abhaengig. Allerdings hat das IN sich zum Ziel gesetzt, diese
Abhaengigkeit zu reduzieren und die Dienste und Infrastruktur fuer 
Privatpersonen zu sichern. Dies geschieht z.B. dadurch, dass das IN
bei mehr als einen Provider Kunde ist und ueber die rechtliche Vertretung
z.B. im DFN und durch eigene WiN-Anschluesse sowohl Infrastruktur des WiN 
(Wissenschaftlichen Hochschulnetz) als auch durch die gleichezitige 
Teilnahme am EUnet dessen Infrastruktur (POPs, UniDo) nutzen kann.


1.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 deutschen EUnet in Dortmund ueber eine spezielle
Privatpersonenregelung teilnehmen und gleichzeitig ueber das IN regulaeres 
Mitglied des Deutschen Forschungsnetzes (DFN) sind.

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 hat es ermoeglicht, gegenueber dem deutschen EUnet als 
*ein* InterEUnet-Teilnehmer aufzutreten. Aufgabe des IN sollte sein, die Teil-
nahme an privaten de-Domains moeglichst preiswert zu realisieren und die 
Gruendung neuer de-Domains 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.

Ein Jahr spaeter war das IN auf 21 Domains angewachsen und in einer
Position, mit anderen Providern (XLink, DFN) zu sprechen und mit dem EUnet
Neuverhandlungen zu fuehren. Diese haben dazu gefuehrt, dass das IN heute
bei zwei Providern (DFN und EUnet) Kunde, WiN-Anschluesse besitzt und 
DFN-Mitglied ist. Allerdings war es dafuer notwendig, einen Verein als 
rechtlichen Rahmen zu schaffen, weil die Provider und die Telekom (wg.
WiN-Anschluss) nur einen Verein als Rechtspartner zu akzeptieren wollten.

An der Idee des Geistes des IN seinen Zielen und seiner Grundlage soll 
sich aber nix aendern, aber schlussendlich sind dafuer alle INler ver-
antwortlich. Diese Aussage braucht aber nicht fuer alle Zeiten so 
stehen bleiben. Durch das Wachstum des IN und die immer komplexes
werdenen rechtlichen und finanziellen Aufwendungen kann es geschehen,
dass das IN eines Tages als Verein Dienstleistungen anbietet - sobald
sich das als notnwendig erweisen sollte.


1.3. Ziele des IN
-----------------
Die Ziele sind einfach darstellbar:

	- Schaffung und Sicherung von guenstigen Zugaengen zu den 
	  internationalen Kommunikationsnetzen (Connectivity) fuer
	  Privatpersonen.
	- Das Wissen und die Strukturen in den Regionen und Netzen 
          zu staerken. 
  	- Eine Infrastruktur zu schaffen, so dass auch die Uebertragungs-
	  kostet minimiert werden koennen und diese Uebertragungswege
	  (z.B. zu Unis) rechtlich abzusichern.
	- Neue Netz-Dienste, wie z.B. IP-Dienste oder X.400 zu Gebuehren
	  ermoeglichen, die sich ein Privatmensch leisten kann.
	- Aufbau eines "Network Managment" zwischen den Domains, um
	  Verbindungen kostenguenstig und schnell zu organisieren.

Das IN besteht aus den Vertretern der Domains, die sich ueber mehrere
Mailinglisten beraten und in diesen Mailinglisten auch diskutieren
um Entscheidungen fuer das IN zu treffen. Dabei werden aber die Formen
so gewahrt, dass jede Domain den ihr ueblichen Entscheidungsweg
(Vorstandswahl, Voting, Diskussion fuer Meinungsbildung, etc.) durch-
fuehren kann. Dazu sollte besser das Kapitel ueber die Entscheidungs-
findung im IN gelesen werden.


2. Wir im IN
------------

2.1. Leistungen
---------------
Das IN selber betreibt aber keine eigenen Gateways oder Netze. 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 
bzw. in den Anfangsphasen und beim Aufbau neuer Domains, sowie bei
der konkreten Bereitstellung von Leistungen auf den IP-Sektor bzw.
internationaler Mail/News.

Als "Teilnehmer des IN" hat mensch Domains, also organisatorische
oder regionale Netze zu verstehen. Einzelpersonen sollten sich an
die in ihrer Region befindlichen Domain-Vertreter wenden und sich
dort direkt um einen Anschluss bemuehen. Kontakthilfe kann dazu
das IN natuerlich leisten.


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- und DFN/IP-Teilnehmer. Demzufolge hat 
	    jeder Teilnehmer am IN das Recht, direkt oder indirekt Internet-
	    dienste in Anspruch zu nehmen, sofern die entsprechenden 
            technischen Voraussetzungen erfuellt sind. Allerdings koennen
	    dadurch Vereinbarungen zwischen Domains und Universitaeten oder 
	    anderen Institutionen bzw. zwischen Domains und den POP`s (des 
	    EUnet) notwendig sein. Im IN werden auch schon eigene Internet-
            Strukturen geschaffen, so z.B. via ISDN und ueber die WiN-
            Anschluesse.
Bitnet:     Es wird dabei geholfen, dass ein deutsches Gateway zwischen
	    EARN/Bitnet und der Domain gefunden wird. Dies ist notwendig,
	    weil sonst E-Mails unnoetigerweise ueber Holland laufen.
WiN:	    Das IN besitzt Anschluesse ans wissenschaftliche Hochschulnetz
	    (WiN). Durch den WiN-Vertrag ist damit gewaehrleistet, dass wir
	    das WiN mitnutzen koennen. Dadurch ist es z.B. rechtlich 
	    moeglich, dass Domains sich an Universitaeten in ihrer Region 
	    anschliessen und ueber diese versorgt werden. Das IN und das 
	    DFN hilft (soweit es geht), diese rechtliche Moeglichkeit 
	    auch in der Praxis nutzen zu koennen.
EUnet:	    Durch die Teilnahme am EUnet ist die Infrastruktur des EUnet
	    nutzbar; u.a. unterhaelt das IN einen Link zum zentralen
	    Knoten des EUnet (germany.eu.net). Desweiteren koennen die
	    dezentralen Backbones des EUnet (POP) in Hamburg, Berlin und
	    Muenchen genutzt werden (Sondervereinbarungen mit den POPs 
	    sind von den Domains zu schliessen). Ausserdem steht die 
	    rechtliche Moeglichkeit offen, dass IN-Teilnehmer ueber EUnet-
 	    Kunden mitversorgt werdenl, falls diese damit einverstanden
   	    sind.
X.400:	    Die Teilnahme an deutschen und europaeischen X.400-Netzen ist
	    durch die DFN-Mitgliedschaft und WiN-Teilnahme moeglich.
IV:	    (=Interessenvertretung). Durch die Teilnahme am EUnet und DFN 
 	    will das IN dort die Interessen von Privatpersonen auf Tagungen, 
	    bei Arbeitskreisen und Versammlungen vertreten. 
Support:    Bei technischen, administrativen und netzpolitischen Fragen 
            werden die entsprechenden Ansprechpartner der Domains oder des 
            IN nach besten Kraeften versuchen, zu helfen.


2.2. Domainkosten
-----------------
Am IN nehmen ja keine Benutzer, sondern Domains teil. Fuer eine Domain
stellt sich vermutlich am Anfang die Frage nach den Kosten. Die beliebte 
Frage "Wie teuer ist das pro Rechner" wird dabei oft gestellt, ist aber 
vom IN gar nicht zu beantworten. Eine Domain muss sich an den Kosten des
IN beteiligen. Eine "untere Schranke" fuer diese Kosten wird auf Grund 
eines gleich vorgestellten Verfahrens ermittelt. 

Wie jetzt diese Summe X auf die einzelnen Teilnehmer einer Domain
umgelegt wird, ist ausschliesslich Sache der Domain selber. Gebuehren-
politik ist i.d.R. die beste Methode, um "Domainpolitik" zu betreiben. 
Anhand der Gebuehren kann mensch Mailboxen mehr zahlen lassen oder
alle gleich. IP-Benutzer koennen staerker zur Kasse gebeten werden
oder aber sie zahlen gerade weniger, weil mensch IP (Internet) in
der eigenen Domain foerdern will. Zu den IN-Kosten koennen ausserdem
Kosten fuer Fernlinks und aehnliches dazukommen, die mit umgelegt
werden, etc. Da dies alles autonom geschieht, koennen die Preise fuer
einen Rechner in einer IN-Domain von Domain zu Domain unterschiedlich
sein. Derzeit sind Gebuehren zwischen 8 DM und 25 DM im Monat anzu-
treffen, je nach dem was die Domain erreichen will. 

Daher kann hier nur auf die Frage geantwortet werden: "Wie hoch ist
der IN-Anteil einer Domain ?". Praktisch ist das viel einfacher. 

Es wird jeden Monat eine Liste der Sites innerhalb der Domain an
den IN-Kassenwart gemailt. Auf diese Art hat der Kassenwart die
Gesamtzahl aller Sites im IN. Gleichzeitig hat das IN ein "Einnahme-
ziel" festgelegt, welches sich aus den aktuellen Kosten des IN und
evntl. Ruecklagen berechnet. Das Einnahmeziel fuer die 2. Haelfte des
Jahres 1992 wurde z.B. auf 4500 DM festgelegt. Nun werden die Kosten 
des IN im gleichen Verhaeltnis zur Groesse der Domains (Anzahl der
Sites in der Domain) umgelegt. Eine Domain mit 30 Sites wird dabei 
einen Anteil von ca. 330 DM zugeteilt (Stand: 7/1992). 

Nun gibt es aber einige Domains, in denen eigentlich besondere 
Strukturen zu beruecksichtigen sind. Beispielsweise eine Domain, die 
nur eine Site hat (Verein), aber ziemlich viele Teilnehmer. Ein 
anderer Fall koennte eine Domain fuer ein Mailboxnetz sein, wo viele 
"Terminals" oder Benutzer pro Site zu erwarten sind. Da aber alle Faktoren, 
die eine Rolle spielen koennten, gar nicht beruecksichtigt werden koennen,
hat mensch sich im IN auf ein einfaches Zaehlverfahren (eben nach
Sites) geeinigt. 
Damit aber das Ganze nicht allzu ungerecht wird, sind die Domains die 
solche "Sonderfaelle" darstellen, von sich aus aufgerufen, mehr zu 
zahlen. Im Notfall koennte das IN auch bestimmen, dass eine Domain mehr 
zahlen muss - das war aber bis heute nie notwendig. Das IN sieht sich 
eben als Solidargemeinschaft.

Nun gut. Einige Domains zahlen also mehr, als der "Richtwert" vor-
gibt. Nachdem nun diese Domains (in Form ihrer Sitezahlen und
Kostenanteile) vom IN abgezogen wurden, werden fuer die restlichen
Domains die Kosten endgueltig bestimmt. Daraus resultiert, dass eine
durchschnittliche Domain mit 30 Sites ca. 270 DM zu zahlen hat. 

Dieser Wert kann vom Monat zu Monat leicht varieren, aber tendenziell 
wird es im IN immer guenstiger - es sei denn, ein Einnahmeziel wird hoch-
gesetzt oder es entstehen zusaetzliche Kosten. So ist z.B. die erwartete 
"starken" Kostenminderung in der 2. Haelfte 1992 hinfaellig geworden, 
weil die gleichzeitige Teilnahme am EUnet und DFN die Bildung von 
Ruecklagen erforderten und daher ein Einnahmeziel von 4500 DM monatlich 
fuer die zweite Jahrehaelfte beschlossen wurde.

Auch sind die Teilnahmezahlen im IN inzwischen recht hoch, so dass eine 
Kostenminderung fuer die Domains nur noch langsam zu erwarten ist 
(Kostenhalbierung bei einen Wachstum um 100% ist eben bei 50 Teilnehmern 
leichter als bei 400). 

Wenn ihr also aktuell wissen wollt, wieviel eure Domain zu zahlen haette, 
fragt einfach mal nach. Falls eure Domain ein "Normalfall" ist, koennt 
ihr aber mit obigen Beispielzahlen als "Worst Case" rechnen.

Anzumerken waere noch, dass besonders Server/Client-Konstrukte in
einer Domain die Kostenverteilung ungerecht gestalten koennen. Daher
gibt es eine Pflicht, solche Konstrukte (Mailbox mit Terminals, etc.)
beim IN zu melden. Sind solche Verhaeltnisse in einer Domain anzu-
treffen, so sollte sich die Domain zur gerechteren Verteilung der
Kosten mit einen entsprechend hoeheren Betrag an den Kosten des IN
beteiligen.


2.3. Teilnahme am Individual Network (Domain)
---------------------------------------------
Am IN kann keine Privatperson direkt teilnehmen. Am IN nehmen nur Second-
Level Domains teil. Falls in einer Region noch keine Domain des IN ver-
treten ist, wird aber gern beim Aufbau einer neuer Domain geholfen.

Will eine Domain dem IN beitreten, so hat sie dafuer verschiedene Schritte
zu unternehmen. Als erstes wendet sie sich an einen Vertreter des IN, dem 
ihm namentlich bekannt ist. Eine Liste dieser Vertreter kann z.B. in den 
vernetzten Gateway-Brettern sowie in de.org.in regelmaessig unter dem Betreff 
"Status des IN" abgerufen oder in der Mailinglist angefordert werden.

Der Beitritt einer Domain findet nach dem folgenden "Rezept" statt:

1. Der Domain-Verantwortliche hat diese Info in Haenden, weil hier die 
   entsprechenden Formulare enthalten sind.

2. Sie stellt sich in der Mailinglist "in" vor, gibt schon mal technische
   und organisatorische Informationen. Ausserdem gibt er bekannt, wer
   der Vertreter der Domain im IN sein soll - damit dieser in der 
   Maillinglist eingetragen werden kann. Es werden nun einige Fragen
   diskutiert (gibt es in der Region schon eine Domain, ist der Name
   sinnvoll, etc). 

3. Ist 2. geklaert, wird ab jetzt zuegig weitergearbeitet. Die Domain 
   stellt einen Antrag auf eine Domain. Diesen Antrag schickt er an den 
   angegebenen Bearbeiter des IN. Sobald die Punkte 4, 5 und 6 eindeutig 
   geklaert sind, wird der Antrag an DE-NIC weitergeleitet. 
   Der Antrag auf eine Domain befindet sich in Anhang A.

4. Sie fuellt das Formular in Anhang B aus und schickt es an den angegebenen 
   Menschen. Die Daten werden im IN gebraucht, um im Domain Name Service die 
   entsprechenden Daten einzutragen. 

5. Sie druckt den Antrag in Anhang C aus und schickt ihn dem Kassenwart des 
   IN. 

6. Sie stellt klar, dass der Mailweg zwischen dem genutzten Provider und 
   dem eigenen Domainrechner gesichert ist.
   Die elektronischen Bestaetigungen der beteiligten Rechner zwischen dem
   letztern Internet-Knoten (z.B. eine Universitaet oder dem EUnet) 
   und der eigentlichen Domain sind an den zustaendigen Mennschen (siehe 
   Kapitel 3.1) weiterzuleiten.

   Nochmal: Irgendwo werden die Mails von einen "echten" Internet-Knoten
   zu der neuen Domain laufen. Das kann direkt (UUCP) oder indirekt ueber
   mehrere UUCP-Knoten und Gateways laufen. Jeder einzelne der Netzknoten
   zwischen dem "echten" Internet-Knoten und der neuen Domain muss einen
   Tabelleneintrag fuer diese neue Domain vornehmen - sonst entstehen
   Mailschleifen. Dazu bitte noch Kapitel 3.1 lesen. Es geht nicht, dass
   im DNS-Antrag ein MX auf einen UUCP-Knoten gesetzt wird. Das ist 
   technisch garnicht moeglich.

7. Sie erfuellt die in der IN-Netiqette geforderten technischen Massnahmen, 
   wie z.B. die Adressierung an postmaster@beispiel.de. 

8. Sie wartet auf die Rueckmeldung, dass jetzt alles laeuft. 

Dieses "Rezept" hoert sich sicher nicht gerade einfach an, wird uns
aber zum grossen Teil von den Richtlinien der Provider bestimmt bzw.
ergibt sich aus unserer Erfahrung bei Problemen mit dem "Start" einer
neuen Domain.


2.4. Teilnahme am IN (Internet)
-------------------------------
Durch den Antrag auf eine Domain und die Teilnahme am IN koennen die
Basisdienste Mail, News, Serverdienste, etc. genutzt werden. Nun gibt
es aber auch die Moeglichkeit, darueberhinaus an den Internet-Diensten
teilzunehmen, wie z.B. Remote Login, File Transfer, Internet Relay Chat
(irc), etc. 

Durch die IN-Teilnahme ist nun auch rechtlich/administrativ moeglich 
geworden, die Internet-basierten Netze (z.B. WiN/IP, InterEunet, NSFnet, 
etc) zu nutzen. 

Fuer die Teilnahme am Internet ueber Standleitung, ISDN oder SLIP (Modem)
braucht ein Rechner eine IP-Nummer. IP-Nummern gibt es nun aber nicht
"einzeln", sondern in Klassen. So wie mensch eine Domain bei DE-NIC
beantragt, um Mail einwandfrei machen zu koennen, muss mensch bei DE-NIC
eine Class-C-Netz-Nummer beantragen, um Internet nutzen zu koennen. Eine 
solche Nummer hat z.B. die Form 192.109.65.*. Wobei das * die Werte 
zwischen 0 und 255 (in der Realitaet zwischen 1 und 254) annehmen kann. 
Ein Class-C-Netz kann also bis zu 254 Rechner versorgen. 

Neben dem Antrag auf eine Class-C-Netz-Nummer (Anhang G), muss geklaert 
werden, ueber welche internationalen Wege die Daten fuer ein solches
Class-C-Netz gehen. Derzeit gibt es im IN dafuer zwei Moeglichkeiten.

a) ueber das InterEUnet - die Versorgung ueber das EUnet kann direkt 
   durch das EUnet in Dortmund oder durch die POP's in Muenchen, 
   Hamburg und Berlin geschehen (kostet evntl. extra Geld). Das
   EUnet will fuer das Routen eines Class-C-Netz nochmal extra 100 DM/
   Monat, welches von den Nutzern des Class-C-Netz aufzubringen ist. 

b) ueber das DFN - die Versorgung kann ueber eine Leitung zum DFN in
   Berlin oder zum naechsten WiN-Knoten (der das mitmacht) geschehen. 
   Hier entstehen keine zusaetzlichen Kosten fuer das Class-C-Netz. 
   Evntl. will der Betreiber des WiN-Knotens eine Kostenbeteiligung
   an der genutzten Bandbreite. Das ist aber auch wieder von Fall zu
   Fall verschieden.

Fuer ein Class-C-Netz fuehlt sich ein "Contact" verantwortlich. Wie 
auch die Verantwortlichen fuer eine Domain sind diese Contacts in der
Datei "Status IN", die in de.org.in gepostet wird, veroeffentlicht.

Jedes Class-C-Netz ist an einen "Versorgungspunkt" gebunden. Es kann
also sein, dass Sites aus mehreren Domains ein Class-C-Netz nutzen. Daher
stellen die IP-Verantwortlichen eigene administrative und technische
Kontaktpersonen dar. 

Sie entscheiden (und beantragen) den Acceptable-Use-Status fuer ein
Class-C-Netz. Dies bedeutet, dass das Class-C-Netz auch im amerikanischen
NSFnet (das sind die meisten Rechner, die auf *.edu enden) geroutet wird. 
Dort wird eine gesonderte Unterschrift verlangt. Siehe dazu auch 
Anhang H.

Falls jemand ein Class-C-Netz benutzen bzw. beantragen will, sollte
mensch sich auf jeden Fall vorher mit dem IN absprechen. Entweder
ueber die Mailinglist "in" oder noch besser ueber die Mailinglist
"in-ip". 

Bitte freut euch aber nicht zu frueh. Die Kosten fuer Hard- und Soft-
ware fuer die Teilnahme am Internet sind meist recht hoch. Also fragt 
erstmal in "in-ip" nach den Moeglichkeiten via ISDN, Standleitung, etc 
an. Da das alles noch "neu" ist, gibt es hierfuer noch kein fertiges
"Rezept". Wir gehen davon aus, dass die Leute die ans Internet wollen
auch wissen was sie tun. Aber in Zweifelsfall helfen wir natuerlich
gern.


3. Technische Informationen
---------------------------

3.1. Routing
------------
Das Routing von Mails innerhalb einer Domain uebernimmt der jeweile
Verwaltungsrechner fuer diese Domain. Auf diesem Rechner wird eine 
Tabelle mit allen Sites dieser Domain und den dazu gehoerigen Routen 
gehalten. Diese Tabelle sollte bezueglich Routing Vorrang vor allen 
globaleren Routingtabellen (ZMap, Subnet-Map, Dnet-Map, usw.) haben.

Die Anbindung an das weltweite Internet geschieht ueber MX (Mailex-
changer) Eintraege in das DNS (Domain Name System). Es werden MXe 
fuer 'Domain.DE' und '*.Domain.DE' (Wildcard-MX) eingetragen, die 
auf einen weltweit zuverlaessig ueber TCP/IP SMTP erreichbaren Rechner 
zeigen muessen (Primary-MX). Weitere MXe (Backup-MXe) sind moeglich und 
sogar erwuenscht.

In Ausnahmefaellen koennen auch Site spezifische MXe fuer <Site.Domain.DE>
eingetragen werden.

Der jeweils Primary-MX angegebene Rechner sollte nach statischen Routen
zum Verwaltungsrechner der betreffenden Domain routen. Backup-MX Rechner 
ohne eigene Verbindung zum Verwaltungsrechner der Domain sollten ueber 
statische Routes zum Primary-MX routen.
Auf keinen Fall duerfen Mails fuer die betreffende Domain den Kreis der 
als MXe angegebenen Rechner ueber einen anderen Weg, als den zum Ver-
waltungsrechner der Domain verlassen.

Die jeweils als MX angegebenen Rechner muessen fuer eine moeglichst 
direkte Auslieferungs der Mails fuer die betreffende Domain sorgen. 
Dafuer ist notfalls durch statische Routen auf den MX Rechnern zu 
sorgen. Sind die als MX angegebene Rechner nicht der betreffenden 
Domain zugehoerig, so muss die Benutzung dieser Rechner als MX fuer 
die Domain mit den Betreibern dieses Rechners abgesprochen sein.

Das Datenaustausch zwischen dem EARN/Bitnet (CREN) und IN-Domains 
geschieht per Default ueber Amsterdam im Rahmen der EUnet-Teilnahme. 
Allerdings kann es sinnvoll sein mit einen nahgelegten EARN-Knoten 
die Versorgung abzusprechen. Entsprechende Eintraege muessen dann auf 
den versorgenden EARN-Knoten und bei der GMD (MABOGEN@DEARN.bitnet)
vorgenommen werden. Dies aber vorher mit dem IN absprechen.

Bei den OSI-Netzen (X.400) sieht es im Augenblick so aus, dass die
Nachrichten ueber den Knoten gmdzi.gmd.de ausgetauscht werden.
Dortige Eintraege fuer das Routing werden durch das DE-NIC an
den Betreiber der gmdzi mitgeteilt. Es wird versucht dies auch
direkt durch das IN durchfuehren zu lassen.

Bezueglich der Versorgung aus dem EARN/Bitnet und X.400-Netzen steht 
eine netzpolitische (evntl. kostenpflichtige) Aenderung an. Solange 
gelten aber obige Regelungen.

3.2. Nameserver
---------------
Joerg Lehners (joerg.lehners@arbi.informatik.uni-oldenburg.de) hat sich
freundlicherweise bereit erklaert, fuer das IN einen Nameserver aufzusetzen.
Zur Zeit sind dort von allen IN-Domains die MX-Records eingetragen (MX-
Records geben an, wie die einzelnen Domains auf dem Internet geroutet 
werden). Die entsprechenden Informationen die er dafuer braucht sind
im Anhang B auszufuellen.

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

3.4. Namenswahl
---------------
Dein Domainname sollte nicht zu kurz sein. Desweiteren sollte er nicht 
bekannte Institutionen repraesentieren (z.B. .sun.de) oder eine darstellen, 
die du nicht bist (z.B: .uni-kleinkleckersdorf.de). 
Ebenso duerfen keine Namen verwendet werden, die als ISO-Laendercode schon 
vergeben sind (z.B. .cl.de geht nicht, weil cl schon fuer Chile steht). 
Im Zweifelsfall fragt vorher im IN an, ob eine Domain sinnvoll ist. Falls
eine Domain abgelehnt wird, dann verzoegert das die Teilnahme am globalen
Dorf unverhaeltnismaessig lange.


4. Administrative Informationen
-------------------------------

4.1 Beratung
------------
Soweit moeglich sollen auftretende Fragen innerhalb der Domain geklaert 
werden. Der Sinn von vielen eigenstaendigen Domains ist ja gerade
die Unabhaengigkeit der Domains - sie koennten ohne technische
Probleme aus dem IN austreten und eigene Loesungen suchen. Dieses
Prinzip macht eben manchmal in der Domain auch Arbeit.


4.2. 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 D).

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


4.3. Preispolitik
-----------------
Das IN hat zwar ein Bewertungssystem, welches zum Teil auch von Eigen-
schaften in Domains abhaengen kann, jedoch legt das IN nur Kostenanteil
fuer eine Domain fest. Wie dieses Geld die Domain auf ihre Benutzer
umlegt, bleibt ihr ueberlassen. Preispolitik ist ja meistens auch
Netzpolitik und daher kann dort auch nicht seitens des IN irgendetwas
vorgeschrieben werden. 

Beispielsweise will eine Domain es sich einfach machen und teilt die
Kosten einfach durch die Anzahl der Rechner. Sowas gibt es. Andere
unterscheiden zwischen Mailboxen und Ein-Mensch-Sites. Wieder andere
wollen die Schaffung von Mailboxen oder von Ein-Mensch-Sites foerdern
und schaffen entsprechende Gebuehrenstrukturen. Oder eine Domain will
jene, die in der Domain das meiste Geld investieren, weniger belasten.
Oder die Domain will Internet foerdern und nimmt denen, die das machen
garnix ab - jede Kombination ist denkbar. 

In den meisten Domains gibt es ja neben dem IN-Kostenanteil auch noch
Telefonkosten fuer Fernlinks oder POP-Gebuehren, die auf die Allgemein-
heit umgelegt werden. Daher kann die Teilnahme an einer Domain, wie 
z.B. in Berlin doppelt so teuer sein (weil POP-Gebuehren anfallen),
als in einer Domain wie north.de - wo die Domain einfach zum Ortstakt
eine Datenverbindung hat. Dies ist aber auch wieder Domain-Angelegenheit.


4.4. Support
------------
Soweit moeglich, soll eine Beratung innerhalb der Domain erfolgen, da
die entsprechenden Probleme dort meistens aus der Praxis bekannt sind.
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 bzw. das DFN telefonisch oder via EMail um Hilfe 
zu bitten. Solche Anfragen sollten aber immer ueber das IN gehen, weil
die Provider sonst nicht wissen, ob die Anfrage berechtigt ist oder nicht.
(Mensch stelle sich vor, dass 20 Domains mit 500 Benutzern die Leute
 regelmaessig mit Fragen nerven. :-) )


4.5. 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. Network
Managment heisst daher im IN hauptsaechlich Netzpolitik und bilaterales
diskutieren ueber bessere Verbindungen.


4.6. Netzpolitik, Oeffentlichkeitsarbeit & praktische Arbeit im IN
------------------------------------------------------------------
Das IN vertritt die Interessen seiner Domains nach aussen. Es erstellt
Informationsmaterial und benennt Ansprechpartner.

Das IN existiert ja de facto nicht als Institution auf der einen
Seite und die Domains auf der anderen Seite. Das IN wird aus den
Domains selbst geboren in Form von Mailinglisten und jaehrlichen
Treffen. In der Mailinglist sind von Natur aus erstmal die
Repraesentanten der Domains, wie sie auch im Antrag an den Kassen-
wart benannt wurden. Jeder Domain-Vertreter kann aus seiner Domain
weitere Teilnehmer fuer die Mailinglist benennen, wie z.B. aktive
Benutzer, SysOps mit wichtigen Aufgaben oder User mit administrativen
Aufgaben fuer die Domain (z.B. Map-Verwalter). 

Die Mailinglist ist aber eine Konzeptions-, Koordinierungs- und 
Kooperationsstelle. Sie dient nicht der Information fuer Benutzer. 
Das soll der Domain-Verantwortliche als "Schnittstelle" erledigen.

Derzeitige Mailing-Listen im IN sind:

in:	in@methan.chemie.fu-berlin.de	  - IN-"Rat" (jetzt: Praesidium)
in-nm:	in-nm@methan.chemie.fu-berlin.de  - Netzwerk Managment
in-ip:	in-ip@methan.chemie.fu-berlin.de  - Internet im IN	

In in-nm sind die Teilnehmer aus "in" und die Vertreter der Provider.
In in-ip jene Teilnehmer die mit IP im IN zu tun haben.


4.7. Entscheidungsfindung im IN
-------------------------------
Im Augenblick gilt im IN noch das Konsensprinzip. Also bei Entscheidungen
in der IN-Maillinglist (=Praesidium) darf niemand der Domainvertreter
gegen etwas sein. An einen neuen Verfahren wird aber gerade gearbeitet.

Die Entscheidungen im IN eV finden im Rahmen der Satzung statt.


4.8 Disclaimer
--------------
Um irgendwelchen Irrtuemern oder Fehlinterpretationen vorzubeugen:
Das IN hat nichts mit irgendwelchen Universitaeten zu tun. Einige
IN-Aktivisten sind Studenten oder gar bei Univeristaeten angestellt.
Diese stellen z.T. ausserhalb ihrer regulaeren Arbeitszeit ihre
Freizeit zur Verfuegung um das IN zu unterstuetzen. Die Nutzung
von Universitaet-Resourcen (WiN, Rechenzeit, Modemstrecken, etc)
werden nur mitgenutzt, falls dafuer eine klare Absprache und 
Rechtsgrundlage existiert. Dies geschieht z.T. dankenswerterweise
im Rahmen von Kooperationen in den Regionen oder bei Drittmittel-
projekten.



- * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - 
                             A N H A E N G E
- * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - * - 

ANHANG A	Antrag auf eine DE-DOMAIN


Anmerkung
---------
Dieser Antrag ist an terra@sol.ccc.de zu schicken. Er wird den Antrag
an de-domain@deins.informatik.uni-dortmund.de weiterschicken, sobald
die im Kapitel 2.3 beschriebenen Punkte geklaert sind.

Aendert bitte die mit # gekennzeichneten Zeilen auf eure Domain. Bei der
Auswahl der Domain nehmt bitte aussagefaehige Namen, achtet darauf, dass 
keine Firma oder Regierungstelle Anspruch auf den Namen haben koennte 
(z.B. waere berlin.de nicht moeglich, weil dies fuer die "Stadt Berlin" 
belegt ist).

- - - - - - - - cut here - - - - - - - - -

Domainantrag
------------ 

1. Antragstellende Organisation (zukuenftiger Inhaber der Domain)

1.NAME: Name der Organisation:          <#Regionalnetz Beispiel>
1.RF:   Rechtsform:                     <privat>
        (z.B. eV, GmbH, falls nicht schon aus dem Namen ersichtlich)
1.ADDR: Anschrift der Organisation:     <#Erik Mustermann, Musterstr. 42,
					 #4711 Domainstadt 3>


2. Domain-Name (direkte Subdomain von .DE, z.B. Uni-Bonn.DE)

2:      <#BeiSpiel.DE>


3. Ansprechpartner

3.1 Administrativer Kontakt (Verantwortliche Autoritaet fuer die Domain)

3.ADDR: Anschrift der Organisation:     <#Beispiel-Domain, c/0 Erik Mustermann, 
					 #Musterstr. 42, 4711 Domainstadt 3>

3.AC.NAME:      Name:           <#Erik Mustermann>
3.AC.FUNC:      Funktion/Titel: <Domain-Verwalter>
3.AC.ADDRESS:   Post-Adresse:   <#Musterstr. 42, 4711 Domainstadt 3>
3.AC.EMAIL:     E-Mail:         <#em@foo.beispiel.de>
3.AC.PHONE:     Telefon: (int.) <#+49 47 111213>


3.2 Technischer Kontakt

3.TC.NAME:      Name:           <#Erika Mustermann>
3.TC.FUNC:      Funktion/Titel: <Betreiberin von foo>
3.TC.ADDRESS:   Post-Adresse:   <#Musterstr. 42, 4711 Domainstadt 3>
3.TC.EMAIL:     E-Mail:         <#postmaster@foo.beispiel.de>
3.TC.PHONE:     Telefon: (int.) <#+49 47 111213>


4.  Verwaltung der Domain in der Organisation

	Individual Network eV

5.  Anschluss an externe Netze fuer Mail (und/oder IP)

5.1 An welche externe Netze wird diese Domain selbst angeschlossen sein?
    (bitte zutreffendes ankreuzen)

5.EUNET:        EUnet           <x>
5.EUNET-IP:     auch ueber IP?  <>
5.UKA:          uka[1]          <>
5.LAND:         Landesnetze[2]  <>      <>
5.LAND-IP:      auch ueber IP?  <>
5.OTHER:        sonstige[5]     <DFN>      <x>
5.OTHER-IP:     auch ueber IP?  <>


5.2 Angestrebte weitere Netz-Anschluesse

5.3 Gibt es Anschluesse Ihrer Organisation an weitere Netze, die NICHT
    in der Adressierung ueber die hier beantragte Domain eingeschlossen
    sind? (z.B. DFN MHS dessen Adressen ausschliesslich in der Domain
    DBP.DE liegen; oder Sie haben EARN-Knoten fuer die Sie KEINE Domain-
    Adressierung unterstuetzen wollen)

6.  Mail-Routing

6.1 Primaeres Netz

#Bemerkung. Hier muss ein Internet-Knoten angegeben werden, an den die
#Mail an BeiSpiel.DE geroutet werden sollen. Teilweise ist der An-
#schluss aber ueber UUCP realisiert. Dann wendet euch am besten an
#die Mailinglist, was da eingetragen werden muss (i.d.R. germany.eu.net),
#weil dies meistens seitens des IN offiziele Mitteilungen an einen Provider
#erfordert.

6.PRIM: <#mcshh.hanse.de>


7.  Mail-Gateways

7.1 Betreiben Sie einen Gateway?
    falls ja, bitte naehere Angaben, die fuer das Routing zu Ihrer Domain
    von Bedeutung sind

7.GATE: <nein>      <>


8.  Statistische Angaben

8.1 Wieviele weitere Subdomains planen Sie in der angemeldeten
    Domain auf der unmittelbar darunterfolgenden Hierarchiestufe
    einzurichten (Verzweigungsgrad)?

8.VERZW:        <1>


8.2 Wie tief beabsichtigen Sie die Subdomains zu gliedern?
    (Gliederungstiefe der Domain in  kaufmann@zpl.dfn.dbp.de ist 4)

8.DEPTH:        <3>

8.4 Wieviel Rechner werden unter dieser Domain angeschlossen?

8.TOD:  zur Zeit:       <#10>
8.1Y:   in einem Jahr:  <#30>
8.2Y:   in zwei Jahren: <#50>


9.  Verwendung von IP-Netzen

        Netz-Name               IP-Netz-Nummer
9.IP    <>                      <>


10.  Domain-Name-Server (nur relevant bei externen IP-Verbindungen)

# Diese Daten NICHT aendern. Stellt aber sicher, dass der Verwalter
# des IN-DNS das Formular in Anhang B erhalten hat, bevor ihr DIESEN
# Antrag an DE-NIC schickt.

10.1 Wollen Sie einen selbst organisierten Domain-Name-Service
     fuer Ihre Domain betreiben? (Das geht nur bei vorhandenen
     externen IP-Verbindungen)

10.DNS: <ja> (im Rahmen des IN)

10.2 Falls ja, muessen mindestens zwei unabhaengige Name-Server
     benannt werden. Fuer jeden sind die folgenden technische Angaben
     erforderlich:

     (a) Technische Beschreibung der Name-Server (Maschinentyp, Software,
         Software-Versionen)

10.DNS-TECH:    <Cadmus, etc. Allgemeiner DNS fuer IN-Domains>

     (b) Domain-Name des Servers
10.DNS-NAME:    <arbi.informatik.uni-oldenburg.de>
         IP-Adresse(n) des Servers
10.DNS-IP:      <134.106.1.7>

     (d) Ist der Name-Server betriebsbereit und mit den richtigen
         Daten geladen?
10.DNS-READY:   <ja>
               falls nein: ab wann voraussichtlich?
                           (bitte in diesem Fall Meldung bei endgueltiger
                           Bereitstellung machen)
10.DNS-RD-DATE: <18.1.1992>

13.  Sonstiges

13.REM: <Die Domain ist Teilnehmer im IN und wird entsprechend am EUnet
	 teilnehmen. >

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

ANHANG B 	DNS-Anmeldung


Fragebogen fuer die Domain Name System Informationen einer IN-Domain
====================================================================

Diese ist zu mailen an Joerg.Lehners@arbi.informatik.uni-oldenburg.de
bzw. Joerg.Lehners@uniol.zer. Aenderungen sind ihm ebenfalls mitzuteilen.
ACHTUNG !  Dies ist KEIN Domain-Antrag !  Dafuer ist Anhang A da.

Domainname:

	<fasel.de>

Ein-Zeilen Beschreibung der Domain:

	<Private Benutzer von Blafasel Computern>

Administrativer Kontakt:
	(mehrere sind moeglich)
	(jeweils Name, Anschrift, E-Mail-Adresse, Telefon)

	<Hein Hannes>
	<Laberweg 25>
	<D-9653 Faselberg>
	<Germany>
	<hein@blubb.fasel.de, hein@informatik.uni-sonstwo.de>
	<49 30 123456>

Technischer Kontakt:
	(mehrere sind moeglich, kann auch identisch zum
	Administrativen Kontakt sein)
	(jeweils Name, Anschrift, E-Mail-Adresse, Telefon)

	<Hein Hannes>
	<Laberweg 25>
	<D-9653 Faselberg>
	<Germany>
	<hein@blubb.fasel.de, hein@informatik.uni-sonstwo.de>
	<49 30 123456>


Vorgesehene Mail-Exchanger (MX):
	(die Benutzung eines Mail-Exchangers muss mit dem Betreiber
	des Mail-Exchanger abgesprochen sein;
	der Mail-Exchanger sollte volle Internet-Konnektivitaet
	haben, andernfalls ist ein Back-Up-Mail-Exchanger zwingend;
	Der Primary Mail-Exchanger muss Mails fuer die betreffende
	Domain ueber sogenannte 'hardcoded routes' weiterleiten,
	andernfalls sind Mail-Schleifen moeglich)

    Primary:
	<kiste.informatik.uni-sonstwo.de>

    Backup:
	(optional, mehrere moeglich):

	<kiste2.informatik.uni-sonstwo.de>
	<mail.Germany.EU.net>

    Ausnahmen (wenn einzelner Rechner oder Subdomains anders geroutet
	       werden sollen):
	(optional, mehrere moeglich;
	Angabe in der Form:
	    Rechner/Domain
	    Name
	    Primary-MX
	    Backup-MXe (optional, mehrere moeglich))

	<Rechner>
	<murks.fasel.de>
	<kasten.cs.uni-anderswo.de>

	<Domain>
	<sub.fasel.de>
	<kasten.cs.uni-irgendwo.de>
	<mail.Germany.EU.net>

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

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 Connectivity beim EUnet zu bezahlen. Weiterhin 
verpflichten wir uns, keine Universitaeten oder Firmen in unserer Domain 
anzuschliessen. Dafuer erhalten wir das Recht, alle Dienstleistungen der
Provider 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, die Teilnehmerliste zu
jeden 20. eines Monats an den Kassenwart zu schicken.

Mit diesen Eintrag wird die Domain Mitglied im Individual Network eV,
der die Rechtsvertretung gegenueber den Providern darstellt.

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

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-Mailinglist (E-Mail): ________________________

Bisher Kunde bei einen Provider gewesen ?

( ) nein      ( ) ja, und zwar (z.B. EUnet) ______________

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

( ) nein       ( ) ja


Anzahl der Systeme in der Domain               _________________

Anmerkungen:

________________________________________________________________

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

Der Antrag ist zu richten an:

Andreas Baess
Fontanestr. 12
4044 Kaarst 1
Telefon: privat: 02131 605652
	 Buero:   0211 4954 246

	Ort, Datum					Unterschrift
	
	-------------					---------------

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

ANHANG D	Netiqette


Artikel 1: Zustaendigkeit
-------------------------
Die Domains entscheiden ueber ihre Politik, ihre Netiqette und ihren
technischen Anschluss autonom. Das IN hat die Aufgabe, die internationale
Connectivity zu erhalten und die Arbeit der Domains zu koordinieren. Die 
Domains informieren sich ueber ihre "Politik" gegeneinander und kooperieren
fuer eine gemeinsame "Politik" im IN.

Artikel 2: User
---------------
Fuer das Verhalten der User beim Posten, Mailen und bei der Nutzung anderer
Netzdienste sei hier auf die regionalen und netzspezifischen Netiqetten
verwiesen. Die IN-Netiqette bezieht sich allein auf Dinge im Rahmen des IN 
oder im Zusammenleben der Domains.

Artikel 3: Weitergabe von News
-----------------------------
Die ueber das IN bezogenen News (Ausnahme: de.all) duerfen nur an Sites
weitergegeben werden, die dazu auch durch eine Vereinbarung mit einen
Provider berechtigt sind.

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

Artikel 5: Solidaritaetsprinzip
-------------------------------
Das IN lebt davon, dass die Domains sich gegenseitig vertrauen und
keine versucht, die andere zu uebervorteilen. Wir sehen uns als
Solidargemeinschaft mit dem Ziel guenstige und sichere internationale
Connectivity zu schaffen. Daher sind die Bedingungen im Rahmen der
"Kostenverteilung im IN" (siehe entsprechendes Kapitel) einzuhalten.

Artikel 6: 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 
oder einen anderen Provider abschliessen, ist gestattet.

Artikel 7: Abwerbung
--------------------
Die gezielte Abwerbung von Sites aus einer anderen Domain hat zu unter-
bleiben.

Artikel 8: Verwaltungsrechner
-----------------------------
Der Verwaltungsrechner einer Domain muss auch unter seiner Domain 
erreichbar sein. 
Beispiel: 

	Der Rechner sol ist Verwaltungsrechner fuer .ccc.de
	Das heisst: sol.ccc.de ist auch als ccc.de erreichbar.

postmaster@ccc.de ist daher eine sinnvolle Adresse. Unter dieser Adresse
muessen die Verantwortlichen der Domain erreichbar sein.

Artikel 9: News, Controlmessages
--------------------------------
Die wesentlichen Aussenweltverbindungen einer Domain sollten dafuer sorgen,
dass sendsys, version und evntl. checkgroups nur nach aussen und in die
Welt gelangen, wenn sie dadurch keine "Katastrophen" ausloesen.

Artikel 10: Persoenlichkeitsschutz
----------------------------------
Es duerfen beim Mailverkehr und bei anderen Diensten zwischen IN-Domains
und in die internationalen Datennetze keine unnoetigen Verkehrs- und
Inhaltsdaten erhoben werden. Solche Daten duerfen nur fuer eine kurze Dauer 
und auch nur dann im technisch oder administrativ notwendigen Rahmen erhoben 
werden.

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

Artikel 12: Kommerzielle Nutzung
--------------------------------
Die Nutzung der interationale Connectivity und die Nutzung bestimmter 
nationaler Infrastruktur (z.B. WiN-Leitungen) fuer kommerzielle Interessen 
ist verboten. Das IN hat sich zum Ziel gesetzt, Privatpersonen anzu-
schliessen.

Artikel 13: Ausschluss von Domains
----------------------------------
Der Verstoss gegen die IN-Netiqette, insbesondere gegen Artikel 5 oder
Artikel 12, kann den Ausschluss der Domain aus dem IN zur Folge haben. 


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
ANHANG E	Liste fuer monatliche Kassenwartmeldungen

Diese Liste soll bis zum 20. jedes Monats an andreas@easix.gun.de
gemailt werden.

Die Liste hat folgenden Aufbau:

DOMAIN: domain.de
SYSTEMS: 123
LIMIT: 450 
EMAIL: user@host.domain.de
PHONE: 0815/4711
SITELIST
site1.domain.de
site2.domain.de
site3.domain.de
site4.domain.de
ENDLIST

Erklaerungen:
	DOMAIN		- Der Name der Domain die mir ihre Daten senden 
			  moechte. Beispiel: DOMAIN: in-berlin.de
	SYSTEMS		- Anzahl der Sites innerhalb der Domain
			  Beispiel: SYSTEMS: 78
	LIMIT		- Ein Mindesbeitrag den die Domain bereit ist zu
			  zahlen, weil ansonsten der Beitrag fuer die 	
			  Domain nach den reinen Anteil/Rechner-Prinzip
			  zu niedrig ausfaellt. Wer keinen Mindesbetrag
			  setzen will, laesst die Zeile weg. 
			  Beispiel (toppoint):  LIMIT 266
	EMAIL		- Die email-Adresse des Ansprechpartners fuer
			  Meldungen und Abrechnung fuer den Fall, dass 
			  ich ihn erreichen moechte.
			  Beispiel: in-berlin-adm@in-berlin.de
	PHONE		- Die Telefonnummer des Ansprechpartners fuer
			  Meldung und Abbrechnung fuer den Fall das es
			  schnell gehen sollte. 
			  Beispiel: (Wer braucht ein Beispiel. :-) )
	SITELIST	- Leitet ab der naechsten Zeile eine einfache
			  Liste aller Sites in der Domain ein. Anzahl
			  der User auf jeder Site muss nicht mehr
			  mitgeteilt werden.
	ENDLIST		- Die vorherige Zeile war der letzte Rechner
			  innerhalb der Siteliste.

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

ANHANG F	Satzung des Vereins "Individual Network"


Beschlossen am 21.6.1992 durch die Gruendungsmitglieder des Individual
Network eV.


$ 1  Name, Sitz, Geschaeftsjahr

1. Der Verein fuehrt den Namen "Individual Network". Er fuehrt nach der 
   Eintragung in das Vereinsregister den Zusatz "e.V." im Namen.

2. Der Vereinssitz ist Oldenburg (Olbg)

3. Der Verein ist selbstlos taetig. Er verfolgt keine eigenen wirtschaftlichen
   Zwecke. Etwaige Gewinne sind stets den satzungsgemaessen Zwecken
   zuzufuehren.

4. Das Geschaeftsjahr des Vereins ist das Kalenderjahr.



$ 2  Zweck des Vereins

1. Der Verein bezweckt die Foerderung der privat betriebenen 
   Datenkommunikation. Dazu gehoert insbesondere:

a) Foerderung von Bildung und Wissenschaft durch die Schaffung eines
   oeffentlichen Zugangs zu internationalen elektronischen Diskussionsforen 
   und Kommunikationsnetzen. 

b) Aufbau, Foerderung und Unterhalt von oeffentlichen Netzzugaengen zur 
   Benutzung durch Mitglieder und Nichtmitglieder gegen Erstattung der 
   entstehenden Kosten. Diese werden von regionalen und organisatorischen
   Einheiten verwaltet (Domains(. Naehere Einzelheiten regelt ein Benutzer-
   vertrag.

c) Einfuehrung und Fortbildung von Mitgliedern und interessierten Nicht-
   mitgliedern in den Umgang mit nationalen und internationalen 
   Kommunikationsnetzen.

d) Vertretung oeffentlicher Interessen im Bereich der privaten
   Datenkommunikation; insbesondere die Zusammenarbeit mit staatlichen
   und nichtkommerziellen Institutionen.

e) Foerderung der nationalen und internationalen Zusammenarbeit auf dem Gebiet
   der elektronischen Kommunikation.

f) Der Verein stellt seine Arbeit der Oeffentlichkeit zur Vertretung der
   ideellen Belange seiner Mitglieder dar:

     - mittels Durchfuehrung von oeffentlichen Workshops und Anwenderseminaren.

     - durch Eigendarstellungen in den Medien.

g) Durchfuehrung von Forschungs- und Entwicklungsarbeiten.



$ 3  Gemeinnuetzigkeit

1. Der Verein verfolgt ausschliesslich und unmittelbar gemeinnuetzige Zwecke im
   Sinne des Abschnitts "Steuerbeguenstigte Zwecke" der Abgabenordnung
   (Paragraph 52 Abs. 2AO 77). Die Mittel des Vereins duerfen nur fuer
   satzungsgemaesse Zwecke verwendet werden.

2. Die Mitglieder erhalten als solche keine Zuwendungen aus den Mitteln des
   Vereins. Es darf keine Person durch Ausgaben, die dem Zweck des Vereins
   fremd sind, oder unverhaeltnismaessig hohe Verguetungen beguenstigt werden.

3. Der Verein ist selbstlos taetig; er verfolgt nicht in erster Linie
   eigenwirtschftliche Zwecke.



$ 4  Mitglieder

Mitglieder des Vereins koennen regionale oder organisatorische Einheiten
(Domains) werden, die sich als eingetragene oder nicht eingetragene Vereine 
konstituieren und sich zu den Zielen des Vereins bekennen. Die Domains sind in 
ihrer inneren Struktur frei. Jede Domain hat bei Beschluessen und Abstimmungen 
eine Stimme. Jede Domain bestimmt einen oder mehrere Vertreter, die dieses 
Stimmrecht auf Mitgliederversammlungen oder im Praesidium wahrnehmen.

Natuerliche Personen koennen dem Verein nur als Foerdermitglieder beitreten.
Foerdermitglieder besitzen kein Stimmrecht.

$ 5  Beginn und Ende der Mitgliedschaft

1. Eine Aufnahme in den Verein erfolgt auf schriftlichen Antrag des Kandidaten
   beim Praesidium
   Der Beschluss wird dem Antragsteller wahlweise schriftlich oder ueber 
   elektronische Post mitgeteilt.

2. Die Mitgliedschaft endet:

a) bei natuerlichen Personen durch deren Tod, bei anderen Mitgliedern mit 
   deren Aufloesung (Erloeschen). 

b) nach schriftlicher Kuendigung eines Mitglieds zum Ende des Kalendermonates. 
   Die Kuendigung muss mindestens einen Monat vor dem Kuendigungszeitpunkt 
   schriftlich beim Verein eingegangen sein.

c) durch Beschluss des Praesidiums, wenn das Verbleiben des Mitglieds 
   nach Ansicht einer 2/3 Mehrheit der stimmberechtigter Mitglieder des 
   Praesidiums die Interessen des Vereins schaedigt; dem Mitglied ist vor 
   dem Beschluss Gehoer zu gewaehren.


$ 6 Rechte und Pflichten der Mitglieder

1. Die Mitglieder sind gehalten, den Verein bei der Erfuellung seiner
   satzungsgemaessen Aufgaben zu unterstuetzen.

2. Die Mitglieder sind in ihren geschaeftlichen Aktivitaeten frei.

3. Mitglieder haben in dieser Eigenschaft keinen Anspruch auf das Vermoegen 
   des Vereins.


$7  Mitgliedsbeitraege

Mitglieder entrichten einen Beitrag, dessen Hoehe und Faelligkeit in einer 
von der Mitgliederversammlung beschlossenen Beitragsordnung festgelegt ist.


$8 Organe

1. die Mitgliederversammlung

2. das Praesidium

3. der Vorstand



$ 9  Mitgliederversammlung

1. Die ordentliche Mitgliederversammlung findet mind. einmal im Jahr statt. 
   Sie wird vom Vorstand des Vereins einberufen.

2. Eine ausserordentliche Mitgliederversammlung wird vom Vorsitzenden des
   Vereins auf Praesidiumsbeschluss auf Antrag von mind. 25% der stimm-
   berechtigtes Mitglieder des Praesidiums einberufen.

3. Die Einladung zur Mitgliederversammlung ist den Mitgliedern schriftlich
   unter Angabe von Ort, Zeit und Tagesordnung mindestens vier Wochen, zur
   ausserordentlichen Mitgliederversammlung mindestens zwei Wochen vorher zu
   uebersenden, wobei die Einladung als bewirkt gilt, wenn sie fristgerecht
   zur Post gegeben worden ist.

4. Mitglieder koennen sich durch einen Bevollmaechtigten oder durch ein anderes
   Mitglied vertreten lassen. Die Vertretungsbefugnis ist dem
   Versammlungsleiter schriftlich nachzuweisen. Kein Mitglied kann mehr als
   ein weiteres Stimmrecht ausueben.

5. Antraege zur Tagesordnung muessen fuer die ordentliche
   Mitgliederversammlung mindestens zwei Wochen, fuer die ausserordentliche
   Mitgliederversammlung eine Woche vor dem Versammlungstermin dem
   Vorsitzenden des Vorstands schriftlich vorliegen. Sie werden von diesem
   den Mitgliedern unverzueglich bekanntgegeben.



$ 10  Aufgaben der Mitgliederversammlung

1. Die Mitgliederversammlung ist das oberste Organ des Vereins. Sie ist fuer
   alle Angelegenheiten zustaendig, die nicht durch diese Satzung einem anderen
   Organ uebertragen sind. Sie hat insbesondere folgende Aufgaben:

   a) sie waehlt den Vorstand des Vereins.

   b) sie waehlt den Abschlusspruefer fuer das laufende Geschaeftsjahr.

   c) sie beschliesst ueber die mittel- und langfristigen Ziele des Vereins.

   d) sie beschliesst ueber die Entlastung des Vorstandes.

   e) sie beschliesst ueber Satzungsaenderungen; zu einem solchen Beschluss 
      ist die Anwesenheit mindestens der Haelfte der stimmberechtigten Mit-
      glieder und eine Dreiviertelmehrheit innerhalb der Versammlung 
      erforderlich.

   f) sie beschliesst ueber Angelegenheiten, die zur Zustaendigkeit des
      Vorstandes gehoeren und die der Vorstand ihr zur Beschlussfassung
      vorlegt.

   g) sie beschliesst ueber Angelegenheiten, die zur Zustaendigkeit des
      Praesidiums gehoeren und die das Praesidium ihr zur Beschlussfassung
      vorlegt.

   h) sie beschliesst ueber die Aufloesung des Vereins gemaess Paragraph 15 
      dieser Satzung.



$ 11  Ablauf der Mitgliederversammlung

1. Die Mitgliederversammlung leitet der Vorsitzende, im Falle seiner
   Verhinderung dessen Stellvertreter. Ist auch dieser verhindert, so waehlt
   die Mitgliederversammlung einen Versammlungsleiter mit einfacher Mehrheit
   aus ihrer Mitte. Eine Verhinderung liegt auch vor, wenn eine eigene 
   Angelegenheit des Vorsitzenden oder seines Stellvertreters zu eroertern 
   ist, solange diese Eroerterung stattfindet. Wahlen werden stets von einem 
   Wahlleiter geleitet, den die Mitgliederversammlung vor Beginn des Wahlaktes 
   im Wege offener Abstimmung bestimmt.

2. Die Mitgliederversammlung ist nicht beschlussfaehig, wenn weniger als 1/3
   oder als 7 stimmberechtigte Mitglieder persoenlich anwesend sind.

3. Beschluesse werden mit einfacher Mehrheit der abgegebenen gueltigen Stimmen
   gefasst, soweit das Gesetz oder die Satzung keine hoehere Mehrheit
   vorschreiben. Die Art der Abstimmung ist offen, wenn nicht ein persoenlich
   anwesendes Mitglied widerspricht.

4. Wahlen werden grundsaetzlich einzeln in geheimer Abstimmung durchgefuehrt. 
   Der Wahlleiter kann offen und/oder en bloc abstimmen lassen, wenn nicht mehr
   als ein persoenlich anwesende Mitglieder widerspricht. Gewaehlt ist, wer
   die einfache Mehrheit der abgegebenen Stimmen - bei Blockwahl die relativ
   meisten Stimmen - erhalten hat.

5. Die Mitgliederversammlung kann sich eine Geschaeftsordnung geben.

6. Die Beschluesse der Mitgliederversammlung sind zu Beweiszwecken in 
   einen Beschlussbuch einzutragen und vom jeweiligen Versammlungsleiter
   zu unterschreiben. Dabei sollen Ort und Zeit der Versammlung sowie
   das jeweilige Abstimmungsergebnis festgehalten werden. 


$ 12    Vorstand

1. Der Vorstand besteht aus dem Vorsitzenden, dessen Stellvertreter und 
   einem Schatzmeister.

2. Der Vorstand wird auf ein Jahr gewaehlt. Wiederwahl ist zulaessig. Er 
   bleibt im Amt, bis ein neuer Vorstand bestimmt ist.

3. Der Vorstand vertritt den Verein nach aussen. Zur wirksamen Vertretung
   ist die Mitwirkung von zwei Vorstandsmitgliedern notwendig.

4. Die Mitglieder des Vorstandes ueben ihre Taetigkeit ehrenamtlich aus.


$ 13  Aufgaben des Vorstandes

1. Der Vorstand ist verantwortlich fuer die ordnungsgemaesse Verwaltung aller
   Aemter und die satzunggemaesse Erfuellung der Aufgaben des Vereins. Er ist
   gesetzlicher Vertreter im Sinne des Paragraph 26 BGB.

2. Dem Vorstand obliegen insbesondere folgende Aufgaben:

  a) Er foerdert die Zusammenarbeit der Mitglieder im Sinne der Ziele des
     Vereins.

  b) Er bereitet die Beschluesse der Mitgliederversammlung vor und vollzieht
     sie.

  c) Er berichtet der Mitgliederversammlung mindestens einmal im Jahr ueber
     die wesentlichen Aktivitaeten des Vereins.

3. Der Vorstand handelt nach Beschluessen des Praesidiums und der Mit-
   gliederversammlung.

4. Der Vorstand ist ermaechtigt, die Eintragung des Vereins in das
   Vereinsregister und die Anerkennung der Gemeinnuetzigkeit zu bewirken, und
   das sonst Noetige zur Aufnahme der Vereinstaetigkeit zu veranlassen.
   

$ 14 Praesidium

1. Das Praesidium besteht aus den Vertretern der regionalen und 
   organisatorischen Verwaltungseinheiten. (Domains)

2. Ein Vertreter einer regionalen oder organisatorischen Verwaltungs-
   einheit kann weitere Mitglieder fuer das Praesidium vorschlagen.

3. Das Praesidium gibt sich eine Geschaeftsordnung. Das Praesidium 
   uebernimmt die in der Geschaeftsordnung festgelegten Aufgaben.

4. Beschluesse des Praesidiums erfolgen mit der schriftlichen oder 
   muendlichen Zustimmung oder per elektronischer Post (e-mail) von mehr 
   als 2/3 seiner Mitglieder.

5. Das Praesidium hat die Aufgabe dem Vorstand die Richtlinien fuer sein
   Handeln im Sinne der Vereinsziele vorzugeben.


$ 15 Haftung

1. Fuer die Verbindlichkeiten des Vereins haftet der Verein mit seinem
   Vereinsvermoegen.

2. Eine persoenliche Haftung der Mitglieder fuer Verbindlichkeiten des
   Vereins besteht nicht.


$ 16  Aufloesung

1. Die Aufloesung des Vereins kann nur in einer Mitgliederversammlung, in der
   mindestens die Haelfte der stimmberechtigten Mitglieder anwesend sind, mit
   Dreiviertelmehrheit beschlossen werden; Stimmenthaltungen bleiben
   unberuecksichtigt. Dabei ist auch zu beschliessen, wer zum Liquidator
   bestellt wird.

2. Bei Aufloesung des Vereins oder bei Wegfall steuerbeguenstigter Zwecke faellt
   das Vermoegen des Vereins an eine juristische Person des oeffentlichen
   Rechts oder eine andere steuerbeguenstigte Koerperschaft.

3. Diese Bestimmungen gelten entsprechend bei Wegfall des bisherigen Zwecks des
   Vereins.

4. Beschluesse, durch die die vorstehenden Bestimmungen oder eine andere fuer 
   die Gemeinnuetzigkeit wesentliche Satzungsbestimmung geaendert, ergaenzt 
   oder aufgehoben wird, oder durch die der Verein aufgeloest, in eine andere 
   Koerperschaft ueberfuehrt oder durch die sein Vermoegen als Ganzes 
   uebertragen wird, sind der zustaendigen Finanzbehoerde unverzueglich 
   mitzuteilen und duerfen nur mit deren Zustimmung durchgefuehrt werden.


						Oldenburg, den 21.6.1992

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

ANHANG G 	Class-C-Netz-Antrag

Dieser Antrag ist an hostmaster@deins.informatik.uni-dortmund.de zu 
schicken. Er wird dort vom Deutschen Network Information Center (DE-NIC) 
bearbeitet. Aendert bitte die entsprechenden Angaben auf eure Situation.


1)   Administrator:

Organization		Individual Network
Name			c/o Erik Mustermann
Title	  		Verwalter in28c-net
Mail Address    	Erik Mustermann,
			Blahstr. 2, 
			2000 Hamburg 76
Phone Number		+49 40 7651234
Fax			-
Net Mailbox		em@muster.domain.de
NIC-Ident	   	-


2)   Technical Contact:

Organization		Individual Network
Name			c/o Erik Mustermann
Title	  		Verwalter in28c-net
Mail Address    	Erik Mustermann,
			Blahstr. 2, 
			2000 Hamburg 76
Phone Number		+49 40 7651234
Fax			-
Net Mailbox		em@muster.domain.de
NIC-Ident	   	-


Secondary Technical Contact:
	
Organization    	Individual Network
Name            	c/o Erika Mustermann
Title			SysOp
Mail Address    	Erika Mustermann
			Suelzstr. 47b
			11 Teststadt
Phone Number    	+49 441 12345
Fax			-
Net Mailbox    		erika@suelz.domain.de
NIC-Ident		-

3)   The short name of the network (up to 12 characters).

	in28c-net
      	    

4)   The long name of the network (up to 20 characters).

	28. Class-C-Netz for Individual Network 


5)   Geographically, where is this network located?

	Northwest of germany
		

6)   A citation to a document that describes the network.  This
     should identify a document that describes the network in a
     technical sense.
	

		

7)   Gateway information:



8)   An estimate of the number of hosts that will be on the network

(a) initially		= 3
(b) within one year 	= 10
(c) two years		= 20
(d) five years		= ?


9)   Is a class C network number acceptable for your purposes, 
     and if not why not?

	acceptable


10)  Networks are characterized as being either Research, Defense,
     Government - Non Defense, or Commercial, and the network
     address space is shared between these three areas.  Which type
     is this network?

Network Type:   	Research

		

11)  What is the purpose of the network?

	Private Network for normal cititizens for User of
	the Individual Network. 

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

ANHANG H 	Acceptable Use Policy 

Dieser Text ist auszudrucken, zu unterschreiben und dem Provider zu 
schicken, ueber den das entsprechende Class-C-Netz geroutet wird.

     
      Interim                                              3 July 1990
      NSFNET
      Acceptable Use Policy
     
     The purpose of NSFNET is to support research and education in and
     among academic institutions in the U.S. by providing access to unique
     resources and the opportunity for collaborative work.
     
     This statement represents a guide to the acceptable use of the NSFNET
     backbone. It is only intended to address the issue of use of the
     backbone. It is expected that the various middle level networks will
     formulate their own use policies for traffic that will not traverse
     the backbone.
     
        (1) All use must be consistent with the purposes of NSFNET.
     
        (2) The intent of the use policy is to make clear certain cases
            which are consistent with the purposes of NSFNET, not to
            exhaustively enumerate all such possible uses.
     
        (3) The NSF NSFNET Project Office may at any time make
            determinations that particular uses are or are not
            consistent with the purposes of NSFNET. Such determinations
            will be reported to the NSFNET Policy Advisory Committee
            and to the user community.
     
        (4) If a use is consistent with the purposes of NSFNET, then
            activities in direct support of that use will be considered
            consistent with the purposes of NSFNET. For example,
            administrative communications for the support infrastructure
            needed for research and instruction are acceptable.
     
        (5) Use in support of research or instruction at not-for-profit
            institutions of research or instruction in the United States
            is acceptable.
     
        (6) Use for a project which is part of or supports a research or
            instruction activity for a not-for-profit institution of
            research or instruction in the United States is acceptable,
            even if any or all parties to the use are located or
            employed elsewhere. For example, communications directly
            between industrial affiliates engaged in support of a
            project for such an institution is acceptable.
     
        (7) Use for commercial activities by for-profit institutions is
            generally not acceptable unless it can be justified under
            (4) above. These should be reviewed on a case-by-case basis
            by the NSF Project Office.
     
        (8) Use for research or instruction at for-profit institutions
            may or may not be consistent with the purposes of NSFNET,
            and will be reviewed by the NSF Project Office on a
            case-by-case basis.
 
---
	We acknowledge the NSFnet acceptable use, and confirm that
	our activities involving the use of the NSFnet are conforming
	to this policy.

-- 
-----------------------------------------------------------------------------
!   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  !
-----------------------------------------------------------------------------