[LACNIC/Politicas] LAC-2025-5: Sub-asignación de Recursos IPv4 a Terceros

Wed Oct 29 19:56:01 -03 2025

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.

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

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. 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

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.

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

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

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.

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 7644 bytes
Desc: not available
URL: <https://mail.lacnic.net/pipermail/politicas/attachments/20251029/2e2bde14/attachment-0001.png>