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

Mon Nov 3 12:02:26 -03 2025

Buen dia a todos.

Entendemos que esta propuesta ofrece una alternativa para atacar una
situación real que todos sabemos ocurre y perjudica a la comunidad.

Como es de vuestro conocimiento, para la construcción de esta propuesta se
relevaron opiniones en la lista previo a enviar la primera versión y hemos
tomado en consideración lo vertido en la lista, como oportunamente hemos
expuesto.

La  propuesta ha demostrado generar interés por parte de la comunidad,
apoyo manifiesto y entendemos que no hay objeciones que hayan quedado sin
respuesta.

Hemos aceptado hacer un cambio editorial a lo sugerido por Fernando.

Todo es susceptible de mejora, pero creemos que el peor escenario es no
tener nada, ya que permite que se consolide la situación actual no deseada.

A continuación, detallamos las refutaciones correspondientes a los
comentarios recientemente recibidos.

---------------------------------------------------------------

Fernando Frediani

1- Si bastara solicitar una justificación, no habría necesidad de un límite

en el tamaño del prefijo. El tamaño máximo del prefijo para la

transferencia tiene como objetivo garantizar que esta política no se

utilice indiscriminadamente por parte de las organizaciones para

transferir cada vez más bloques indefinidamente.

WG: El limite no debe ser analizado aisladamente. Le propuesta considera un
mecanismos que cruza varias variables: ASN de la LACNIC, limite y
justificación. La combinación es la que minimiza los riesgos del aml uso.

2- Hay un pequeño malentendido entre lo que dije y la respuesta. El

problema no es quién recibe los bloques, sino quién los regala.

Quien regala bloques está demostrando que no necesita recibir más.

WG: Entendemos la preocupación. Recibir una bloque requiere los mecanismos
de justificación y entendemos esto está cubriendo situación descripta.

3- 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"

WG: Entendemos que podemos hacer un cambio editorial, ya que lo indicado no
altera el espiritu de la propuesta.

Jordi Palet

4- 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?

WG: Entendemos que las subasignaciones en cuestión deben cumplir con los
mismos requisitos que otro tipo de subasignaciones. No vemos que esto vaya
en detrimento del espíritu de la propuesta.

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

WG: Fue aclarado oportunamente. No consideramos necesario ampliar.

6- 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?

WG: La inconsistencia que se nos está atribuyendo no la consideramos como
tal. Ya hemos respondido oportunamente y por ello consideramos que no
requiere ampliar. Respecto de los incumplimientos ya expresamos que no
requieren ser explícitos en la propuesta porque ya están contemplados en el
manual.

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

WG: Entendemos que este comentario resulta contradictorio con otros
comentarios expresados por la misma persona, por ello omitiremos responder
al respecto. Por otra parte, otros en la lista también han estado de
acuerdo con lo propuesto por los autores de la propuesta. Entendemos además
que este es el mecanismo más directo que busque mantener los recursos en la
región, frente a otras propuestas de dudosa efectividad y factibilidad de
control.

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

WG: Ya hemos aclarado oportunamente. No creemos necesario ampliación.

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

WG:  La propuesta considera mantener el requisito de ASN e IPv6 con lo cual
hay acuerdo de servicio involucrado.

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

WG: Ya hemos aclarado oportunamente. No creemos necesario ampliación.

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

WG: Ya hemos aclarado oportunamente. No creemos necesario ampliación.

Hernan Arcidiacono

CTIO

+549 11 5025 5106

[image: image.png]

On Mon, Nov 3, 2025 at 10:27 AM Uesley Correa via Politicas <
politicas at lacnic.net> wrote:

> 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.
> >
> >
> _______________________________________________
> 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/20251103/6cbad950/attachment-0001.png>