NASK Road Show 2010

W związku z ostatnimi propozycjami nowych usług domenowych czyli .PL Registry Lock, DNSSEC oraz usługi aftermarket, chciałbym zaproponować Państwu spotkania konsultacyjne z NASK (nazwijmy roboczo „NASK Road Show 2010”).

Celem spotkań jest próba weryfikacji założeń NASK co do proponowanych usług, dopracowanie usług w ten sposób aby były bardziej atrakcyjne dla rynku oraz być może rozwój tych usług (...aukcje?). Obecnie NASK, w sytuacji kiedy został wdrożony mechanizm pre-paid, ma większe możliwości uruchamiania nowych propozycji dla rynku gdyż problem wygenerowania ewentualnych zaległości finansowych Partnera już nie istnieje.

Plan spotkań jest następujący:
• Warszawa, 12 stycznia 2010 r., 11.00 - 15.00 w NASK
• Szczecin, 13 stycznia 2010 r.(miejsce i czas do uzgodnienia)
• Bydgoszcz, 14 stycznia 2010 r. (miejsce i czas do uzgodnienia)
• Luty 2010 r. - dyskusja elektroniczna
• Kraków, 16 marca 2010 r. – spotkanie podsumowujące (miejsce i czas do uzgodnienia)

Na spotkaniu w Warszawie, oprócz tematów wymienionych na wstępie, będziemy omawiali temat reaktywacji projektu ENUM. Swój udział w naszym spotkaniu potwierdził pan Dyrektor Tomasz Karamon z Urzędu Komunikacji Elektronicznej. Konsultacje dotyczące ENUM mają na celu znalezienie takich rowiazań pomiędzy Partnerami, Abonentami usług telekomunikacyjnych, Operatorami telekomunikacyjnymi, UKE oraz NASK, które pozwolą na rozwój tego projektu w Polsce.

Osoby zainteresowane proszę o zgłaszanie się do Zespołu Rozwoju Programu Partnerskiego w NASK bądź wpis w komenatrzu. Na postawie liczby zgłoszeń będziemy organizowali odpowiednie warunki lokalowe na spotkanie.

NASK jako operator rynku wtórnego.

W ciągu ostatnich kilku tygodni przedstawiłem propozycje dwóch nowych usług: .PL Registry Lock oraz DNSSEC. Planuję zrobić spotkanie w pierwszym kwartale 2010 r. na którym omówimy i dopracujemy szczegóły tych usług wraz z Partnerami i innymi osobami zainteresowanymi tymi projektami. Obie te (proponowane) usługi związane są z bezpieczeństwem, a dokładniej z poprawą tego bezpieczeństwa.

Teraz chciałbym przedstawić zarysy projektu związanego z rynkiem wtórnym. Nieukrywam, że sam uważam ten pomysł za kontrowersyjny, ale to nie znaczy że nie należy rozpocząć dyskusji na ten temat. Temat został już jakiś czas temu zasugerowany mi przez kilka osób niezależnie, wersje różniły się w swoim kształcie, niemniej jednak idea pozostawała zawsze taka sama: NASK jako operator rynku wtórnego.

Second hand domains...

Propozycja zakłada udostępnienie Naskowego (hurtowego) kanału sprzedaży domen dla osób, które chciałyby sprzedać swoje domeny na wolnym rynku. Osoba, która jest abonentem domeny oraz posiada AuthInfo, będzie mogła wystawić poprzez swojego Partnera domenę do sprzedaży w kanale Partnerskim NASK (poprzez EPP). NASK będąc pytanym o dostępność domeny będzie mógł odpowiedzieć wtedy nie tylko czy domena jest wolna albo zajęta ale również, czy jest dostępna na rynku wtórnym i za jaką cenę. Klient każdego Partnera będzie mógł w ten sposób dokonać zakupu po ustalonej cenie.

