zgłoszonych w ramach uzgodnień konsultacji społecznych

Departament Spraw Obronnych MI 1 czerwca 2011 Zestawienie uwag do projektu rozporządzenia Rady Ministrów w sprawie wymagań technicznych i eksploatacyjnych dla interfejsów umoŝliwiających wykonywanie zadań i obowiązków na rzecz obronności, bezpieczeństwa państwa oraz bezpieczeństwa i porządku publicznego (art. 182 ustawy - Prawo telekomunikacyjne) zgłoszonych w ramach uzgodnień konsultacji społecznych Lp Jedn. red. Zgłaszający Treść uwagi Uzgodnienie 1-2 - 3-4 - 5-6 - Uwagi ogólne Prawodawca określił w nim wymagania techniczne i eksploatacyjne dla interfejsów, pomijając ustawowy wymóg kierowania się zasadą minimalizacji nakładów przedsiębiorcy telekomunikacyjnego i podmiotów uprawnionych (przykłady w uwagach nr 2, 3, 25, 26, 28) Nie uwzględniono aktualnego stanu technologicznego i jego kierunków rozwoju w zakresie dostępnych funkcjonalności LI dla poszczególnych generacji telefonii komórkowej (np.: LTE, Voice over LTE), a takŝe konwergencji usług np. przenikanie się sieci mobilnych i stacjonarnych tak jak świadczenie usług sieci stacjonarnej z wykorzystaniem sieci ruchomej. Nie wzięto pod uwagę moŝliwości stosowania innych, nowoczesnych identyfikatorów uŝytkowników jako kryteriów wyboru obiektu obserwacji np. ENUM. Budowane wg zaproponowanej w projekcie specyfikacji interfejsów systemy LEMF i ADMF z załoŝenia będą przestarzałe" technologicznie juŝ w trakcie ich budowy. Pominięto potrzebę unifikacji rozwiązań systemowych budowanych na potrzeby uprawnionych podmiotów oraz na potrzeby sądów i prokuratorów (np. moŝliwość przekazywania postanowień prokuratorskich w postaci elektronicznej - styk HI1 interfejsu HI i interfejs HI A- B), powodując tym samym zwiększenie kosztów ponoszonych przez przedsiębiorcę telekomunikacyjnego. Projekt rozporządzenia nie uwzględnia rozwiązań interfejsowych przygotowanych przed dniem wejścia w Ŝycie ustawy z dnia 24 kwietnia 2009 r. o zmianie ustawy - Prawo telekomunikacyjne oraz niektórych innych ustaw, spełniających wymagania określone w art. 179 ust. 4-4b i art. 180d Prawa telekomunikacyjnego. MoŜliwość stosowania i eksploatacji takich rozwiązań została dopuszczona na mocy art. 15 ust. 1 powołanej wyŝej ustawy z dnia 24 kwietnia 2009 r. NaleŜy przy tym zaznaczyć, Ŝe w latach 2008-2009, gdy uprawnione podmioty budowały systemy LEMF nowej generacji, specyfikacja interfejsów dot. tych systemów została uzgodniona z przedsiębiorcami telekomunikacyjnymi oraz interfejsy te zostały przetestowane, a następnie systemy posiadające uzgodnione interfejsy zostały akredytowane przez ABW i wdroŝone do eksploatacji Projekt nie uwzględnia faktu istnienia roamingu krajowego pomijając wymagania na funkcjonalność LI w rozbiciu na kaŝdego partnera roamingowego, co powoduje takŝe brak unormowań w zakresie podziału odpowiedzialności tych partnerów roamingowych za przygotowanie odpowiedniej infrastruktury specjalnej zapewniającej ciągłość i efektywną dostępność uprawnionych podmiotów do treści kontrolowanych przekazów telekomunikacyjnych. Projektodawca pominął fakt uwarunkowań zawartych w zasadach i procedurach określonych w przepisach odrębnych, o których mowa w art. 180d Prawa telekomunikacyjnego, przykładowo pominięto konieczność posiadania dostępu pracowników przedsiębiorcy telekomunikacyjnego do funkcjonalności niezbędnych do pełnienia przez tego przedsiębiorcę roli gestora systemu ADMF, odpowiedzialnego prawnie za ich gotowość eksploatacyjną. 1

