Solicitamos a la convocante establecer una nueva fecha para la realización de la visita técnica, con la finalidad de permitir una mayor participación de oferentes, que favorecerá a la competitividad de las ofertas a ser presentadas, esto en consideración a la obligatoriedad del requisito para la presentación de la oferta. Así también, solicitamos prorrogar el plazo de apertura y entrega de ofertas.
Solicitamos a la convocante establecer una nueva fecha para la realización de la visita técnica, con la finalidad de permitir una mayor participación de oferentes, que favorecerá a la competitividad de las ofertas a ser presentadas, esto en consideración a la obligatoriedad del requisito para la presentación de la oferta. Así también, solicitamos prorrogar el plazo de apertura y entrega de ofertas.
- Solicitamos a la convocante establecer una nueva fecha para la realización de la visita técnica, con la finalidad de permitir una mayor participación de oferentes, que favorecerá a la competitividad de las ofertas a ser presentadas.
- Solicitamos a la convocante establecer una nueva fecha para la realización de la visita técnica, con la finalidad de permitir una mayor participación de oferentes, que favorecerá a la competitividad de las ofertas a ser presentadas.
Requisito “802.1AE”. Solicitamos a la Convocante dejar como opcional el requerimiento de compatibilidad con el estándar IEEE 802.1AE (MACsec), o bien admitir funcionalidades de seguridad equivalentes o superiores que aseguren confidencialidad e integridad del tráfico a nivel de acceso (p. ej., mecanismos de seguridad de capa 2 o superiores con cifrado y control de acceso robusto).
La exigencia cerrada de un único estándar (802.1AE) no resulta indispensable para la consecución del objeto ni para la operación prevista, existiendo alternativas tecnológicas que brindan nivel de seguridad equivalente o superior. Mantenerlo como requisito obligatorio restringe injustificadamente la concurrencia, pudiendo direccionar la provisión a una sola marca/modelo, en contravención a los principios de igualdad y libre competencia de la Ley N° 7021/22.
La Ley 7021/22 dispone que los Pliegos de Bases y Condiciones (PBC) deben elaborarse conforme la reglamentación y documentos estándar de la DNCP, lo que impone a la convocante evitar exigencias que limiten la competencia sin justificación técnica proporcional (art. 45, primer párrafo).
Además, la Ley exige que, al definir la necesidad y estudiar el mercado, la convocante identifique proveedores y verifique si existe competencia, ajustando las condiciones del llamado en función de ese análisis. Requisitos técnicos que reducen artificialmente la concurrencia deben revisarse para asegurar pluralidad de oferentes (arts. 25 y 26).
La petición concreta es: Mantener 802.1AE como “opcional” y admitir soluciones equivalentes que cumplan el objetivo de seguridad requerido (cifrado del enlace de acceso o medidas superiores), preservando la igualdad y libre competencia en el proceso.
Requisito “802.1AE”. Solicitamos a la Convocante dejar como opcional el requerimiento de compatibilidad con el estándar IEEE 802.1AE (MACsec), o bien admitir funcionalidades de seguridad equivalentes o superiores que aseguren confidencialidad e integridad del tráfico a nivel de acceso (p. ej., mecanismos de seguridad de capa 2 o superiores con cifrado y control de acceso robusto).
La exigencia cerrada de un único estándar (802.1AE) no resulta indispensable para la consecución del objeto ni para la operación prevista, existiendo alternativas tecnológicas que brindan nivel de seguridad equivalente o superior. Mantenerlo como requisito obligatorio restringe injustificadamente la concurrencia, pudiendo direccionar la provisión a una sola marca/modelo, en contravención a los principios de igualdad y libre competencia de la Ley N° 7021/22.
La Ley 7021/22 dispone que los Pliegos de Bases y Condiciones (PBC) deben elaborarse conforme la reglamentación y documentos estándar de la DNCP, lo que impone a la convocante evitar exigencias que limiten la competencia sin justificación técnica proporcional (art. 45, primer párrafo).
Además, la Ley exige que, al definir la necesidad y estudiar el mercado, la convocante identifique proveedores y verifique si existe competencia, ajustando las condiciones del llamado en función de ese análisis. Requisitos técnicos que reducen artificialmente la concurrencia deben revisarse para asegurar pluralidad de oferentes (arts. 25 y 26).
La petición concreta es: Mantener 802.1AE como “opcional” y admitir soluciones equivalentes que cumplan el objetivo de seguridad requerido (cifrado del enlace de acceso o medidas superiores), preservando la igualdad y libre competencia en el proceso.
El Plan de entrega fija que “los bienes deberán ser entregados a los 15 días calendario posteriores a la recepción del anticipo”. Además, el propio pliego aclara que “día” significa día corrido, salvo que se indique hábil.
Por qué ese plazo restringe la concurrencia? El paquete incluye un Micro Data Center Modular y otros equipos de alta complejidad e importación; 15 días corridos tras el anticipo resultan materialmente insuficientes para fabricación/ensamble, despacho internacional, nacionalización, logística interna, instalación y puesta en marcha. (Ver que el propio PBC identifica el MDC Modular como parte del alcance).
Un plazo tan breve reduce artificialmente la cantidad de fabricantes y oferentes que pueden cumplir, afectando la igualdad y la libre competencia (principios del art. 4 de la Ley 7021/22) y contrariando el deber de que los PBC se ajusten a la reglamentación y documentos estándar de la DNCP (art. 45), evitando requisitos desproporcionados que no guardan relación con el objeto.
Pedido concreto (redacción propuesta para SICP): Solicitud de adecuación del Plan de Entrega
Atendiendo a que el Llamado incluye bienes de fabricación/importación compleja —en particular el Micro Data Center Modular— solicitamos:
a) Reemplazar el plazo actual de 15 días calendario por 120 días hábiles para el Ítem 1.5 (Micro Data Center Modular).
b) Establecer 60 días hábiles para los restantes ítems de equipamiento, cuando corresponda importación.
c) Prever entregas parciales y recepción provisional por hito (arribo/nacionalización, instalación, puesta en marcha), manteniendo las garantías y penalidades del contrato.
El pedido se fundamenta en lo siguiente: El plazo vigente no es razonable ni proporcional a los tiempos de fabricación, transporte internacional y formalidades aduaneras, por lo que restringe la concurrencia y podría direccionar el proceso, en tensión con los principios de igualdad y libre competencia (art. 4, Ley 7021/22). Asimismo, el art. 45 exige que los PBC se ajusten a la reglamentación y documentos estándar de la DNCP, evitando requerimientos que limiten la competencia sin justificación técnica equivalente.
Efectos: Dado que el ajuste implica modificar el PBC, solicitamos emitir Adenda y reflejar el nuevo Plan de Entrega; de corresponder, prorrogar los plazos del procedimiento conforme prevé el propio pliego ante modificaciones (p. ej., cuando se emiten adendas y prórrogas).
El Plan de entrega fija que “los bienes deberán ser entregados a los 15 días calendario posteriores a la recepción del anticipo”. Además, el propio pliego aclara que “día” significa día corrido, salvo que se indique hábil.
Por qué ese plazo restringe la concurrencia? El paquete incluye un Micro Data Center Modular y otros equipos de alta complejidad e importación; 15 días corridos tras el anticipo resultan materialmente insuficientes para fabricación/ensamble, despacho internacional, nacionalización, logística interna, instalación y puesta en marcha. (Ver que el propio PBC identifica el MDC Modular como parte del alcance).
Un plazo tan breve reduce artificialmente la cantidad de fabricantes y oferentes que pueden cumplir, afectando la igualdad y la libre competencia (principios del art. 4 de la Ley 7021/22) y contrariando el deber de que los PBC se ajusten a la reglamentación y documentos estándar de la DNCP (art. 45), evitando requisitos desproporcionados que no guardan relación con el objeto.
Pedido concreto (redacción propuesta para SICP): Solicitud de adecuación del Plan de Entrega
Atendiendo a que el Llamado incluye bienes de fabricación/importación compleja —en particular el Micro Data Center Modular— solicitamos:
a) Reemplazar el plazo actual de 15 días calendario por 120 días hábiles para el Ítem 1.5 (Micro Data Center Modular).
b) Establecer 60 días hábiles para los restantes ítems de equipamiento, cuando corresponda importación.
c) Prever entregas parciales y recepción provisional por hito (arribo/nacionalización, instalación, puesta en marcha), manteniendo las garantías y penalidades del contrato.
El pedido se fundamenta en lo siguiente: El plazo vigente no es razonable ni proporcional a los tiempos de fabricación, transporte internacional y formalidades aduaneras, por lo que restringe la concurrencia y podría direccionar el proceso, en tensión con los principios de igualdad y libre competencia (art. 4, Ley 7021/22). Asimismo, el art. 45 exige que los PBC se ajusten a la reglamentación y documentos estándar de la DNCP, evitando requerimientos que limiten la competencia sin justificación técnica equivalente.
Efectos: Dado que el ajuste implica modificar el PBC, solicitamos emitir Adenda y reflejar el nuevo Plan de Entrega; de corresponder, prorrogar los plazos del procedimiento conforme prevé el propio pliego ante modificaciones (p. ej., cuando se emiten adendas y prórrogas).
Solicitud de adecuación/flexibilización de especificaciones técnicas para promover concurrencia y evitar direccionamiento de marca.
Conforme al principio de igualdad y libre competencia, toda empresa técnicamente solvente debe poder participar “sin restricciones y en igualdad de oportunidades” (Ley 7021/22, art. 4, d). Por su parte, los pliegos deben elaborarse “con la mayor amplitud” para que concurra el mayor número de oferentes, debiendo ser claros, objetivos e imparciales, y no pueden exigir elementos no técnicamente indispensables si con ello se limitan las posibilidades de concurrencia (Ley 7021/22, art. 45, párrafos 3° y 5°).
A la luz de esas reglas, solicitamos ajustar mínimos o marcar como opcionales las siguientes exigencias del PBC, manteniendo el desempeño necesario para la operación y ampliando la competencia:
Interfaces de cobre:
Pliego: “Interfaces: ≥ 24 x 1GE RJ45”. Solicitamos aceptar ≥ 16 x 1GE RJ45 como mínimo suficiente (resto por SFP/SFP+), pues rara vez se utilizan 24 puertos en el perímetro; la reducción no afecta la finalidad ni la escalabilidad y evita direccionamiento de modelos muy específicos. (PBC, Caract. de Rendimiento y HW, ítem 14).
Uplinks de 10GE:
Pliego: “≥ 6 x 10GE SFP+ (incluir los SFP)”. Solicitamos aceptar ≥ 2 x 10GE SFP+ como base y permitir ampliación modular (módulos/slots) cuando la topología lo requiera. Esto preserva el objetivo técnico y evita restringir a un número de bahías inusual para esta gama. (PBC, ítem 18).
Puntos de Acceso soportados:
Pliego: “Puntos de Acceso Soportados: ≥ 512”. Pedimos marcarlo Opcional, por tratarse de una funcionalidad de gestión de APs no indispensable en un NGFW perimetral (el mismo pliego ya admite como opcional la administración de switches y AP desde la consola). (PBC, ítem 8 “Capacidad de administrar switches y AP — Opcional”).
Rendimientos máximos
“Inspección de Firewall: ≥ 17,5 Gbps” → solicitar marcar como referencial (no excluyente), atendiendo a que el rendimiento efectivo depende del perfil de tráfico y servicios activos. (Bloque de performance del NGFW).
“Prevención de amenazas: ≥ 9,4 Gbps” y “Inspección Antimalware: ≥ 9,4 Gbps” → solicitar aceptar a partir de 5,5 Gbps como mínimo razonable para el entorno del llamado (equilibrio entre costo/beneficio y necesidades reales), manteniendo la evaluación por valor por dinero. (Bloques de IPS/AV/AM).
“Inspección y Descifrado TLS/SSL (DPI SSL): ≥ 5 Gbps”, “Conexiones por segundo: ≥ 114.000”, y “Cantidad de conexiones DPI SSL: ≥ 350.000” → solicitar dejar como opcionales por ser parámetros fuertemente dependientes de políticas y niveles de cifrado, y cuya sobredimensión encarece sin aportar valor operativo cierto. (Bloques DPI/SSL y métricas asociadas).
Túneles VPN site-to-site
Pliego: “≥ 4.000”. Pedimos opcional o un mínimo sustancialmente menor (p.ej., ≥ 200), acorde a la arquitectura institucional prevista y a las mejores prácticas; mantener 4.000 obliga a equipos de nicho. (Bloque VPN IPSec/SSL).
Características de red avanzadas
Pliego exige, entre otros: ruteo multicast, jumbo frames, subinterfaces lógicas, NAT de origen/destino simultáneo, NAT64/NAT46, ECMP, PBR, PBR por FQDN, balanceo WAN específico (Round Robin/Spillover/Percentage). Solicitamos:
Mantener NAT y ruteo estándar, pero marcar como opcionales multicast, jumbo frames, subinterfaces lógicas, NAT64/NAT46, ECMP, PBR y PBR por FQDN, por no ser técnicamente indispensables para el objetivo perimetral y limitar la oferta a fabricantes puntuales. (PBC, ítems 41 a 47).
En balanceo de carga WAN, sustituir la exigencia de métodos específicos por la capacidad genérica de equilibrar enlaces (criterio funcional, no de marca/método). (PBC, ítem 40).
SD-WAN
Pliego: “Tecnología SD-WAN…” (ítem 49). Solicitar opcional: es una arquitectura que excede el rol perimetral mínimo del NGFW y condiciona a suites propietarias.
Autenticación y portal
“Para reglas con autenticación no transparente deberá proporcionarse un portal” → Opcional (muchas instituciones usan SSO/IdP externos). (ítem 54).
“Soportar reglas IPv6” → Opcional si la red objetivo aún es dual-stack o IPv4-only, evitando sobre-especificación. (ítem 56).
DPI y tráfico cifrado
“DPI bidireccional” y “DPI sin proxies” → Opcional (hay enfoques equivalentes con proxies/ICAP o modo TAP según políticas). (ítems 58 y 59).
“Definir excepciones a tráfico cifrado por dominio/categorías” → Opcional, dado que depende de la política de privacidad/seguridad de cada organismo. (ítem 61).
VPN e identificación fuerte
“IKEv1/v2” → Opcional mantener ambos; hoy IKEv2 suele bastar y mejora interoperabilidad sin atar marca. (ítem 64).
“Uso de OTP” → Opcional, ya que la MFA puede centralizarse en el IdP institucional (Entra ID/otros) y no en el NGFW. (ítem 67).
Filtros web “de marca”
“YouTube en modo restringido”, “Safe Search” y “evitar URLs embebidas” → Opcionales; son políticas de navegación que pueden resolverse en otras capas (proxy/DNS/IdP) y su exigencia como “excluyente” restringe la competencia. (ítems 78–80).
En virtud de los arts. 4, d) y 45 de la Ley 7021/22, y a fin de evitar la exigencia de elementos no técnicamente indispensables que limiten la concurrencia, solicitamos emitir adenda que: (i) ajuste mínimos donde arriba se propone (p.ej., 16×RJ45; ≥2×10GE SFP+ con ampliación), y (ii) marque como “Opcional/Referencial” los requerimientos de arquitectura avanzada, rendimientos pico y políticas de navegación que no resultan esenciales para la seguridad perimetral buscada, manteniendo la evaluación por valor por dinero conforme el propio PBC. Con estos cambios se preserva la finalidad técnica, se reduce el sesgo hacia modelos específicos y se garantiza igualdad y libre competencia entre múltiples fabricantes y oferentes.
Solicitud de adecuación/flexibilización de especificaciones técnicas para promover concurrencia y evitar direccionamiento de marca.
Conforme al principio de igualdad y libre competencia, toda empresa técnicamente solvente debe poder participar “sin restricciones y en igualdad de oportunidades” (Ley 7021/22, art. 4, d). Por su parte, los pliegos deben elaborarse “con la mayor amplitud” para que concurra el mayor número de oferentes, debiendo ser claros, objetivos e imparciales, y no pueden exigir elementos no técnicamente indispensables si con ello se limitan las posibilidades de concurrencia (Ley 7021/22, art. 45, párrafos 3° y 5°).
A la luz de esas reglas, solicitamos ajustar mínimos o marcar como opcionales las siguientes exigencias del PBC, manteniendo el desempeño necesario para la operación y ampliando la competencia:
Interfaces de cobre:
Pliego: “Interfaces: ≥ 24 x 1GE RJ45”. Solicitamos aceptar ≥ 16 x 1GE RJ45 como mínimo suficiente (resto por SFP/SFP+), pues rara vez se utilizan 24 puertos en el perímetro; la reducción no afecta la finalidad ni la escalabilidad y evita direccionamiento de modelos muy específicos. (PBC, Caract. de Rendimiento y HW, ítem 14).
Uplinks de 10GE:
Pliego: “≥ 6 x 10GE SFP+ (incluir los SFP)”. Solicitamos aceptar ≥ 2 x 10GE SFP+ como base y permitir ampliación modular (módulos/slots) cuando la topología lo requiera. Esto preserva el objetivo técnico y evita restringir a un número de bahías inusual para esta gama. (PBC, ítem 18).
Puntos de Acceso soportados:
Pliego: “Puntos de Acceso Soportados: ≥ 512”. Pedimos marcarlo Opcional, por tratarse de una funcionalidad de gestión de APs no indispensable en un NGFW perimetral (el mismo pliego ya admite como opcional la administración de switches y AP desde la consola). (PBC, ítem 8 “Capacidad de administrar switches y AP — Opcional”).
Rendimientos máximos
“Inspección de Firewall: ≥ 17,5 Gbps” → solicitar marcar como referencial (no excluyente), atendiendo a que el rendimiento efectivo depende del perfil de tráfico y servicios activos. (Bloque de performance del NGFW).
“Prevención de amenazas: ≥ 9,4 Gbps” y “Inspección Antimalware: ≥ 9,4 Gbps” → solicitar aceptar a partir de 5,5 Gbps como mínimo razonable para el entorno del llamado (equilibrio entre costo/beneficio y necesidades reales), manteniendo la evaluación por valor por dinero. (Bloques de IPS/AV/AM).
“Inspección y Descifrado TLS/SSL (DPI SSL): ≥ 5 Gbps”, “Conexiones por segundo: ≥ 114.000”, y “Cantidad de conexiones DPI SSL: ≥ 350.000” → solicitar dejar como opcionales por ser parámetros fuertemente dependientes de políticas y niveles de cifrado, y cuya sobredimensión encarece sin aportar valor operativo cierto. (Bloques DPI/SSL y métricas asociadas).
Túneles VPN site-to-site
Pliego: “≥ 4.000”. Pedimos opcional o un mínimo sustancialmente menor (p.ej., ≥ 200), acorde a la arquitectura institucional prevista y a las mejores prácticas; mantener 4.000 obliga a equipos de nicho. (Bloque VPN IPSec/SSL).
Características de red avanzadas
Pliego exige, entre otros: ruteo multicast, jumbo frames, subinterfaces lógicas, NAT de origen/destino simultáneo, NAT64/NAT46, ECMP, PBR, PBR por FQDN, balanceo WAN específico (Round Robin/Spillover/Percentage). Solicitamos:
Mantener NAT y ruteo estándar, pero marcar como opcionales multicast, jumbo frames, subinterfaces lógicas, NAT64/NAT46, ECMP, PBR y PBR por FQDN, por no ser técnicamente indispensables para el objetivo perimetral y limitar la oferta a fabricantes puntuales. (PBC, ítems 41 a 47).
En balanceo de carga WAN, sustituir la exigencia de métodos específicos por la capacidad genérica de equilibrar enlaces (criterio funcional, no de marca/método). (PBC, ítem 40).
SD-WAN
Pliego: “Tecnología SD-WAN…” (ítem 49). Solicitar opcional: es una arquitectura que excede el rol perimetral mínimo del NGFW y condiciona a suites propietarias.
Autenticación y portal
“Para reglas con autenticación no transparente deberá proporcionarse un portal” → Opcional (muchas instituciones usan SSO/IdP externos). (ítem 54).
“Soportar reglas IPv6” → Opcional si la red objetivo aún es dual-stack o IPv4-only, evitando sobre-especificación. (ítem 56).
DPI y tráfico cifrado
“DPI bidireccional” y “DPI sin proxies” → Opcional (hay enfoques equivalentes con proxies/ICAP o modo TAP según políticas). (ítems 58 y 59).
“Definir excepciones a tráfico cifrado por dominio/categorías” → Opcional, dado que depende de la política de privacidad/seguridad de cada organismo. (ítem 61).
VPN e identificación fuerte
“IKEv1/v2” → Opcional mantener ambos; hoy IKEv2 suele bastar y mejora interoperabilidad sin atar marca. (ítem 64).
“Uso de OTP” → Opcional, ya que la MFA puede centralizarse en el IdP institucional (Entra ID/otros) y no en el NGFW. (ítem 67).
Filtros web “de marca”
“YouTube en modo restringido”, “Safe Search” y “evitar URLs embebidas” → Opcionales; son políticas de navegación que pueden resolverse en otras capas (proxy/DNS/IdP) y su exigencia como “excluyente” restringe la competencia. (ítems 78–80).
En virtud de los arts. 4, d) y 45 de la Ley 7021/22, y a fin de evitar la exigencia de elementos no técnicamente indispensables que limiten la concurrencia, solicitamos emitir adenda que: (i) ajuste mínimos donde arriba se propone (p.ej., 16×RJ45; ≥2×10GE SFP+ con ampliación), y (ii) marque como “Opcional/Referencial” los requerimientos de arquitectura avanzada, rendimientos pico y políticas de navegación que no resultan esenciales para la seguridad perimetral buscada, manteniendo la evaluación por valor por dinero conforme el propio PBC. Con estos cambios se preserva la finalidad técnica, se reduce el sesgo hacia modelos específicos y se garantiza igualdad y libre competencia entre múltiples fabricantes y oferentes.
Señores de la Convocante, conforme al principio de igualdad y libre competencia, y a fin de evitar referencias cerradas a una sola marca o configuración, solicitamos flexibilizar/adecuar los siguientes requerimientos del Ítem 1.4 – NGFW, de modo que se admitan alternativas técnicamente equivalentes y prestaciones funcionales que aseguren el objetivo del servicio, sin restringir indebidamente la concurrencia. Recordamos que el propio PBC prevé que, cuando determinadas características solo puedan describirse por nomenclatura o marcas, deben usarse “a manera de referencia” y adecuadas a estándares internacionales, evitando cerrar el mercado; y que las modificaciones sustanciales en especificaciones deben instrumentarse por adenda con prórroga del tope de consultas, para garantizar la difusión y la concurrencia. Asimismo, el Artículo 45 de la Ley 7021/22 impone que los PBC se ajusten a los reglamentos y a los documentos estándar de la DNCP, lo que incluye redactar EETT neutrales y competitivas. A su vez, los Artículos 25 y 26 de la misma Ley obligan a definir la necesidad y realizar estudio de mercado, identificando proveedores y condiciones de transacción si existe o no competencia, para fijar requisitos acordes al contexto competitivo.
Bajo ese marco, proponemos:
A. Interfaces y capacidad física
1. “Interfaces: ≥ 24 x 1GE RJ45” → Aceptar ≥ 16 x 1GE RJ45 cuando se cumplan los anchos de banda y sesiones requeridos en el dimensionamiento real. Ello evita sobredimensionar puertos que “nunca se utilizan todos”, abriendo a más marcas sin afectar la función (neutralidad de marca del PBC).
2. “≥ 6 x 10GE SFP+ (incluir SFP)” → Aceptar 2 x 10GE SFP+ base, ampliables por módulos hasta el total requerido. Esta modularidad es práctica y evita atar la solución a una placa propietaria (neutralidad PBC).
B. Escalabilidad Wi-Fi/SD-Branch
3. “Puntos de Acceso Soportados: ≥ 512” → Dejar como opcional. La gestión de AP masiva suele ser de suites WLAN; exigir 512 en el NGFW puede direccionar a pocas marcas sin necesidad para el caso.
C. Rendimientos (Throughput)
4. “Inspección de Firewall: ≥ 17,5 Gbps” → Opcional (evaluar que el throughput cumpla la demanda real del sitio).
5. “Prevención de amenazas: ≥ 9,4 Gbps” → Aceptar ≥ 5,5 Gbps.
6. “Inspección Antimalware: ≥ 9,4 Gbps” → Aceptar ≥ 5,5 Gbps.
7. “DPI SSL: ≥ 5 Gbps” → Opcional, considerando que el descifrado TLS se activa selectivamente (impacto en privacidad/latencia).
8. “Conexiones por segundo: ≥ 114.000” y “Conexiones DPI SSL: ≥ 350.000” → Opcionales. Sugerimos ponderar por escenario de tráfico real; fijar umbrales muy altos suele concentrar la competencia en 1–2 marcas.
Fundamento general: neutralidad de EETT y apertura a equivalentes; adecuación a mercado/competencia (Ley 7021/22, arts. 25–26).
D. Funciones de red
9. Multicast, jumbo frames, subinterfaces lógicas, NAT origen/destino → Opcionales, dejando obligatorias solo las funciones esenciales del enrutamiento/NAT según diseño objetivo.
10. Balanceo de múltiples WAN (Round Robin/Spillover/Percentage) → Aceptar equilibrio bidireccional de carga u algoritmos funcionalmente equivalentes.
11. QoS (802.1p, DSCP, VoIP) y PBR por servicio/origen/destino/FQDN → Opcionales; mantener compatibilidad pero sin atar a implementaciones puntuales (evita direccionamiento de marca).
12. ECMP → Opcional.
13. Soporte IPv6 → Opcional (o “requerido si existe tráfico IPv6 en producción”).
Fundamento: evitar “atributos propietarios” como condición sine qua non cuando existen múltiples caminos técnicos para el mismo fin.
E. Seguridad avanzada (SSL, proxies, sandbox, A/V)
14. DPI bidireccional / sin proxies / excepciones por dominio/categoría → Opcionales; permitir estrategias equivalentes (p. ej., modo proxy explícito o bypass por política) cuando el objetivo de seguridad se cumple.
15. Compatibilidad IPS entre zonas internas y análisis de protocolos específicos (CIFS/NetBIOS, IM/P2P) → Opcionales o condicionados a casos de uso. CIFS/NetBIOS no siempre existe en entornos actuales.
16. Sandbox y lista detallada de tipos de archivos (PE, DLL, PDF, Office, JAR, APK, etc.) → Mantener sandbox como recomendable, pero no restrictivo a un único motor o nube; admitir equivalentes (on-prem/cloud) y listas de tipos configurables.
Fundamento: que las EETT describan requisitos esenciales y de funcionamiento (no implementaciones cerradas), como manda el PBC, y que se usen estándares/alternativas.
F. Autenticación/Control de navegación
17. Portal de autenticación para reglas no transparentes → Opcional (aceptar SSO/IdP equivalentes).
18. YouTube restringido / Safe Search y bloqueo de URLs embebidas → Opcionales; admitir equivalentes (en DNS, proxy seguro, integración con motores de búsqueda).
19. Autenticación (RADIUS, TACACS+, AD, LDAP, base interna, TS/Citrix, locales) → Opcional mantener al menos AD/LDAP/RADIUS; las demás como compatibles o equivalentes.
20. Cuotas de tiempo/tráfico por usuario → Opcional.
G. VPN/Acceso remoto/Zero Trust
21. IPSec IKEv1/v2 y OTP para VPN → Opcionales (aceptar MFA/IdP equivalentes).
22. ZTNA con verificación de postura (versión de agente/OS, ubicación, pantalla de bloqueo, app instalada, archivo, registro, cifrado de disco) → Opcional y no atado a un agente único; admitir controles equivalentes (NAC/MDM/EDR/ posture checks vía IdP).
23. Compatibilidades de agente por OS (macOS Ventura/Sonoma listados; Linux Fedora/Oracle/Ubuntu; iOS 15.x) → Aceptar familias de OS equivalentes (incluir CentOS y Ubuntu LTS diversos), y no fijar minor versions que direccionan fabricantes.
24. Integración con EDR (CrowdStrike, SentinelOne, Capture Client) → Opcional, admitir cualquier EDR con integración estándar (syslog/API).
25. Consola con revocación/asignación remota de licencias → Opcional (gestión puede residir en IdP/MDM/portal del fabricante).
Fundamento: describir función sin atar a marcas/agents concretos; documentos estándar DNCP/Art. 45.
H. Observación sobre requerimientos que parecen del Ítem 1.5 – Micro Data Center (MDC)
Hemos identificado exigencias como tensión/alimentación trifásica 380/400/415V, rangos de temperatura T1/T3/LT, carga TI 17–25 kW y densidad por rack 6–7 kW, que corresponden al Ítem 1.5 “Micro Data Center Modular” (no al NGFW). Solicitamos dejarlas como opcionales en la sección correcta (1.5) y no condicionantes del 1.4, a fin de evitar incompatibilidades cruzadas y restricciones no pertinentes al objeto del NGFW. El cuadro de suministros del PBC distingue expresamente ambos ítems (1.4 NGFW y 1.5 MDC).
Fundamento: que cada EETT especifique lo esencial y de funcionamiento del ítem correspondiente; si se ajustan o redistribuyen estas EETT por adenda, corresponderá prorrogar el tope de consultas.
Marco normativo invocado (síntesis)
• PBC – Neutralidad de marca y estándares: aludir a marcas solo como referencia, adecuando a estándares internacionales.
• PBC – EETT deben describir características esenciales/funcionales (no implementaciones propietarias).
• PBC – Aclaraciones/Adendas: modificaciones sustanciales implican adenda y prórroga del tope para consultas.
• Ley 7021/22, Art. 45 – PBC: su elaboración debe ajustarse a reglamentos y a documentos estándar DNCP
• Ley 7021/22, Arts. 25–26 – Necesidad y estudio de mercado: definir la necesidad y constatar competencia en el mercado para fijar requisitos acordes al contexto.
Petitorio:
i) Que la Convocante incorpore por adenda las flexibilizaciones detalladas, aceptando alternativas y equivalencias funcionales en los puntos arriba listados, conforme a la normativa vigente; y
ii) Que, de corresponder, se prorrogue el tope de consultas según PBC para asegurar la debida difusión.
Señores de la Convocante, conforme al principio de igualdad y libre competencia, y a fin de evitar referencias cerradas a una sola marca o configuración, solicitamos flexibilizar/adecuar los siguientes requerimientos del Ítem 1.4 – NGFW, de modo que se admitan alternativas técnicamente equivalentes y prestaciones funcionales que aseguren el objetivo del servicio, sin restringir indebidamente la concurrencia. Recordamos que el propio PBC prevé que, cuando determinadas características solo puedan describirse por nomenclatura o marcas, deben usarse “a manera de referencia” y adecuadas a estándares internacionales, evitando cerrar el mercado; y que las modificaciones sustanciales en especificaciones deben instrumentarse por adenda con prórroga del tope de consultas, para garantizar la difusión y la concurrencia. Asimismo, el Artículo 45 de la Ley 7021/22 impone que los PBC se ajusten a los reglamentos y a los documentos estándar de la DNCP, lo que incluye redactar EETT neutrales y competitivas. A su vez, los Artículos 25 y 26 de la misma Ley obligan a definir la necesidad y realizar estudio de mercado, identificando proveedores y condiciones de transacción si existe o no competencia, para fijar requisitos acordes al contexto competitivo.
Bajo ese marco, proponemos:
A. Interfaces y capacidad física
1. “Interfaces: ≥ 24 x 1GE RJ45” → Aceptar ≥ 16 x 1GE RJ45 cuando se cumplan los anchos de banda y sesiones requeridos en el dimensionamiento real. Ello evita sobredimensionar puertos que “nunca se utilizan todos”, abriendo a más marcas sin afectar la función (neutralidad de marca del PBC).
2. “≥ 6 x 10GE SFP+ (incluir SFP)” → Aceptar 2 x 10GE SFP+ base, ampliables por módulos hasta el total requerido. Esta modularidad es práctica y evita atar la solución a una placa propietaria (neutralidad PBC).
B. Escalabilidad Wi-Fi/SD-Branch
3. “Puntos de Acceso Soportados: ≥ 512” → Dejar como opcional. La gestión de AP masiva suele ser de suites WLAN; exigir 512 en el NGFW puede direccionar a pocas marcas sin necesidad para el caso.
C. Rendimientos (Throughput)
4. “Inspección de Firewall: ≥ 17,5 Gbps” → Opcional (evaluar que el throughput cumpla la demanda real del sitio).
5. “Prevención de amenazas: ≥ 9,4 Gbps” → Aceptar ≥ 5,5 Gbps.
6. “Inspección Antimalware: ≥ 9,4 Gbps” → Aceptar ≥ 5,5 Gbps.
7. “DPI SSL: ≥ 5 Gbps” → Opcional, considerando que el descifrado TLS se activa selectivamente (impacto en privacidad/latencia).
8. “Conexiones por segundo: ≥ 114.000” y “Conexiones DPI SSL: ≥ 350.000” → Opcionales. Sugerimos ponderar por escenario de tráfico real; fijar umbrales muy altos suele concentrar la competencia en 1–2 marcas.
Fundamento general: neutralidad de EETT y apertura a equivalentes; adecuación a mercado/competencia (Ley 7021/22, arts. 25–26).
D. Funciones de red
9. Multicast, jumbo frames, subinterfaces lógicas, NAT origen/destino → Opcionales, dejando obligatorias solo las funciones esenciales del enrutamiento/NAT según diseño objetivo.
10. Balanceo de múltiples WAN (Round Robin/Spillover/Percentage) → Aceptar equilibrio bidireccional de carga u algoritmos funcionalmente equivalentes.
11. QoS (802.1p, DSCP, VoIP) y PBR por servicio/origen/destino/FQDN → Opcionales; mantener compatibilidad pero sin atar a implementaciones puntuales (evita direccionamiento de marca).
12. ECMP → Opcional.
13. Soporte IPv6 → Opcional (o “requerido si existe tráfico IPv6 en producción”).
Fundamento: evitar “atributos propietarios” como condición sine qua non cuando existen múltiples caminos técnicos para el mismo fin.
E. Seguridad avanzada (SSL, proxies, sandbox, A/V)
14. DPI bidireccional / sin proxies / excepciones por dominio/categoría → Opcionales; permitir estrategias equivalentes (p. ej., modo proxy explícito o bypass por política) cuando el objetivo de seguridad se cumple.
15. Compatibilidad IPS entre zonas internas y análisis de protocolos específicos (CIFS/NetBIOS, IM/P2P) → Opcionales o condicionados a casos de uso. CIFS/NetBIOS no siempre existe en entornos actuales.
16. Sandbox y lista detallada de tipos de archivos (PE, DLL, PDF, Office, JAR, APK, etc.) → Mantener sandbox como recomendable, pero no restrictivo a un único motor o nube; admitir equivalentes (on-prem/cloud) y listas de tipos configurables.
Fundamento: que las EETT describan requisitos esenciales y de funcionamiento (no implementaciones cerradas), como manda el PBC, y que se usen estándares/alternativas.
F. Autenticación/Control de navegación
17. Portal de autenticación para reglas no transparentes → Opcional (aceptar SSO/IdP equivalentes).
18. YouTube restringido / Safe Search y bloqueo de URLs embebidas → Opcionales; admitir equivalentes (en DNS, proxy seguro, integración con motores de búsqueda).
19. Autenticación (RADIUS, TACACS+, AD, LDAP, base interna, TS/Citrix, locales) → Opcional mantener al menos AD/LDAP/RADIUS; las demás como compatibles o equivalentes.
20. Cuotas de tiempo/tráfico por usuario → Opcional.
G. VPN/Acceso remoto/Zero Trust
21. IPSec IKEv1/v2 y OTP para VPN → Opcionales (aceptar MFA/IdP equivalentes).
22. ZTNA con verificación de postura (versión de agente/OS, ubicación, pantalla de bloqueo, app instalada, archivo, registro, cifrado de disco) → Opcional y no atado a un agente único; admitir controles equivalentes (NAC/MDM/EDR/ posture checks vía IdP).
23. Compatibilidades de agente por OS (macOS Ventura/Sonoma listados; Linux Fedora/Oracle/Ubuntu; iOS 15.x) → Aceptar familias de OS equivalentes (incluir CentOS y Ubuntu LTS diversos), y no fijar minor versions que direccionan fabricantes.
24. Integración con EDR (CrowdStrike, SentinelOne, Capture Client) → Opcional, admitir cualquier EDR con integración estándar (syslog/API).
25. Consola con revocación/asignación remota de licencias → Opcional (gestión puede residir en IdP/MDM/portal del fabricante).
Fundamento: describir función sin atar a marcas/agents concretos; documentos estándar DNCP/Art. 45.
H. Observación sobre requerimientos que parecen del Ítem 1.5 – Micro Data Center (MDC)
Hemos identificado exigencias como tensión/alimentación trifásica 380/400/415V, rangos de temperatura T1/T3/LT, carga TI 17–25 kW y densidad por rack 6–7 kW, que corresponden al Ítem 1.5 “Micro Data Center Modular” (no al NGFW). Solicitamos dejarlas como opcionales en la sección correcta (1.5) y no condicionantes del 1.4, a fin de evitar incompatibilidades cruzadas y restricciones no pertinentes al objeto del NGFW. El cuadro de suministros del PBC distingue expresamente ambos ítems (1.4 NGFW y 1.5 MDC).
Fundamento: que cada EETT especifique lo esencial y de funcionamiento del ítem correspondiente; si se ajustan o redistribuyen estas EETT por adenda, corresponderá prorrogar el tope de consultas.
Marco normativo invocado (síntesis)
• PBC – Neutralidad de marca y estándares: aludir a marcas solo como referencia, adecuando a estándares internacionales.
• PBC – EETT deben describir características esenciales/funcionales (no implementaciones propietarias).
• PBC – Aclaraciones/Adendas: modificaciones sustanciales implican adenda y prórroga del tope para consultas.
• Ley 7021/22, Art. 45 – PBC: su elaboración debe ajustarse a reglamentos y a documentos estándar DNCP
• Ley 7021/22, Arts. 25–26 – Necesidad y estudio de mercado: definir la necesidad y constatar competencia en el mercado para fijar requisitos acordes al contexto.
Petitorio:
i) Que la Convocante incorpore por adenda las flexibilizaciones detalladas, aceptando alternativas y equivalencias funcionales en los puntos arriba listados, conforme a la normativa vigente; y
ii) Que, de corresponder, se prorrogue el tope de consultas según PBC para asegurar la debida difusión.
Sobre el Ítem 1.5 – MICRO DATA CENTER (MODULAR), se solicita tener en cuenta los siguientes puntos que restringen la competencia:
1) Dimensiones totales (Al × An × Pr): 2000×(600–7400)×1350 mm (Exigido)
Pedido: que se acepte rango equivalente y/o se deje como “referencial” (no excluyente).
Fundamento: el propio PBC indica que las EETT deben ser “lo suficientemente amplias para evitar restricciones” y utilizar normas equivalentes o superiores; fijar medidas cerradas limita la concurrencia sin acreditar necesidad funcional específica.
Principios: igualdad y libre competencia (art. 4, Ley 7021) y elección por valor por dinero; además, la Entidad debe definir la necesidad y alternativas (arts. 25 y 26) antes de cerrar especificaciones.
2) Capacidad de refrigeración: 12,5 kW (Exigido)
Pedido: que se admitan equipos desde 3,5 kW, o, alternativamente, que el requisito se exprese en función de la carga térmica real del proyecto (p. ej., “capacidad ≥ 1,2 × carga de TI prevista”).
Fundamento: la carga de TI y la densidad por rack ya están fijadas en el PBC; sin una justificación técnica, exigir 12,5 kW como mínimo podría ser desproporcionado y excluyente frente a soluciones modulares de menor huella/carga.
Principios/Reglas: planificación y estudio de mercado (arts. 25 y 26, Ley 7021) exigen ajustar la especificación a la necesidad demostrada y a soluciones alternativas disponibles, favoreciendo competencia y eficiencia.
3) Refrigeración inteligente: 1+1 (Exigido)
Pedido: que se acepten esquemas de redundancia funcionalmente equivalentes (N, N+1, 2N) según capacidad ofertada, o que el 1+1 sea optativo.
Fundamento: exigir una topología única restringe proveedores; el criterio debe ser disponibilidad y continuidad del servicio (resultado), no la única arquitectura. El PBC habilita aceptar normas/capacidades equivalentes.
4) Capacidad del SAI/UPS: 10 kVA (Exigido)
Pedido: que se admitan soluciones desde 6 kVA, siempre que cubran la carga de TI y tiempo de respaldo requeridos; o que se fije como criterio dimensionamiento por carga (kW) y autonomía.
Fundamento: el PBC fija carga de TI y tiempos de respaldo (15/30 min); dimensionar por regla fija de 10 kVA puede excluir equipos que cumplen funcionalmente.
Principios: igualdad/competencia y valor por dinero (optimización de recursos) favorecen especificar por desempeño, no por una potencia rígida.
5) Reconocimiento facial: “Estándar – Exigido”
Pedido: que pase a “Opcional” o que se acepte control de acceso equivalente (p. ej., credencial + PIN, biometría alternativa) sin proxy de marca.
Fundamento: se trata de un accesorio no esencial para la función principal (alojamiento y continuidad de TI) y reduce la concurrencia; el PBC ordena que las EETT eviten restricciones y acepten equivalentes.
Bases normativas y procedimentales invocadas. Principios (Ley 7021): igualdad de trato, libre competencia y valor por dinero (orientación a resultados y eficiencia). Planificación y Estudio de Mercado (arts. 25 y 26): la Entidad debe definir la necesidad, analizar soluciones alternativas y competencia en el mercado antes de cerrar EETT que podrían ser restrictivas.
Redacción técnica en el PBC: las EETT deben ser amplias y admitir normas equivalentes o superiores, evitando restricciones.
Solicitudes formales complementarias:
Adenda y prórroga del tope de consultas: si la Convocante acepta flexibilizar/modificar las EETT, deberá prorrogar obligatoriamente el plazo para consultas y emitir la adenda correspondiente (publicación en SICP), conforme el PBC.
Criterio de evaluación por desempeño: que en las especificaciones se priorice criterio funcional (carga de TI, autonomía, disponibilidad, eficiencia) por sobre marcas/modelos o topologías únicas, en línea con el valor por dinero.
Sobre el Ítem 1.5 – MICRO DATA CENTER (MODULAR), se solicita tener en cuenta los siguientes puntos que restringen la competencia:
1) Dimensiones totales (Al × An × Pr): 2000×(600–7400)×1350 mm (Exigido)
Pedido: que se acepte rango equivalente y/o se deje como “referencial” (no excluyente).
Fundamento: el propio PBC indica que las EETT deben ser “lo suficientemente amplias para evitar restricciones” y utilizar normas equivalentes o superiores; fijar medidas cerradas limita la concurrencia sin acreditar necesidad funcional específica.
Principios: igualdad y libre competencia (art. 4, Ley 7021) y elección por valor por dinero; además, la Entidad debe definir la necesidad y alternativas (arts. 25 y 26) antes de cerrar especificaciones.
2) Capacidad de refrigeración: 12,5 kW (Exigido)
Pedido: que se admitan equipos desde 3,5 kW, o, alternativamente, que el requisito se exprese en función de la carga térmica real del proyecto (p. ej., “capacidad ≥ 1,2 × carga de TI prevista”).
Fundamento: la carga de TI y la densidad por rack ya están fijadas en el PBC; sin una justificación técnica, exigir 12,5 kW como mínimo podría ser desproporcionado y excluyente frente a soluciones modulares de menor huella/carga.
Principios/Reglas: planificación y estudio de mercado (arts. 25 y 26, Ley 7021) exigen ajustar la especificación a la necesidad demostrada y a soluciones alternativas disponibles, favoreciendo competencia y eficiencia.
3) Refrigeración inteligente: 1+1 (Exigido)
Pedido: que se acepten esquemas de redundancia funcionalmente equivalentes (N, N+1, 2N) según capacidad ofertada, o que el 1+1 sea optativo.
Fundamento: exigir una topología única restringe proveedores; el criterio debe ser disponibilidad y continuidad del servicio (resultado), no la única arquitectura. El PBC habilita aceptar normas/capacidades equivalentes.
4) Capacidad del SAI/UPS: 10 kVA (Exigido)
Pedido: que se admitan soluciones desde 6 kVA, siempre que cubran la carga de TI y tiempo de respaldo requeridos; o que se fije como criterio dimensionamiento por carga (kW) y autonomía.
Fundamento: el PBC fija carga de TI y tiempos de respaldo (15/30 min); dimensionar por regla fija de 10 kVA puede excluir equipos que cumplen funcionalmente.
Principios: igualdad/competencia y valor por dinero (optimización de recursos) favorecen especificar por desempeño, no por una potencia rígida.
5) Reconocimiento facial: “Estándar – Exigido”
Pedido: que pase a “Opcional” o que se acepte control de acceso equivalente (p. ej., credencial + PIN, biometría alternativa) sin proxy de marca.
Fundamento: se trata de un accesorio no esencial para la función principal (alojamiento y continuidad de TI) y reduce la concurrencia; el PBC ordena que las EETT eviten restricciones y acepten equivalentes.
Bases normativas y procedimentales invocadas. Principios (Ley 7021): igualdad de trato, libre competencia y valor por dinero (orientación a resultados y eficiencia). Planificación y Estudio de Mercado (arts. 25 y 26): la Entidad debe definir la necesidad, analizar soluciones alternativas y competencia en el mercado antes de cerrar EETT que podrían ser restrictivas.
Redacción técnica en el PBC: las EETT deben ser amplias y admitir normas equivalentes o superiores, evitando restricciones.
Solicitudes formales complementarias:
Adenda y prórroga del tope de consultas: si la Convocante acepta flexibilizar/modificar las EETT, deberá prorrogar obligatoriamente el plazo para consultas y emitir la adenda correspondiente (publicación en SICP), conforme el PBC.
Criterio de evaluación por desempeño: que en las especificaciones se priorice criterio funcional (carga de TI, autonomía, disponibilidad, eficiencia) por sobre marcas/modelos o topologías únicas, en línea con el valor por dinero.
Declaración jurada Conocimiento del Sitio de la instalación.
Solicitamos a la convocante sea aceptada una declaración jurada de que el oferente cuenta con los conocimientos del sitio de la instalación y pueda presentarlo bajo fe de juramento con su oferta.
13-10-2025
Declaración jurada Conocimiento del Sitio de la instalación.
Solicitamos a la convocante sea aceptada una declaración jurada de que el oferente cuenta con los conocimientos del sitio de la instalación y pueda presentarlo bajo fe de juramento con su oferta.
Solicitamos respetuosamente a la convocante pueda aceptar una declaración jurada de que el oferente tiene conocimiento del sitio de la instalación para ofertar o que se vuelva a habilitar una nueva fecha para la visita técnica en caso de que la convocante establezca como obligatorio la presentación de la constancia de la visita para ofertar en esta licitación. Esto amparado en las leyes vigentes de contrataciones publicas, de modo a tener mayor competencia y ofertas a beneficio de la convocante, por otro lado la aceptación de dicha solicitud evitará afectar al proceso con posibles protestas por limitar la participación.
Solicitamos respetuosamente a la convocante pueda aceptar una declaración jurada de que el oferente tiene conocimiento del sitio de la instalación para ofertar o que se vuelva a habilitar una nueva fecha para la visita técnica en caso de que la convocante establezca como obligatorio la presentación de la constancia de la visita para ofertar en esta licitación. Esto amparado en las leyes vigentes de contrataciones publicas, de modo a tener mayor competencia y ofertas a beneficio de la convocante, por otro lado la aceptación de dicha solicitud evitará afectar al proceso con posibles protestas por limitar la participación.