Abonent wystawiając domenę w takim kanale sprzedaży musiałby zobowiązać się do niesprzedawania jej w inny sposób ze względu na charakter takiej sprzedaży domen (natychmiastowy, bez dodatkowej ingerencji / akceptacji dotychczasowego Abonenta).
NASK zajmowałby się pośrednictwem w wykonaniu transakcji i z racji obsługi przez nas rejestru moglibyśmy zagwarantować, że domena zmieni Abonenta natychmiast po transakcji. Istnienie systemu pre-paid gwarantowałoby także to, że Partner posiada środki na wykonanie takiej transakcji. Należy oczywiście założyć, że Partnerzy pobieraliby z tego tutułu prowizję, podobnie jak NASK (za wystawienie domeny do sprzedaży oraz prowizję od sprzedaży).

Zostawiam Państwu ten temat do przemyślenia... Ja daję mu 30% szans na wdrożenie... jeśli będzie zainteresowanie Partnerów oraz klientów, nie widzę powodu aby nie wykorzystać takiej możliwości w interesie zarówno Abonentów, Partnerów jak i NASK.

Inwestujemy w bezpieczeństwo: DNSSEC oraz .PL Registry Lock

W ostatnim czasie prezentowałem koncepcję nowej usługi jaką jest .PL Registry Lock. Po publikacji bloga otrzymałem wiele uwag, zarówno pozytywnych jak i sugestii zmiany niektórych (zaproponowanych) zasad. Mam też przegląd propozycji co do cen takiej nowej usługi. Nadal zbieram uwagi i sugestie dotyczące kształtu „.PL Registry Lock” i będę dopracowywał koncepcję w najbliższych tygodniach. Za dotychczasowe uwagi dziękuję i... oczekuję na więcej.

Oprócz „.PL Registry Lock” chciałbym powrócić do tematu DNSSEC...

Dotychczas DNSSEC był projektem inżynierskiem, bez wdrożeń komercyjnych. Jak być może Państwo wiecie, pojawiły się już pierwsze trzy wdrożenia DNSSEC w Europie, aczkolwiek nie są to wdrożenia NSEC3, czyli bezpieczniejszej i lepszej odmiany DNSSEC, którą planuje wdrożyć NASK. Obok wymienionych kilku wdrożeń po stronie rejestrów domen, ICANN poważnie przymierza się do „podpisania” roota z wykorzystaniem technologii DNSSEC. Według zapewnień ICANN nastąpi to na przełomie pierwszego i drugiego półrocza 2010 r.

Mam nadzieję, że w najbliższym półroczu, z jednej strony kraje, które wdrożyły DNSSEC dla swoich klientów (.CZ .SE .BG) będa mogły pochwailić się swoimi osiągnięciami i porażkami DNSSECowymi, a z drugiej strony będziemy mieli większą wiedzę na temat funkcjonowania DNSSEC na poziomie root. Chciałbym też nadmienić, że NASK od kilku lat wykorzystuje DNSSEC dla projektu ENUM i nasze doświadczenia są generalnie pozytywne z tym projektem.

Biorąc to wszystko co napisałem pod uwagę, chciałbym przedstawić Państwu propozycję spotkania w NASK w marcu lub kwietniu 2010 na którym moglibyśmy omówić szczegóły i propozycje zarówno jeśli chodzi o plany NASK jak i aktualną sytuację na świecie z wdrożeniem DNSSEC oraz projektów typu „Registry Lock” (głównie VeriSign). Spotkanie będzie też okazją do wymiany poglądów oraz dyskusji na temat kształtu tych umów. Spotkanie będzie otwarte, tzn. będą w nim mogli uczestniczyć nie tylko Partnerzy NASK, ale także osoby zainteresowane tymi projektami.

Moje plany jeśli chodzi o harmonogram wdrożenia poszczególnych usług wygląda on następująco:

wdrożenie .PL Registry Lock:
1. Spotkanie w NASK - marzec 2010 r.
2. Zamknięcie uzgodnień szczegółowych w zakresie usługi „.PL Regsitry Lock” – maj 2010 r.
3. Wdrożenie testowe – lipiec 2010 r.
4. Umowa prawna – sierpień 2010 r.
5. Wdrożenie produkcyjne – 30 sierpnia 2010 r.

