🚀 go-pugleaf

                             - OSITEL/400 message -

Verursacher:                      C=DE;A=DBP;P=FGAN;O=FFM;OU=RUFVAX;S=bel
Erstempfaenger:                   C=de;A=dbp;P=dfn;OU=zpl;S=win-ip/c
Betreff:                          hinweise

liebe kollegen,
einige anmerkungen zu herrn kaehler's hinweisen:
1.) die hinweise in der vorliegenden form sind wohl mehr fuer die
betreiber eines routers an einem LAN ins WIN/IP gedacht, als fuer
die einzelnen tcp/ip benutzer, fuer die man lokal benutzungshinweise
erstellen sollte, bis auf eine formulierung des "acceptable use"
des DE-Internets.
 
2.) nutzung von ip ueber win kann mit zwwei zielsetzungen geschehen:
  a) erreichen von tcp/ip partnern ausserhalb deutschlands (nicht nur
    usa - denn ripe sollte man nicht ganz aus der sicht verlieren)
  b) erreichen von tcp/ip partnern in deutschland ueber das win
     (nicht win partner muessen in gegenseitiger absprache direkt
      angesprochen werden. z.B. wenn wir mit uni erlangen ip'en
      wollen, muessten wir win benutzen, fuer sel dagegen uns direkt
      mit denen zusammensetzen)
  
3.) erhaelt ein teilnehmer nach vertragsabschluss mit dem dfn von
    diesem eine ip-nummer (bereich) zugeteilt ? dfn verteilt doch
    wohl nur ip-addresse fuer router. das lan kann doch schon eine
    eigene ip-adresse haben (evtl schon mit connect status z.b. wir
    haben 128.7. beim sri-nic eingetragen !). als lan betreiber
    wuerde ich nicht die adressen nur deshalb aendern muessen, weil
    wir auch ueber win ip machen wollen.
  
4.) wenn dfn ip adresse vergibt muss er auch fuer connect-status sorgen.
  
5.) vollfunktionale router:
   bezueglich gateway protokolle sollte man nicht unbedingt egp anfuehren,
   (vgl. ietf nachricht von mir)
   router sollte unbedingt trace funktion haben, um evtl. fehler
   besser suchen zu koennen
   (Beispiel: bei einem test zwischen einem siemens telnet und einem
    sun-telnet auf unserem netz - allerdings unter benutzung unseres
    x.25 anschlusses an die post als interne extern schleife -
    gerieten die beiden telnets aus dem takt und beschossen sich
    30 minuten lang nur mit options wie die weltmeister, was der
    telnet benutzer garnicht bemerken kann, da der optionen zirkus
    fuer ihn transparent stattfindet. nur zufaellig durch beobachtung
    unseres datus-anschlusses bemerkten wir dies und konnten die
    paket- aufzeichnung benutzen, diesen fehler zu analysieren)
  
6.) fuer jeden router muss ein zustaendiger da sein, an den man
    evtl. fehlverhalten eines teilnehmers an dessen lokalen netz
    melden kann, damit er dies abstellt z.B. wenn wieder einmal
    entdeckt, dass man mit icmp-echo herrlich die konnektivitaet
    von netzen feststellen kann und nun dauernd verbindungen nach
    australien, hawaii korea etc herstellt und laufzeiten "misst".
  
7.) nicht vollfunktionale router sollten nur fuer eine begrenzte
    zeit zugelassen werden bis ein cisco box o.ae. bestellt und
    geliefert ist.
  
8.) auch im sttischen routing sollten default eintrage verboten sein.
  
9.) bei der paketgroesse 1024 byte habe ich bauchschmerzen:
   die cisco koennen das aber nicht alle unix systeme (4.2 bsd)
   ausserdem vergroessern sich round trip zeiten gewaltig.
   (Zahlen liefere ich noch wenn wir wieder mit uk testen koennen)
   segmentieren sollte man moeglichst vermeiden.
   kann sein, dass hier die empfehlung fuer usa und innerdeutschen
   verkehr getrennt werden sollte.
   auf jeden fall sollte man die beliebten telnet mini pakete
   mit einem datenbyte verbieten (kein remote echo beim telnet!)
  
so weit die ins unreine getippten vorschlaege.
  
mfg gerd beling
.
original: C=DE;A=DBP;P=FGAN;"MRUFVAX202900330133839-AGp"
not delivered to:
    recipient: C=de;A=dbp;P=dfn;OU=zpl;S=win-ip/c
    Reason: unableToTransfer
    Diagnostic: unrecognizedORName