[LACNIC/Politicas] LAC-2025-5: Sub-asignación de Recursos IPv4 a Terceros
Fernando Frediani
fhfrediani at gmail.com
Thu Oct 30 23:19:05 -03 2025
Uesley, agradeço a resposta e o esclarecimento.
E você tem razão ! Não havia lido exatamente dessa maneira que você
explicou e de fato o receptor por ter recursos atribuídos por LACNIC
necessita ser membro e para ser membro ter presença legal na região.
A única ressalva que faço com relação à redação é que no lugar de dizer
que devem ter "ASN e IPv6" talvez seria mais preciso dizer que "sejam
membros e portanto tenham assinado o contrato de membresia com LACNIC",
pois ter ou não algum desses recursos é menos relevante para esse
contexto, porém é claro esse não é motivo de objeção, então de minha
parte considero que este ponto está resolvido.
Aguardo a consideração para os demais pontos e sigo com a opinião que
são importantes terem ajustes para deixar a política mais completa com
relação à esses detalhes finais.
Saudações
Fernando Frediani
On 10/30/2025 11:31 AM, Uesley Correa via Politicas wrote:
> Hola a todos!
>
> Contesto este punto de Fernando:
>
> La sección 2.3.2.19.2 establece que la organización receptora debe tener
> un ASN y una dirección IPv6 asignados por LACNIC, pero no especifica
> claramente que deba tener una sede en la región de LACNIC y ser miembro.
> Podría argumentarse que una organización con recursos asignados en
> múltiples RIRs, incluyendo LACNIC, pero sin representación legal en la
> región, sería también elegible para recibir recursos.
>
> Modificando la sección 2.3.2.19.2, a) para algo como: "La organización
> receptora deberá *ser miembro* y contar al menos con un ASN y
> direccionamiento IPv6 asignado por LACNIC"
>
> Respuesta:
> La propuesta indica que el receptor debe tener un ASN y dirección IPv6
> asignados por LACNIC. Por ende, es miembro de LACNIC. LACNIC solamente
> designa recursos numéricos a entidades que los vayan a utilizar en la
> región (aunque sean entidades multinacionales por ejemplo). Eso ya indica
> que algo tendrán en la región. Y la propuesta también indica que los que
> vayan a recibir subasignaciones pasarán por el mismo proceso de
> comprobación de necesidad por parte de LACNIC. Así que si uno indica que lo
> va a usar en otra región, eso no comprueba necesidad y luego, no será
> aprobada la subasignación.
>
> Saludos,
> Uesley Corrêa - Analista de Telecomunicaciones
> CEO Telecom ISP Solutions
>
>
> Em qui., 30 de out. de 2025 às 06:41, jordi.palet--- via Politicas <
> politicas at lacnic.net> escreveu:
>
>> Hola Hernan, todos,
>>
>> Aclaro algunos aspectos entre líneas.
>>
>> Saludos,
>> Jordi
>>
>> @jordipalet
>>
>>
>>> El 29 oct 2025, a las 23:56, Hernan Arcidiacono via Politicas <
>> politicas at lacnic.net> escribió:
>>> Buenas tardes amigos. Dado que estamos próximos al fin del periodo de
>>> discusión, los autores decidimos hacer el mejor esfuerzo y consolidar los
>>> comentarios que gentilmente nos han hecho llegar a través de la lista o
>> en
>>> el micrófono en el FPP de El Salvador.
>>>
>>> Pedimos disculpas si la consolidación que hicimos generó alguna omisión o
>>> mala interpretación, y si lo hizo sepan fue involuntaria.
>>>
>>> Dado que la propuesta tuvo una amplia discusión y que hubo un apoyo
>>> manifiesto en el FPP, el consolidado espera cubrir la respuesta a
>>> vuestros comentarios (más allá que la mayoría ya fueron respondidos
>>> oportunamente).
>>>
>>> Sin más, encontrarán debajo la información mencionada.
>>>
>>> Atentamente
>>>
>>> Uesley, Douglas, edmundo y Hernan
>>>
>>>
>> --------------------------------------------------------------------------------------------------------
>>> JORDI PALET
>>>
>>> 1) Siempre he entendido que no queremos que haya fuga de prefijos en
>>> alquiler fuera de la región. La propuesta indica que hay que tener un
>> ASN y
>>> prefijo IPv6 de LACNIC, pero no indica la obligación de usar los recursos
>>> alquilados en la región, ni con dicho ASN. El texto actual por lo tanto
>>> permite la fuga de recursos en alquiler que posiblemente tendrían precios
>>> más bajos que los que estén en alquiler de otras regiones.
>>>
>>> WG: La propuesta propone dar a LACNIC elementos que sean estrictamente
>>> verificables. Es por ello que consideramos el ASN de LACNIC y la
>> asignación
>>> de IPv6 como válidos. Esto garantiza que el receptor sea miembro de
>> LACNIC
>>> con el correspondiente acuerdo de servicios firmado. Como tal, al miembro
>>> le corresponde cumplir con las lo definido en el manual como todo
>> miembro.
>>> Solo a modo de ejemplo, y fuera del alcance de esta propuesta, el miembro
>>> deberá cumplir con el punto 1.2 sobre ”Principios para una buena
>>> administración y custodia” entre otros.
>>>
>> Cumplir con el 1.2 solo garantiza que el 50% de los recursos sub-asignados
>> sean usados en la región. Siempre que hemos discutido el tema de las
>> sub-asignaciones (a partir de ahora para aclarar el resto del texto, el
>> término es asimilable a alquiler, leasing, etc., dado que hablamos de
>> sub-asignaciones SIN vinculación con le infraestructura de quien ha
>> recibido legítimamente los recursos de LACNIC o incluso mediante
>> transferencias permanentes), hemos indicado que queremos que sea un
>> beneficio para la región y se quería evitar su uso en otras regiones.
>>
>> Por lo tanto no basta con el texto propuesto, sino que hay que poner una
>> limitación especifica para que las sub-asignaciones sean solo y
>> exclusivamente para su uso dentro de la región. Sin esa limitación la
>> posibilidad de que se usen ya no solo el 50% sino mucho mas y se hagan
>> “trampas” para que parezca, en caso de auditoria de LACNIC, que el 50% esta
>> en la región se incrementa enormemente.
>>
>> Independientemente del ASN, para que el requisito de IPv6 si no se pide su
>> uso?
>>
>>> 2) La propuesta indica que en whois se refleje vinculando el bloque
>> de
>>> direcciones con el ASN del receptor, sin embargo, de nuevo eso no implica
>>> que se este anunciando con ese ASN, debería ser 100% explicito.
>>>
>>> WG: Respuesta contenida en el punto 1
>> No, eso no esta aclarado en el 1. Poseer un ASN de la región no obliga a
>> usarlo. Es mas se pueden estar anunciando esos bloques sub-asignados con
>> múltiples ASNs. De nuevo esto debe ser explicito en el texto, tanto si se
>> quiere que sea anunciado dentro de la región, o aclarar, si no es el caso,
>> que no es un requisito.
>>
>>> 3) Me resulta muy chocante este texto “por lo que proponemos un
>>> mecanismo que incentive a la regularización de quienes deseen cumplir con
>>> las políticas, aun sabiendo que no todos lo adoptarán”. Estamos asumiendo
>>> que no todos regularizarán y no ponemos medidas como parte de la
>> propuesta
>>> para recuperar los recursos que no se regularicen? Entonces para que
>>> queremos una propuesta, dejémoslo como esta, es más fácil, no ?
>>>
>>> WG: El texto citado es parte de la justificación presentada y no refleja
>> el
>>> texto propuesto a incluir en el manual. Es de público conocimiento que
>>> existe un problema y la presente política desea ser parte de la solución.
>>> Entendemos que el manual ya contempla las medidas a tomar ante posibles
>>> incumplimientos.
>> Tengo bien claro que ese texto no es parte del texto de la propuesta, pero
>> si es parte de su justificación. Como vosotros mismos contestáis, eso es
>> inconsistente al indicar “que no refleja el texto propuesto …”. Es decir,
>> tenemos una justificación que no es acorde con el texto propuesto?
>>
>> Precisamente lo que quiero decir, es que si se asume lo que esta en la
>> justificación, habrá que aclarar que se hace si se incumple (sub-asignando
>> fuera de la política) una vez que se implementa. Se marca un periodo de
>> transición, por ejemplo?
>>
>>
>>> 4) Creo que no se debe pedir un ASN ni IPv6 de
>>> LACNIC, especialmente, vinculado con lo dicho en puntos anteriores, si no
>>> se obliga y comprueba que se usan.
>>>
>>> WG: Respuesta contenida en el punto 1
>> Bueno como he dicho antes, no me parece correcto, es una restricción
>> innecesario, ya lo han indicado otros en la lista anteriormente,
>> especialmente si no se obliga a su uso.
>>
>>> 5) Creo que es inconsistente pedir % de uso a un año, cuando el
>>> alquiler puede ser a menor plazo. Obtendremos respuestas falsas,
>> obviamente.
>>> WG: En la propuesta no se refiere al término alquiler, sino a
>>> subasignación. La misma no tiene asociada una duración por lo que
>>> entendemos que los comentarios respecto al plazo no aplican y no vemos
>>> contradicción alguna con la justificación requerida.
>>>
>> Ya hemos aclarado que sub-asignaciones de recursos sin conexión no es otra
>> cosa que decir alquiler/leasing/arrendamiento/etc, con otra expresión, pero
>> el objetivo es el mismo: Te cedo direcciones que no uso, sin que tengamos
>> conexión directa, para que las uses como quieras. No pretendamos negarlo,
>> hay que ser muy honrados y transparentes. Si estoy equivocado, por favor,
>> aclarar diferencias entre sub-asignación sin conexión y alquiler, porque de
>> otro modo, no sabemos de que estamos hablando.
>>
>> Efectivamente la sub-asignación (que no subasignación, dado que es
>> incorrecto en castellano/español según la RAE), siempre se ha propuesto sin
>> plazo, sin embargo, precisamente por eso, dado que puede tener un plazo
>> inferior a la justificación que se indica, es una clarísima
>> contraindicación, porque nunca se puede realizar la evaluación basada en
>> plazos cuando el plazo es discrepante o inexistente.
>>
>>> 6) La entidad receptora no está sujeta a las políticas de LACNIC? Si se
>>> pide ASN y prefijo IPv6 no tiene mucho sentido que no sea explicito ese
>>> requisito, pero igualmente si decidimos no pedir ASN/IPv6, sigo pensando
>>> que se debe firmar el acuerdo de servicios por parte del receptor y
>> obligar
>>> al uso de los recursos en la región.
>>>
>>> WG: Si el receptor tiene ASN y prefijo IPv6 de LACNIC es porque el
>> receptor
>>> de la subasignación tiene firmado acuerdo de servicio con LACNIC y por
>> ende
>>> es miembro. Para completar, ver respuesta contenida en el punto 1
>> Precisamente eso es lo que pretendo decir. Dado que hay ASN e IPv6 de
>> LACNIC, eso obliga a que se haya firmado acuerdo de servicios. Sin embargo,
>> si al final desde la comunidad opinamos que no tiene sentido pedir ASN e
>> IPv6 si no se usan, habrá que pedir la firma del acuerdo de servicios por
>> separado.
>>
>>> 7) Que ocurre con los que ya estan alquilando en contra de las politicas
>>> actuales? tienen que hacer la justificación para regularizar o quedan
>>> regularizados de facto? Creo que debe hacerse la regularización y debe
>> ser
>>> explicito que no hacerlo es incumplimiento de las políticas y por tanto
>>> motivo de recuperación de recursos. Buscamos darle una solución al
>>> problema, pero no podemos pasar por alto incumplimientos desde el momento
>>> en que se resuelva.
>>>
>>> WG: Respuesta contenida en el punto 3
>> Como he indicado, no esta claro bajo mi punto de vista. Hay una fase de
>> transición o adaptación? Creo que sería lo razonable, de otro modo los
>> plazos de la política de la política de recuperación pueden quedarse cortos
>> y no pode cumplirse (incluso por parte de LACNIC).
>>
>>>
>>> 8) Este comentario del análisis de impacto y la respuesta de los autores
>> me
>>> chirría de manera especial. "Interpretamos que, según el espíritu de la
>>> propuesta, un bloque recibido por una organización como “Sub-asignación
>> de
>>> recursos IPv4 a terceros” no podrá a su vez ser subasignado parcial o
>>> totalmente por el receptor bajo esta misma modalidad”. La propuesta no
>>> tiene ningún texto que permita inferir esto y lo que los autores deberían
>>> haber hecho es decirlo explícitamente, no aceptarlo como “si era nuestro
>>> espíritu, ah pero no nos dimos cuenta”. El PDP no permite modificar el
>>> texto de las propuestas en el foro público. De otro modo, cada vez que
>> los
>>> autores de cualquier propuesta no se den cuenta de aspectos tan
>> importantes
>>> como este, lo estaríamos corrigiendo sobre la marcha solo con la
>>> “interpretación del espíritu”. Entiendo que se pueda usar esa
>>> interpretación para algo que si está en el texto pero no está 100% claro,
>>> porque además el PDP nos permite, en el llamado a últimos comentarios,
>>> resolverlo. Pero nunca para algo que no está en el texto ni de lejos.
>>>
>>> WG: Ratificamos lo solicitado en el foro público. Entendemos no nos
>> compete
>>> opinar al respecto.
>> Cuando como autor se indica algo que tu texto no dice ni aclara, ni se
>> mete en ese aspecto, debemos ser honestos y responder algo como “no lo he
>> tenido en cuenta”. De otro modo, cualquiera en la comunidad, incluyendo el
>> propio LACNIC, puede inferir que algo que no esta(ba) en cualquier
>> propuesta si está en el “espíritu de la propuesta” en cualquier momento
>> incluso una vez implementada.
>>
>> Si aceptamos esos cambios durante la discusion de una propuesta o en el
>> foro público, estaríamos manipulando el PDP, y por tanto incumpliéndolo.
>> Eso es totalmente inaceptable. Como ponemos el límite en lo que aceptamos
>> como “espíritu de la propuesta” en una u otra propuesta? Es imposible,
>> ilógico, y por tanto absurdo.
>>
>>> FERNANDO FREDIANI
>>>
>>> 9) Si posible, ajuste el límite de tamaño de bloque que se puede
>>> transferir para considerar *lo que una organización ya tiene*, en lugar
>>> de lo máximo que se puede sub-asignar según esta propuesta.
>>> La justificación es que, dado que esta política busca privilegiar a las
>>> organizaciones más pequeñas con asignaciones muy pequeñas o nulas,
>> quienes
>>> ya tengan una asignación mínima pueden recurrir a mejores enfoques, como
>>> las transferencias permanentes.
>>> Personalmente, creo que /22 sería suficiente, pero si se mantiene /21
>>> como base, no creo que sea un problema o motivo de objeción.
>>>
>>> WG: Entendemos la sugerencia. No tenemos comentario al respecto. Hemos
>>> adoptado lo que entendemos fue un consenso mayoritario en la discusión
>>> previa en la lista. Entendemos también que el requerir una justificación
>>> con un mecanismo preexistente en el manual, pone una barrera de entrada a
>>> quienes quisieran solicitar nuevas subdelegaciones sin haber cumplido con
>>> las obligaciones asumidas en la primera.
>>>
>>> 10) Agregar un nuevo punto que diga que aquellas organizaciones que
>>> cedan bloques para ser sub-asignados no podrán recibir nuevos bloques por
>>> un periodo mínimo de tiempo.
>>>
>>> WG: Entendemos la preocupación. No obstante creemos que existen
>> mecanismos
>>> que mitigan este tipo de riesgos. Por ejemplo, aplicar para recibir una
>>> transferencia ya tiene per se mecanismos que establece restricciones. Por
>>> otro lado, subasignar y estar en la lista para recibir recursos
>> recuperados
>>> parece una situación imporbable. Hemos preferido mantener el esquema
>> simple
>>> en búsqueda de rápida aplicación y adopcón.
>>>
>>> 11) Agregar un nuevo punto para dejar más claro que estas
>>> sub-asignaciones sólo pueden ocurrir dentro de la región LACNIC
>>> (intra-RIR)..
>>>
>>> WG: No lo vemos necesario dado que de la manera que lo hemos planteado ya
>>> implica que la subasignación es de un miembro de LACNIC a otro miembro de
>>> LACNIC. Completa la respuesta el Punto 6.
>>>
>>> HENRI ALVES DE GODOY
>>>
>>> 12) Es esencial que el receptor firme un compromiso mínimo para
>> avanzar
>>> en los mecanismos de transición a IPv6. La propuesta debe evitar la
>>> perpetuación de CGNAT como solución permanente. La aceptación de
>> prácticas
>>> de alquiler sin contrapartidas claras de transición es un riesgo.
>>>
>>> WG: Como hemos expresado en la lista, el objetivo es el de atender un
>> tema
>>> que más allá del despliegue de IPv6, sucede de una manera que trae
>>> perjuicios ya conocidos.
>>>
>>> 13) Tener asignado IPv6 (2.3.2.19.2.a) no garantiza un compromiso
>> real
>>> de uso; el IPv6 debe ser implementado en redes y servicios.
>>>
>>> WG: Entendemos esta respondido en el punto 1.
>>>
>>> 14) Solicitó a los autores cambiar la frase "direccionamiento IPv6"
>>> (2.3.2.19.2.a) por la terminología más correcta de "bloques" o "prefijo"
>> de
>>> direcciones IPv6.
>>>
>>> WG: Como se respondió en la lista consideramos que "direccionamiento
>> IPv6"
>>> es suficiente ya que LACNIC solo asigna prefijos como mínimo /48.
>>>
>>> 15) Preguntó a los autores cómo se comprobará, medirá y acompañará
>> la
>>> demostración de la necesidad inmediata (25% de uso) (2.3.2.19.2.c).
>>>
>>> WG: El mecanismo de justificación ya es preexistente en el manual y esta
>>> política no contempla mecanismos adicionales a los preexistente.
>>> LUCIANO S. DOS SANTOS
>>>
>>> 16) Sugiere que el IPv6 no solo deba estar designado/asignado
>>> (2.3.2.19.2.a), sino también en uso, implementado, y con tráfico
>> razonable.
>>> Esto debería ser comprobado con documentación durante la solicitud.
>>>
>>> WG: entendemos esta respondido en el punto 1.
>>>
>>> GUILLERMO HUAMANI DE LA TORRE
>>>
>>> 17) Solicitó una precisión sobre el término "tercero" y el
>>> alcance de "dentro/fuera
>>> de la infraestructura" para facilitar una implementación homogénea.
>>>
>>> WG: Como se respondió en la lista anteriormente, los términos y conceptos
>>> ya son preexistentes en el manual y entendemos que no requiere
>> aclaración.
>>> 18) Sugirió añadir una definición operativa de "tercero", como
>>> "entidad no titular de la asignación ni parte de la infraestructura bajo
>>> control operacional del miembro," dejando explícito que los dispositivos
>> de
>>> clientes que operan dentro de la infraestructura del miembro no son
>>> considerados "terceros".
>>>
>>> WG: Entendemos esta respondida en punto 17
>>>
>>>
>>>
>>> NICOLAS ANTONIELLO
>>>
>>> 19) Propuso resolver la inconsistencia de justificación de uso del
>> 50%
>>> en un año cambiando la redacción a "50% en un plazo no mayor a un año"
>> (ej.
>>> si se piden por 3 meses, se justifica el 100% en 3 meses).
>>>
>>> WG: No vemos inconsistencia porque la subasignación contemplada en esta
>>> propuesta no tiene asociada una duración.
>>>
>>> 20) Propuso modificar el mecanismo antiespeculación (2.3.2.19.5), ya
>>> que solo cubre bloques de transferencias o del pool de recuperados.
>> Sugirió
>>> una frase más amplia que cubra todos los casos de asignación,
>>> indicando que ninguna
>>> asignación se puede reasignar en un plazo menor a 3 años (salvo que esté
>>> indicado en la sección respectiva).
>>>
>>> WG: Entendemos el comentario pero no lo consideramos necesario ya que las
>>> fuentes de nuevas IPv4 para miembros son exclusivamente las mencionadas.
>>> Para el caso de los IXPs que acceden al pool de recursos para
>>> infraestructura critica, los IXPs deben cumplir requisitos para
>> obtenerlas
>>> y tienen un uso específico, por lo que en caso de no dar cumplimiento e
>>> intentar una subasignación de la contempladas en la propuesta serán
>>> pasibles de las medidas que el manual contempla.
>>>
>>> 21) Sugirió que el tamaño mínimo debería ser /24, y expresó que no
>>> estaba convencido de la necesidad de un tamaño máximo de asignación
>> (/21).
>>> WG: Entendemos la sugerencia pero no ha sido el consenso alcanzado en la
>>> lista al respecto.
>>>
>>>
>>>
>>> JAIME CRUZ
>>>
>>> 22) Sugirió que el tamaño máximo de sub-asignación debería ser un
>> /22,
>>> argumentando que es equivalente al máximo asignado históricamente a los
>>> ISPs. La propuesta contempla un /21 como máximo.
>>>
>>> WG: No tenemos comentarios.
>>>
>>> 23) Preguntó si una organización que recibe una delegación puede
>>> recibir una segunda delegación de otro ISP. Sugirió que la organización
>>> debería poder recibir delegación solo una vez.
>>>
>>> WG: Hemos buscado equilibrar las restricciones y a su vez contemplar los
>>> posibles casos, y entendemos que el planteado es uno de ellos y
>>> consideramos es aceptable.
>>>
>>> EDWIN SALAZAR
>>>
>>> 24) Sugirió que el periodo antiespeculación de 3 años (2.3.2.19.5)
>>> para bloques recién transferidos o recuperados debería ser más corto. La
>>> escasez de recursos en la región debe incentivar que se pongan a
>>> disposición de otros ISPs más pequeños en el menor tiempo posible.
>>>
>>> WG: Los autores y lo discutido en la lista no coinciden con lo pedido ya
>>> que el mecanismo anti especulación es parte central de la propuesta.
>>>
>>>
>>>
>>> Hernan Arcidiacono
>>>
>>> CTIO
>>>
>>> +549 11 5025 5106
>>>
>>>
>>> [image: image.png]
>>>
>>>
>>> On Mon, Oct 13, 2025 at 1:15 AM Fernando Frediani via Politicas <
>>> politicas at lacnic.net> wrote:
>>>
>>>> Al continuación del Foro de Políticas en El Salvador, quisiera dejar
>>>> aquí algunas sugerencias para los autores con base en lo discutido para
>>>> una posible próxima versión de esta propuesta, que ya ha evolucionado
>> bien.
>>>> - Si posible, ajuste el límite de tamaño de bloque que se puede
>>>> transferir para considerar *lo que una organización ya tiene*, en lugar
>>>> de lo máximo que se puede sub-asignar según esta propuesta.
>>>> La justificación es que, dado que esta política busca privilegiar a las
>>>> organizaciones más pequeñas con asignaciones muy pequeñas o nulas,
>>>> quienes ya tengan una asignación mínima pueden recurrir a mejores
>>>> enfoques, como las transferencias permanentes.
>>>> Personalmente, creo que /22 sería suficiente, pero si se mantiene /21
>>>> como base, no creo que sea un problema o motivo de objeción.
>>>>
>>>> - Agregar un nuevo punto que diga que aquellas organizaciones que cedan
>>>> bloques para ser sub-asignados no podrán recibir nuevos bloques por un
>>>> periodo mínimo de tiempo.
>>>>
>>>> - Agregar un nuevo punto para dejar más claro que estas sub-asignaciones
>>>> sólo pueden ocurrir dentro de la región LACNIC (intra-RIR).
>>>>
>>>> Saludos cordiales
>>>> Fernando Frediani
>>>>
>>>> On 10/10/2025 2:14 PM, Luciano S. dos Santos via Politicas wrote:
>>>>> Bom dia Senhores!
>>>>>
>>>>> Estando presente no LACNIC 44, acompanhando a discussão na lista, e
>>>>> conversando com parte dos autores, gostei muito da proposta e da forma
>>>> como
>>>>> ela foi feita. Explico aqui o meu ponto de vista:
>>>>>
>>>>>
>>>>> - A Proposta já veio de uma discussão prévia, não somente na lista,
>>>> mas
>>>>> entre os operadores, em outros espaços. Isso mostrou uma maturidade
>>>> na
>>>>> abordagem de alteração da Política atual, e o desejo comum da
>>>> comunidade em
>>>>> tratar um desejo específico, mesmo pessoas com pontos de vista que
>>>> muitas
>>>>> vezes divergem.
>>>>> - Ela vem para tratar um problema específico! Temos uma situação que
>>>> tem
>>>>> ocorrido, e que precisa ser regulamentada, para que justamente isso
>>>> ocorra
>>>>> da forma mais transparente possível. Afinal os recursos são do
>>>> LACNIC, dos
>>>>> NIRs são alocados para uso mediante a política de numeração
>>>> respectiva. Se
>>>>> o mercado evoluiu, necessitamos de pequenos ajustes para que esses
>>>>> controles continuem eficientes.
>>>>> - Registro aqui que pessoalmente sou contra a locação dos recursos
>> de
>>>>> numeração, mas também entendo que o esgotamento do recurso de
>>>> numeração de
>>>>> IPv4 gera transtornos às entidades que precisam desses recursos, e
>>>> esse
>>>>> tipo de proposta permitir um mecanismo transparente para que isso
>>>> ocorra.
>>>>> Compartilho o desejo que os recursos do nosso RIR permaneçam aqui.
>>>>> - No item 2.3.2.19.2 vejo que não somente o IPv6 deva estar
>>>> designado,
>>>>> mas em uso, implementado e com tráfego razoável perante a estrutura
>>>> do
>>>>> possuidor de recurso, e isso deveria ser comprovado através de
>>>> documentação
>>>>> durante a requisição.
>>>>> - A meu ver faz muito sentido ter um mecanismo antiespeculação como
>>>>> proposto no item 2.3.2.19.5.
>>>>>
>>>>> Quiçá futuras propostas de mudanças tenham essa mesma abordagem
>>>>> conservadora nas mudanças propostas, com uma visão compartilhada entre
>>>>> diferentes vozes.
>>>>>
>>>>> Deixo a todos um grande abraço, sempre um prazer reencontrá-los nos
>>>> eventos
>>>>> presenciais.
>>>>>
>>>>> Att,
>>>>>
>>>>> Luciano Santos
>>>>> NZM Consultoria / Fourfibras Provedor de Internet
>>>>> Network Admin
>>>>>
>>>>>
>>>>> On Mon, 6 Oct 2025 at 15:58, Henri Alves de Godoy via Politicas <
>>>>> politicas at lacnic.net> wrote:
>>>>>
>>>>>> Olá Jordi, obrigado pelos seus comentários.
>>>>>>
>>>>>> Pode até parecer que se trata algum tipo de castigo, mas não é isso.
>>>> Longe
>>>>>> disso. Acredito que as mudanças de opinião são válidas e saudáveis,
>> pois
>>>>>> refletem maturidade e abertura ao diálogo. No entanto, precisamos
>>>>>> encontrar, ao longo desta semana, uma forma de atender às demandas da
>>>>>> comunidade sem abrir mão dos princípios que sustentam a Internet na
>>>> região,
>>>>>> garantindo coerência técnica e responsabilidade.
>>>>>>
>>>>>> Vejo que este é o momento de transformar as diferentes opiniões em uma
>>>>>> construção coletiva. Quem sabe pegar aqui os tópicos principais e
>>>> elaborar
>>>>>> um compilado equilibrado pode ser o caminho mais produtivo para
>>>> refletir o
>>>>>> consenso possível, mantendo o compromisso com o avanço do IPv6, mas
>>>> também
>>>>>> apoiando os pequenos provedores que ainda necessitam de IPv4 para
>>>>>> viabilizar mecanismos de transição, essenciais nesse processo.
>>>>>>
>>>>>> Assim, poderemos atender à comunidade de forma equilibrada dando
>>>> exemplo de
>>>>>> cooperação e responsabilidade técnica em nossa região.
>>>>>>
>>>>>> Abraços !
>>>>>> Henri.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Em seg., 6 de out. de 2025 às 15:12, jordi.palet--- via Politicas <
>>>>>> politicas at lacnic.net> escreveu:
>>>>>>
>>>>>>> Hola Henri,
>>>>>>>
>>>>>>> Lo que necesitamos es soluciones. Cuando una “ley” esta equivocada,
>>>>>> porque
>>>>>>> las prácticas nos dicen que esa norma no es la que quiere la
>> comunidad,
>>>>>>> esta claro que se desobedece y lo que es imposible es castigar o
>>>>>> encarcelar
>>>>>>> a todos.
>>>>>>>
>>>>>>> Yo soy el primero que no estaba de acuerdo con las transferencias, y
>>>> sin
>>>>>>> embargo, al final, si lo que busco es el bien de la comunidad, tengo
>>>> que
>>>>>>> aceptar que eso es lo mejor, y por eso presente una propuesta de
>>>>>>> transferencias aún en contra de mi opinion personal y fue adoptada
>> por
>>>> la
>>>>>>> comunidad.
>>>>>>>
>>>>>>> Las normas deben evolucionar con los tiempos; creo que todos
>> conocemos
>>>> el
>>>>>>> dicho “es de sabios cambiar de opinión”.
>>>>>>>
>>>>>>> Saludos,
>>>>>>> Jordi
>>>>>>>
>>>>>>> @jordipalet
>>>>>>>
>>>>>>>
>>>>>>>> El 2 oct 2025, a las 17:24, Henri Alves de Godoy via Politicas <
>>>>>>> politicas at lacnic.net> escribió:
>>>>>>>> Ola Ivan, boa noite , como estas ?
>>>>>>>>
>>>>>>>> Obrigado pelo seu comentário.
>>>>>>>>
>>>>>>>> Concordo que não se pode cobrir o sol com um dedo, mas também não se
>>>>>> pode
>>>>>>>> usar isso como justificativa para legitimar práticas que nos afastam
>>>>>> das
>>>>>>>> melhores práticas regionais e globais. O fato de o mercado encontrar
>>>>>>> saídas
>>>>>>>> informais não significa que a comunidade deva institucionalizá-las
>> sem
>>>>>>>> contrapartidas claras de transição.
>>>>>>>>
>>>>>>>> Agradeço pelo seu resgate histórico que nos lembra como esse debate
>> se
>>>>>>>> arrasta há décadas. Porém, justamente pela nossa experiência
>>>> acumulada,
>>>>>>>> precisamos reconhecer que aceitar práticas de aluguel e sub-alocação
>>>> de
>>>>>>>> IPv4 como algo natural é um risco que já mostrou seus efeitos
>> nocivos
>>>>>> no
>>>>>>>> passado.
>>>>>>>>
>>>>>>>> Portanto, o consenso só será possível se estiver acompanhado de
>>>>>>> compromisso
>>>>>>>> e responsabilidade como você bem disse. Caso contrário, estaremos
>>>>>> apenas
>>>>>>>> consolidando o problema em vez de resolvê-lo.
>>>>>>>>
>>>>>>>> Abraços !
>>>>>>>> Henri.
>>>>>>>>
>>>>>>>>
>>>>>>>> Em qui., 2 de out. de 2025 às 16:38, Ivan Morales via Politicas <
>>>>>>>> politicas at lacnic.net> escreveu:
>>>>>>>>
>>>>>>>>> Algunas reflexiones personales sobre este proceso:
>>>>>>>>>
>>>>>>>>> Negar un problema o algo que ya sucede no hace que desaparezca o se
>>>>>>>>> resuelva por si solo. Es un hecho que existen y existiran alquiler
>> o
>>>>>>>>> transferencias temporales o como quieran llamarles, nos guste o no.
>>>>>>>>>
>>>>>>>>> En todo caso el proposito final de la propuesta es encontrar una
>>>>>>>>> solución de compromiso a un problema existente. En una democracia
>> no
>>>>>>>>> todos van a estar de acuerdo total o parcialmente, pero es lo que
>>>> hay.
>>>>>>>>> Lejos de desestimar la propuesta por x o y motivo personal o
>>>>>> filosofico,
>>>>>>>>> propongo encontrar una solución.
>>>>>>>>>
>>>>>>>>> En lo personal apoyo que se siga promoviendo la implementación del
>>>>>> IPv6
>>>>>>>>> hasta el 100% mientras tanto, no podemos parar el desarrollo de
>>>>>> nuestras
>>>>>>>>> economias.
>>>>>>>>>
>>>>>>>>> El NAT se presento en el RFC 1631 en 1994 y el IPv6 se especifico
>> por
>>>>>>>>> primera vez en el RFC 1883 en diciembre de 1995, osea el NAT nacio
>>>>>> antes
>>>>>>>>> de tener una solución definida al problema del agotamiento de los
>>>> IPs.
>>>>>>>>> No deberia de ser asi, estoy de acuerdo, pero fue asi y es algo que
>>>> no
>>>>>>>>> podemos cambiar.
>>>>>>>>>
>>>>>>>>> En el 2005 estuve en una reunión en Veracruz Mexico en el marco de
>> la
>>>>>>>>> Comision Tecnica de la Red Clara y llegaron a darnos una platica
>>>> sobre
>>>>>>>>> la implementación del IPv6 de una Universidad Portuguesa, que en
>> ese
>>>>>>>>> momento estaban bien avanzados en el tema. A la pregunta de que
>>>> cuando
>>>>>>>>> se implementaria definitivamente el IPv6, la respuesta fue "No
>>>>>> sabemos,
>>>>>>>>> esperamos que en no mas de unos 5 años". A la pregunta de si la
>>>>>> escases
>>>>>>>>> de IPv4 no daria lugar a que en un futuro se comercializaran estas,
>>>> la
>>>>>>>>> respuesta fue "Eso nunca va a pasar, porque todo esta planificado".
>>>>>>>>>
>>>>>>>>> Lo anterior me lleva a tres reflexiones:
>>>>>>>>>
>>>>>>>>> 1. No podemos predecir el futuro.
>>>>>>>>>
>>>>>>>>> 2. Academicos o investigadores, no son muy buenos para estimar lo
>> que
>>>>>> el
>>>>>>>>> mercado, en este caso el Internet, el cual es esencialmente un
>>>>>> negocio,
>>>>>>>>> va a hacer para que funcione.
>>>>>>>>>
>>>>>>>>> 3. La ley de la oferta y la demanda se aplica tambien al Internet.
>>>>>>>>>
>>>>>>>>> En resumen y para no aburrirlos, logremos un consenso, que "No
>>>> podemos
>>>>>>>>> tapar el sol con un dedo."
>>>>>>>>>
>>>>>>>>> Saludos:
>>>>>>>>>
>>>>>>>>> Ivan Morales
>>>>>>>>>
>>>>>>>>> Gerente Sismanet
>>>>>>>>> _______________________________________________
>>>>>>>>> Politicas mailing list
>>>>>>>>> Politicas at lacnic.net
>>>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>>>> Desuscribirse/Descadastre-se/Unsubscribe
>>>>>>>>> <
>> https://mail.lacnic.net/mailman/listinfo/politicasDesuscribirse/Descadastre-se/Unsubscribe
>>>>>>>> :
>>>>>>>>> https://mail.lacnic.net/mailman/options/politicas
>>>>>>>>>
>>>>>>>>> El Codigo de Conducta de la Comunidad de LACNIC (
>>>>>>>>> https://rir.la/codigoconducta-SP) aplica a las listas de discusion
>>>> de
>>>>>>>>> LACNIC.
>>>>>>>>> O Codigo de Conduta da Comunidade do LACNIC (
>>>>>>>>> https://rir.la/codigoconducta-PT) se aplica as listas de discussao
>>>> do
>>>>>>>>> LACNIC.
>>>>>>>>> LACNIC's Community Code of Conduct (
>> https://rir.la/codigoconducta-EN
>>>> )
>>>>>>>>> applies to LACNIC's discussion lists.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> --
>>>>>>>> _______________________________________________
>>>>>>>> Politicas mailing list
>>>>>>>> Politicas at lacnic.net
>>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>>> Desuscribirse/Descadastre-se/Unsubscribe:
>>>>>>> https://mail.lacnic.net/mailman/options/politicas
>>>>>>>> El Codigo de Conducta de la Comunidad de LACNIC (
>>>>>>> https://rir.la/codigoconducta-SP) aplica a las listas de discusion
>> de
>>>>>>> LACNIC.
>>>>>>>> O Codigo de Conduta da Comunidade do LACNIC (
>>>>>>> https://rir.la/codigoconducta-PT) se aplica as listas de discussao
>> do
>>>>>>> LACNIC.
>>>>>>>> LACNIC's Community Code of Conduct (
>> https://rir.la/codigoconducta-EN)
>>>>>>> applies to LACNIC's discussion lists.
>>>>>>>
>>>>>>>
>>>>>>> **********************************************
>>>>>>> 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.
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Politicas mailing list
>>>>>>> Politicas at lacnic.net
>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>> Desuscribirse/Descadastre-se/Unsubscribe
>>>>>>> <
>> https://mail.lacnic.net/mailman/listinfo/politicasDesuscribirse/Descadastre-se/Unsubscribe
>>>>>>> :
>>>>>>> https://mail.lacnic.net/mailman/options/politicas
>>>>>>>
>>>>>>> El Codigo de Conducta de la Comunidad de LACNIC (
>>>>>>> https://rir.la/codigoconducta-SP) aplica a las listas de discusion
>> de
>>>>>>> LACNIC.
>>>>>>> O Codigo de Conduta da Comunidade do LACNIC (
>>>>>>> https://rir.la/codigoconducta-PT) se aplica as listas de discussao
>> do
>>>>>>> LACNIC.
>>>>>>> LACNIC's Community Code of Conduct (https://rir.la/codigoconducta-EN
>> )
>>>>>>> applies to LACNIC's discussion lists.
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>> _______________________________________________
>>>>>> Politicas mailing list
>>>>>> Politicas at lacnic.net
>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>> Desuscribirse/Descadastre-se/Unsubscribe
>>>>>> <
>> https://mail.lacnic.net/mailman/listinfo/politicasDesuscribirse/Descadastre-se/Unsubscribe
>>>>> :
>>>>>> https://mail.lacnic.net/mailman/options/politicas
>>>>>>
>>>>>> El Codigo de Conducta de la Comunidad de LACNIC (
>>>>>> https://rir.la/codigoconducta-SP) aplica a las listas de discusion de
>>>>>> LACNIC.
>>>>>> O Codigo de Conduta da Comunidade do LACNIC (
>>>>>> https://rir.la/codigoconducta-PT) se aplica as listas de discussao do
>>>>>> LACNIC.
>>>>>> LACNIC's Community Code of Conduct (https://rir.la/codigoconducta-EN)
>>>>>> applies to LACNIC's discussion lists.
>>>>>>
>>>>>>
>>>> _______________________________________________
>>>> Politicas mailing list
>>>> Politicas at lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>> Desuscribirse/Descadastre-se/Unsubscribe
>>>> <
>> https://mail.lacnic.net/mailman/listinfo/politicasDesuscribirse/Descadastre-se/Unsubscribe
>>> :
>>>> https://mail.lacnic.net/mailman/options/politicas
>>>>
>>>> El Codigo de Conducta de la Comunidad de LACNIC (
>>>> https://rir.la/codigoconducta-SP) aplica a las listas de discusion de
>>>> LACNIC.
>>>> O Codigo de Conduta da Comunidade do LACNIC (
>>>> https://rir.la/codigoconducta-PT) se aplica as listas de discussao do
>>>> LACNIC.
>>>> LACNIC's Community Code of Conduct (https://rir.la/codigoconducta-EN)
>>>> applies to LACNIC's discussion lists.
>>>>
>>>>
>>> --
>>> *No Imprimas Digitalizá*ESTE MENSAJE ES CONFIDENCIAL. Puede contener
>>> información amparada por el secreto profesional. Si usted ha recibido
>> este
>>> e-mail por error, por favor comuníquenoslo inmediatamente vía e-mail y
>>> tenga la amabilidad de eliminarlo de su sistema; no deberá copiar el
>>> mensaje ni divulgar su contenido a ninguna persona. Muchas gracias.
>>>
>>> THIS
>>> MESSAGE IS CONFIDENTIAL. It may also contain information that is
>> privileged
>>> or otherwise legally exempt from disclosure. If you have received it by
>>> mistake please let us know by e-mail immediately and delete it from your
>>> system; should also not copy the message nor disclose its contents to
>>> anyone. Many thanks.
>>>
>>>
>>> NSS S.A. – IPLAN | CUIT: 30-70265297-5 | IVA
>>> Responsable Inscripto | Ingr. Brutos: 901-033512-0 Inscripción I.G.J.:
>>> 24/02/1999, N° 2588, libro 4, tomo - Sociedades por Acciones | Sede
>> Social:
>>> Reconquista 865 2° Piso, CABA
>>> <
>> https://maps.google.com/?q=Reconquista+865+2%C2%B0+Piso,+CABA&entry=gmail&source=g>
>>
>>> C1003ABQ
>>>
>>>
>>>
>>> Ley 25326 - art.27. - inc. 3. El titular podrá en cualquier
>>> momento solicitar el retiro o bloqueo de su nombre de los bancos de
>> datos a
>>> los que se refiere el presente artículo.
>>>
>>>
>>> Decreto 1558/01 - art. 27. -
>>> 3er. párrafo. En toda comunicación con fines de publicidad que se
>> realice
>>> por correo, teléfono, correo electrónico, Internet u otro medio a
>> distancia
>>> a conocer, se deberá indicar, en forma expresa y destacada, la
>> posibilidad
>>> del titular del dato de solicitar el retiro o bloqueo, total o parcial,
>> de
>>> su nombre de la base de datos. A pedido del interesado, se deberá
>> informar
>>> el nombre del responsable o usuario del banco de datos que proveyó la
>>> información.
>>>
>>>
>>>
>>> El titular de los datos personales tiene la facultad de
>>> ejercer el derecho de acceso a los mismos en forma gratuita y a
>> intervalos
>>> no inferiores a 6 meses, salvo que se acredite un interés legítimo al
>>> efecto conforme lo establecido por el artículo 14, inciso 3 de la ley
>>> 25326.-
>>>
>>>
>>>
>>> La Agencia de Acceso a la Información Pública , órgano de
>>> control de la ley Nº 25.326, tiene la atribución de atender las
>> denuncias y
>>> reclamos que se interpongan con relación al incumplimiento de las normas
>>> sobre protección de datos personales.
>>>
>>> <image.png>_______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>> Desuscribirse/Descadastre-se/Unsubscribe:
>> https://mail.lacnic.net/mailman/options/politicas
>>> El Codigo de Conducta de la Comunidad de LACNIC (
>> https://rir.la/codigoconducta-SP) aplica a las listas de discusion de
>> LACNIC.
>>> O Codigo de Conduta da Comunidade do LACNIC (
>> https://rir.la/codigoconducta-PT) se aplica as listas de discussao do
>> LACNIC.
>>> LACNIC's Community Code of Conduct (https://rir.la/codigoconducta-EN)
>> applies to LACNIC's discussion lists.
>>
>>
>> **********************************************
>> 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.
>>
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
>> Desuscribirse/Descadastre-se/Unsubscribe
>> <https://mail.lacnic.net/mailman/listinfo/politicasDesuscribirse/Descadastre-se/Unsubscribe>:
>> https://mail.lacnic.net/mailman/options/politicas
>>
>> El Codigo de Conducta de la Comunidad de LACNIC (
>> https://rir.la/codigoconducta-SP) aplica a las listas de discusion de
>> LACNIC.
>> O Codigo de Conduta da Comunidade do LACNIC (
>> https://rir.la/codigoconducta-PT) se aplica as listas de discussao do
>> LACNIC.
>> LACNIC's Community Code of Conduct (https://rir.la/codigoconducta-EN)
>> applies to LACNIC's discussion lists.
>>
>>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
> Desuscribirse/Descadastre-se/Unsubscribe: https://mail.lacnic.net/mailman/options/politicas
>
> El Codigo de Conducta de la Comunidad de LACNIC (https://rir.la/codigoconducta-SP) aplica a las listas de discusion de LACNIC.
> O Codigo de Conduta da Comunidade do LACNIC (https://rir.la/codigoconducta-PT) se aplica as listas de discussao do LACNIC.
> LACNIC's Community Code of Conduct (https://rir.la/codigoconducta-EN) applies to LACNIC's discussion lists.
>
More information about the Politicas
mailing list