wdrożenie DNSSEC (dokładniej NSEC3):
1. Spotkanie w NASK - marzec 2010 r.
2. Uzgodnienia szczegółów usługi, dopracowanie procesow administracyjnych po stronie NASK i Partnerów – lipiec 2010 r.
3. Szkolenia Partnerów, edukacja klientów – do grudnia 2010 r.
4. Wdrożenie testowe – marzec 2011 r.
5. Wdrożenie produckyjne – czerwiec 2011 r.

Ktoś może zadać pytanie - czemu tak dużo czasu zajmuje wdrożenie DNSSEC? Niestety DNSSEC jest usługą wymagajaca po stronie Registrarów (czyli w przypadku .PL Partnerów) bardzo dużo wysiłku. Sama technologia nie jest skomplikowana. Skomplikowane jest wdrożenie procedur administracyjnych zapewniajacych klientowi, że jego domena będzie dostępna. Niestety w przypadku DNSSEC, drobna pomyłka powoduje, że serwery DNS traktują domenę jako podpisaną nieprawidłowo i nie zwracają odpowiedzi do klienta. Duże problemy z domeną .GOV (dla administracji rządowej w USA) na początku tego roku pokazują, że drobny bład w autoryzacji podpisow powoduje, że nawet poprawna domena może być niedostępna. W przypadku .PL musimy zrobić wszystko, żeby nie powtórzyć błędów zarówno .GOV jak i kolegów z .SE oraz .CZ.

I jak zwykle zapraszam Państwa do dyskusji na temat tych usług już teraz... Szczególnie będzie ciekawe poznanie Państwa wizji co do ewentualnego sukcesu komercyjnego DNSSEC dla Partnerów, czyli mówiąc inaczej, jak będzie można sprzedać tą usługę klientom tak, by byli oni z tego zadowoleni, a Partner aby dzięki temu zyskał udział w rynku bądź wygenerował zysk.

.PL Lock Service - usługa dla wymagających

Podczas ostatniej konferencji ICANN byłem pytany przez trzech różnych Registrarów o możliwość wprowadzenia dla klientów i Partnerów NASK nowego serwisu polegającego na dodatkowym zabezpieczeniu domen. Zostałem o to samo zapytany ostatnio przez jednego z rodzimych Partnerów (z pierwszej 10-tki), więc czas chyba rozważyć, czy nie wdrożyć tego pomysłu w życie.

Za pomysłem nowego serwisu kryje się obawa niektórych Rejestratorów i Abonentów o to, że ktoś np. może włamać się na system Partnera (Registrara) i dokonać nieautoryzowanych zmian na domenach – transferu domeny, zmiany serwerów nazw, zmiany abonenta itd. Ponieważ wszystko dokonywane jest automatycznie, nie ma możliwości ręcznej weryfikacji takich transakcji.

Rozwiązaniem jest wprowadzenie mechanizmów ustawiania w systemie Registry NASK statusu „server Update Prohibited” na żądanie Partnera. Przy tak ustawionym statusie na domenie, nie jest możliwe automatyczne wykonanie jakiejkolwiek operacji poprzez EPP (protokół komunikacyjny automatycznej wymiany danych między NASK a Partnerem, odbywający się bez udziału człowieka). W przypadku kiedy Partner będzie jednak chciał dokonać zmian dla swojego klienta, zwróci się do NASK telefonicznie lub mailowo w celu „odblokowania” możliwości zmian. NASK potwierdzi tożsamość osoby reprezentującej Partnera za pomoca np. niezależnego hasła (niewykorzystywanego w systemach automatycznych), oddzwoni na ustalony wcześniej numer bądź wykorzysta mechanizm „one-time passwords”. Po przeprowadzonej w ten sposób bezpiecznej autentykacji NASK zdejmie blokadę z domeny (lub domen), Partner dokona zmian poprzez EPP (automatycznie) a następnie NASK przywróci status serverUpdateProhibited.

