Decizie CNSC 52/2021

CONSILIUL NAȚIONAL DE SOLUȚIONARE A CONTESTAȚIILOR C. N. S. C. Str. Stavropoleos nr.6, Sectorul 3, București, România, CP 030084, CIF 20329980 Tel. +4 021 3104641 Fax. +4 021 3104642 Fax. +4 021 8900745 www.cnsc.ro În conformitate cu prevederile art. 12 alin. (1) și ale art. 27 alin. (1) din Legea nr. 101/2016 privind remediile și căile de atac în materie de atribuire a contractelor de achiziție publică, a contractelor sectoriale și a contractelor de concesiune de lucrări și concesiune de servicii, precum și pentru organizarea și funcționarea Consiliului Național de Soluționare a Contestațiilor, Consiliul adoptă următoarea DECIZIE Nr. 52/C7/2716 Data: 11.01.2021 Prin contestația înregistrată la Consiliul National de Soluționare a Contestațiilor cu nr. 53319/04.12.2020, formulată de către S.C. TELEKOM ROMANIA COMMUNICATIONS S.A., cu sediul în București, P-ta Presei Libere nr. 3-5, Clădirea City Gate, Turnul de Nord, et. 7-18, sector 1, înmatriculată la Oficiul Registrului Comerțului sub nr. J40/8926/1997, având CUI 427320, împotriva rezultatului licitației publice organizată de către MINISTERUL APĂRĂRII – UNITATEA MILITARĂ 02415 BUCUREȘTI, cu sediul în București, Str. Drumul Taberei nr. 7-9, sector 6, în cadrul procedurii de licitație deschisă, împărțită pe loturi, în vederea încheierii acordului-cadru de furnizare având ca obiect ”Acord cadru de furnizare Switchuri diverse tipuri – 6 loturi”, pentru Lotul nr. 2 ” Switch 24 porturi FO”, se solicită suspendarea procedurii până la soluționarea definitivă a contestației, anularea raportului procedurii, a comunicării privind rezultatul procedurii, precum și a tuturor actelor ce au stat la baza comunicărilor rezultatului procedurii, obligarea autorității contractante la reluarea procedurii de atribuire în sensul reevaluării ofertelor clasate pe locurile 1 și 2, cu consecința stabilirii caracterului inacceptabil și neconform al acestora și declararea ofertei sale ca fiind câștigătoare. Asupra capătului de cerere privind suspendarea procedurii, Consiliul s-a pronunțat prin încheiere. Procedura de soluționare în fața Consiliului s-a desfășurat în scris. CONSILIUL NAŢIONAL DE SOLUŢIONARE A CONTESTAŢIILOR, asupra cauzei de faţă, constată următoarele: ........................................................................................... 1

Pentru aceste motive, în baza legii și a mijloacelor de probă aflate la dosar, CONSILIUL DECIDE: Admite, în parte, contestația formulată de către S.C. TELEKOM ROMANIA COMMUNICATIONS S.A., cu sediul în București, P-ta Presei Libere nr. 3-5, Clădirea City Gate, Turnul de Nord, et. 7-18, sector 1, în contradictoriu cu MINISTERUL APĂRĂRII – UNITATEA MILITARĂ 02415 BUCUREȘTI, cu sediul în București, Str. Drumul Taberei nr. 7-9, sector 6. Anulează, în parte, procesul verbal de evaluare a conformității propunerilor tehnice cu prevederile caietului de sarcini și, după caz, cu factorii de evaluare, înregistrat cu nr. A-9495/08.10.2020, raportul procedurii nr. A-11110/23.11.2020 și actele subsecvente acestuia, respectiv mențiunile referitoare la ofertele prezentate de S.C. UNIVERSAL CARD SYSTEM S.A. și S.C. MARCTEL S.I.T. S.R.L. pentru lotul 2. Anulează procesele verbale de evaluare a propunerilor financiare, înregistrate cu nr. A-10507/05.11.2020 și A-10791/12.11.2020. Anulează, în parte, procesul verbal al ședinței de verificare a documentelor suport/dovezilor aferente celor declarate în DUAE, înregistrat cu nr. A-11078/20.11.2020, respectiv a mențiunilor referitoare la lotul 2. Anulează, în parte, raportul procedurii nr. A-11110/23.11.2020 și actele subsecvente acestuia, respectiv a mențiunilor referitoare la ofertele prezentate de S.C. UNIVERSAL CARD SYSTEM S.A. și S.C. MARCTEL S.I.T. S.R.L. pentru lotul 2. Obligă MINISTERUL APĂRĂRII – UNITATEA MILITARĂ 02415 BUCUREȘTI ca, în termen de 10 zile de la primirea prezentei, să procedeze la reanalizarea propunerilor tehnice prezentate de S.C. UNIVERSAL CARD SYSTEM S.A. și S.C. MARCTEL S.I.T. S.R.L. pentru lotul 2, cu luarea în considerare a celor precizate în motivare. Respinge, ca inadmisibilă, solicitarea S.C. TELEKOM ROMANIA COMMUNICATIONS S.A. de obligare a MINISTERULUI APĂRĂRII – UNITATEA MILITARĂ 02415 BUCUREȘTI la declararea ofertei sale ca fiind câștigătoare a lotului 2. Prezenta decizie este obligatorie pentru părți. Împotriva prezentei decizii se poate formula plângere, în termen de 10 zile de la comunicare pentru părțile cauzei, respectiv de la data luării la cunoștință de către alte persoane vătămate. 2

CONSILIUL NAȚIONAL DE SOLUȚIONARE A CONTESTAȚIILOR C. N. S. C. Str. Stavropoleos nr.6, Sectorul 3, București, România, CP 030084, CIF 20329980 Tel. +4 021 3104641 Fax. +4 021 3104642 Fax. +4 021 8900745 www.cnsc.ro În conformitate cu prevederile art. 12 alin. (1) și ale art. 27 alin. (1) din Legea nr. 101/2016 privind remediile și căile de atac în materie de atribuire a contractelor de achiziție publică, a contractelor sectoriale și a contractelor de concesiune de lucrări și concesiune de servicii, precum și pentru organizarea și funcționarea Consiliului Național de Soluționare a Contestațiilor, Consiliul adoptă următoarea DECIZIE Nr. ... Data: ... Prin contestația înregistrată la Consiliul National de Soluționare a Contestațiilor cu nr. 53319/04.12.2020, formulată de către ..., cu sediul în ..., înmatriculată la Oficiul Registrului Comerțului sub nr. ...., având CUI ....., împotriva rezultatului licitației publice organizată de către ..., cu sediul în ..., în cadrul procedurii de licitație deschisă, împărțită pe loturi, în vederea încheierii acordului-cadru de furnizare având ca obiect ”Acord cadru de furnizare Switchuri diverse tipuri – 6 loturi”, pentru Lotul nr. 2 ” Switch 24 porturi FO”, se solicită suspendarea procedurii până la soluționarea definitivă a contestației, anularea raportului procedurii, a comunicării privind rezultatul procedurii, precum și a tuturor actelor ce au stat la baza comunicărilor rezultatului procedurii, obligarea autorității contractante la reluarea procedurii de atribuire în sensul reevaluării ofertelor clasate pe locurile 1 și 2, cu consecința stabilirii caracterului inacceptabil și neconform al acestora și declararea ofertei sale ca fiind câștigătoare. Asupra capătului de cerere privind suspendarea procedurii, Consiliul s-a pronunțat prin încheiere. Procedura de soluționare în fața Consiliului s-a desfășurat în scris. CONSILIUL NAŢIONAL DE SOLUŢIONARE A CONTESTAŢIILOR, asupra cauzei de faţă, constată următoarele: Consiliul a fost legal sesizat și este competent, potrivit dispozițiilor art. 12 alin. (1) din Legea nr. 101/2016, să soluționeze contestația de faţă, prin care ..., critică rezultatul procedurii, solicitând anularea raportului procedurii, a comunicării privind rezultatul procedurii, precum 1

și a tuturor actelor ce au stat la baza comunicărilor rezultatului procedurii, obligarea autorității contractante la reluarea procedurii de atribuire în sensul reevaluării ofertelor clasate pe locurile 1 și 2, cu consecința stabilirii caracterului inacceptabil și neconform al acestora și declararea ofertei sale ca fiind câștigătoare. Prin contestația înregistrată la Consiliul National de Soluționare a Contestațiilor cu nr. 53319/04.12.2020, formulată de către ..., critică rezultatul

procedurii

antemenționată,

în

sensul

evaluării necorespunzătoare de către comisia de evaluare a ofertelor clasate pe locurile 1 și 2, respectiv oferta depusă de către ..., care a totalizat 100 puncte și oferta depusă de către ..., solicitând reevaluarea acestora, considerând că acestea sunt neconforme și declararea ofertei sale, clasată pe locul 3 cu un punctaj de 29,55 puncte, ca fiind câștigătoare, având în vedere motivele ce urmează a fi expuse. Invocând prevederile Art.215 alin(5) din Legea nr. 98/2016 și art. 137 alin.(3) lit.a) din HG nr. 395/2016, contestatorul susține că oferta ... nu satisface o multitudine din cerințele caietului de sarcini prevăzute în specificațiile tehnice, Anexa 2 la acesta, astfel: a) În cadrul cerinței 3.2.4. - Cerințe specifice - Cerința C13 subpunctul d) - protocolul propus de ofertant - VRRP -, ca echivalent la protocolul indicat de autoritate și anume HSRP, nu este compatibil cu protocolul cerut de autoritate. b) În cadrul cerinței 3.2.4. - Cerințe specifice - Cerința C14 subpunctul b) - printre protocoale de rutare dinamica a traficului IPv4 indicate de autoritate se numără și EIGRP- Stub, protocol care nu este suportat pe echipamentul Juniper EX4300-32F propus de ..., acest lucru fiind indicat chiar de ofertant prin neadăugarea acestuia în matricea de conformitate. c) În cadrul cerinței 3.2.4. - Cerințe specifice - Cerința C14 subpunctul c) - pentru suport pentru protocoale de rutare dinamică a traficului IPv4 se numără și protocoalele EIGRP, protocol care nu este suportat pe echipamentul Juniper EX4300-32F propus de ..., acest lucru fiind indicat chiar de ofertant prin ne-adăugarea acestuia în matricea de conformitate și DVMRP - protocol care a fost scos din lista suportata de Junos OS (sistemul de operare de pe echipamentul Juniper EX4300-32F) începând cu versiunea 16.1 (la momentul ofertării ultima versiune disponibila fiind Junos OS 20.1), versiune care la data ofertării nu mai era suportată de către Juniper după cum se poate observa pe site-ul oficial Juniper: https://support.iuniper. net/support/eol/software/junos/#7

