Para el Ítem 1, solicitamos a la convocante tenga a bien modificar el parámetro de “Cantidad mínima de ACL basadas en el puerto aplicadas al ingreso de los paquetes” a “Cantidad mínima de ACLs”, considerando que la restricción a un tipo específico de implementación (basadas en puerto e ingreso) limita innecesariamente la arquitectura de los equipos, cuando en la práctica las ACL pueden aplicarse en distintos niveles (L2/L3, ingreso/egreso) sin afectar su funcionalidad. Esta modificación permite mayor flexibilidad en el diseño de red, evita condicionamientos a implementaciones particulares de fabricantes y garantiza la participación de un mayor número de oferentes, sin comprometer la seguridad, el control de tráfico ni la operación del sistema.
Para el Ítem 1, solicitamos a la convocante tenga a bien modificar el parámetro de “Cantidad mínima de ACL basadas en el puerto aplicadas al ingreso de los paquetes” a “Cantidad mínima de ACLs”, considerando que la restricción a un tipo específico de implementación (basadas en puerto e ingreso) limita innecesariamente la arquitectura de los equipos, cuando en la práctica las ACL pueden aplicarse en distintos niveles (L2/L3, ingreso/egreso) sin afectar su funcionalidad. Esta modificación permite mayor flexibilidad en el diseño de red, evita condicionamientos a implementaciones particulares de fabricantes y garantiza la participación de un mayor número de oferentes, sin comprometer la seguridad, el control de tráfico ni la operación del sistema.
Para el Ítem 1, solicitamos a la convocante tenga a bien modificar el parámetro de “Cantidad mínima de ACL basadas en VLAN aplicadas al ingreso de los paquetes: 2.000” a “Soporte de ACLs: Exigido”, considerando que la exigencia de una cantidad específica y de un tipo particular de implementación constituye una sobre-especificación que no necesariamente responde a requerimientos reales de la red. En la práctica, la efectividad de las ACL no depende exclusivamente de su aplicación por VLAN ni de una cantidad elevada, sino de su correcta definición y ubicación dentro de la arquitectura de red. Mantener este requisito limita innecesariamente la participación de oferentes y condiciona la solución a tecnologías específicas, sin aportar beneficios tangibles en términos de seguridad, control de tráfico o desempeño. La modificación propuesta asegura flexibilidad tecnológica, igualdad de condiciones y una implementación eficiente, sin comprometer la operación ni la seguridad del sistema.
Para el Ítem 1, solicitamos a la convocante tenga a bien modificar el parámetro de “Cantidad mínima de ACL basadas en VLAN aplicadas al ingreso de los paquetes: 2.000” a “Soporte de ACLs: Exigido”, considerando que la exigencia de una cantidad específica y de un tipo particular de implementación constituye una sobre-especificación que no necesariamente responde a requerimientos reales de la red. En la práctica, la efectividad de las ACL no depende exclusivamente de su aplicación por VLAN ni de una cantidad elevada, sino de su correcta definición y ubicación dentro de la arquitectura de red. Mantener este requisito limita innecesariamente la participación de oferentes y condiciona la solución a tecnologías específicas, sin aportar beneficios tangibles en términos de seguridad, control de tráfico o desempeño. La modificación propuesta asegura flexibilidad tecnológica, igualdad de condiciones y una implementación eficiente, sin comprometer la operación ni la seguridad del sistema.
Para el Ítem 1, solicitamos a la convocante tenga a bien modificar el parámetro de “Soporte de EAP-MD5” a opcional, considerando que este método se encuentra obsoleto y presenta vulnerabilidades conocidas, al no proporcionar mecanismos de protección robustos como autenticación mutua ni cifrado de credenciales. Mantenerlo como obligatorio no solo no aporta mejoras en la seguridad de la red, sino que puede implicar riesgos innecesarios y limitar la adopción de métodos más seguros y actuales, como EAP-TLS o PEAP. Asimismo, su exigencia restringe la participación de oferentes cuyos equipos priorizan estándares modernos de seguridad. Establecerlo como opcional promueve el uso de tecnologías más seguras, garantiza la flexibilidad en la implementación y no compromete la operación ni la protección del sistema.
Para el Ítem 1, solicitamos a la convocante tenga a bien modificar el parámetro de “Soporte de EAP-MD5” a opcional, considerando que este método se encuentra obsoleto y presenta vulnerabilidades conocidas, al no proporcionar mecanismos de protección robustos como autenticación mutua ni cifrado de credenciales. Mantenerlo como obligatorio no solo no aporta mejoras en la seguridad de la red, sino que puede implicar riesgos innecesarios y limitar la adopción de métodos más seguros y actuales, como EAP-TLS o PEAP. Asimismo, su exigencia restringe la participación de oferentes cuyos equipos priorizan estándares modernos de seguridad. Establecerlo como opcional promueve el uso de tecnologías más seguras, garantiza la flexibilidad en la implementación y no compromete la operación ni la protección del sistema.
Para el Ítem 1, solicitamos a la convocante tenga a bien modificar el parámetro de “Cantidad mínima de grupos LAG por sistema: 100” a “Tamaño de LAG: hasta 48”, considerando que la exigencia de una cantidad elevada de grupos LAG constituye un sobredimensionamiento que no necesariamente responde a los requerimientos reales de la red. En la práctica, la eficiencia y disponibilidad de la agregación de enlaces dependen más de la capacidad y tamaño de cada LAG que de la cantidad total de grupos configurables. Mantener el requisito actual limita la participación de oferentes y condicionar la solución a arquitecturas específicas, sin aportar beneficios tangibles en términos de rendimiento o continuidad operativa.
Para el Ítem 1, solicitamos a la convocante tenga a bien modificar el parámetro de “Cantidad mínima de grupos LAG por sistema: 100” a “Tamaño de LAG: hasta 48”, considerando que la exigencia de una cantidad elevada de grupos LAG constituye un sobredimensionamiento que no necesariamente responde a los requerimientos reales de la red. En la práctica, la eficiencia y disponibilidad de la agregación de enlaces dependen más de la capacidad y tamaño de cada LAG que de la cantidad total de grupos configurables. Mantener el requisito actual limita la participación de oferentes y condicionar la solución a arquitecturas específicas, sin aportar beneficios tangibles en términos de rendimiento o continuidad operativa.
Para el Ítem 1, solicitamos a la convocante tenga a bien eliminar o establecer como opcional el requisito de “Cantidad mínima de puertos pertenecientes a grupos LAG”, considerando que esta exigencia constituye una sobre-especificación que no necesariamente responde a los requerimientos reales de la red. En la práctica, la cantidad de puertos por grupo LAG depende del diseño específico de la arquitectura y de las necesidades de redundancia y capacidad, no siendo un parámetro fijo determinante para el desempeño o la continuidad operativa. Mantener este requisito limitara la participación de oferentes y condicionara la solución a implementaciones particulares de ciertos fabricantes, sin aportar beneficios tangibles en términos de rendimiento o disponibilidad.
Para el Ítem 1, solicitamos a la convocante tenga a bien eliminar o establecer como opcional el requisito de “Cantidad mínima de puertos pertenecientes a grupos LAG”, considerando que esta exigencia constituye una sobre-especificación que no necesariamente responde a los requerimientos reales de la red. En la práctica, la cantidad de puertos por grupo LAG depende del diseño específico de la arquitectura y de las necesidades de redundancia y capacidad, no siendo un parámetro fijo determinante para el desempeño o la continuidad operativa. Mantener este requisito limitara la participación de oferentes y condicionara la solución a implementaciones particulares de ciertos fabricantes, sin aportar beneficios tangibles en términos de rendimiento o disponibilidad.
Para el Ítem 1, solicitamos a la convocante tenga a bien eliminar o establecer como opcional el requisito de “No debe almacenar el password de los administradores localmente, se debe generar un hash MD5 o SHA1 en configuración local”, considerando que la exigencia específica de algoritmos como MD5 o SHA1 resulta técnicamente desactualizada, debido a sus vulnerabilidades conocidas y su progresivo desuso en estándares modernos de seguridad. Asimismo, este requerimiento entra en conflicto con implementaciones más robustas que utilizan algoritmos actuales (como SHA-256 y otros mecanismos avanzados de protección de credenciales), o con esquemas de autenticación centralizada (RADIUS/TACACS+) donde no se almacenan credenciales localmente. Mantener esta exigencia limita la participación de oferentes y restringe la adopción de mejores prácticas de seguridad. Su modificación permite flexibilidad tecnológica, permitirá el uso de mecanismos más seguros y garantiza la protección de credenciales sin comprometer la operación.
Para el Ítem 1, solicitamos a la convocante tenga a bien eliminar o establecer como opcional el requisito de “No debe almacenar el password de los administradores localmente, se debe generar un hash MD5 o SHA1 en configuración local”, considerando que la exigencia específica de algoritmos como MD5 o SHA1 resulta técnicamente desactualizada, debido a sus vulnerabilidades conocidas y su progresivo desuso en estándares modernos de seguridad. Asimismo, este requerimiento entra en conflicto con implementaciones más robustas que utilizan algoritmos actuales (como SHA-256 y otros mecanismos avanzados de protección de credenciales), o con esquemas de autenticación centralizada (RADIUS/TACACS+) donde no se almacenan credenciales localmente. Mantener esta exigencia limita la participación de oferentes y restringe la adopción de mejores prácticas de seguridad. Su modificación permite flexibilidad tecnológica, permitirá el uso de mecanismos más seguros y garantiza la protección de credenciales sin comprometer la operación.
Para el Ítem 1, solicitamos a la convocante tenga a bien eliminar o establecer como opcional el requisito de “Soporte de configuración de rescate almacenada especialmente por el administrador”, considerando que esta funcionalidad no es esencial para la operación de la red, ya que los mecanismos estándares de respaldo y recuperación de configuración (backup/restore) permiten cumplir con los mismos objetivos de forma eficiente y controlada. Mantener su obligatoriedad limita la presentación de diferentes marcas y responde a implementaciones específicas de ciertos fabricantes, limitando la participación de oferentes y la compatibilidad de soluciones. Su eliminación o establecimiento como opcional garantiza flexibilidad tecnológica, evita restricciones innecesarias y permite mantener la continuidad operativa y la capacidad de recuperación del sistema sin comprometer su estabilidad ni administración.
Para el Ítem 1, solicitamos a la convocante tenga a bien eliminar o establecer como opcional el requisito de “Soporte de configuración de rescate almacenada especialmente por el administrador”, considerando que esta funcionalidad no es esencial para la operación de la red, ya que los mecanismos estándares de respaldo y recuperación de configuración (backup/restore) permiten cumplir con los mismos objetivos de forma eficiente y controlada. Mantener su obligatoriedad limita la presentación de diferentes marcas y responde a implementaciones específicas de ciertos fabricantes, limitando la participación de oferentes y la compatibilidad de soluciones. Su eliminación o establecimiento como opcional garantiza flexibilidad tecnológica, evita restricciones innecesarias y permite mantener la continuidad operativa y la capacidad de recuperación del sistema sin comprometer su estabilidad ni administración.
Para el Ítem 1, solicitamos a la convocante tenga a bien eliminar o establecer como opcional el requisito de “Permitirá deshacer cambios de configuración que no se confirmen dentro de un plazo preestablecido”, considerando que esta funcionalidad no es esencial para la operación de la red, ya que los procedimientos estándar de gestión de cambios, junto con mecanismos de respaldo y restauración de configuración, permiten recuperar estados previos de forma controlada. Asimismo, esta característica corresponde a implementaciones específicas de ciertos fabricantes, por lo que su obligatoriedad limita la participación de oferentes y condiciona la solución tecnológica.
Para el Ítem 1, solicitamos a la convocante tenga a bien eliminar o establecer como opcional el requisito de “Permitirá deshacer cambios de configuración que no se confirmen dentro de un plazo preestablecido”, considerando que esta funcionalidad no es esencial para la operación de la red, ya que los procedimientos estándar de gestión de cambios, junto con mecanismos de respaldo y restauración de configuración, permiten recuperar estados previos de forma controlada. Asimismo, esta característica corresponde a implementaciones específicas de ciertos fabricantes, por lo que su obligatoriedad limita la participación de oferentes y condiciona la solución tecnológica.
Para el Ítem 1, solicitamos a la convocante tenga a bien eliminar o establecer como opcional el requisito de “Capacidad de soportar la función de envío de pruebas para evaluar el desempeño en tiempo real de la red (RPM)”, considerando que esta funcionalidad no es esencial para la operación normal de la red ni para garantizar la continuidad de los servicios. La obligatoriedad de RPM limita la participación de oferentes, ya que no todos los fabricantes implementan esta función de manera nativa, y generará costos adicionales innecesarios sin mejorar la estabilidad, seguridad o desempeño de la infraestructura. Eliminarla o establecerla como opcional permite flexibilidad tecnológica, asegura igualdad de condiciones para los oferentes y mantiene la eficiencia de la inversión pública sin comprometer la operación ni la gestión efectiva del rendimiento de la red.
Para el Ítem 1, solicitamos a la convocante tenga a bien eliminar o establecer como opcional el requisito de “Capacidad de soportar la función de envío de pruebas para evaluar el desempeño en tiempo real de la red (RPM)”, considerando que esta funcionalidad no es esencial para la operación normal de la red ni para garantizar la continuidad de los servicios. La obligatoriedad de RPM limita la participación de oferentes, ya que no todos los fabricantes implementan esta función de manera nativa, y generará costos adicionales innecesarios sin mejorar la estabilidad, seguridad o desempeño de la infraestructura. Eliminarla o establecerla como opcional permite flexibilidad tecnológica, asegura igualdad de condiciones para los oferentes y mantiene la eficiencia de la inversión pública sin comprometer la operación ni la gestión efectiva del rendimiento de la red.
Para el Ítem 1, solicitamos a la convocante tenga a bien modificar el parámetro de ““100-120V / 200-240V auto detectable” a “Alimentación de 100-240V”, considerando que esta modificación garantiza la compatibilidad con cualquier rango de voltaje comúnmente disponible, facilita la instalación en distintos entornos y evita limitaciones innecesarias en la elección de marcas. La modificación mantiene la seguridad y el correcto funcionamiento del sistema, a la vez que amplía la participación de oferentes y permite soluciones más flexibles y eficientes en la infraestructura eléctrica. Así también, se adecua los rangos de voltaje del país.
Para el Ítem 1, solicitamos a la convocante tenga a bien modificar el parámetro de ““100-120V / 200-240V auto detectable” a “Alimentación de 100-240V”, considerando que esta modificación garantiza la compatibilidad con cualquier rango de voltaje comúnmente disponible, facilita la instalación en distintos entornos y evita limitaciones innecesarias en la elección de marcas. La modificación mantiene la seguridad y el correcto funcionamiento del sistema, a la vez que amplía la participación de oferentes y permite soluciones más flexibles y eficientes en la infraestructura eléctrica. Así también, se adecua los rangos de voltaje del país.