Opisana procedura oczywiście dodatkowo zabezpiecza klienta, niemniej jednak powoduje, że zmiany nie mogą być dokonywane automatycznie i będą wymagały trochę czasu na ich dokonanie. Tak jak w przypadku każdego zabezpieczenia gdzie musimy wybrać inny kanał autentykacji, należy z czegoś zrezygnować (pełna automatyzacja, zmiana w ciągu kilku sekund) na rzecz nieco bardziej skomplikowanej procedury (zmiana danych może trwać nawet kilkanaście minut).

Podobne rozwiązanie zaproponował niedawno VeriSign i nazywa się to „Registry Lock Service - com/net”. Opis tego serwisu można znaleźć na stronie VeriSign.

Podobnie jak VeriSign, NASK zaproponowałby też cennik na zasadzie „tiered pricing” gdzie cena za usługę byłaby uzależniona od ilości domen w ten sposób dodatkowo zabezpieczonych. Oczywiście ceny nie byłyby tak kosmiczne jak w przypadku VeriSign (100 USD za rok za domenę), niemniej jednak usługa powinna mieć status „VIP” i chociażby ze względu na jej charakter, wymaga wysiłku zarówno po stronie Partnera jak i NASK.

Czekam na Państwa opinie zarówno jako Partnerow NASK jak i Abonentów domen. Bez zainteresowania Abonentów nie ma oczywiście sensu dalsza dyskusja nad taką usługą... Ja ze swojej strony podchodzę całkowicie neutralnie do tego pomysłu i jestem gotowy wdrożyć go o ile będzie faktyczne zainteresowanie rynku.

Zakończyłem migrację na Blogspota

Właśnie zakończyłem migrację na Blogspota z Webhosting i Webinside oraz z własnej strony. Tyle blogów, rozrzuconych po kilku portalach nie miało sensu. Zacząłem pisać na Webhosting oraz na swojej stronie... później doszedł Webinside... W sumie uzbierało się 68 blogów, w tym 40 w tym roku...

Postanowiłem umieścić wszystko w jednym miejscu żeby nie zmieniać linków w przyszłości czy też liczyć na support dwóch komercyjnych portali... Oczywiście nie mam nic przeciwko aby napisać na chociażby Webinside, ale wolę mieć pełną treść na swoim blogu na Blogspocie, gdzie mogę podać własny URL i mieć nad tym pełną kontrolę...

Tak więc zapraszam do zapoznania się z poprzednimi blogami...

Oczywiście przeprowadzka z Webhosting/Webinside oznacza utratę komentarzy pod blogami - czasami bardzo cennych dyskusji, ale trudno.

Muszę też przyznać że Blogspot ma bardzo ciekawe funkcje. Weźmy chociażby możliwość łatwej modyfikacji wyglądu (układu) bloga. Dodawanie różnych funkcji jak np. własnej wizytówki widocznej dla czytelników. Dodawnie blogów poprzez e-mail. Eksport całości bloga wraz z ustawieniami do XML (można użyć do backupu). Generalnie dla mnie rewelacja.

Konferencja IGF: Creating an opportunity for all

W Sharm el-Sheikh właśnie zakończyła się kolejna konferencja Internet Governance Forum[1], której tutuł to „Tworzenie możliwości dla wszystkich”

Jak podają źródła ONZ, na konferencję przyjechało 1800 uczestników z 112 krajów w tym reprezentanci 96 rządów. Ciekaw jestem ilu z nich przyjechało ze względu na miejsce i czas konferencji – Sharm el-Sheikh, a ilu ze względu na samą konferencję... Zakładając, że z tych 1800 uczestników powiedzmy 1600 musiało przylecieć samolotem i że koszt przelotu jednej osoby to 500 EUR (to raczej kwota zaniżona, bo część osób leciała z Europy, ale duża część z Azji, Australii czy Ameryki) a koszt hotelu konferencyjnego to powiedzmy 150 EUR na osobę (x5 noclegów) to daje 2 000 000 EUR kosztów samego przelotu i pobytu uczestników...