. d) În cadrul cerinței 3.2.4. - Cerințe specifice - Cerința C14 subpunctul d) - pentru suport pentru rutare IPv6 și protocoale de rutare dinamică a traficului IPv6 se numără și protocolul EIGRP, protocol care nu este suportat pe echipamentul Juniper EX4300-32F propus de ..., acest lucru fiind indicat chiar de ofertant prin neadăugarea acestuia în matricea de conformitate. e) În cadrul cerinței 3.2.8. - Cerințe mecano-climatice - Cerința C28 nu este îndeplinită nici pentru punctul a nici pentru punctul b, 2

ofertantul punând la dispoziție doar un document de la producător prin care se specifică faptul că echipamentul ofertat a fost ținut la o umiditate și o temperatura în conformitate cu cerințele autorității contractante (test care a fost făcut special pentru aceasta procedura) fără însă a confirma faptul că echipamentul a funcționat. De altfel în broșura tehnică a echipamentului care a fost anexată ofertei se specifică foarte clar intervalele în care echipamentul a fost testat și funcționează: - Temperatura de operare: 0°C^+45°C și nu -5°C^+45°C Umiditate (operare): 10 -r 85%; - fără condensare și nu 10 -r 95%. f) În cadrul cerinței 3.5 - Cerințe privind garanția produsului - Cerința C35. - Ofertantul a propus un support de tip basic partner support cu codul de produs PA5-SUP-EX4300SITE - PSS Basic Support for 5 Year Prepaid NETWORK LICENSE for EX4300 48T/48P/32F) acest suport fiind de tip basic care nu garantează înlocuirea echipamentului defect în 48 de ore în conformitate cu cerința mai sus menționată după cum se poate vedea și pe pagina producătorului: https://www.juniper. net/assets/us/en/local/pdf/datasheets/1000333-en.pdf. Nerespectarea acestor cerințe esențiale din cadrul caietului de sarcini face produsul ofertat de către ... incompatibil cu infrastructura de rețea a autorității contractante, neasigurând astfel interoperabilitatea cu sistemul în care produsul trebuie integrat. În același timp, ofertantul nu a demonstrat în cadrul ofertei că produsul propus îndeplinește într-un mod echivalent cerințele funcționale definite prin specificațiile tehnice, astfel cum rezultă în mod necesar din interpretarea art. 156 alin. 4 din legea nr. 98/2016, motiv pentru care oferta acestuia trebuia respinsă ca neconformă. Invocând prevederile art. 215 alin.(5) din Legea nr. 98/2016 și prevederile art. 137 alin.(3) lit.a) din HG nr. 395/2016, contestatorul susține că și oferta ... nu satisface o multitudine din cerințele caietului de sarcini prevăzute în specificațiile tehnice, Anexa 2 la acesta, astfel: a) În cadrul cerinței 3.2.3. - Cerințe privind interfețele - Cerința C9 - Autoritatea cere 24 de SFP uri de tip FX, SFP-uri reconfirmate și în clarificarea A3532 din 14.04.2020 în timp ce ofertantul a propus SFP-uri de tip SX, modelul propus nefiind echivalent și compatibil cu cel propus de autoritate, ci reprezentând alt standard; b) În cadrul cerinței 3.2.3. - Cerințe privind interfețele - Cerința C11 - Autoritatea cere 24 de cabluri de fibra optica de tip OM1 - conform clarificării A3532 din 14.04.2020, dar ofertantul ... a prezentat în oferta sa doar 24 de cabluri, neoferind astfel cantitatea cerută de autoritate; c) În cadrul cerinței 3.2.4. - Cerințe specifice - Cerința C14 subpunctul c - pentru suport pentru protocoale de rutare dinamică a traficului IPv4 se numără și protocoalele: i. EIGRP - protocol care nu este suportat pe echipamentul Allied Telesis X930-28GSTX propus de ..., ofertantul indicând ca echivalență protocolul OSPF-Stub, protocol care este, de altfel și el cerut de autoritate

și

care

nu

este

echivalent

funcțional: 3

https://community.cisco.com/t5/routing/difference-b-w-stub-in-ospf- and-eigrp/td-p/690403 ii. DVMRP - care nu are ca echivalență funcțională IGMP Proxy și static multitasking route, după cum o indică și literatura de specialitate: https://docs.oracle.com/cd/E19859-01/820-3252-

11/FP44ucgIGMP Proxy.html. d) În cadrul cerinței 3.5 - Cerințe privind garanția produsului - Cerința C35. - Ofertantul a propus un support de tip NetCover Preferred Support cu codul de produs AT-X930- 28GSTX-SYNCP5 acest suport nu garantează înlocuirea echipamentului defect în 48 de ore în conformitate cu cerința mai sus menționată după cum se poate vedea și pe pagina producătorului: https://www.alliedtelesis.com/en/services/netcover, în fapt nici un suport oferit de producător nu garantează înlocuirea echipamentului defect în 48 de ore ci, în cel mai bun caz, în variantele de support Advanced și Elite, doar expedierea către clientul final în următoare zi lucrătoare a produsului înlocuitor „Next business day shipment for advanced hardware replacement". Nerespectarea acestor cerințe esențiale din cadrul caietului de sarcini face produsul ofertat de către ... incompatibil cu infrastructura de rețea a autorității contractante, neasigurând astfel interoperabilitatea cu sistemul în care produsul trebuie integrat, precizează contestatorul. În același timp, ofertantul nu a demonstrat în cadrul ofertei că produsul propus îndeplinește într-un mod echivalent cerințele funcționale definite prin specificațiile tehnice, astfel cum rezultă în mod necesar din interpretarea art. 156 alin. (4) din legea nr. 98/2016, motiv pentru care oferta acestuia trebuia respinsă ca neconformă. Pentru toate motivele anterior expuse, ... solicită admiterea contestației astfel cum a fost formulată. Prin adresa cu nr. A11759/14.12.2020, înregistrată la C.N.S.C. cu nr. 55153/14.12.2020, autoritatea contractantă ... a formulat punct de vedere asupra contestației formulată de ..., prezentând structurat considerentele sale la criticile aduse de contestator, după cum urmează: În ce privește oferta ... constând în echipamentul Juniper EX4300- 32F, autoritatea contractantă susține: 1. Referitor cerinței ”3.2.4./C13 d. Switch-ul trebuie să asigure suport pentru protocoale de asigurare a disponibilității ridicate la nivel de legătură rețea: d. Hot Standby Router Protocol (HSRP)”, Echipamentul ofertat dispune de suport pentru protocoalele: d. Echipamentul îndeplinește cerința prin folosirea protocolului alternativ VRRP. Legat de critica contestatorului: ” Protocolul propus de ofertant - VRRP - ca echivalent la protocolul indicat de autoritate și anume HRSP, nu este compatibil cu protocolul cerut de autoritate”, autoritatea contractantă precizează că HRSP este un protocol proprietar CISCO (RFC 2281), iar VRRP este un protocol standard IEEE (RFC 3768). Diferența între cele două protocoale este că HRSP folosește UDP pentru comunicație între echipamente, iar VRRP folosește TCP. Nu este afectată funcționalitatea rețelei. Protocoalele sunt echivalente. 4

2. Referitor cerinței: ” 3.2.4./C14 b. Switch-ul trebuie să ofere următoarele facilitați de rutare IP: b). protocoale de rutare dinamică a traficului IPv4: RIPvl, RIPv2, EIGRP-Stub și OSPF”, se susține că echipamentul oferă suport pentru: b. RIP vl/v2 și OSPF. Legat de critica contestatorului: ” Printre protocoalele de rutare dinamică a traficului IPv4 indicate de autoritate se numără și EIGRP- Stub, protocol care nu este suportat pe echipamentul Juniper EX4300- 32F propus de ..., acest lucru fiind indicat de ofertant prin ne-adăugarea acestuia în matricea de conformitate”, autoritatea contractantă precizează că EIGRP este un protocol proprietar CISCO (RFC 6878), iar OSFP (RFC 2328) este protocol standard. Funcționalitatea oferită de protocolul EIGRP este acoperită prin folosirea protocolului OSPF. Compatibilitatea protocoalelor este exemplificată pe pagina producătorului:

kb.juniper.net/InfoCenter/index? page=content&id=KB14893 3. Referitor cerinței: ” 3.2.4/C14 c. Switch-ul trebuie să ofere următoarele facilitați de rutare IP: c. suport pentru protocoale de rutare dinamică a traficului IPv4: BGP, EIGRP, PIM (moduri sparse, dense și sparse-dense), DVMRP, prin upgrade software ulterior”, se menționează că echipamentul oferă suport pentru: c. BGP, PIM, DVMRP incluse în licența ofertată în complet. Legat de critica contestatorului: ” Pentru suport pentru protocoale de rutare dinamică a traficului IPv4 se numără și protocolul EIGRP, protocol care nu este suportat pe echipamentul Juniper EX4300-32F propus de ..., acest lucru fiind indicat chiar de ofertant prin neadăugarea acestuia în matricea de conformitate și DVMRP - protocol care a fost scos din lista suportată de Junos OS începând cu versiunea 16.1 (la momentul ofertării ultima versiune disponibilă fiind Junos OS 20.1), versiune care la data ofertării nu mai era suportată de Juniper după cum se poate observa pe site-ul oficial Juniper”, autoritatea contractantă precizează că protocolul EIGRP (RFC 6878) nu este suportat pe echipamentul ofertat, deci suport pentru acest protocol nu poate exista. Explicații despre echivalența protocolului au fost menționate anterior arată autoritatea contractantă. Protocolul DVMRP (RFC 1075) este apărut în Noiembrie 1988. Funcționalitățile sunt îndeplinite de protocolul PIM (RFC 8736) echivalent, apărut în Martie 2016. DVMRP este bazat pe un standard vechi, care nu mai satisface cerințele rețelelor din prezent. DVMRP nu mai este vizibil începând cu versiunea Junos OS 16.1, dar comenzile rămân accesibile și configurabile. 4. Referitor cerinței: ” 3.2.4/C14 d. Switch-ul trebuie să ofere următoarele facilitați de rutare IP: c. suport pentru protocoale de rutare dinamica a traficului IPv4: BGP, EIGRP, PIM (moduri sparse, dense și sparse-dense), DVMRP, prin upgrade software ulterior”, se precizează că echipamentul oferă suport pentru: d. suport pentru rutare IPv6 și protocoale de rutare dinamică a traficului IPv6: RIP, OSPF și EIGRP, prin upgrade ulterior al software-ului. 5

