DODATEČNÉ INFORMACE č. 3 K ZADÁVACÍM PODMÍNKÁM
DODATEČNÉ INFORMACE č. 3 K ZADÁVACÍM PODMÍNKÁM
v souladu s § 49 odst. 2) zákona č. 137/2006 Sb.,
o veřejných zakázkách, ve znění pozdějších předpisů (dále jen „zákon“)
Identifikace zadavatele: Česká republika – Ministerstvo financí
Xxxxxxxx 00
X.X.XXX 77
118 10 Praha 1
IČ: 00006947
Osoba oprávněná jednat za zadavatele: XXXx. Xxx. Xxxx Xxxxxxx
JUDr. Ing.
Digitálně podepsal XXXx. Xxx. Xxxx Xxxxxxx
Xxxx Xxxxxxx
DN: c=CZ, cn=XXXx. Xxx. Xxxx Xxxxxxx, o=Česká republika - Ministerstvo financí, ou=14820,
………………………………..
ou=Letenská 15, 118 10 PRAHA 1, ou=Ministerstvo financí, serialNumber=ICA - 10316340
Datum: 2014.05.20 12:47:09 +02'00'
Podpis:
V Praze dne: 20. května 2014
Název veřejné zakázky: | Poskytování datových komunikačních služeb pro potřeby resortu MF na období 2014+ |
Evidenční číslo veřejné zakázky: | VZ 480211 |
Druh zadávacího řízení: | Otevřené řízení |
Dotaz č. 1
Centrální zadavatel využil Přílohu č. 2 – Poptávané služby k definici koncových bodů služeb a specifikaci požadovaných technických parametrů těchto služeb. Dodavatel, ve snaze připravit kvalitní nabídku, zpracovává dodané informace a na jejich základě připravuje nákladový a cenový model. Při těchto přípravných činnostech dodavatel narazil na následující nesrovnalosti v definici poptávaných služeb, které znemožňují provedení kalkulací a stanovení nabídkové ceny některých služeb.
Otázka:
Dodavatel proto žádá centrálního zadavatele, aby upravil či doplnil zadání u následujících požadavků:
a. U služby s identifikací KIMFIDD_4011 poskytl kompletní seznam požadovaných vlastností služby, jmenovitě doplnil požadovanou úroveň pro QoS, Bezpečnost a Dostupnost služby.
b. U služby s identifikací KIMFIDD_3082 potvrdil nebo opravil adresní informace, kdy dodavatel zjistil, že definovanému RUIAN kódu odpovídá nikoli lokalita Mladá Boleslav, Průmyslová 829, ale lokalita Kosmonosy (okres Mladá Boleslav), Průmyslová 829.
c. U služby s identifikací KIMFIDD_3341 potvrdil nebo opravil adresní informace, kdy centrálním zadavatelem definovanému RUIAN kódu odpovídá adresa Nymburk, Xxxxxxxx xxxxx 000/00, nikoli uvedená adresa Nymburk, U Staré sladovny 470/15. Dle ruční kontroly dodavatele se jedná o rohovou budovu, ale pro správné stanovení nákladů a tudíž i ceny řešení dodavatel potřebuje znát přesnou adresní informaci a vyloučit případné chyby v ručních opravách adresních informací.
d. U služby s identifikací KIMFIDD_4021 poskytl přesné adresní informace, neboť v obci Dolní lomná se vyskytuje objekt s číslem evidenčním 120 i s číslem popisným 120. Z tohoto důvodu se jedná o nejednoznačné určení koncové lokality a dodavatel tak není schopen stanovit nákladovou strukturu připojení takové lokality. Objekty v obou uvedených umístěních jsou definovatelné RUIAN kódem, proto dodavatel
žádá, aby součástí opraveného zadání byl též RUIAN kód dané lokality a bylo tak možné předejít komplikacím s nejednoznačným určením lokalit.
e. U služby s identifikací KIMFIDD_3087 poskytl přesné adresní informace, neboť centrálním zadavatelem definovaný RUIAN kód odkazuje na adresu Říčany (okres Praha-východ), Strašín, K Babickým Hranicím, č. ev. 148 nikoli na centrálním zadavatelem definovanou adresu Říčany u Prahy, Nupaky 148. Dle ruční kontroly v mapovém software se jedná o dvě naprosto odlišné lokality a dodavatel tak není schopen určit, kterou z lokalit má centrální zadavatel na mysli.
f. U následujících služeb dodavatel dohledal další, zpřesňující adresní údaje nebo adresní úpravy korigoval a žádá tímto centrálního zadavatele, aby potvrdil, že skutečný stav požadavků odpovídá následujícím adresním definicím
i. KIMFIDD_3038: Doplněn údaj adresního místa (RUIAN 14260689). Dohledáno na základě uvedených adresních informací.
ii. KIMFIDD_3255: Doplněn údaj adresního místa (RUIAN 25701932). Dohledáno na základě uvedených adresních informací.
iii. KIMFIDD_4011: Doplněn údaj adresního místa (RUIAN 12428531). Dohledáno na základě uvedených adresních informací.
iv. KIMFIDD_4012: Doplněn údaj adresního místa (RUIAN 3184625). Dohledáno na základě uvedených adresních informací.
v. KIMFIDD_4014: Doplněn údaj adresního místa (RUIAN 23928085). Dohledáno na základě uvedených adresních informací.
vi. KIMFIDD_4015: Doplněn údaj adresního místa (RUIAN 23884967). Dohledáno na základě uvedených adresních informací.
vii. KIMFIDD_4016: Doplněn údaj adresního místa (RUIAN 19109024). Dohledáno na základě uvedených adresních informací.
viii. KIMFIDD_4017: Doplněn údaj adresního místa (RUIAN 25838890). Dohledáno na základě uvedených adresních informací.
ix. KIMFIDD_4018: Dle VDP ČUZK zjištěno, že ulice Kvítkova v napajedlech neexistuje a provedena oprava na ulici „Kvítkovická“. Na základě takto opraveného názvu ulice doplněn údaj adresního místa (RUIAN 4085451).
x. KIMFIDD_4019: Doplněn údaj adresního místa (RUIAN 26204924). Dohledáno na základě uvedených adresních informací. Dodavatel zde uvádí, že v České republice existují dvě obce Lípa. Jedna v okrese Havlíčkův Brod a druhá v okrese Zlín. Vzhledem ke skutečnosti, že dodavatel v obci Lípa v okrese Havlíčkův Brod nenalezl adresní místo s identifikací 276, dodavatel předpokládá, že centrální zadavatel má ve své poptávce na mysli lokalitu Lípa v okrese Zlín.
xi. KIMFIDD_4020: Doplněn údaj adresního místa (RUIAN 20689624). Dohledáno na základě uvedených adresních informací.
Odpověď č. 1
Ad a) Zadavatel doplňuje následující parametriku pro službu KIMFIDD_4011, která je obdobná ostatním službám pro koncového uživatele MF-GFŘ:
Typ služby: x Profily QoS: Profil 5 Bezpečnost: SEC0 Dostupnost: SLA2
Ad b) Lokalita je v tomto případě jednoznačně určena RUIAN kódem 25670026.
Ad c) Lokalita je v tomto případě jednoznačně určena RUIAN kódem 1234714. Jedná se o rohovou budovu a adresa je Xxxxxxxx xxxxx 000/00, Xxxxxxx.
Ad d) Jedná se o objekt Celní správy s jednoznačným RUIAN kódem 14096625, tedy objekt s e.č. 120 v obci Dolní Lomná.
Ad e) Správné určení RUIAN kódu dle sdělení Koncového uživatele je 25735411 s adresou Nupaky č.p. 148.
Ad f) Zadavatel potvrzuje zpřesňující informace Dodavatele a potvrzuje správnost těchto požadavků, které odpovídají adresním definicím i až xi.
Dotaz č. 2
Při vyhodnocování požadavků na zajištění bezpečnosti služby, dle variant parametru „Bezpečnost“, tedy SEC0, SEC1 a SEC2 dodavatel opět (stejně jako v předchozí soutěži) narazil na skutečnost, že v rámci poptávky jsou definovány i služby s požadavkem na zajištění bezpečnosti na úrovni SEC2, tedy dle definice
„Bezpečnost služby je rozšířena nasazením šifrování
- šifrování musí být nasazeno minimálně na dvou službách IP MPLS VPN, začleněných do téže VPN (musí být vytvořeny minimálně konec A a konec B)
- šifrování je zajištěno šifrováním AES-256“.
Již v rámci předcházející soutěže dodavatel vznesl dotaz, jehož cílem bylo získat od centrálního zadavatele podrobnější informace o tom, jak má být zajištěno end-to-end s fullmesh topologií při zachování soutěžení per jednotlivá služba a to v módu, kdy bude následně možné zajistit i provoz takovýchto služeb v „potenciálně multioperátorském prostředí“. Původní znění dotazu dodavatel přikládá:
V Odpovědi č. 7 Dodatečných informací č. 6 Centrální zadavatel uvádí "Komunikace bude probíhat jako fullmesh, viz předcházející dotaz, bodem A a bodem B jsou lokality zadavatele definované v příslušné tabulce (tj. např. šifrovaná komunikace může probíhat na VPN ÚZSVM mezi ÚP České Budějovice a OP Český Krumlov a zároveň mezi ÚP České Budějovice a OP Písek)". Centrální zadavatel v zadávací dokumentaci dále stanovil vyhodnocování pro každou lokalitu samostatně, což znamená, že existuje nezanedbatelná pravděpodobnost, že lokality VPN ÚZSVM budou připojeny více operátory. Vzhledem k výše uvedenému dodavatel postrádá definici koordinace mezi všemi zúčastněnými operátory, tedy nastavení systému tak, aby bylo možné nasadit šifrování v rámci VPN zajišťované více poskytovateli. Dále dodavatel upozorňuje, že při použití end-to-end šifrování je vždy vybudován tunel mezi dvěma koncovými lokalitami, což znamená, že pro vybudování fullmesh topologie by bylo zapotřebí n-1 tunelů, což znamená 2x(n-1) konfigurací. Vybudování fullmesh topologie je v multi-operátorském prostředí velice náročná akce, kdy největší potíže budou způsobeny při běžném provozu takové VPN sítě.
Skutečně Centrální zadavatel požaduje nasazení šifrování end-to-end s fullmesh topologií při zachování soutěžení per jednotlivá služba? Může centrální zadavatel definovat procesní rámec zajištění poptávané služby šifrování provozu?
Centrální zadavatel na základě dotazu dodavatele změnil zadávací dokumentaci tak, že pro všechny služby požadoval parametr „Bezpečnost“ na úrovni maximálně SEC1. Dodavatel přikládá odpověď centrálního zadavatele (konkrétně viz příloha této žádosti o dodatečné informace):
Centrální zadavatel požaduje v případě poptávky parametru SEC2 realizovat šifrované spojení v souladu s Katalogovým listem v modu fullmesh, a to buď v síti Poskytovatele anebo v případě podpory tohoto modelu s využitím nativních prostředků Interconnectu CMS.
S ohledem na tento dotaz změnil Pověřující centrální zadavatel ÚZSVM požadavek na úroveň parametru Bezpečnosti – SEC ze SEC2 na SEC1. Touto Dodatečnou informací se tak u všech lokalit mění hodnota Bezpečnost z SEC2 na SEC1.
Dodavatel je přesvědčen, že provozovat end-to-end šifrování pro VPN s fullmesh topologií v multioperátorském prostředí bez znalosti jasného provozního modelu není možné, respektive dodavateli v takovémto prostředí nejsou schopni stanovit náklady, spojené s provozem takových služeb a tedy ani stanovit nabídkové ceny. Dodavateli dále není patrné, z jakého důvodu centrální zadavatel nevyužil čas mezi ukončením předchozí soutěže a soutěže nové k tomu, aby všechny své požadavky zvážil a novou soutěž vypsal ve stavu, kdy budou jasně ošetřené minimálně oblasti, které se již v minulosti staly překážkou k transparentnímu průběhu soutěže.
Otázka:
Dodavatel tedy žádá centrálního zadavatele, aby opravil zadávací dokumentaci tak, aby poptávané služby bylo možné realizovat v potenciálně multioperátorském prostředí. Dále dodavatel žádá centrálního zadavatele, aby (vzhledem k nutnosti významných zásahů do zadávací dokumentace) prodloužil lhůtu na podání nabídek tak, aby dodavateli byli schopni správně reagovat na nové, upravené zadání.
Odpověď č. 2
Zadavatel je v požadavku na realizaci šifrování SEC2 konzistentní s odpovědí uváděnou Uchazečem. Tj. realizace full mesh šifrování bude realizována mininimálně v rámci předmětných lokalit sítě Poskytovatele, pokud full mesh není řešeno v provozním prostředí v rámci CMS. Pokud je bude full mesh šifrování řešeno v souladu se standardy CMS, které jsou veřejně dostupné a bližší informace je možné získat u provozovatele CMS případně věcného gestora CMS (Ministerstvo vnitra).
Realizace šifrování typu full mesh mezi lokalitami koncového uchazeče pouze v síti Poskytovatele bude považována za splnění daného požadavku, a to i za předpokladu, že komunikace v rámci CMS bude probíhat nešifrovaně (Zadavatel považuje CMS za důvěryhodný peeringový uzel). Splění tohoto požadavku, tj. realizace full mesh šifrování je běžnou službou poskytovanou provozovateli IP MPLS sítí a nedochází k rozšíření a ni úpravě zadávací dokumentace.
Dotaz č. 3
Centrální zadavatel při zpracovávání Zadávací dokumentace využil koncept vytvoření „katalogového listu“, který (jakožto Příloha č. 1 – Specifikace předmětu veřejné zakázky“) tvoří po technické stránce základní část zadávací dokumentace. Parametry, definované v Příloze č. 1 centrální zadavatel následně používá v Příloze č. 2 – Poptávané služby. V Příloze č. 2 ovšem centrální zadavatel, z dodavateli neznámého důvodu, nedodržel jím nadefinované parametry služeb a v parametru služby kapacita požaduje u patnácti služeb kapacitu 32 Mbit/s a u jedné pak kapacitu 64 Mbit/s, které ovšem v katalogovém listu definovány nejsou. Dodavatel uvádí, že po technické stránce je samozřejmě možné nakonfigurovat službu jak s kapacitou 32, tak 64 Mbit/s, ale
a) toto zadání je v rozporu s centrálním zadavatelem definovanými parametry služeb dle Přílohy č. 1 a
b) takovéto tříštění kapacit a definování zbytečně širokého spektra kapacitních profilů je zbytečné, neboť zbytečně komplikuje provozní model a centrální zadavateli nepřinese žádné úspory, neboť pro zajištění služby s přenosovou kapacitou 32 Mbit/s (dle specifikace v Příloze č. 2) a kapacitou 35 Mbit/s (nejbližší vyšší kapacitou dle definice v Příloze č. 1) je nutné použít shodné technologie, což znamená dosáhnout shodných nákladů a tedy i cen. Stejné pravidlo platí i pro kapacitu 64 Mbit/s vs. 70 Mbit/s.
Otázka:
Dodavatel žádá centrálního zadavatele, aby upravil Přílohu č. 1 nebo Přílohu č. 2 tak, aby zadávací dokumentace nebyla ve vzájemném rozporu (dodavatel doporučuje úpravu Přílohy č. 2 do souladu s Přílohou č. 1). Zároveň dodavatel žádá, aby centrální zadavatel odpovídajícím způsobem prodloužil lhůtu pro podání nabídek, jelikož provedené korekce Zadávací dokumentace ovlivní podmínky pro přípravu nabídek.
Odpověď č. 3
Stanovené kapacity v katalogovém listu jsou z pohledu technického i ekonomického arbitrární a byly stanoveny v rámci Katalogových listů KIVS. Stanovení jiné a přitom analogické kapacity, která je bližší prostředí ICT, nemá dopad na okruh uchazečů ani na cenotvorbu. Stanovená kapacita je jednoznačná z pohledu poptávky. Poptávaná kapacita vychází z reálných požadavků zadavatele interpolovaná o časový horizont až 48 měsíců, který je přítomen v záměru zadavatele pro uzavření smlouvy na dobu neurčitou.
Pro kapacity 32 Mbit/s platí, že se jedná o Symetrické neagregované připojení s kapacitou 32 Mbit/s s Dostupnými všemi QoS profily.
Pro kapacity 64 Mbit/s platí, že se jedná o Symetrické neagregované připojení s kapacitou 64 Mbit/s s Dostupnými všemi QoS profily.
Dále je možné uvést, že stanovení jiné než katalogové kapacity má historické kořeny v tvorbě a konstrukci katalogových listů a poptávek v rámci KIVS a formálně byla jiná kapacita součtem v katalogovém listu nižších kapacit.
Dotaz č. 4
Centrální zadavatel v rámci podmínek veřejné zakázky požaduje soupis provozních a technických zařízení, která budou zajišťovat připojení do CMS (viz str. 8 zadávací dokumentace, poslední odstavec).
Centrální zadavatel rovněž píše, že způsob a postup připojení je dostupný u MV ČR a zavazuje se, že uloží veřejný standard pro připojení do CMS v příslušné části nástroje E-ZAK. Přes pečlivou kontrolu však dodavatel v nástroji E-ZAK avizované dokumenty nemůže nalézt.
Uvedené dokumenty jsou pro určitou část plnění veřejné zakázky klíčové. S ohledem na jejich důležitost je též nanejvýše vhodné, aby je obdrželi všichni zájemci o zadávanou veřejnou zakázku ve shodné podobě a cestou od centrálního zadavatele. Žádám tedy centrálního dodavatele o jejich vložení do nástroje E-ZAK.
Odpověď č. 4
Veškeré dokumenty jsou veřejně přístupné. V aktuálním znění jsou k dispozici u provozovatele CMS. Zadavatele tyto dokumenty vloží do E-ZAK, ale konkrétní technické řešení je věcí jednání mezi Uchazečem a provozovatelem CMS a Zadavatel respektuje tuto oboustrannou dohodu/smlouvu bez ohledu na konkrétní technické specifikace. Zadavatel poskytne veškerou nutnou součinnosti pro připojení uchazečů do CMS před podpisem Smlouvy.
Dotaz č. 5:
S ohledem na uplatněné žádosti o dodatečné informace žádá dodavatel o prodloužení lhůty pro podání nabídek a to alespoň o 14 kalendářních dnů.
Odpověď č. 5
Veškeré odpovědi Zadavatele mají s ohledem na jejich předmět pouze vysvětlující charakter a nemají dopad na znění Zadávací dokumentace.
Standard pro připojení do CMS
Pro připojení poskytovatele služeb KIVS (dále jen Operátor) k infrastruktuře CMS – Interconnect je nezbytné splnění podmínek uvedených v jednotlivých částech tomto dokumentu.
Definice rozhraní mezi CMS a Operátorem
Každý Operátor jako poskytovatel datového připojení komunikační infrastruktury veřejné správy poskytující nebo mající zájem poskytovat služby veřejné správě cestou Centrálního místa služeb (dále jen CMS) musí svým zákazníkům na své náklady umožnit kromě poskytování samotné komunikační infrastruktury mezi jednotlivými uzly subjektu i připojení k datovým zdrojům a službám dostupným pro všechny orgány veřejné moci v prostředí Centrálního místa služeb. K připojení Operátora k CMS slouží jeho moduly, tzv. Interconnect. Pravidla definující podmínky a způsob připojení Operátora k modulům Interconnect jsou následující:
1. Redundantní připojení dvěma nezávislými spoji do lokalit s instalovanými moduly Interconnect CMS, viz obrázek:
Lokality se směrovači Interconnect.
Lokalita | Adresa |
IC-1 | Olšanská 4, Praha 3 |
IC-2 | HC Nagano, K červenému dvoru 25, Praha 3 |
2. Rozhraní mezi směrovačem Interconnect CMS a Operátorem bude realizováno spojem na bázi technologií Gigabit Ethernet (IEEE802.3z, příp. IEEE802.3ab). nebo 10Gigabit Ethernet (IEEE802.3ae). Rozhraní musí podporovat tagování VLAN dle 802.1Q, jednotlivé VPN budou předávány formou jednotlivých VLAN.
3. Fyzické rozhraní využívá optickou trasu
4. Propojení Operátora a směrovačů Interconnect předpokládá využití technologie MPLS VPN na straně Operátora i CMS, propojení je pak realizováno dle RFC4364 odstavec 10a (Simple IP Interconnect). xxxx://xxxxxxxxxxx.xxxx.xxx/xxx/xxx0000/
5. Směrovací informace mezi propojovací sítí CMS a jednotlivými Operátory jsou předávány pomocí směrovacího protokolu eBGP-4 - dle RFC 4271. xxxx://xxxxxxxxxxx.xxxx.xxx/xxx/xxx0000/
6. Adresní rozsahy IPv4 spojnic KIVS spravuje, koordinuje a operátorovi přiděluje provozovatel CMS - Česká pošta, s.p., Odštěpný závod ICT služby (dále jen Provozovatel CMS).
7. Adresní rozsahy IPv6 spojnic KIVS spravuje, koordinuje a operátorovi přiděluje Provozovatel CMS. O tyto rozsahy je možné požádat až po upgrade CMS na verzi 2.0.
8. Infrastruktura Operátora musí v případě potřeby umožnit Provozovateli CMS sběr a vyhodnocování provozních statistik KIVS a poskytnout jeho dohledovému systému informace na bázi SNMP, syslog a Netflow.
Další provozní podmínky zřízení služby přístupu k Interconnectu CMS
Pro připojení Operátora do CMS, které je dislokováno v objektu Ministerstva vnitra Xxxxxxxx 0, Xxxxx 0 a v objektu hostingového centra Nagano společnosti Telefónica Czech Republic, K Xxxxxxxxx xxxxx 0000/00, Xxxxx 0, musí být splněny následující podmínky:
1. Operátor na vlastní náklady zpracuje realizační projekt (dále jen RP) konektivity. RP musí být zpracován jak v případě zajištění konektivity vlastním kabelem Operátora tak i v případě pronájmu lambd od jiných Operátorů. RP musí obsahovat textovou a výkresovou část řešící konektivitu do Interconnectu CMS včetně souhlasu Ministerstva vnitra případně i vlastníka objektu (v případě HC Nagano) s uložením v kabelovodu, průběhem trasy v objektu, zakončením optického kabelu v technologické místnosti - alokace místa ve stojanu pro zakončení optického kabelu případně umístění nového stojanu.
Osnova projektu :
Realizační projekt stavby
Název akce: Napojení xxxxxxx Xxxxxxxx 0, XX Nagano
Místo stavby: Praha Investor:
Dodavatel:
Technická zpráva musí minimálně obsahovat:
- Profil a typ optického kabelu, optické konektory
- Instalace a montáž optického kabelu
- Optické spojky:
- Trasa a ukončení optického kabelu
- Způsob nakládání s odpady
- Vliv stavby na životní prostředí:
- Bezpečnost práce a protipožární ochrana
- Užívání veřejného prostranství
- Řešení autorského dozoru
- Dokumentace návrhu řešení
2. RP musí být schválen Ministerstvem vnitra. Provozovatel CMS zpracuje stanovisko k těmto RP.
3. Ukončení kabelů zajistí na vlastní náklady operátor ve vlastních optických patch panelech max. 2U.
4. Operátor dodá optické patch cordy dle konektorů v propojovací místnosti (na straně MV konektor LC) stejně tak patch cord pro konektivitu do CMS (LC-LC).
5. Operátor se dále zavazuje dodat SFP (příp. GBiC) dle specifikace Provozovatele CMS.
6. Operátor garantuje funkčnost celé trasy až po cílový SFP modul v Interconnectu CMS.
7. Konfigurace IP konektivity a autonomního systému operátora na rozhraní k CMS; tj. BGP peering, bude prováděna dle specifikace Provozovatele CMS.
8. Operátor garantuje schopnost upgrade připojení k CMS z 1 Gbit/s na 10 Gbit/s do dvou kalendářních měsíců od odeslání žádosti o upgrade ze strany MV.
9. Operátor se zavazuje do CMS propagovat pouze routy specifikované Provozovatelem CMS a na své straně neprovádět PAT adres subjektů, kteří nejsou uživateli služeb CMS tj. zabránit přístupu ke službám CMS neoprávněným osobám.
10. Požadavky na zřízení, změny a zrušení služeb spojených s konektivitou do CMS předkládá koncový subjekt KIVS připojený přes operátora standardní cestou na Ministerstvo vnitra prostřednictvím technické specifikace (dále jen TS), a to v rozsahu aktuálně platného katalogu služeb CMS.
11. Operátor bere na vědomí a souhlasí, že služba Interconnect CMS se nepovažuje za nedostupnou, pokud je nedostupnost způsobena okolnostmi vylučujícími odpovědnost nebo z důvodu neplnění podmínek dle těchto provozních podmínek ze strany operátora KIVS. Za okolnost vylučující odpovědnost se kromě okolností dle obecné právní úpravy považuje také vyhlášení mimořádného nebo výjimečného stavu nebo požadavek Ministerstva vnitra ČR na omezení nebo dočasné zrušení přístupu k CMS z důvodu ohrožení bezpečnosti.
12. Operátor se dále zavazuje provádět ochranu před útoky DDoS a ostatními známými hrozbami ze svých sítí (např. monitoringem poskytovaných služeb).
13. V případě, že k takovému útoku dojde, je Provozovatel CMS oprávněn odpojit bez náhrady Operátora od systému CMS do doby odstranění bezpečností hrozby, která vznikla na straně tohoto Operátora. V takovémto případě je odpovědnost na straně Operátora a případné smluvní pokuty za nedodržení SLA a ostatní vícenáklady na straně Provozovatele CMS i koncových uživatelů hradí Operátor.
14. Požadavky na změnu operátorského rozhraní/prostředí předkládá Operátor Provozovateli CMS včetně souhlasu subjektů KIVS, kteří jsou jeho přípojkami do CMS připojeni a souhlasu odpovědného zástupce MV. Požadavek je zadán 3 měsíce před požadovanou změnou.
15. Informace o plánovaném provozním výpadku poskytované služby musí Operátor prokazatelně doručit na odpovědné pracoviště MV - HelpDesk MV (dále jen HD MV) a to minimálně 30 dní před plánovaným výpadkem.
16. Informace o závadách, výpadcích a chybovosti služby je Operátor povinen neprodleně informovat HD MV spravovaný Provozovatelem CMS. Kontaktní údaje: mail xxxxxx@xxxx.xx nebo xxxxxxxx.xx@xxxxx.xx, telefon 000 000 000.
17. Operátor musí poskytovat službu HelpDesk/ServiceDesk (dále jen HD/SD) a to s dostupností 24x7.
18. Veškerá komunikace spojená s odstraňováním poruch, výpadky a chybovostí služeb musí být realizována prostřednictvím HD MV a HD/SD Operátora.
19. Operátor musí definovat rozhraní loopback pro ověření konektivity na své straně.
20. Do prostředí CMS není Operátorovi poskytován dálkový přístup a to ani pro ověření konektivity.
Kontaktní osoby pro spolupráci s Operátory:
Za ČP s.p., Xxx. Xxxxxxxx Xxxx tel. 000 000 000, 000 000 000 xxxxxxxx.xxxx@xxxxx.xx
Za MV XXXx. Xxxxx Xxxxxx xxx. 000 000 000, 000 000 000 xxxxx@xxxx.xx Za správu objektů MV: Xxx. Xxxxxxxx Xxxx, Zařízení služeb MV, tel. 000 000 000
Žádost o připojení k CMS – IC
Uchazeč vyplňuje pouze silně orámovaná pole
Služba CMS | „Připojení k CMS – IC“ | |
Název uchazeče |
| zřízení služby |
Identifikační údaje uchazeče | změna služby |
Přidělené číslo požadavku zrušení služby
Interní identifikace uchazeče
Popis PE routeru uchazeče (uveďte výrobce, typ a verzi operačního systému)
Popis optické trasy – Xxxxxxxx 0, Xxxxx
Vložte odkaz na soubor
Popis optické trasy – HC Nagano, Praha
Vložte odkaz na soubor
Příloha – grafické znázornění optických tras
Vložte odkaz na soubor
Příloha – realizační projekt Xxxxxxxx 0, Xxxxx
Vložte odkaz na soubor
Příloha – realizační projekt HC Nagano, Praha
Vložte odkaz na soubor
Potvrzení žádosti
Zástupce uchazeče:
Xxxxx a příjmení osoby:
....................................................................................................................................................………........….....
Organizace nebo firma a funkce:
..........................................................................................................................................………...................
Adresa organizace nebo firmy:
.............................................................................................................................................………............. Telefon: ................................... .................. E-mail: ……...……………………………………...
Žádost o připojení k CMS – IC byla předána .
V ................................. Dne ................................. Podpis
.................................
Zástupce zřizovatele:
Xxxxx a příjmení osoby:
....................................................................................................................................................………........….....
Organizace nebo firma a funkce:
..........................................................................................................................................………...................
Adresa organizace nebo firmy:
.............................................................................................................................................………................... Telefon: ................................... .................. E-mail: ……...……………………………………...
Žádost připojení k CMS – IC byla převzata zřizovatelem.
V ................................. Dne ................................. Podpis
.................................