I tak, IGF 2009 zostanie zapamiętane głównie przez incydent z usuwaniem materiałów organizacji Open Net Initiative (ONI) w związku z protestem Chin. Jak wyjaśnił Marcus Kummer „UN also has to operate within certain rules, including the respect for national sovereignty and territorial integrity of Member States”. Czy to oznacza, że plakat z reklamą książki i odniesieniem do Chińskiego muru narusza „national sovereignty and territorial integrity” Chin? Mam co do tego wątpliwości, szczególnie jeśli chodzi o tą integralność terytorialną... Na pierwszym spotkaniu IGF, które miało miejsce w 2006 roku w Atenach, też były organizacje broniące otwartości Internetu i walczące z cenzurą i do żadnych incydentów nie dochodziło. Mam nadzieję, że incydent z ONI nie stanie się standardem na przyszłość...

Analizując draft raportu końcowego[2] w nieco żartobliwy (złośliwy?) sposób, mamy następujące wyniki:
• Słowo „access”zostało powtórzone 37 razy
• Słowo „security” zostało powtórzone 18 razy
• „privacy” 15 razy
• „diversity” 14 razy
• „multistakeholder” 13 razy
• „IPv6” 12 razy
• „openness” 11 razy
• „IDN” 9 razy
• „mulitilingual” 5 razy
• „transparency” 5 razy
• „intellectual property rights” tylko 1 raz...

I w sumie można na tym poprzestać... Zdecydowanie „multilingual” straciło w stosunku do poprzednich lat (teraz słowo klucz to „IDN”) a „transparency” nigdy nie było na topie... Pozytywny wzrost znaczenia „privacy”. „Access”, „multistakeholder” i „diversity” jak zwykle na topie. Nowością (i to w dobrym kierunku) jest „security” z tak dobrym wynikiem ... Niestety za żadnym z powyższych nie stoi jakiś konkretny i znaczący content, ale też IGF jest ciałem dyskusyjnym bez prawa do tworzenia standardów czy wprowadzania wiążących dla rządów poszczególnych krajów decyzji.

Z innych ciekawych spraw, jak donosi oficjalny raport, uczestnicy wyrazili zadowolenie z podpisanej umowy pomiędzy Internet Corporation for Assigned Names and Numbers (ICANN) a rządem USA. Pytanie tylko, czy faktycznie potrzeba było wydać tyle pieniędzy, żeby to ustalić?

W trakcie spotkania IGF prezentowane były (oczywiste) kwestie związane:
1) z potrzebą wdrożenia IPv6 (ITU zobowiązało się do wsparcia rzadów krajów rozwijających się przy przejściu z IPv4 na IPv6),
2) planami w zakresie IDN-ccTLD (została podniesiona kwestia potrzeby konkurencji przy wyborze podmiotów zarządzających nowymi IDN-ccTLD; pytanie tylko co na to obecne rejestry mające ochotę na obsługę nowych TLD?)
3) planami wdrożenia DNSSEC na poziomie root,
4) wdrożeniem Affirmation of Commitments przez ICANN i rząd USA (wraz z pojawiającymi się komantarzami na temat tego, czy przypadkiem funkcja IANA nie powinan zostać przejęta przez organizację międzynarodową; propozycja aby nad tym debatował IGF została przyjęta z entuzjazmem, co oznacza, że IGF zajmie się tym w kolejnych latach, prawdopodobnie „już” w Wilnie w roku 2010)
5) balansem pomiędzy prywatnością a bezpieczeństwem, oraz równowagą pomiędzy wolnością wypowiedzi i dostępem do informacji a prawami autorskimi (niestety ta ostatnia kwestia nie znalazła szerokiego zainteresowania na IGF; akurat tutaj jest duży obszar do zagospodarowania, być może temat jest zbyt trudny?).
6) kwestiami rozwoju społeczności Internetowych wobec prywatności (tylko pytanie czym się tu zajmować: skoro ktoś chce się dzielić sobą w Internecie, to ma do tego pełne prawo i co tu komu do tego?)
7) istota prawa do prywatności obok prawa do swobodnej wypowiedzi
8) zapewnienie standardów w dziedzinie ICT dających osobom niepełnosprawnym łatwiejszy dostęp do zasobów Internetu (tylko gdzie konkrety!?)
9) konieczność szkoleń dla LEA[3] w zakresie tzw. „cybercrime” (oj zdecydowanie to jest potrzebne!!!)