Legat de critica contestatorului: ” Pentru suport pentru rutare IPv6 și protocoale de rutare dinamică a traficului IPv6 se numără și protocolul EIGRP, protocol care nu este suportat pe echipamentul Juniper EX4300- 32F propus de ..., acest lucru fiind indicat chiar de ofertant prin neadăugarea acestuia în matricea de conformitate”, autoritatea contractantă susține că protocolul EIGRP (RFC 6878) nu este suportat pe echipamentul ofertat, deci suport pentru acest protocol nu poate exista. Explicații despre echivalența protocolului au fost menționate anterior. 5. Referitor cerinței: ”3.2.8./C28 Switch-ul trebuie să funcționeze în următoarele condiții de mediu: a) Temperatura de operare: -5° C +45°C; b) Umiditate (operare); 10 95% fără condensare”, se precizează că echipamentul a fost testat de către furnizor în privinţa unei funcționări normale în condițiile mecano climatice specificate. Legat de critica contestatorului: ” Cerința nu este îndeplinită nici pentru punctul a nici pentru punctul b, ofertantul punând la dispoziție doar un document de la producător prin care se specifică faptul că echipamentul ofertat a fost ținut la o umiditate și o temperatură în conformitate cu cerințele autorității contractante (test care a fost făcut special pentru această procedură) fără însă a confirma faptul că echipamentul a funcționat. De altfel în broșura tehnică a echipamentului care a fost anexată ofertei se specifică foarte clar intervalele în care echipamentul a fost testat și funcționează: Temperatura de operare: 0 C - +45 C și nu -5 C - +45 C; Umiditate (operare): 10 - 85%, fără condensare și nu 10 - 95%”, autoritatea contractantă precizează faptul că, conform certificatului oferit de producător, din 7 Aprilie 2020, temperatura de operare și umiditatea de operare se încadrează în cerințele din specificația tehnică: Temperatura de operare: -5 C - +45 C Umiditate (operare): 10 - 95%. Totodată, autoritatea contractantă menționează faptul că, în oferta contestatorului este prezentat un echipament care are umiditatea de operare 5 - 90% (fără condensare), caracteristică ce nu satisface în totalitate cerința. 6. Referitor cerinței: ” În cazul defectării echipamentelor hardware în perioada de garanție, furnizorul, fără alte costuri suplimentare pentru beneficiar, trebuie sa le repare sau sa le înlocuiască în maxim 48 de ore de la momentul raportării. În situația în care un echipament este înlocuit, acesta va beneficia de o perioadă de garanție similară cu a produsului înlocuit. înlocuirea se va face numai cu componente noi conform configurației din documentație”, în ofertă se precizează că echipamentele defecte vor fi înlocuite în maxim 48 de ore de la momentul raportării cu componente noi conform configurației din documentație. Legat de critica contestatorului: ” Ofertantul a propus un suport de tip basic partner support cu codul de produs PA5- SUP-EX4300SITE - PSS Basic Support for 5 Year Prepaid NETWORK LICENSE for EX4300 48T/48P/32F) acest suport fiind de tip basic care nu garantează înlocuirea echipamentului defect în 48 de ore în conformitate cu cerința 6

mai sus menționată după cum se poate vedea și pe pagina producătorului https://www.iuniper.net/assets/us/en/local/ pdf/datasheets/10003 3 3 -en. pdf”, autoritatea contractantă menționează că ofertantul și-a asumat îndeplinirea cerinței. Conform contractului, în perioada garanției eventualele probleme vor fi soluționate prin grija furnizorului. În ce privește oferta ... constând în echipamentul ALLIED TELESIS X930-28GSTX, autoritatea contractantă susține: 1. La cerința: ” 3.2.3./C10 Ofertantul trebuie sa livreze: a. 24 transceivere SFP tip 100 Base-FX Multi-Mode ( 1300nm)”, oferta ... livrează: a. 24 trancivere SFP de tip lOOOBase-FX Multi-Mode: AT- SPSX. Legat de critica contestatorului: ” Autoritatea cere 24 de SFP-uri de tip FX, SFP-uri reconfirmate și în clarificarea A3532 din 14.04.2020 în timp ce ofertantul a propus SFP-uri de tip SX, modelul propus nefiind echivalent și compatibil cu cel propus de autoritate, ci reprezentând alt standard”, autoritatea contractantă consideră a fi o eroare de redactare, precizând faptul că conformitatea ofertei este reconfirmată prin inventarul de complet și cerința CI. 2. La cerința: ” 3.2.3./C11 Ofertantul trebuie să livreze 26 patch- corduri duale de fibra optica 50/125 cu lungimea minim 1 ml, care sa permită conectarea switch-ului la o cablare structurata cu ODF-uri ce folosesc conectori de fibra optica tip SC. Patch-cordurile FO au conectori SC-SC”, ofertantul livrează 24 de patch- corduri duale de fibră optică 50/125 cu lungimea minim 1 m, care permite conectarea switch-ului la o cablare structurată cu ODF-uri ce folosesc conectori de fibră optică tip SC, conform cu răspunsul la solicitarea de clarificare nr. A3532 din 14.04.2020. Referitor criticii contestatorului: ” Autoritatea cere 24 de cabluri de fibră optică de tip OM1 - conform clarificării A3532 din 14.04.2020, dar ofertantul ... a prezentat în oferta sa doar 24 de cabluri, neoferind astfel cantitatea cerută de autoritate”, autoritatea contractantă menționează o eroare de redactare. 3. La cerința: ” 3.2.4./C14 c. Switch-ul trebuie sa ofere următoarele facilitați de rutare IP: c. suport pentru protocoale de rutare dinamică a traficului IPv4: BGP, EIGRP, PIM (moduri sparse, dense și sparse-dense), DVMRP, prin upgrade software ulterior”, în ofertă se precizează că switch-ul ul oferă următoarele facilități de rutare IP: c. Suport pentru protocoalele de rutare dinamică a traficului IPv4: BGP, EIGRP compatibiliy mode prin OSPF, PIM (moduri sparse, dense și sparsedense pe aceeași mașină în instanțe diferite), DVMRP compatibility mode prin IGMP Proxy și static multicast routing, prin upgrade software ulterior. Legat de criticile contestatorului: ” Pentru suport pentru protocoale de rutare dinamica a traficului IPv4 se numără și protocoalele: i) EIGRP - protocol care nu este suportat pe echipamentul Allied Telesis X930- 28GSTX propus de ..., ofertantul indicând că are echivalență protocolul OSPF-Stub, protocol care este, de altfel și el cerut de autoritate și care 7

nu

este

echivalent

funcțional: https://communitv.cisco.com/t5/routinu/difference-b-w-stub-in-ospf- and-eigtp/td-Ji/690403 ; ii) DVMRP - care nu are ca echivalența funcțională IGMP Proxy și static multitasking route după cum o indică și literatura

de

specialitate: https://docs.oracle.com/cd/E19859- 01/8203252-11/FP44

ucg

IGM_PProxv.html” , autoritatea contractantă menționează: i) EIGRP este un protocol proprietar CISCO (RFC 6878), iar OSPF (RFC 2328) este protocol standard. Funcționalitatea oferită de protocolul EIGRP este acoperită prin folosirea protocolului OSPF. Diferența între cele două protocoale este de configurare a echipamentelor, diferență expusă chiar în link-ul furnizat în contestație și ii) DVMRP (RFC 1075) și IGMP (RFC 4605) sunt protocoale echivalente. Ambele au scopul de rutare multicast. Prin răspunsul consolidat nr. A3532 din 14.04.2020, autoritatea contractantă acceptă protocoale echivalente. 4. La cerința: ” 3.5./C35 în cazul defectării echipamentelor hardware în perioada de garanție, furnizorul, fără alte costuri suplimentare pentru beneficiar, trebuie să le repare sau să le înlocuiască în maxim 48 de ore de la momentul raportării. În situația în care un echipament este înlocuit, acesta va beneficia de o perioadă de garanție similară cu a produsului înlocuit. înlocuirea se va face numai cu componente noi conform configurației din documentație”, potrivit ofertei, în cazul defectării echipamentelor hardware în perioada de garanție, ..., fără alte costuri suplimentare pentru beneficiar, repară sau înlocuiește în maxim 48 de ore lucrătoare de la momentul raportării, conform cu răspunsul la solicitarea de clarificare nr. A3532 din 14.04.2020. În situația în care un echipament este înlocuit, acesta va beneficia de o perioadă de garanție similară cu a produsului înlocuit valabilă până la data declarată în certificatul de garanție emis de către ofertant, înlocuirea se va face numai cu componente noi conform configurației din documentație. În ce privește critica contestatorului: ” Ofertantul a propus un suport de tip NetCover Preferred Support cu codul de produs AT-X930- 28GSTX- SYNCP5 acest suport nu garantează înlocuirea echipamentului defect în 48 de ore în conformitate cu cerința menționată mai sus după cum

se

poate

vedea

și

pe

pagina

producătorului: https://www.alliedtelesis.com/en/

services/netcover , în fapt nici un suport oferit de producător nu garantează înlocuirea echipamentului defect în 48 de ore ci, în cel mai bun caz, în varianta support Advanced și Elite, doar expedierea către clientul final în următoarea și lucrătoare a produsului înlocuitor "Next business day shipment for advanced hardware replacement””, autoritatea contractantă precizează că ofertantul și-a asumat îndeplinirea cerinței. Conform contractului, în perioada garanției eventualele probleme vor fi soluționate prin grija furnizorului. Prin adresa înregistrată la Consiliu cu nr. 58422/30.12.2020, contestatorul formulează concluzii scrise, prin care solicită înlăturarea 8

