[LACNIC/Politicas] LAC-2025-5: Sub-asignación de Recursos IPv4 a Terceros
Oscar Robles
oscar.robles at gmail.com
Fri Oct 31 09:36:22 -03 2025
Recuerden que hay casos especiales de titulares de recursos en la región (IPv4, al menos) que siguen siendo legados y que no tienen un contrato de membresía de LACNIC (o de los NIRs), es decir, no todos los titulares de recursos de LACNIC son asociados.
Por lo tanto, si buscan que tengan una relación contractual y/o que estén sujetos a las políticas de LACNIC, deberían referirse a asociados/miembros.
Por otro lado, si lo que interesa es solo el origen de los recursos, lo correcto sería referirse a titulares de espacio de la región de LACNIC.
Saludos,
Oscar
> On 31 Oct 2025, at 3:19, Fernando Frediani via Politicas <politicas at lacnic.net> wrote:
>
> 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.
>>
> _______________________________________________
> 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