7-8 9 10 - TP 11 - W rozporządzeniu powinien znaleźć się zapis, Ŝe z obowiązku posiadania rozwiązania zgodnego z proponowaną specyfikacją zwolnieni są wszyscy operatorzy, którzy juŝ posiadają zawarte porozumienia z podmiotami uprawnionymi na udostępnianie treści przekazów telekomunikacyjnych za pośrednictwem interfejsów Z uwagi na skalę proponowanych zmian, oraz istotność regulowanej materii, wskazane jest aby przedmiotowe rozporządzenie zapewniało trwałości obecnie funkcjonujących rozwiązań. W projekcie rozporządzenia powinien znaleźć się zapis zwalniający operatorów którzy juŝ posiadają zawarte porozumienia z podmiotami uprawnionymi na udostępnianie treści przekazów telekomunikacyjnych za pośrednictwem interfejsów z obowiązku posiadania rozwiązania zgodnego z proponowaną w nowelizacji specyfikacją. Brak zapisu o bezwarunkowym dopuszczeniu do dalszego uŝytkowania rozwiązań, które funkcjonują juŝ teraz trudno odczytać inaczej, jak swego rodzaju sankcję nałoŝoną na tych operatorów, którzy wychodząc naprzeciw potrzebom Państwa zainwestowali olbrzymie środki (zarówno finansowe, jak i ludzkie) w wypracowanie, uzgodnienie a następnie zaimplementowanie interfejsu. Podkreślić trzeba, Ŝe konieczność dostosowania obecnie uŝytkowanych rozwiązań do proponowanego rozporządzenia będzie zmuszała operatorów do rozwaŝenia czy ponosić dalsze koszty dostosowywania i utrzymywania interfejsu, czy teŝ powrócić do sytuacji sprzed kilku lat, kiedy nie było interfejsów. Nie ulega wątpliwości, Ŝe w przypadku wyłączenia interfejsów najbardziej zmianę tę odczują podmioty uprawnione, które inwestowały olbrzymie publiczne środki w budowę systemów, które teraz trzeba będzie albo zmienić, albo wręcz w niektórych obszarach wyłączyć. Warto teŝ zauwaŝyć, Ŝe w przypadku gdy operator jednak zdecyduje się na dostosowanie systemu do nowych wymagań, to i tak przez okres kilku miesięcy (czas na przebudowę i ponowną certyfikacji systemu) podmioty uprawnione, które juŝ teraz mają podpisane stosowne porozumienia, zostaną pozbawione moŝliwości korzystania z interfejsu. Aby uniknąć wyŝej opisanych problemów wystarczy zapisać w rozporządzeniu, Ŝe specyfikacja dotyczy wyłącznie interfejsu do tych podmiotów, które w chwili wejścia w Ŝycie rozporządzenia nie miały podpisanego porozumienia o którym mowa w art. 179 ust 4a. Postulujemy, by w Rozporządzeniu znalazł się przepis, który przewiduje, Ŝe wszyscy przedsiębiorcy telekomunikacyjni, którzy juŝ wykonują za pomocą interfejsów zadania i obowiązki na rzecz obronności, bezpieczeństwa państwa oraz bezpieczeństwa i porządku publicznego, zwolnieni zostali z obowiązku posiadania rozwiązania zgodnego z nową specyfikacją wprowadzaną przedmiotowym Rozporządzeniem albo, aby uelastycznić treść rozporządzenia w taki sposób, aby istniejące rozwiązania mogły się w nim zmieścić. W naszej ocenie, przedsiębiorcy, którzy juŝ posiadają lub negocjują porozumienia/umowy z podmiotami uprawnionymi powinni mieć zagwarantowaną moŝliwość stosowania interfejsu w wersji juŝ uzgodnionej i zaakceptowanej przez strony umowy (przedsiębiorcę telekomunikacyjnego i podmiot uprawniony) bez konieczności migrowania na interfejsy o nowej specyfikacji, którą narzuca projekt Rozporządzenia. Taka migracja wymuszałaby na operatorach ponoszenie dodatkowych kosztów i de facto karałaby tych operatorów, którzy - wobec próŝni prawnej - podjęli dobrowolną (i na własny koszt) inicjatywę wypracowania standardów interfejsów, stwarzając tym samym warunki do realizacji zadań na rzecz obronności, bezpieczeństwa państwa oraz bezpieczeństwa i porządku publicznego. NaleŜy dopuścić moŝliwość podpisania umowy z zainteresowanymi słuŝbami np. na implementację interfejsu H1, H2, H3 /Legal Intercept/ bez konieczności implementacji interfejsu HI A-B. Rozumiejąc, Ŝe w warstwie technologicznej niezbędna jest identyfikacja uprawnionego podmiotu pragniemy podkreślić, Ŝe format LIID identyfikuje jednoznacznie uprawniony podmiot, co jest sprzeczne z wymaganiami ABW stawianymi przedsiębiorcom telekomunikacyjnym w procesie akredytacji systemów zaimplementowanie dodatkowych mechanizmów anonimizacji LIID w sieci telekomunikacyjnej stanowi dodatkowy, koszt po stronie przedsiębiorców telekomunikacyjnych. uwaŝa ze wymagania w zakresie konstruowania black box winny zostać wyraźnie określone w rozporządzeniu w taki sposób, aby ochrona informacji nie powodowała 2