apărărilor autorității contractante și admiterea contestației, din următoarele motive: I. Argumente privind neconformitatea ofertei ...: 1. Cu privire la faptul că oferta ... nu respectă cerința 3.2.4. - Cerințe specifice – Cerința C13 subpunctul d, în sensul că protocolul propus de ofertant, VRRP, ca echivalent la protocolul indicat de autoritate, HSRP, nu este compatibil cu acesta din urmă, contestatorul consideră răspunsul autorității contractante nesatisfăcător, întrucât: Ofertând un protocol alternativ, ... nu a prezentat în cadrul propunerii sale dovezi care să demonstreze că acest protocol îndeplinește în mod echivalent cerința stabilită de autoritatea contractantă în cadrul documentației. Ofertantul avea această obligație și în virtutea dispozițiilor art. 156 alin. (4) din Legea nr. 98/2016, potrivit cărora ” În cazul în care autoritatea contractantă stabilește specificațiile tehnice potrivit dispozițiilor alin. (1) lit. b), aceasta nu respinge o ofertă pe motiv că lucrările, produsele sau serviciile oferite nu sunt conforme cu specificațiile tehnice la care se face trimitere, dacă ofertantul demonstrează în oferta sa, prin orice mijloace adecvate, că soluțiile propuse îndeplinesc într-un mod echivalent cerințele definite prin specificațiile tehnice.” În lipsa acestor dovezi, autoritatea contractantă avea obligația de a declara oferta ... drept neconformă, afirmă contestatorul. Nici în punctul de vedere transmis de autoritatea contractantă și nici după consultarea dosarului achiziției, contestatorul susține că nu a putut identifica dovezile care demonstrează că protocolul VRRP îndeplinește cerințele impuse. În mod evident, simpla afirmație că acest protocol îndeplinește aceste cerințe nu poate fi suficientă, motiv pentru care se impunea respingerea ofertei ... În același sens, prin ”RĂSPUNS CONSOLIDAT LA SOLICITĂRILE DE CLARIFICĂRI LA DOCUMENTAȚIA DE ATRIBUIRE” (denumit în continuare „Răspuns consolidat”) nr. A3532 din 14.04.2020, autoritatea contractantă precizează cu deplină claritate în ce condiții recunoaște echivalența, și anume în condițiile asigurării interoperabilității tehnologice și operaționale cu infrastructura existentă, fără a aduce modificări asupra acesteia. Or, cele două protocoale de comunicație (HSRP – solicitat de autoritatea contractantă prin documentația de atribuire, și VRRP, ofertat de operatorul economic) nu respectă cerința sine qua non de asigurare a interoperabilității tehnologice și operaționale cu infrastructura existentă, fără a aduce modificări asupra acesteia întrucât cele două protocoale de comunicație sunt diferite și nu interoperează între ele. În condițiile în care infrastructura existentă se bazează pe protocolul de comunicație HSRP, utilizarea protocolului VRRP, care nu doar că este diferit de cel existent, solicitat de autoritatea contractantă (HSRP), dar nici nu interoperează cu acesta, cerința clară și expresă a autorității contractante de asigurare a interoperabilității tehnologice și operaționale cu infrastructura existentă nu poate fi respectată deoarece integrarea, în cadrul infrastructurii existente, a unui echipament bazat pe protocolul 9

VRRP (ofertat de operatorul economic) nu doar că necesită modificări ale infrastructurii existente, dar aceste modificări sunt substanțiale. Prin urmare, acceptând, în cadrul procesului de evaluare, echivalența protocolului de comunicație VRRP cu cerințele documentației de atribuire, citite în lumina clarificărilor publicate de către autoritatea contractantă, aceasta din urmă încalcă flagrant chiar propria opinie, obligatorie, exprimată cu deplină claritate în răspunsurile la întrebările de clarificare: „Având în vedere necesitatea interoperabilității tehnologice și operaționale cu infrastructura existentă, fără a aduce modificări asupra acesteia, toate cerințele tehnice sunt minime și obligatorii”. În aceste condiții, contestatorul solicită Consiliului să constate că autoritatea contractantă a evaluat oferta ... cu nerespectarea prevederilor documentației de atribuire, așa cum au fost clarificate prin răspunsurile la solicitările de clarificare, drept pentru care consecința nu poate fi decât respingerea ofertei depuse de ... 2. Referitor faptului că oferta ... nu respectă cerința 3.2.4. - Cerințe specifice – Cerința C14 subpunctul b, în sensul că printre protocoale de rutare dinamică a traficului IPv4 indicate de autoritate se numără și EIGRP-Stub, protocol care nu este suportat pe echipamentul Juniper EX4300-32F propus de ..., acest lucru fiind indicat chiar de ofertant prin neadăugarea acestuia în matricea de conformitate, din nou contestatorul consideră nesatisfăcător răspunsul autorității contractante, întrucât: Referitor la precizarea autorității contractante potrivit căreia EIGRP este un protocol proprietar CISCO, iar OSFP un protocol standard nu prezintă relevanță în cauză, atâta timp cât protocolul OSPF propus de ofertant nu asigură interoperabilitatea cu infrastructura existentă, fără modificări aduse asupra acesteia. Mutatis mutandis, sunt aplicabile și în acest caz cele prezentate mai sus cu privire la nerespectarea primei cerințe, arată contestatorul. Astfel, ofertantul nu a prezentat dovezi adecvate care să probeze că protocolul OSPF îndeplinește cerințele impuse de autoritatea contractantă. În mod evident, simpla afirmație că acest protocol îndeplinește aceste cerințe nu poate fi suficientă, motiv pentru care se impunea respingerea ofertei acestuia. Contestatorul învederează că, și în prezentul caz, sunt aplicabile precizările generice menționate la punctul 1, și anume faptul că autoritatea contractantă a precizat cu deplină claritate în ce condiții recunoaște echivalența, și anume în condițiile asigurării interoperabilității tehnologice și operaționale cu infrastructura existentă, fără a aduce modificări asupra acesteia. Concret, cele două protocoale (EIGRP și OSPF) nu sunt echivalente din punct de vedere tehnic, precizează contestatorul, prezentând diferențelor acestora sub formă tabelară: OSPF EIGRP Tipul de protocol 10

OSPF EIGRP OSPF este un protocol Link State. EIGRP este un protocol Distance Vector. Arhitectura OSPF are nevoie de o arhitectură de rețea ierarhică împărțită în arii. EIGRP nu are limitările OSPF. Sistemul de calcul al metricii OSPF folosește un cost bazat doar pe lățimea de bandă. EIGRP folosește o metrică bazată pe 5 parametri ce rezultă într-o formulă complexă. Stocare și procesare OSPF necesită resurse mai mari de stocare și procesare deoarece:  folosește un algoritm de tip SPF (Dijkstra) pentru determinarea celei mai bune rute;  necesită menținerea topologiei complete a rețelei în memoria echipamentului. EIGRP necesită resurse mai mici de stocare și procesare decât OSPF deoarece nu are limitările OSPF. Comunicații: mesajele de comunicație a celor două protocoale NU sunt interoperabile OSPF nu poate înțelege mesajele de comunicație ale EIGRP EIGRP nu poate înțelege mesajele de comunicație ale OSPF Timpul de convergență a rețelei OSPF are un timp de convergență a rețelei mai mare decât EIGRP deoarece OSPF NU menține în permanență o rută de back-up pentru orice destinație, așa cum se întâmplă în cazul EIGRP. EIGRP are un timp de convergență a rețelei mai mic decât OSPF deoarece EIGRP menține în permanență o rută de back-up pentru orice destinație. Referitor link-ului prezentat de către autoritatea contractantă (http://kb.juniper.net/InfoCenter/index?page=content&id=KB14893), contestatorul precizează că, diametral opus față de cele susținute de autoritatea contractantă, chiar pe prima pagină a adresei web se menționează, în mod clar, că nu există compatibilitate intre EIGRP (care aparține CISCO) și Juniper, astfel: ”SYMPTOMS: The Cisco EIGRP protocol will not work if connected to EX Switches în transit”. În consecință, singura asemănare dintre OSPF și EIGRP constă în faptul că ambele sunt protocoale de rutare dinamică, ceea ce nu conduce însă la concluzia că ar fi și echivalente, cu atât mai mult cu cât există și 11

alte protocoale de rutare dinamică, precum RIP, ISIS, BGP, etc. fără a se putea considera că ar exista o echivalență între toate aceste protocoale întemeiată pe simplul și unicul fapt că toate sunt protocoale. Dimpotrivă, fiecare are particularitățile și necesitățile specifice de arhitectură și implementare. Totodată, așa cum rezultă cu claritate din documentația de atribuire, autoritatea contractantă a indicat în mod neechivoc necesitatea separării funcționale între diferitele protocoale de rutare, precum și necesitatea asigurării suportului pentru toate acestea. Mai mult, referitor tot la nerespectarea de către ofertantul ... a cerințelor de interoperabilitate solicitate de autoritatea contractantă („Având în vedere necesitatea interoperabilității tehnologice și operaționale cu infrastructura existentă, fără a aduce modificări asupra acesteia, toate cerințele tehnice sunt minime și obligatorii”), în susținerea celor precizate anterior, contestatorul precizează faptul că echipamentul Juniper EX 4300-32F, în configurația ofertată de către ... este neconform și din următoarele motive: - La cerința C9 pct. b), autoritatea contractantă a solicitat 1 (un) „modul de uplink cu două porturi”. Formularea „modul” presupune posibilitatea ca o componentă să fie extrasă din echipament și, dacă este necesar, să fie mutată într-un alt echipament compatibil, în funcție de necesitățile autorității contractante, aspect care nu s-a regăsit în oferta ...; - La cerința C9 pct. c), autoritatea contractantă a solicitat 2 (două) porturi pentru interconectare într-o arhitectură redundantă, sub forma de switch virtual, cu un singur management, prin tehnologie de tip „StackWise” sau echivalent, la o viteză de minim 64 Gbps, pentru conectarea cu echipamentele existente. Având în vedere modul în care autoritatea contractantă a formulat cerința, rezultă că este absolut necesară folosirea unei interfețe dedicate StackWise cu conector proprietar, ceea ce nu se regăsește în echipamentul Juniper. 3. În ce privește nerespectarea cerinței 3.2.4. - Cerințe specifice – Cerința C14 subpunctul c –contestatorul afirmă că, pentru suport pentru protocoale de rutare dinamică a traficului IPv4 se numără și protocoalele EIGRP, protocol care nu este suportat pe echipamentul Juniper EX4300-32F propus de ..., acest lucru fiind indicat chiar de ofertant prin neadăugarea acestuia în matricea de conformitate și DVMRP – protocol care a fost scos din lista suportată de Junos OS (sistemul de operare de pe echipamentul Juniper EX4300-32F) începând cu versiunea 16.1 (la momentul ofertării ultima versiune disponibilă fiind Junos OS 20.1), versiune care la data ofertării nu mai era suportată de către Juniper după cum se poate observa pe site-ul oficial Juniper: https://support.juniper.net/support/eol/software/junos/#7 . Din punctul de vedere al autorității contractante pentru această cerință reiese că autoritatea contractantă a solicitat, prin documentația de atribuire, ofertarea DVMRP, iar ofertantul nu a ofertat DVMRP. 12

