[LACNIC/Politicas] LAC-2025-5: Sub-asignación de Recursos IPv4 a Terceros
Uesley Correa
uesleycorrea at gmail.com
Mon Nov 3 10:27:26 -03 2025
Hola a todos!
Contesto directamente a Fernando: Evaluando internamente en el WG y vamos a
proponer un cambio editorial para agregar este punto que comentas, una vez
que eso no cambia el espíritu de la propuesta.
Saludos,
Uesley Corrêa - Analista de Telecomunicaciones
CEO Telecom ISP Solutions
Em sex., 31 de out. de 2025 às 09:36, Oscar Robles via Politicas <
politicas at lacnic.net> escreveu:
> 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.
> >
> _______________________________________________
> 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.
>
>
More information about the Politicas
mailing list