Należy pozytywnie zaznaczyć rolę Chairmana konferencji, Ministra Komunikacji i Technologii Informacyjnych Egiptu, p.Tareka Kamela. Minister Kamel wymienił jako ważne takie sparwy jak: cyber-bezpieczeństwo ponadgraniczne (często się o tym zapomina, niestety), dostęp szerokopasmowy w krajach rozwijajacych się, treści w językach innych niż angielski oraz adresowanie uwagi w kierunku młodych ludzi. Trzeba przyznać, że akurat Minister Kamel z Egiptu jest na świecie i w Egipcie postacią bardzo pozytywną i ministrem któremu się faktycznie „chce” i zna się na tym co robi. I pokazał to na konferencji.

Oczywiście nie obyło się bez sesji poświęconej przyszłości samego IGF. To jest generalnie ciekawe – im mniej potrzebna organizacja, tym więcej poświęca czasu na dyskusję o swojej przyszłości. Moje doświadczenia chociażby z CENTR czy ITU są takie, że jak jest faktycznie dużo pracy i lista potrzebnych rzeczy do zrobienia, to nikt się nie zastanawia nad tym czy jest potrzebna „kontynuacja” i czym się należy zajmować...

Przypisy:
[1] To jest tak piękna fraza, że należy ją pozostawić w oryginale: The IGF is a forum for multi-stakeholder dialogue on public policy related to Internet governance issues, such as the Internet's sustainability, robustness, security, stability and development.
[2] Internet Governance Forum raport 18 listopad 2009
[3] Law enforcement agency

Przekierowania w służbie domen ze znakami narodowymi

Największy rejestr domen narodowych świata - CNNIC czyli rejestr domen z końcówka .CN (Chiny), wprowadzil bardzo ciekawą funkcjonalność dla przyszłych użytkowników domen ze znakami narodowymi.

Użytkownik, który wpisze w przeglądarce nazwę domenową z końcówka .CN ze znakami spoza podstawowego zestawu znaków ASCII, zostaje automatycznie przekierowany na specjalną stronę z informacją w języku chińskim o treści „Domena nie została jeszcze zarejestrowana. Kliknij tu aby dowiedzieć się więcej o rejestracji domen oraz tu aby zarejestrować taka domenę”. Przekierownie realizowane jest przez bardzo prosty mechanizmem DNS o nazwie „wildcards”.



Celem tego działania jest oczywiście promocja domen ze znakami narodowymi a przy okazji zwiększenie ich sprzedaży.

Jeśli ktoś ma ochtę sprawdzić jak mechanizm działa, wystarczy wpisać dowolny ciąg znaków rozpoczynający się od xn—i kończacy się na .CN. Zostaniemy wtedy przekierowani na opisywaną wyżej stronę.

Inne rejestry narodowe także używaja DNS wildcards, chociaż tutaj już dla wszystkich domen celem zwiększenia całkowitej sprzedaży. Wśród tych rejestrów jest .cg, .kr, .mp, .nu, .ph, .rw, .st, .tk, .vg oraz .ws.

Pytanie oczywiście pozostaje, czy wildcards nie wprowadzają użytkowników w bład? Jeśli pomylimy numer telefonu i wybierzemy nieistniejący, to zazwyczaj dostajemy sygnał ostrzegawczy w słuchawce. Gdyby wildcards zostały wprowadzone w praktyce w telefonii, to zamiast sygnału ostrzegawczego dostalibyśmy reklamę np. operatora komórkowego... Pytanie czy zwykły użytkownik Internetu chce wildcards...?