... precizează că autoritatea contractantă nu a renunțat la DVMRP, neexistând nicio clarificare sau erată în acest sens. Prin urmare, în lumina dispozițiilor Legii nr. 98/2016, în special art. 3 alin. (1) lit. z) și art. 154 și ale Anexei 1 la HG nr. 395/2016, în special art. 20 alin. (1) și (2) și art. 123 alin. (1), ofertantul avea obligația legală de a își elabora oferta în conformitate cu prevederile documentației de atribuire, iar, prin documentația de atribuire, autoritatea contractantă a solicitat DVMRP, însă acesta nu a fost ofertat de ... În aceste condiții, ... solicită constatarea faptului că autoritatea contractantă a efectuat evaluarea ofertei ... cu nerespectarea flagrantă a documentației de atribuire, cu ignorarea prevederilor exprese și imperative ale art. 123 din Anexa 1 la HG nr. 395/2016. 4. Cu privire la nerespectarea cerinței 3.2.4. - Cerințe specifice – Cerința C14 subpunctul d - pentru suport pentru rutare IPv6 și protocoale de rutare dinamică a traficului IPv6 se numără și protocolul EIGRP, protocol care nu este suportat pe echipamentul Juniper EX4300- 32F propus de ..., acest lucru fiind indicat chiar de ofertant prin ne- adăugarea acestuia în matricea de conformitate. Contestatorul iterează argumentația de la punctul 2 pe care o consideră aplicabilă și în prezentul caz, unde, dacă s-ar aplica cele ofertate de ..., ar trebui reconfigurată întreaga rețea, deci mii de echipamente. Totodată, ținând cont și de faptul că cele două protocoale de rutare (OSPF și EIGRP) au fost solicitate ambele, distinct, de autoritatea contractantă, coroborat cu faptul că protocolul EIGRP nu este suportat pe echipament, reiese în mod evident că oferta depusă de către ... nu este conformă și trebuia respinsă, consideră contestatorul. 5. Asupra nerespectării cerinței 3.2.8. - Cerințe mecano-climatice – Cerința C28 nu este îndeplinită nici pentru punctul a nici pentru punctul b, ofertantul punând la dispoziție doar un document de la producător prin care se specifica faptul ca echipamentul ofertat a fost ținut la o umiditate și o temperatură în conformitate cu cerințele autorității contractante (test care a fost făcut special pentru aceasta procedură) fără însă a confirma faptul că echipamentul a funcționat. De altfel în broșura tehnică a echipamentului care a fost anexata ofertei se specifica foarte clar intervalele în care echipamentul a fost testat și funcționează: -Temperatura de operare: 0ᴼC÷+45ᴼC și nu -5ᴼC÷+45ᴼC; -Umiditate (operare): 10 ÷ 85%, fără condensare și nu 10 ÷ 95%. 6. Cu privire la cerința 3.5 - Cerințe privind garanția produsului, ofertantul a propus un support de tip basic partner support cu codul de produs PA5-SUP-EX4300SITE - PSS Basic Support for 5 Year Prepaid NETWORK LICENSE for EX4300 48T/48P/32F) acest suport fiind de tip basic care nu garantează înlocuirea echipamentului defect în 48 de ore în conformitate cu cerința mai sus menționată după cum se poate vedea și pe

pagina

producătorului: https://www.juniper.net/assets/us/en/local/pdf/datasheets/1000333- en.pdf. 13

Precizarea autorității contractante conform căreia „Ofertantul și-a asumat îndeplinirea cerinței” încalcă major prevederile legislației aplicabile, în special art. 3 alin. (1) lit. z) și art. 154 din Legea nr. 98/2016, precum și art. 20 alin. (1) și (2) și art. 123 alin. (1) din Anexa 1 la HG nr. 98/2016, menționate la punctul 3. Contestatorul învederează faptul că ofertantul are obligația de a elabora oferta în conformitate cu prevederile documentației de atribuire. În cadrul documentației de atribuire – Fișa de date și Modelele de formulare, autoritatea contractantă a precizat cu deplină claritate cum dorește să fie elaborată oferta (propunerea tehnică), iar acest mod nu constă nicidecum în „asumarea îndeplinirii cerinței” de către ofertant. Astfel, în Fișa de date se menționează în mod expres că „În propunerea tehnică depusă, ofertantul are obligația de a face dovada conformității produselor care urmează a fi livrate cu cerințele prevăzute în Caietul de Sarcini (inclusiv specificația tehnică). Propunerea tehnică, la fiecare lot în parte, va conține, "Matricea de conformitate"- formularul TH, Formularul Detalii Producător și va fi însoțită de foi de catalog/similare emise de producătorul echipamentelor ofertate din care să rezulte cu ușurință specificațiile tehnice ale produselor ofertate precum si, corespondență acestora cu cerințele tehnice din caietul de sarcini (fișa de produs). Propunerea tehnică va fi prezentată astfel încât să permită identificarea cu ușurință a corespondentei cu specificațiile tehnice”. Prin urmare, se solicită ca ofertantul să facă „dovada” conformității produselor ofertate, nu doar să „își asume îndeplinirea cerinței”, subliniază contestatorul. Mai mult, autoritatea contractantă precizează operatorilor economici și cum trebuie făcută această dovadă, solicitând prezentarea obligatorie a propunerii tehnice prin intermediul matricii de conformitate din cadrul Formularului TH, parte integrantă a Secțiunii a IV-a a Documentației de atribuire, „Modele formulare”, secțiune care cuprinde și următoarea mențiune (pe prima pagină): „Completarea formularelor se va face respectând instrucțiunile din subsol, astfel încât informațiile să fie complete și fără echivoc pentru a permite verificarea concordanței acestora cu documentele de confirmare care vor fi depuse ulterior la solicitarea autorității contractante.”, contestatorul redând în acest sens conținutul Formularului TH. Or, așa cum se poate constata (și cum a constatat, de altfel, și autoritatea contractantă), ofertantul ... nu a elaborat oferta în conformitate cu prevederile documentației de atribuire, iar mențiunea autorității contractante („Ofertantul și-a asumat îndeplinirea cerinței”) nu poate fi primită, consideră contestatorul. II. Argumente privind neconformitatea ofertei ... 1. Legat de cerința 3.2.3./C10, în punctul său de vedere, autoritatea contractantă eludează însăși esența aspectului dedus soluționării Onoratului Consiliu: lungimea de undă necesară pentru a îndeplini cerința autorității contractante este de 1300 nm, aspect pe care 14

aceasta îl afirmă atât în caietul de sarcini, cât și în răspunsurile la solicitările de clarificare. Nerespectarea cerinței privind lungimea de undă conduce, în mod direct și automat, la incompatibilitatea echipamentului respectiv cu infrastructura existentă. Or, exact acest lucru se întâmplă în cazul echipamentului ofertat de ..., acesta neputând funcționa pe lungimea de undă solicitată de autoritatea contractantă (1300nm). Cerința autorității contractante specifică o lungime de undă de 1300 nm, în timp ce echipamentul (tranceiver-ul) ofertat de către ... funcționează la o lungime de undă de 850 nm. Acest aspect este confirmat chiar de producătorul echipamentului, după cum se poate verifica

pe

pagina

producătorului: https://www.alliedtelesis.com/en/documents/datasheet-sp-series (SFP-ul ofertat de către ... pentru transceiver SFP de tip 100Base-FX fiind AT- SPSX). Prin urmare, oferta depusă de ... este neconformă și trebuie respinsă, potrivit contestatorului. 2. Referitor cerinței 3.2.3./C11, contestatorul afirmă că a luat notă de mențiunea autorității contractante („Eroare de redactare”) și face precizarea că, potrivit Răspunsului consolidat nr. A3532 din 14.04.2020, autoritatea contractantă a solicitat 26 de cabluri de fibră optică de tip OM1. Având în vedere că ofertantul ... a ofertat mai puține cabluri – doar 24, în loc de 26, cât a solicitat autoritatea contractantă, oferta sa este neconformă. 3. Referitor cerinței 3.2.4./C14 c, contestatorul face trimitere la mențiunile sale de la punctul 2 aferent ..., pe care le menține în integralitate, fără a le reitera la acest punct. Cu privire la echivalența dintre DVMRP, pe de o parte, și IGMP Proxy și static multicasting, pe de altă parte, contestatorul menționează că cele două tehnologii nu sunt echivalente, deci nu este respectată cerința expresă a autorității contractante („Având în vedere necesitatea interoperabilității tehnologice și operaționale cu infrastructura existentă, fără a aduce modificări asupra acesteia, toate cerințele tehnice sunt minime și obligatorii”). Contestatorul prezintă, în continuare, principalele elemente diferențiatoare, care determină lipsa echivalenței acestora: - DVMRP este un protocol de rutare dinamic pentru multicast. Acesta ar putea fi, eventual, echivalat cu protocolul mai nou PIM (Protocol Independent Multicast), așa cum a transmis autoritatea contractantă prin punctul de vedere la care facem referire (nu însă și în cadrul documentației de atribuire; - Protocolul IGMP are ca rol facilitarea apartenenței unui „host” la un anumit grup de multicast. Funcționalitatea IGMP Proxy poate să facă această cerere în numele „host-ului” – prin urmare, nu își are locul în respectarea cerinței; 15

