[lacnog] Announcing Windows CLAT Public Preview
Uesley Correa
uesleycorrea en gmail.com
Vie Jul 31 14:16:43 -03 2026
[image: image.png]
¿Es buena práctica o no? ¿Lo dejarían sangrar hasta la muerte?
Dejo como reflexión.
Uesley Corrêa - Analista de Telecomunicaciones
CEO Telecom ISP Solutions
On Fri, Jul 31, 2026 at 2:14 PM Uesley Correa <uesleycorrea en gmail.com>
wrote:
> Jordi,
>
> Y por eso me guardo el derecho de no hacer lo que va en contra de mis
> ideales. Punto. En ningún momento dije que hago o que apruebo. Pero tampoco
> debo decir que alguien es irresponsable por tomar una decisión que
> corresponde a SU PROPIO NEGOCIO. Son las reglas del juego. Como dijiste del
> médico (y bien dicho), te invito a conocer un poco más la salud
> principalmente pública de la mayoría de los países (fuera de tu burbuja).
> Vas a ver que todo lo que dijiste suena muy lindo en los libros y en los
> conceptos, pero en la vida real no funciona así. Bienvenido a la vida real
> :-)
>
> Saludos,
>
> Uesley Corrêa - Analista de Telecomunicaciones
> CEO Telecom ISP Solutions
>
>
> On Fri, Jul 31, 2026 at 1:59 PM jordi.palet--- vía LACNOG <
> lacnog en lacnic.net> wrote:
>
>> Hola Uesley,
>>
>> Entiendo totalmente lo de bailar al son de la musica que toca, igual que
>> lo de la falta de tiempo libre, pero no puedo estar de acuerdo.
>>
>> Cualquier persona o empresa que atienda a clientes tenemos la obligación
>> de hacerlo bien y eso exige la continua autoformación.
>>
>> Es como decir que un médico no tiene que seguir formándose continuamente
>> y estar al cabo del más mínimo nuevo conocimiento que surja.
>>
>> Entiendo que las empresas están para ganar dinero, todos lo necesitamos
>> al menos para vivir, pero me parecía poco ético no hacerlo al 1000%, igual
>> que lo sería en el caso de un médico. Es más, un médico que por no estar al
>> día, cometa errores en la salud de un paciente, estaría incurriendo en
>> delito, no? Quizás no tenemos la misma percepción cuando no esta en juego
>> la vida humana y ese es parte del problema? Ya se que nos metemos en
>> discusiones filosóficas! Pero a veces hay que tener esa perspectiva.
>>
>> También entiendo que le recomendemos al cliente como hacer las cosas con
>> las mejores prácticas y que muchas veces el cliente no quiere. Pero lo
>> importante, es haberlo documentado para que el cliente no te lo pueda echar
>> a tu espalda en el futuro. Hay una responsabilidad civil frente a terceros
>> cuando hacemos trabajos para otros, da igual que sea empresa o persona, ni
>> mas ni menos que la que tiene el médico, aunque parezca que no es tan grave
>> porque es ingeniería, no salud! pero puede que una ingeniería mal hecha
>> impacte en un mecanismo que vigila la salud de una persona!
>>
>> Saludos,
>> Jordi
>>
>> @jordipalet
>>
>> El 31 jul 2026, a las 12:48, Uesley Correa <uesleycorrea en gmail.com>
>> escribió:
>>
>> Hola!
>>
>> Coincido con Fernando sobre “tiempo libre”. Como casi no lo tengo, leo
>> cuando puedo. Y veo que estamos como perros tras la cola. Yo me considero
>> evangelista de IPv6. Pero al fin del día, me baso en dos conceptos:
>>
>> - autonomía de sistema. Si alguien es sistema autónomo, puedo recomendar
>> e indicar buenas prácticas. Pero él es quien va a decidir qué hacer en su
>> sistema autónomo. Y claro, convivir con consecuencias que puedan existir;
>> - el que paga la cuenta. Quien paga la cuenta, me paga para solucionar.
>> El no quiere saber si lo hago con IPv4, IPv6, IPv8 o fragmentos de roca
>> lunar. Nuevamente, puedo recomendarle mejores prácticas (de hecho, eso hace
>> parte de mi trabajo) pero si quien paga no está dispuesto, que hago yo?
>>
>> En mi red personal, en mi sistema autónomo, las cosas andan como a mí me
>> gusta. De resto, aprendí a bailar como suena la canción.
>>
>> Saludos!
>>
>>
>> Enviado do Gmail para iPad
>>
>> On Fri, 31 Jul 2026 at 07:31 Fernando Frediani <fhfrediani en gmail.com>
>> wrote:
>>
>>> Olá Fernando
>>>
>>> É um pouco confuso pra mim compreender o que quer dizer quando fala de
>>> maneira tão pragmática sobre maneiras de implementação de IPv6, fora do que
>>> as RFCs e boas práticas recomendam e trata NAT66 e similares como
>>> ferramentas legítimas e aceitáveis para qualquer cenário.
>>>
>>> Vejo que não é e nem deve ser assim, principalmente em locais onde
>>> existem l pessoas buscando aprender como fazer da maneira correta e pessoas
>>> que são referência pública devem prpcurar ensinar qual é o caminho e as
>>> melhores práticas e que se basear no que o IETF produz faz sim sentido.
>>>
>>> Já é difícil para pessoas em geral que não são da área de
>>> telecomunicações e internet como nós aqui (em geral gerentes de TI,
>>> desenvolvedores, etc) entender redes e IPv6. Não me parece razoável dizer à
>>> eles que está tudo bem em fazer NAT66 "já que resolve um problema".
>>>
>>> Qual o sentido de desenvolver todo um trabalho no IETF, que leva meses
>>> ou até anos para virar padrão no intuito de que a Internet possa trabalhar
>>> em consenso e possa ser referência para vendors desenvolverem seus produtos
>>> se de maneira muito fácil ignora-se isso para "resolver um problema" ?
>>>
>>> Fernando
>>>
>>> On Thu, 30 Jul 2026, 19:13 Fernando Gont, <fgont en si6networks.com> wrote:
>>>
>>>> On 30/07/2026 06:33, jordi.palet--- vía LACNOG wrote:
>>>> >
>>>> >> El 25 jul 2026, a las 1:28, Fernando Gont <fgont en si6networks.com>
>>>> escribió:
>>>> >>
>>>> >> On 24/07/2026 19:28, Fernando Frediani wrote:
>>>> >>> No estoy de acuerdo con algunos puntos.
>>>> >>> Los firewalls existen por una razón. Que una dirección IP sea
>>>> pública no significa que deba estar sin protección.
>>>> >>
>>>> >> Nadie argumento eso.
>>>> >>
>>>> >> El argumento fue otro: Nada es gratis.
>>>> >
>>>> > Ninguna evolución de nada, en la vida, es gratis!
>>>>
>>>> El concern suele tenerlo quien tiene que pagar la cuenta.... :-)
>>>>
>>>>
>>>>
>>>> >> Cuando los sistemas no tienen direcciones publicas, precisas de que
>>>> un sistema este explicitamente traduciendo direcciones para que alguien
>>>> llegue al sistema en cuestion (fail-safe, default deny),
>>>> >>
>>>> >
>>>> > Que las direcciones sean públicas/globales o privadas no
>>>> necesariamente implica seguridad. Un router de borde o incorpora un
>>>> firewall, o lo tiene justo detrás.
>>>> >
>>>> >> Por otro lado, a partir del momento en que utilizas direccionamiento
>>>> publico, quedas expuesto a todos los issues de renumbering (
>>>> https://www.rfc-editor.org/rfc/rfc9096.html). Mientras que si
>>>> utilizas direccionamiento privado, eso no te afecta.
>>>> >>
>>>> >>
>>>> >
>>>> > Pero te afectan otros, y hay que poner en la balanza si es mejor
>>>> prefijos persistentes, frente a prefijos globales y privadas y complejidad
>>>> añadida, cuando los prefijos persistentes, no suponen complejidad añadida,
>>>> porque el CPE igualmente debe tener firewall.
>>>>
>>>> El problema es, justamente, que quien es afectado no controla eso. Asi
>>>> de simple.
>>>>
>>>>
>>>>
>>>> >>> Y estoy de acuerdo en que no se debe fomentar ni enseñar NAT66 ni
>>>> NPTv6,
>>>> >>> ya que no son buenas prácticas y van en contra del espíritu de
>>>> IPv6. Que > alguien las use y funcionen no significa que sean correctas.
>>>> >>
>>>> >> Ahi es donde esta el error: estas aceptando a IPv6 como dogma.
>>>> >
>>>> > Lo que hacemos es aceptar la evolución que tenemos. Si en lugar de
>>>> IPv6, hubiera sido TP/IX, aceptaríamos igual esa evolución.
>>>>
>>>> A mi me parece una vision derrotista. :-)
>>>>
>>>> Por que alguien deberia aceptar como "dogma", algo desarrollado en un
>>>> momento sin gran experiencia operacional (y en un entorno
>>>> complemtamente
>>>> diferente), y que en 30 años logro 50% de *trafico* (no necesariamente
>>>> despliegue!)?
>>>>
>>>>
>>>> Por el contrario: creo que hay que arreglar todo lo que hay para
>>>> arreglar.
>>>>
>>>> Que IETF (6man en particular) pueda convivir felizmente con la idea que
>>>> multihoming/multiaddressing no funciona, deberia espantarnos.
>>>>
>>>>
>>>>
>>>> >
>>>> >> Repito lo mismo de antes: hay millones de cosas en IPv6 que nadie
>>>> las repetiria en un protocolo si hoy uno fuera a diseñar uno desde cero.
>>>> >> (encabezados de extension, DHCPv6 y SLAAC, etc.)
>>>> >
>>>> >
>>>> > Debatible: diferentes personas tiene diferentes puntos de vista. El
>>>> consenso al que llegamos en IETF, hoy podría no ser el mismo, pero
>>>> podríamos caer en otros diseños que podríamos también debatir como erróneos.
>>>>
>>>> SLAAC vs DHCPv6 es debatible? :-)
>>>>
>>>> La situacion en materia de configuracion automatica se resume a: bien
>>>> fea. --- llegando a cosas tales como implementar registro
>>>> dedirecciones
>>>> en SLAAC.
>>>>
>>>>
>>>> (Repito: los largos debates sostenidos en el tiempo sobre este tema me
>>>> parecen de poca honra al tiempo que se nos ha dado en este planeta) --
>>>> lo que alguno llamaria "gente con mucho tiempo libre" o personas "sin
>>>> problemas reaLes por resolver".
>>>>
>>>> Frecuentemente uno se queda con la idea que hay mas ganas de debetir --
>>>> por el debate en si -- que en solucionar problemas o hacerle la vida
>>>> mas
>>>> facil a quien quiera desplegar IPv6.
>>>>
>>>> Slds,
>>>> --
>>>> Fernando Gont
>>>> SI6 Networks
>>>> e-mail: fgont en si6networks.com
>>>> PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494
>>>>
>>>> _______________________________________________
>>>> LACNOG mailing list
>>>> LACNOG en lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>>
>>> _______________________________________________
>>> LACNOG mailing list
>>> LACNOG en lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/lacnog
>>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>>
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>
>>
>>
>> **********************************************
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com
>> The IPv6 Company
>>
>> This electronic message contains information which may be privileged or
>> confidential. The information is intended to be for the exclusive use of
>> the individual(s) named above and further non-explicilty authorized
>> disclosure, copying, distribution or use of the contents of this
>> information, even if partially, including attached files, is strictly
>> prohibited and will be considered a criminal offense. If you are not the
>> intended recipient be aware that any disclosure, copying, distribution or
>> use of the contents of this information, even if partially, including
>> attached files, is strictly prohibited, will be considered a criminal
>> offense, so you must reply to the original sender to inform about this
>> communication and delete it.
>>
>> _______________________________________________
>> LACNOG mailing list
>> LACNOG en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/lacnog
>> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog
>>
>
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20260731/a1e8c7f3/attachment-0001.htm>
------------ próxima parte ------------
Se ha borrado un mensaje adjunto que no está en formato texto plano...
Nombre : image.png
Tipo : image/png
Tamaño : 1241018 bytes
Descripción: no disponible
Url : <https://mail.lacnic.net/pipermail/lacnog/attachments/20260731/a1e8c7f3/attachment-0001.png>
Más información sobre la lista de distribución LACNOG