12-13 2 14 15 16 2 17 I.1 18 III.3 nadmiernych kosztów Projekt nie uwzględnia standardu IPv6, co moŝe spowodować konieczność róŝnego rodzaju mechanizmów opakowania IPv6 w IPv4 co skomplikuje i podwyŝszy koszty budowy interfejsów równieŝ ze względu na kończący się zapas adresów Treść projektu rozporządzenia, uzasadnienie, OSR Z uwagi na harmonogram budŝetowania środków u przedsiębiorców telekomunikacyjnych, czas niezbędny na opracowania i wdroŝenia zmian oraz wielomiesięczny proces certyfikacji rozwiązania przez ABW, konieczne jest zapewnienia odpowiedniego okresu na wejście w Rozporządzenia w Ŝycie. Proponuje się, by vacatio legis dla rozporządzenia wynosił 36 miesięcy. Przewidziany w projekcie termin wejścia w Ŝycie rozporządzania po upływie 6 miesięcy o dnia ogłoszenia powinien zostać znacznie wydłuŝony. Istotnym jest, iŝ harmonogramy budŝetowania środków u największych operatorów nie umoŝliwiają dokonania istotnych zmian w nagłym trybie. Ponadto, naleŝy wskazać, iŝ niezbędne jest zachowanie odpowiedniego czasu dla operatorów na opracowanie i wdroŝenie zmian przewidzianych w projekcie rozporządzenia. Dodatkowo naleŝy wskazać, iŝ zaimplementowane nowe rozwiązanie winno przejść proces certyfikacji dokonywanej przez Agencję Bezpieczeństwa Wewnętrznego, który to proces trwa wiele miesięcy. Mając na uwadze powyŝsze stoi na stanowisku, iŝ wejście w Ŝycie rozporządzenia winno nastąpić z zachowaniem co najmniej 36- miesięcznego vacatio legis. Krótszy okres na dostosowanie do nowej sytuacji prawnej będzie dodatkowym argumentem dla operatorów za tym, aby nie ponosić ryzyka braku zgodności posiadanych rozwiązań z przepisami, tylko wyłączyć moŝliwość korzystania z interfejsu. Podkreślenia wymaga, iŝ zgodnie z delegacją ustawową zawartą w art. 182 ustawy Prawo telekomunikacyjne projekt rozporządzenia winien być opracowywany z zachowaniem zasady minimalizacji nakładów przedsiębiorcy telekomunikacyjnego i podmiotów uprawnionych. Zakładany okres vacatio legis jest nie do przyjęcia, poniewaŝ okres niezbędny jest co najmniej 36 miesięczny okres na procedury budŝetowania, zamawiania, wdroŝenia oraz akredytacji w ABW systemów Lawfull Interception. Dla operatorów telefonii stacjonarnej, na skutek duŝego wolumenu ruchu oraz róŝnorodności usług, wprowadzenie proponowanego standardu interfejsu wiązać się będzie z koniecznością przebudowy sieci, baz danych oraz istniejących systemów LI. Ze względu na juŝ przyjęte rozwiązania (często chronione patentami), wolumen i architekturę sieci przebudowa systemu wiązać się będzie z bardzo duŝymi kosztami po stronie operatora i nie będzie mogła być wykonana w nakazanym czasie Załącznik nr 1 W projekcie znajduje się aŝ 21 odwołań do róŝnych dokumentów nie funkcjonujących w polskim porządku prawnym (np. w pkt: IV. 1.1, IV. 1.2, IV.2.13, IV.3.2, IV.3.4, IV.3.6, IV.4.3, IV.4.4, IV.4.5, IV.4.6, IV.4.7, V.1.2, V.1.3, V.1.5, V.1.10 Załącznika nr 1 do rozporządzenia). Aby moŝliwe było powoływanie się na te dokumenty muszą być one wcześniej wprowadzone do stosowania w polskim systemie prawnym przez ministra właściwego do spraw łączności w drodze rozporządzenia na mocy delegacji zawartej w art. 3 ust. 3 Prawa telekomunikacyjnego. Wobec powyŝszego zarzutu właściwym rozwiązaniem jest przeniesienie odwołań do przywołanych dokumentów do umów, o których mowa w art. 179 ust. 4a Prawa telekomunikacyjnego. W definicji obiektu monitorowanego naleŝy usunąć słowa uŝytkownik lub abonent" 19 IV.1.1 Zamiast 1000BASE-T" zapisać 100/1000BASE-T" 3