- Funcționalitatea de „static multicast” oferită de către echipamentul X930-28GSTX nu poate fi echivalată cu DVMRP întrucât nu reprezintă un protocol de rutare multicast, ci doar posibilitatea de scriere de reguli manuale statice de rutare multicast. O astfel de echivalare dintre „static multicast” cu DVMRP ar avea consecințe absurde și neconforme cu prevederile documentației de atribuire, precum echivalarea oricărui protocol de rutare dinamică IPv4/IPv6 (ex: RIP, OSPF, BGP, etc.) cu rutarea statică, ceea ce nu poate fi primit. Mai mult, referitor tot la nerespectarea de către ofertantul ... a cerințelor de interoperabilitate solicitate de autoritatea contractantă („Având în vedere necesitatea interoperabilității tehnologice și operaționale cu infrastructura existentă, fără a aduce modificări asupra acesteia, toate cerințele tehnice sunt minime și obligatorii”), în susținerea celor precizate anterior, contestatorul învederează Consiliului că echipamentul Allied Telesis X930-28GSX, în configurația ofertată de către ... este neconform și din următoarele motive: - La cerința C9 pct. b), autoritatea contractantă a solicitat 1 (un) „modul de uplink cu două porturi”. Formularea „modul” presupune posibilitatea ca o componentă să fie extrasă din echipament și, dacă este necesar, să fie mutată într-un alt echipament compatibil, în funcție de necesitățile autorității contractante, aspect care nu s-a regăsit în oferta ..., ci doar un modul pentru stacking; - La cerința C9 pct. c), autoritatea contractantă a solicitat 2 (două) porturi pentru interconectare într-o arhitectură redundantă, sub forma de switch virtual, cu un singur management, prin tehnologie de tip „StackWise” sau echivalent, la o viteză de minim 64 Gbps, pentru conectarea cu echipamentele existente. Având în vedere modul în care autoritatea contractantă a formulat cerința, rezultă că este absolut necesară folosirea unei interfețe dedicate StackWise cu conector proprietar, ceea ce nu se regăsește în echipamentul Allied Telesis; - Referitor la cerința C13, pct. c), Per-VLan Spanning Tree Plus, documentația Allied Telesis nu permite posibilitatea de rulare a câte o instanță de Rapid Spanning Tree pentru fiecare VLAN, ci doar posibilitatea de rulare pentru VLAN-uri multiple a MSTP (cerință care este solicitată separat, expres, la pct. b) al Cerinței C13). 4. Cu privire la cerința 3.5./C35, contestatorul face trimitere la mențiunile sale de la punctul I.6 aferent ..., aplicabile mutatis-mutandis. Nerespectarea tuturor acestor cerințe esențiale din cadrul documentației de atribuire face produsele celor doi ofertanți incompatibile cu infrastructura de rețea a autorității contractante, neasigurând astfel interoperabilitatea cu sistemul în care produsul trebuie integrat. În același timp, ofertanții clasați pe locurile 1 și 2 în clasamentul Lotului 2 nu au demonstrat în cadrul ofertelor că produsele propuse îndeplinesc într-un mod echivalent cerințele funcționale definite prin specificațiile tehnice, astfel cum rezultă în mod necesar din interpretarea art. 156 alin. (4) din legea nr. 98/2016 precum și din Răspunsul 16

consolidat prezentat de către autoritate și menționat supra, motiv pentru care ofertele acestora trebuiau respinse ca neconforme.

Din înscrisurile aflate la dosarul cauzei, Consiliul constată următoarea situație de fapt: În calitate de autoritate contractantă, ... a inițiat o procedură de licitație deschisă, desfășurată online, divizată pe loturi, organizată în vederea încheierii acordului-cadru de furnizare având ca obiect ”Acord cadru de furnizare Switchuri diverse tipuri – 6 loturi”, pentru Lotul nr. 2 ” Switch 24 porturi FO”, cod CPV ..., prin publicarea în SICAP a anunțului de participare nr. .... Potrivit anunțului de participare și a documentației de atribuire, criteriul de atribuire este „cel mai bun raport calitate-preț”, iar valoarea totală estimată a acordului-cadru privind furnizarea este de ... lei, fără T.V.A. Se are în vedere că autoritatea contractantă a divizat contractul supus procedurii de atribuire în cauză în 6 loturi, astfel cum este menționat la pct. II.1.6. din cadrul fișei de date a achiziției, iar prezenta contestație vizează numai lotul nr. 2, cu o valoare estimată de ... lei, fără TVA. Conform raportului procedurii nr. A11110/23.11.2020, pentru lotul nr. 2 ”Switch 24 porturi FO”, oferta ... s-a clasat pe primul loc, totalizând un număr de 100 puncte, pe locul al doilea oferta ..., totalizând 32,94 puncte, pe locul al treilea oferta contestatorului ... cu un total de 29,55 puncte, urmata de alți trei ofertanți cu punctaje mai mici. Împotriva raportului procedurii nr. A11110/23.11.2020, a adresei de comunicare a rezultatului procedurii nr. A11111/23.11.2020, prin care oferta ... a fost declarată câștigătoare pentru lotul nr. 2, iar oferta ... a fost declarată admisibilă dar necâștigătoare, a formulat acesta din urmă contestație, susținând că ofertele depuse de către ... și ..., clasate pe locurile I și II sunt neconforme și solicitând reevaluarea și respingerea acestora, precum și declararea ofertei sale ca fiind câștigătoare. Procedând la soluționarea contestației formulate de ..., Consiliul constată că aceasta vizează rezultatul procedurii de atribuire pentru lotul 2 – „Switch 24 porturi FO”, fiind formulate critici referitoare la ofertele clasate pe locurile 1 și 2, depuse de ... și ... Astfel, Consiliul constată că ... reclamă faptul că ofertele prezentate de ofertanții clasați pe primele două locuri în clasamentul final pentru lotul 2 nu îndeplinesc cerințele de la punctele 3.2.4 – Cerințe specifice, Cerința C13 subpunctul d), Cerința 14 subpunctele b), c) și d), Cerința 3.2.8 – cerințe mecano-climatice – Cerința 28 și cerința 3.5 – Cerințe privind garanția produsului – Cerința C35 (...), respectiv cerințele de la punctul 3.2.3 – Cerințe privind interfețele – Cerința C9, Cerința C10 și Cerința C11, Cerința 3.2.4 – cerințe specifice, Cerința C14 subpunctul c) și Cerința 3.5 – cerințe privind garanția produsului – cerința C35 (...). Raportat la criticile formulate de contestator, Consiliul are în vedere că în cuprinsul documentului intitulat „Specificații tehnice switch-uri”, 17

parte integrantă a documentației de atribuire, sunt menționate următoarele: - 3.2.3 Cerințe privind interfețele – cerința 9 – se solicită, între altele, că „Switch-ul trebuie să dispună minim de: a) 24 porturi GE SFP”; - 3.2.3 Cerințe privind interfețele – cerința 10 – se solicită, între altele, ca „Ofertantul trebuie să livreze: a) 26 tranceivere SFP tip 100 Base-FX Multi Mode (1300 nm)”, modificată prin clarificarea postată în SICAP în data de 15.04.2020 prin care s-a stabilit că dintr-o eroare materială „s-a redactat 26 în loc de 24”; - 3.2.3 Cerințe privind interfețele – cerința 11 – se solicită ca „Ofertantul trebuie să livreze 26 patch-corduri duale de fibră optică 50/125 cu lungimea minim 1 ml, care să permită conectarea switch-ului la o cablare structurată cu ODF-uri ce folosesc conectori de fibră optică tip SC”; - 3.2.4 Cerințe specifice – Cerința 13 punctul d) – Se solicită ca „Switch-ul trebuie să asigure suport pentru protocoale de asigurare a disponibilității ridicate la nivel de legătură rețea: (...) d) Hot Standby Router Protocol (HSRP)”; - 3.2.4 Cerințe specifice – Cerința 14 punctele b), c) și d) – Se solicită ca „Switch-ul trebuie să ofere următoarele facilități de rutare IP: (...) b) protocoale de rutare dinamică a traficului IPv4: RIPv1, RIPv2, EIGRP-Stub și OSPF; c) suport pentru protocoale de rutare dinamică a traficului IPv4: BGP, EIGRP, PIM (moduri sparse, dense și sparse-dense), DVMRP, prin upgrade software ulterior; d) suport pentru rutare IPv6 și protocoale de rutare dinamică a traficului IPv6: RIP, OSPF și EIGRP, prin upgrade ulterior al software- ului”. - 3.2.8 Cerințe mecano-climatice – cerința 28 – unde este prevăzut că „Switch-ul trebuie să funcționeze în următoarele condiții de mediu: a) Temperatura de operare: -5⁰C ÷ +45⁰C; b) Umiditate (operare): 10 ÷ 95 %, fără condensare”. - 3.5 Cerințe privind garanția produsului – cerința 35 – este prevăzut că „În cazul defectării echipamentelor hardware în perioada de garanție, furnizorul, fără alte costuri suplimentare pentru beneficiar, trebuie să le repare sau să le înlocuiască în maxim 48 de ore de la momentul raportării. În situația în care un echipament este înlocuit, acesta va beneficia de o perioadă de garanție similară cu a produsului înlocuit. Înlocuirea se va face numai cu componente noi conform configurației din documentație”. De asemenea, Consiliul reține că la punctul IV.4.1 „Modul de prezentare al propunerii tehnice” din fișa de date a achiziției, este prevăzut că „În propunerea tehnică depusă, ofertantul are obligația de a face dovada conformității produselor care urmează a fi livrate cu cerințele prevăzute în Caietul de Sarcini (inclusiv specificația tehnică). Propunerea 18

tehnică, la fiecare lot în parte, va conține, "Matricea de conformitate"- formularul TH, Formularul Detalii Producător și va fi însoțită de foi de catalog/similare emise de producătorul echipamentelor ofertate din care să rezulte cu ușurință specificațiile tehnice ale produselor ofertate precum și, corespondența acestora cu cerințele tehnice din caietul de sarcini (fișa de produs). Propunerea tehnică va fi prezentată astfel încât să permită identificarea cu ușurință a corespondenței cu specificațiile tehnice. (…) Propunerea tehnică va fi atașată în SEAP și în format word. Nu se acceptă propuneri alternative. Lipsa propunerii tehnice, din SEAP, determină excluderea ofertantului”. În soluționare, Consiliul are în vedere că autoritatea contractantă a furnizat toate informațiile necesare pentru a asigura operatorilor economici o informare completă, corectă și precisă cu privire la cerințele achiziției, fiind detaliate toate cerințele ce se impun a fi îndeplinite de produsele ce urmează a fi ofertate, în conformitate cu prevederile art. 154 din Legea nr. 98/2016. Se reține și faptul că prevederile documentației de atribuire, anterior precizate, așa cum au fost modificate prin clarificarea din 15.04.2020, nu au fost contestate, acestea consolidându-și caracterul obligatoriu, atât pentru ofertanți care, potrivit prevederilor art. 123 alin. (1) din H.G. nr. 395/2016, au obligația de a elabora ofertele în conformitate cu prevederile documentației de atribuire, cât și pentru comisia de evaluare care, în conformitate cu art. 133 alin. (1) și (2) din același act normativ, are obligația de a analiza și de a verifica fiecare ofertă atât din punct de vedere al elementelor tehnice propuse, cât și din punct de vedere al aspectelor financiare pe care le implică, în condițiile în care propunerea tehnică trebuie să corespundă cerințelor minime prevăzute în caietul de sarcini sau în documentul descriptiv. Prin urmare, se reține că prin depunerea ofertelor la procedură, se presupune că ofertanții și-au însușit documentația de atribuire fără rezerve, ceea ce înseamnă că nu li se poate scuza nicio abatere de la prescripțiile ei, opozabile în cel mai mic detaliu (relevantă în acest sens este decizia nr. 1555 din 6 martie 2012 a Curții de Apel Craiova, Secția de contencios administrativ și fiscal). Astfel cum un contract constituie legea părților, și documentația de atribuire, întovărășită de clarificările postate în SEAP, are aceeași valoare pentru părți, iar niciuna dintre ele nu îi poate ignora sau nesocoti clauzele. În aceeași direcție, Curtea de Apel Iași, Secția de contencios administrativ și fiscal, a reținut în decizia nr. 2204 din 21 septembrie 2012 că cerințele riguroase în materie de achiziții publice presupun întocmirea documentelor necesare în conformitate cu prevederile documentației de atribuire, cunoscut fiind faptul că garantarea corectitudinii procedurii achizițiilor publice poate justifica respingerea ofertei pentru orice fel de încălcare a dispozițiilor legale în materie, care ar putea fi considerată de ofertant mai puțin importantă. Raportat la obiectivul general constând în prevenirea și sancționarea încălcării 19

