Re: zgaduj-zgadula

Autor: Witold Owoc (wowoc_at_acs.ucalgary.ca)
Data: Fri 02 Dec 1994 - 18:07:52 MET


Janusz Kaczmarek <Janusz.Kaczmarek_at_cs.put.Poznan.pl> widzi
problem tam gdzie go moim zdaniem nie ma.

} > Witold Owoc <wowoc_at_acs.ucalgary.ca> pisal:
} > PP.pl
} > AEPoznan.pl
} >
} > UG.Tarnowo-Podgorne.Poznan.pl
} > UM-G.Gniezno.Poznan.pl
} >
} > AOS-Borowiec.CBK.PAN.pl
}
} Ha, juz wyobrazamsobie administrowanie i utrzymanie porzadku w takim
} systemie (eee - braku systemu) nazw domenowych. To wszystko to tak
} naprawde Poznan, ale PP musi sie dogadywac z centum, Tarnowo Podgorne
} z kims w Poznaniu, AOS z jakas PANowska centrala?? A ciekawe gdzie
} zlokalizowany bylby odwrotny nameservice? (przy obecnym systemie
} przydzielania numerow IP (regionalnie) logiczne jest, ze jest on
} zregionalizowany). Czyli np. PP o swojej domenie musi rozmawiac
} z centrala na Polske, ale o odwrotnym NS juz zupelnie z kim innym...

Po pierwsze to niedlugo bedzie newIP. I podejrzewam, ze taki np. PAN,
czy tez kazda wieksza uczelnia wyzsza dostanie minimum jeden numer IP
odpowiadajacy dzisiejszej klasie B - czyli ok 60 tys. adresow.

Po drugie (w koncu prawie kazdy to na tych lamach sugeruje) jesli
przyklad reszty swiata jest _jakimkolwiek_ przykladem, to duze
instytucje maja zwykle lacza, ktore wchodza na Internet na szczeblu
regionalnym, a nie lokalnym. Czyli przykladowo (tylko przykladowo):

Cetus.Poznan.pl - 56k ---+
cosik.Poznan.pl - 56k ---|
male.Poznan.pl - 56k ------ 1M
tycie.Poznan.pl - 56k ---| |
micro.Poznan.pl - 56k ---+ |
                              +-- do W-wy i gdzie indziej --- 2-10M ---
                              |
PP.pl - 1M --------|
AEPoznan.pl - 1M --------|
UAM.pl - 1M --------|
                              |
***.Poznan.pl - 1M --------|
                              |
HCP.pl --------------------- 1M

Gdzie *** to Urzad Wojewodzki, i wszystkie urzedy miejskie, gminne
miejsko-gminne itd. Nie jest to administracja centralna, choc UW
siedza okrakiem na plocie pomiedzy administracja lokalna a centralna.

Po trzecie to skoro wyrazane jest zyczenie, by bylo wiecej
dostarczycieli uslug telekomunikacyjnych (###) to ich bedzie wiecej :-)
Wtedy AOS-Borowiec bedzie dzierzawil linie do Poznania i stamtad bedzie
sie laczyl razem z innymi instytutami PANowskimi z Warszawa i gdzie indziej.
Byc moze przez siec regionalna, ale niekoniecznie (podobnie zreszta jak
Zaklady Cegielskiego - HCP.pl)

Kornik.PAN.pl
AOS-Borowiec.CBK.PAN.pl
IFM(?).Poznan.PAN.pl
IM(?).Poznan.PAN.pl a moze Poznan.IM(?).PAN.pl
i inne to wszystko jest ta sama organizacja.
W kazdym z tych miejsc moze byc ze 20 komputerow na Internecie,
teraz wszedzie razem moze sa ze 2.
Projektowanie musi uwzgledniac taka skale wzrostu.

Po czwarte wszystkie sprawy organizacyjne zalatwia sie
u swojego dostawcy lacz. A ze ten dostarczyciel bedzie
musial rozmawiac z kims na szczeblu wojewodztwa (albo i
nawet z 'sama Warszawa' :-), no to co z tego.
Przeciez jednoosobowej firmy komputerowej Cetus nie interesuje,
ze Urzad Miejski rozmawia z kims innym w sprawie swojego DNS,
odwrotnego NS czy numerow IP. Gdy ludzie zadaja pytania typu:
kto sie ukrywa za 204.50.6.9, to albo wiedza jak znalezc
odpowiedz albo tej odpowiedzi nie potrzebuja.

Witold Owoc <wowoc_at_acs.ucalgary.ca>

### Ograniczeniem rozwoju Internetu i sieci komputerowych ogolnie
    rzecz biorac jest niedorozwinieta telekomunikacja, a nie
    NASK. Gdy TP S.A. bedzie miala nadmiary wolnych lacz, to
    bedzie miala co sprzedawac - ale to nie dzisiaj.

P.S. Prosze o ograniczenie przykladow z USA, tam jest na prawde
     inaczej. Dazmy to parametrow technicznych tam osiaganych,
     a nie powielajmy rozwiazania organizacyjne dopasowane do
     _zupelnie_ _innej_ infrastruktury.
     Zwlaszcza przyklady *.gov sa chybione. Ty nie mniej ze
     wzgledu na przypuszczalnie latwe rozpoznawanie URM.gov.pl
     jest OK, mimo iz URM.RzadRP.pl byloby koszerne (jak wodka).

#disclaimer "my.private.views"
---------------------------------------------------------
The University of Calgary had no knowledge of nor in any
way gave its consent to the transmission of this message.



To archiwum zostało wygenerowane przez hypermail 2.1.7 : Wed 19 May 2004 - 15:47:18 MET DST