20 21 22 IV.1.2 IV.1.3 IV.1.2 23 IV.1.3 24 IV.1.6 TP 25 IV.1.7 26 IV.1.8 27 W projekcie w wymaganiach ogólnych dla interfejsu LI HI wymagania w zakresie wyboru protokołu są sprzeczne. Projektodawca dokładnie specyfikując w pkt IV.4.3 Załącznika nr 1 kodeki i format plików audio i wideo wymusza ingerencję przedsiębiorcy telekomunikacyjnego w treść przekazu telekomunikacyjnego mającą wpływ na jego jakość (w sieciach czwartej generacji (Rel.4) często stosowane są inne kodeki niŝ wskazany kodek G.711A). Zamknięta lista kodeków wideo wydaje się równieŝ niewłaściwym rozwiązaniem poniewaŝ wyklucza nowsze rozwiązania w przyszłości. W projekcie naleŝy określić jakie funkcje administracyjne miałyby być realizowane poprzez interfejs HI1, poniewaŝ aktualne zapisy (Załącznik nr 1 pkt 111.1 a) wskazują, Ŝe system ADMF u przedsiębiorcy telekomunikacyjnego będzie administrowany przez wszystkich uŝytkowników systemów LEMF, co jest niedopuszczalne. Zamiast wymagane" zapisać zalecane"; Bezwzględnie naleŝy uwzględnić IPv6: operatorzy telekomunikacyjni przechodzą niedługo na IPv6 z powodu kończenia się puli adresów IPv4. W związku z tym wprowadzenie na interfejsie tylko IPv4 moŝe spowodować konieczność wprowadzenia róŝnego rodzaju mechanizmów opakowywania IPv6 w IPv4 co skomplikuje (zapewnienie niezmienności monitorowanych danych i ich integracji) i podwyŝszy koszt całego przedsięwzięcia Zamiast wymagane" zapisać zalecane"; NaleŜy doprecyzować o jaki protokół chodzi Proponujemy nowe brzmienie całego punktu, zgodne z obowiązującą specyfikacją LIHI na której wzorował się ustawodawca: LIID dla danego typu obiektu (MSISDN, IMEI itp.) zawiera tylko jedna usługę do monitorowania (jedna usługa per LIID). Jeśli obiekt będzie wymagał monitorowania kilku usług, system LEMF powinien za kaŝdym razem przydzielić nowe LIID. Z punktu widzenia uŝytkownika systemu LEMF nie powinno to przysparzać problemów z gromadzeniem treści róŝnych usług dla jednego monitorowanego obiektu". Format LI ID identyfikuje jednoznacznie uprawniony podmiot, co jest sprzeczne z wymaganiami ABW stawianymi przedsiębiorcom telekomunikacyjnym w procesie akredytacji systemów - zaimplementowanie dodatkowych mechanizmów anonimizacji LIID w sieci telekomunikacyjnej stanowi dodatkowy, zbędny koszt po stronie przedsiębiorców telekomunikacyjnych. Bezpodstawne nałoŝenie (przekroczenie delegacji ustawowej) na przedsiębiorcę telekomunikacyjnego nowego obowiązku buforowania (przechowywania przez 72 godziny i przetwarzania) treści kontrolowanych przekazów telekomunikacyjnych na wypadek wystąpienia awarii powodującej brak transmisji pomiędzy ADMF, a LEMF - sugeruje to, Ŝe systemy LEMF eksploatowane przez uprawnione podmioty z załoŝenia mają gorszą niezawodność niŝ sieć i systemy ADMF przedsiębiorcy telekomunikacyjnego, zatem obowiązek zapewnienia właściwego poziomu dostępności w systemach LEMF do udostępnionych treści przekazów telekomunikacyjnych przerzucony został na przedsiębiorców telekomunikacyjnych, co wpływa na znaczne podwyŝszenie kosztów ponoszonych przez tych przedsiębiorców, zaznaczyć naleŝy takŝe, Ŝe przedsiębiorca telekomunikacyjny ma prawo przechowywać treść przekazów telekomunikacyjnych jedynie na potrzeby świadczenia usług telekomunikacyjnych Rozporządzenie nakłada na przedsiębiorcę telekomunikacyjnego nowy obowiązek buforowania (przechowywania przez 72 godziny i przetwarzania) treści kontrolowanych przekazów telekomunikacyjnych na wypadek wystąpienia awarii powodującej brak transmisji 4