dispozițiilor legale în materia procedurilor de achiziție publică, nu i se poate reproșa autorității contractante că a analizat ofertele participanților la procedură în raport de cerințele minime de participare necontestate, sancționând neîndeplinirea acestora. Depășind această introducere de subliniere a importanței respectării întru totul a regulilor impuse de achizitoare în documentația de atribuire, asupra aspectelor sesizate de reclamantă, analizând modul în care autoritatea contractantă a verificat documentele prezentate de ofertanți pentru lotul 2 - „Switch 24 porturi FO”, prin raportare la prevederile documentației de atribuire, la prevederile legale aplicabile în materia achizițiilor publice și la susținerile părților, Consiliul constată că, în mod eronat, membrii comisiei de evaluare au stabilit admisibilitatea ofertelor prezentate de ... și ..., având în vedere considerațiile prezentate în cele ce urmează. Astfel, în ceea ce privește modul de evaluare a propunerii tehnice prezentate de ... pentru lotul 2, Consiliul are în vedere că, referitor la modul de îndeplinire a Cerinței C13 subpunctul d), în cuprinsul Anexei 15 la procesul-verbal privind evaluarea conformității propunerilor tehnice cu prevederile caietului de sarcini, înregistrat cu nr. A-9495 din 08.10.2020, este prevăzut că „Echipamentul ofertat dispune de suport pentru protocoalele: (...) d) Echipamentul îndeplinește cerința prin folosirea protocolului alternativ VRRP”, deși prin caietul de sarcini s-a solicitat „Hot Standby Router Protocol (HSRP)”. Cu privire la acest aspect, Consiliul nu reține în soluționare susținerile autorității contractante, exprimate în cuprinsul punctului de vedere nr. 55153/14.12.2020 potrivit cărora „Protocoalele (VRRP și HSRP – nota Consiliului) sunt echivalente”, întrucât are în vedere prevederile art. 156 alin. (4) din Legea nr. 98/2016 care stabilesc faptul că „În cazul în care autoritatea contractantă stabilește specificațiile tehnice potrivit dispozițiilor alin. (1) lit. b), aceasta nu respinge o ofertă pe motiv că lucrările, produsele sau serviciile oferite nu sunt conforme cu specificațiile tehnice la care se face trimitere, dacă ofertantul demonstrează în oferta sa, prin orice mijloace adecvate, că soluțiile propuse îndeplinesc într-un mod echivalent cerințele definite prin specificațiile tehnice”. Astfel, Consiliul constată că, în măsura în care ... a ofertat un protocol diferit de cel solicitat prin caietul de sarcini, ofertantul în cauză avea obligația de a demonstra, prin orice mijloace, echivalența celor două protocoale. Or, sub acest aspect, Consiliul constată că nu a fost precizat decât faptul că „Echipamentul îndeplinește cerința prin folosirea protocolului alternativ VRRP”, fără a fi prezentate dovezi în acest sens. Aceleași considerații sunt reținute de Consiliu și în ceea ce privește modul de îndeplinire a Cerinței 14 punctul b), în condițiile în care prin caietul de sarcini s-a solicitat „Switch-ul trebuie să ofere următoarele facilități de rutare IP: (...) b) protocoale de rutare dinamică a traficului 20

IPv4: RIPv1, RIPv2, EIGRP-Stub și OSPF”, iar ... a precizat în propunerea tehnică faptul că „Echipamentul oferă suport pentru: (...) RIP v1/v2 și OSPF”, fără a fi făcute precizări cu privire la protocolul EIGRP-stub și fără a fi demonstrată, de către ofertantul în cauză, echivalența dintre protocoalele EIGRP și OSPF, așa cum, în mod eronat, sugerează autoritatea contractantă în cuprinsul punctului de vedere nr. 55153/14.12.2020. În ceea ce privește modul de îndeplinire a cerinței 14, subpunctul c), Consiliul constată că, deși prin documentația de atribuire s-a solicitat „Switch-ul trebuie să ofere următoarele facilități de rutare IP: (...) c) suport pentru protocoale de rutare dinamică a traficului IPv4: BGP, EIGRP, PIM (moduri sparse, dense și sparse-dense), DVMRP, prin upgrade software ulterior”, ... a precizat în cuprinsul propunerii tehnice că „Echipamentul oferă suport pentru BGP, PIM, DVMRP incluse în licența ofertată în complet”, fără a preciza dacă echipamentul ofertat suportă și protocolul EIGRP, așa cum s-a solicitat prin documentația de atribuire și fără a demonstra echivalența acestuia cu unul dintre protocoalele menționate la acest subpunct din propunerea tehnică. Aceleași considerații sunt reținute de Consiliu și cu privire la modul de îndeplinire a cerinței 14 subpunctul d) întrucât deși s-a solicitat ca „Switch-ul trebuie să ofere următoarele facilități de rutare IP: (...) d) suport pentru rutare IPv6 și protocoale de rutare dinamică a traficului IPv6: RIP, OSPF și EIGRP, prin upgrade ulterior al software-ului”, se constată că ... a ofertat „Suport RIF și OSFP incluse în licența ofertată în complet”, fără a oferta și EIGRP și fără a demonstra echivalența acestuia cu unul dintre protocoalele ofertate la acest subpunct. Referitor la modul de îndeplinire a cerinței 28, Consiliul are în vedere că prin documentația de atribuire s-a solicitat ca „Switch-ul trebuie să funcționeze în următoarele condiții de mediu: a) Temperatura de operare: -5⁰C ÷ +45⁰C; b) Umiditate (operare): 10 ÷ 95 %, fără condensare” și, analizând matricea de conformitate prezentată de ... în cadrul propunerii sale tehnice, constată că acesta a precizat „Echipamentul a fost testat de către furnizor în privința unei funcționări normale în condițiile mecano climatice specificate” și a anexat adresa emisă de producătorul Juniper Networks (pag. 475 din dosarul achiziției), fără nr. de înregistrare, din data de 07.04.2020, în cuprinsul căreia se precizează că „echipamentele (...) EX4300-32F oferite au fost supuse unui interval de temperatură ciclic de la -5 la 45 de grade Celsius și un interval de umiditate de 10- 95% fără condensare”, valori ce se încadrează în intervalele de temperatură și umiditate impuse de autoritatea contractantă. Astfel, Consiliul constată că ofertantul în cauză a prezentat documente de la producător din care rezultă îndeplinirea acestei cerințe, așa cum s-a solicitat prin documentația de atribuire, motiv pentru care respinge, ca nefondate, criticile formulate sub acest aspect. În ceea ce privește criticile referitoare la modul de îndeplinire de către ofertantul ... a cerinței 35, analizând conținutul matricei de 21

conformitate, Consiliul constată că ofertantul în cauză a precizat că „Echipamentele defecte vor fi înlocuite, în maxim 48 de ore de la momentul raportării, cu componente noi, conform configurației din documentație”. Astfel, Consiliul constată că ofertantul în cauză s-a angajat ca, în cazul în care îi va fi atribuit contractul de achiziție publică ce face obiectul prezentei proceduri, va asigura garanția echipamentelor hardware, optând pentru înlocuirea echipamentelor defecte, în maxim 48 de ore de la momentul raportării, însă nu a prezentat niciun document emis de producătorul echipamentului ofertat din cuprinsul căruia să rezulte, în mod indubitabil, îndeplinirea cerinței 35, așa cum a solicitat autoritatea contractantă la punctul IV.4.1 „Modul de prezentare al propunerii tehnice” din fișa de date a achiziției, astfel că, în mod eronat, membrii comisiei de evaluare au apreciat că cerința respectivă este îndeplinită, fără a avea la dispoziție vreun mijloc de probă. Cu privire la modul de îndeplinire de către ... a cerințelor 9, 10 și 11 , Consiliul constată că prin acestea s-a solicitat, pe de o parte, ca „Switch-ul trebuie să dispună minim de: a) 24 porturi GE SFP”, iar pe de altă parte, „Ofertantul trebuie să livreze: a) 26 tranceivere SFP tip 100 Base-FX Multi Mode (1300 nm)”, respectiv „Ofertantul trebuie să livreze 26 patch-corduri duale de fibră optică 50/125 cu lungimea minim 1 ml, care să permită conectarea switch-ului la o cablare structurată cu ODF- uri ce folosesc conectori de fibră optică tip SC”. De asemenea, Consiliul are în vedere că în cadrul clarificărilor postate în SICAP în data de 15.04.2020, înregistrată la autoritatea contractantă cu nr. A3532/14.04.2020, la întrebarea formulată de un operator economic interesat de participarea la prezenta procedură de atribuire, potrivit căreia „În documentul «3.1 Specificații tehnice switchuri.pdf», în «SPECIFICAȚIE TEHNICĂ PENTRU ACHIZIȚIE – Switch 24 porturi FO», la paragraful 3, subparagraful 3.2.3, cerința 10 se menționează «26 tranceivere SFP tip 100Base-FX Multi-Mode (1300 nm)». Vă rugăm să ne confirmați că cerința C10 este satisfăcută de către 24 tranceivere SFP tip 100Base-FX Multi-Mode (1300 nm), așa cum este specificată cantitatea la cerința C1”, autoritatea contractantă a formulat următorul răspuns: „În cuprinsul cerinței C10 a apărut o eroare materială de editare (s-a redactat 26 în loc de 24). Produsele ofertate care vor respecta parametrul definit la C10...24 tranceivere 100Base-FX Multi-Mode (1300 nm) sunt conforme”. Analizând conținutul matricei de conformitate prezentată de ... în cadrul propunerii sale tehnice, Consiliul constată că acesta a precizat că „... livrează: a) 24 trancivere SFP de tip 100Base-SX Multi-Mode: AT-SPSX conform cu răspunsul la clarificare nr. A3532 din 14.04.2020; b) 2 trancivere SFP+ de tip 10 GBase-SR: AT-SP10SR; c) 2 trancivere SFP de tip 1000 Base-LX/LH: AT-SPLX10; d) 2 trancivere SFP de tip 1000Base-SX: AT-SPSX. Toate modulele SFP/SFP+ ofertate sunt de la același producător, Allied Telesis, condiție indispensabilă ca toți parametrii de funcționare declarați de către producător să poată fi îndepliniți (consum, stabilitate în timp, funcționare în mediu guvernamental fără blocări și resetări de echipamente). Această 22