28 IV.2 pomiędzy ADMF a LEMF, budzi to zasadnicze wątpliwości prawne czy nie przekracza to zakresu delegacji ustawowej i czy operator telekomunikacyjny jest na podstawie ustawy uprawniony do zatrzymywania tych treści? moŝe to wskazywać takŝe na to, Ŝe obowiązek zapewnienia właściwego poziomu dostępności w systemach LEMF do udostępnionych treści przekazów telekomunikacyjnych przerzucony został na przedsiębiorców telekomunikacyjnych, co wpływa na znaczne podwyŝszenie kosztów ponoszonych przez tych przedsiębiorców, buforowanie winno być, co najwyŝej opcją dopuszczalna wyłącznie z przyczyn technicznych, ale dopuszczać stosowanie innych rozwiązań zabezpieczających Specyfikacja interfejsu HI1 została przygotowana przy współudziale części przedsiębiorców telekomunikacyjnych (wskazanych w uzasadnieniu projektu), co stawia ich i dostawców ich ADMF w uprzywilejowanej sytuacji, wpływając na podwyŝszenie kosztów budowy rozwiązania funkcjonalności LI u pozostałych przedsiębiorców telekomunikacyjnych 29 IV.2.2 TP Po lit. d naleŝy dodać lit. e - parametr okres monitorowania. 30 IV.2.3 IV.2.4 Zamiast obu punktów proponujemy umieszczenie tabeli (macierzy) pokazującej, jakie kryteria obserwacji (parametry) mogą wystąpić w kaŝdej z usług 31 IV.2.3.a TP NaleŜy dodać do zestawienia skrót VoIP 32 IV.2.4.c 33 IV.2.4.d 34 IV.2.5.a TP 35 IV.2.6 36 IV.2.9 37 TP 38 IV.2.10 Zamiast dostęp do internetu" powinno być zapisane usługi dostępu do internetu np.: wlan, dsl" Brak w 2.3 kryteriów monitorowania dla IMSa MoŜe istnieć problem w monitorowaniu IRI + SMS. Uzasadnienie: W sieci TP SMS jest inaczej przesyłany niŝ w sieciach operatorów mobilnych i moŝe istnieć moŝliwość ich monitorowania jedynie w trybie IRI + CC Punkt wewnętrznie sprzeczny skutkujący brakiem moŝliwości implementacji rozporządzenia w systemie operatora Brak technicznych moŝliwości realizacji takiego wymagania w systemie operatora. Dodatkowo zapis wykracza poza obowiązki określone w ustawie prawo telekomunikacyjne Wskazanie sposobu określenia zasięgu, jako przesłanie numerów central, nie ma sensu dla usług, których realizacja nie opiera się o centrale; naleŝy ten fragment wykreślić, chyba istotną informacją jest, kto w danym momencie nie moŝe być monitorowany a nie, który element sieci uległ awarii - a co z numerami przeniesionymi?. Ten punkt trzeba uściślić, czy chodzi o przypadki awarii sieci operatora czy elementów systemu monitoringu? Brak technicznej moŝliwości realizacji takiego wymagania w systemie operatora. Dodatkowo zapis wykracza poza obowiązki określone w ustawie prawo telekomunikacyjne 5

39 IV.2.12 40 IV.2.15 TP 41 IV.3.1 TP 42 IV.3.2 IV.3.4 43 IV.3.6 TP 44 IV.4.1 TP Zapis w obecnym kształcie stanowi bardzo powaŝne zagroŝenie bezpieczeństwa, w tym związane z ujawnieniem celu (obiektu monitorowanego) - naleŝy usunąć słowa włączenia/wyłączenia trybu online oraz" W przypadku kiedy warunki techniczne usługi nie zezwolą na monitorowanie jej przy uŝyciu interfejsu LI HI w trybie automatycznym, zgoda Uprawnionego Podmiotu na realizację jej w trybie półautomatycznym powinna zawierać ustalone timeouty dotyczące czasu realizacji, ustanowienia monitorowania, które będą obowiązywać wszystkie słuŝby. W związku z róŝnorodnością platform VoIP i systemów dostępu do Internetu /ATM, GBE/ wystąpi konieczność weryfikacji w niektórych przypadkach konfiguracji abonenta lub wykonania prac przygotowawczych. W związku z powyŝszym preferowany będzie w TP tryb półautomatyczny pracy interfejsu dla usług internetowych. TP proponuje w związku z powyŝszym zapisanie w rozporządzeniu lub załączniku, z którym Uprawnionym Podmiotem jedynym i wskazanym, operator będzie musiał uzgodnić szczegóły pracy w trybie półautomatycznym i które to uzgodnienia będą wiąŝące dla pozostałych Uprawnionych Podmiotów. Uzasadnienie: Zapis w punkcie 2.15 wskazuje, Ŝe kaŝdy Uprawniony Podmiot musi wyrazić zgodę na realizację w trybie półautomatycznym. W związku z tym dla operatora moŝliwe są dwa warianty: Uprawniony Podmiot godzi się na tryb półautomatyczny na warunkach (timeouty) operatora lub monitoring danej usługi jest realizowany w sposób tradycyjny. Uprawnione Podmioty/SłuŜby/ dysponują bardzo róŝnymi rozwiązaniami i platformami; jeŝeli więc operator będzie musiał uzgadniać ten tryb pracy kaŝdorazowo przed podpisaniem porozumienia z kaŝdym Uprawnionym Podmiotem oddzielnie to będzie to proces kosztowny, długotrwały, nieefektywny Czas na przesłanie danych skojarzonych z przekazem do 10 minut jest nie realny i nie jest do przyjęcia. TP proponuje czas do 24 godzin i doprecyzowanie pojęcia dane skojarzone lub ograniczenie ich do telefonii. Uzasadnienie: W TP rozmowy w technologii VoIP są bilingowane w systemie kolekcji danych, gdzie proces przetwarzania danych trwa do 8 godzin, a z kolei dane o sesji internetowej są on-line dostępne tylko w systemie Radius i w zasadzie niczego nie wnoszą poza tym, ze klient ma włączony modem i jest zalogowany do sieci. Systemy monitorowania ruchu internetowego w TP nie korzystają z Radiusa/systemu autentykacji/ lecz wykorzystują inne parametry jednoznacznie identyfikujące abonenta. Tak krótki czas nie ma takŝe uzasadnienia operacyjnego gdyŝ w naszej ocenie najwaŝniejsza jest treść danych obiektu monitorowanego a poniewaŝ dane są transferowane on-line to Uprawniony Podmiot ma moŝliwość uzyskania wszelkich danych poprzez analizę treści czy czasu rozpoczęcia czy zakończenia transferu danych poprzez interfejs HI3 Wskazany standard ETSI dotyczy tylko usług mobilnych; naleŝy sprawdzić, czy faktycznie wyłącznie dla usług mobilnych ma być realizowane to wymaganie. NaleŜy określić jakie są dopuszczalne wartości pola z nazwą rozszerzenia - ext W sieci TP tylko jeden z systemów (VoIP) koduje dane w systemie ASN.1, dla pozostałych systemów dane są pobierane ręcznie z systemów kolekcji naleŝy dopuścić za porozumieniem stosowanie formatu.txt, naleŝy uszczegółowić co to są dane skojarzone jeśli chodzi o dostęp do Internetu Zapis jest niejednoznaczny. Czy dotyczy całości treści sesji,czy pojedynczych ramek (w przypadku usług dostępu do internetu) czego przekazu 45 IV.4.3 Podział na online i offline ma tylko zastosowanie dla usług rozmów głosowych w sieciach mobilnych 6