condiție, ca toate elementele componente ale switch-ului să aparțină aceluiași producător este impusă ca fiind obligatorie de orice producător”, respectiv că „... livrează 24 de patch-corduri duale de fibră optică 50/125 cu lungimea minim 1 ml, care să permită conectarea switch-ului la o cablare structurată cu ODF-uri ce folosesc conectori de fibră optică tip SC, conform cu răspunsul la solicitarea de clarificare nr. A3532 din 14.04.2020”. Astfel, pe de o parte, Consiliul constată că ofertantul în cauză nu a făcut nicio mențiune cu privire la îndeplinirea cerinței referitoare la lungimea de undă de 1300 nm, așa cum s-a solicitat prin documentația de atribuire, nici în cuprinsul matricei de conformitate și nici în tabelul cu detalii producător (pag. 493 din dosarul achiziției), motiv pentru care admite criticile formulate de ... sub acest aspect. Pe de altă parte, Consiliul constată că prin clarificarea nr. A3532 din 14.04.2020, postată în SICAP în data de 15.04.2020, autoritatea contractantă a precizat că „În cuprinsul cerinței C10 a apărut o eroare materială de editare (s-a redactat 26 în loc de 24). Produsele ofertate care vor respecta parametrul definit la C10...24 tranceivere 100Base-FX Multi-Mode (1300 nm) sunt conforme”. Astfel, se constată că deși autoritatea contractantă a menționat doar cerința C10, în fapt, modificarea numărului de pach-corduri de la 26 la 24 vizează toate cerințele referitoare la aceste elemente, aspect la care s-a raportat comisia de evaluare în etapa de evaluare a propunerilor tehnice pentru lotul 2, motiv pentru care respinge, ca nefondate, criticile formulate sub acest aspect. Cu privire la modul de îndeplinire de către ... a cerinței C14, subpunctul c), prin care s-a solicitat ca „Switch-ul trebuie să ofere următoarele facilități de rutare IP: (...) c) suport pentru protocoale de rutare dinamică a traficului IPv4: BGP, EIGRP, PIM (moduri sparse, dense și sparse-dense), DVMRP, prin upgrade software ulterior”, Consiliul constată că în cuprinsul matricei de conformitate prezentată de acest ofertant se precizează că „Switch-ul trebuie să ofere următoarele facilități de rutare IP: (...) c) Suport pentru protocoale de rutare dinamică a traficului IPv4: BGP, EIGRP compatibility mode prin OSPF, PIM (moduri sparse, dense și sparse-dense), DVMRP compatibility mode prin IGMP Proxy și static multicast routing, prin upgrade software ulterior”. Astfel, Consiliul are în vedere considerațiile reținute anterior în soluționarea criticilor referitoare la oferta prezentată de ... și constată că ofertantul în cauză avea obligația de a demonstra, prin orice mijloace, echivalența protocoalelor, respectiv EIGRP cu OSPF și DVMRP IGMP Proxy și static multicast routing, în conformitate cu prevederile art. 156 alin. (4) din legea nr. 98/2016, chiar și în situația în care prin clarificarea nr. A3532 din 14.04.2020, autoritatea contractantă a precizat că „Produsele ofertate echivalente funcțional sunt conforme”. Or, în măsura în care nu ofertantul în cauză nu a demonstrat echivalența respectivelor protocoale, membrii comisiei de evaluare nu puteau stabili conformitatea ofertei prezentate de acesta, motiv pentru care Consiliul constată caracterul întemeiat al criticilor formulate de contestator sub acest aspect. 23

În ceea ce privește îndeplinirea cerinței C35, Consiliul constată că ... s-a angajat că va îndeplini această cerință fără însă a prezenta vreun document emis de producătorul echipamentelor ofertate pentru lotul 2 din care să rezulte că acesta va asigura înlocuirea echipamentelor hardware ce se vor defecta în perioada de garanție, așa cum s-a solicitat la punctul IV.4.1 „Modul de prezentare al propunerii tehnice” din fișa de date a achiziției unde s-a precizat că „Propunerea tehnică, la fiecare lot in parte, va conține, "Matricea de conformitate"- formularul TH, Formularul Detalii Producător și va fi însoțită de foi de catalog/similare emise de producătorul echipamentelor ofertate din care să rezulte cu ușurință specificațiile tehnice ale produselor ofertate precum și, corespondența acestora cu cerințele tehnice din caietul de sarcini (fișa de produs)”. În ceea ce privește criticile formulate de contestator prin documentul intitulat „Concluzii scrise”, înregistrat la C.N.S.C. cu nr. 58422/30.12.2020, referitoare la modul de îndeplinire de către ... a cerințelor C9, subpunctele b) și c) și C13 subpunctul c), critici formulate după studierea dosarului cauzei, Consiliul le va respinge ca inadmisibile, în conformitate cu prevederile art. 21 alin. (3) din Legea nr. 101/2016 potrivit cărora „Este inadmisibilă prezentarea unor noi motive de contestare și/sau formularea unor noi capete de cerere pe calea concluziilor scrise sau orale ori a precizărilor la contestație ulterior termenului legal de formulare a acesteia”. Referitor la solicitarea contestatorului de obligare a autorității contractante la declararea ofertei prezentate de ... ca fiind câștigătoare pentru lotul 2, Consiliul are în vedere prevederile art. 26 alin. (10) din Legea nr. 101/2016 conform cărora „Consiliul nu poate decide atribuirea contractului către un anumit operator economic, cu excepția situației în care acesta a fost desemnat de autoritatea contractantă sau calitatea sa de ofertant câștigător rezultă din informațiile cuprinse în dosarul de soluționare a contestației”, motiv pentru care va proceda la respingerea, ca inadmisibilă, a acestui capăt de cerere. Prin urmare, Consiliul constată caracterul întemeiat al majorității criticilor formulate de contestator, impunându-se reanalizarea propunerilor tehnice prezentate de ... și ... pentru lotul 2 prin raportare la prevederile documentației de atribuire și la prevederile legale aplicabile, și, eventual, solicitarea de clarificări în cazul în care informațiile sau documentele prezentate de către acești operatori economici sunt incomplete sau eronate sau în cazul în care lipsesc anumite documente din cadrul ofertelor. Acestea fiind, în contextul de fapt și de drept anterior expus, în temeiul prevederilor art. 26 alin. (2) și (5) din Legea 101/2016, Consiliul admite, în parte, contestația formulată de ..., în contradictoriu cu .... Anulează, în parte, procesul verbal de evaluare a conformității propunerilor tehnice cu prevederile caietului de sarcini și, după caz, cu factorii de evaluare, înregistrat cu nr. A-9495/08.10.2020, raportul procedurii nr. A-11110/23.11.2020 și actele subsecvente acestuia, respectiv mențiunile referitoare la ofertele prezentate de ... și ... pentru lotul 2. 24

Anulează procesele verbale de evaluare a propunerilor financiare, înregistrate cu nr. A-10507/05.11.2020 și A-10791/12.11.2020. Anulează, în parte, procesul verbal al ședinței de verificare a documentelor suport/dovezilor aferente celor declarate în DUAE, înregistrat cu nr. A-11078/20.11.2020, respectiv a mențiunilor referitoare la lotul 2. Anulează, în parte, raportul procedurii nr. A-11110/23.11.2020 și actele subsecvente acestuia, respectiv a mențiunilor referitoare la ofertele prezentate de ... și ... pentru lotul 2. Obligă ... ca, în termen de 10 zile de la primirea prezentei, să procedeze la reanalizarea propunerilor tehnice prezentate de ... și ... pentru lotul 2, cu luarea în considerare a celor precizate în motivare. Respinge, ca inadmisibilă, solicitarea ... de obligare a ... la declararea ofertei sale ca fiind câștigătoare a lotului 2. Pentru aceste motive, în baza legii și a mijloacelor de probă aflate la dosar, CONSILIUL DECIDE: Admite, în parte, contestația formulată de către ..., cu sediul în ..., în contradictoriu cu ..., cu sediul în .... Anulează, în parte, procesul verbal de evaluare a conformității propunerilor tehnice cu prevederile caietului de sarcini și, după caz, cu factorii de evaluare, înregistrat cu nr. A-9495/08.10.2020, raportul procedurii nr. A-11110/23.11.2020 și actele subsecvente acestuia, respectiv mențiunile referitoare la ofertele prezentate de ... și ... pentru lotul 2. Anulează procesele verbale de evaluare a propunerilor financiare, înregistrate cu nr. A-10507/05.11.2020 și A-10791/12.11.2020. Anulează, în parte, procesul verbal al ședinței de verificare a documentelor suport/dovezilor aferente celor declarate în DUAE, înregistrat cu nr. A-11078/20.11.2020, respectiv a mențiunilor referitoare la lotul 2. Anulează, în parte, raportul procedurii nr. A-11110/23.11.2020 și actele subsecvente acestuia, respectiv a mențiunilor referitoare la ofertele prezentate de ... și ... pentru lotul 2. Obligă ... ca, în termen de 10 zile de la primirea prezentei, să procedeze la reanalizarea propunerilor tehnice prezentate de ... și ... pentru lotul 2, cu luarea în considerare a celor precizate în motivare. Respinge, ca inadmisibilă, solicitarea ... de obligare a ... la declararea ofertei sale ca fiind câștigătoare a lotului 2. Prezenta decizie este obligatorie pentru părți. Împotriva prezentei decizii se poate formula plângere, în termen de 10 zile de la comunicare pentru părțile cauzei, respectiv de la data luării la cunoștință de către alte persoane vătămate. 25

26