46 IV.4.4 Wskazana norma nie dotyczy ULIC 47 Zamiast LI HI" powinno być HI A-B" 48 V.1.3 TP Dopisać IPv6 systemy SłuŜb muszą być gotowe na IPv6. 49 TP Bezwzględnie naleŝy uwzględnić IPv6 50 V.1.6 TP Dopuścić format.txt. ASN1 nie jest stosowany poza jednym systemem w TP, przebudowa systemów byłaby kosztowna. 51 1.2.2.1 52 1.2.2.4 53 1.2.2.5 54 1.2.2.12 55 56 1.3, 1.4, 1.5, 2 1.3, 1.4, 1.5, 2 57 str. 15 58 str. 22 NaleŜy usunąć zapis dot. RTRequest Załącznik nr 2 NaleŜy usunąć Dopuszcza się wysłanie zlecenia aktywacji z pewnym wyprzedzeniem", gdyŝ taki zapis jest sprzeczny z punktem 2.6 Zapis jest sprzeczny z punktem 2.8 Brak zdefiniowanych wymaganych minimalnych parametrów kryptograficznych - długości klucza, algorytmy. Załączone struktury ASN.1 są niepoprawne i nie kompilują się - np. UnsignedRequestDetail (specyfikacja ASN.1 dla UnsignedRequestDetail) - skutkuje to brakiem moŝliwości implementacji w systemie operatora, co z kolei będzie skutkować koniecznością wyłączenia interfejsu i powrotu do bezinterfejsowego" obsługiwania wniosków podmiotów uprawnionych. W strukturach ASN.1 usunięto komentarze, które są niezbędne do właściwego i jednoznacznego zaimplementowania w systemie operatora wymagań określonych w rozporządzeniu Brak określonego sposobu kodowania dla parametrów takich jak MSISDN, IMSI np. w UnsignedRequestDetail Umieszczony w strukturze ASN.1 Regon powinien być opcjonalny 7