[LACNIC/Politicas] Nueva versión de la propuesta LAC-2020-1
Miguel A. Brante
mbrante at insacom.cl
Fri Apr 16 13:35:57 -03 2021
Buen día a todos,
Me he devuelto a leer la genesis de esta propuesta, por allá a inicios de 2020, y he ido leyendo linea por línea cada uno de los argumentos a favor y en contra en cada una de las versiones.
Creo que sin haber incluso leido los viejos correos, las conclusiones (Quizá) siguen siendo las mismas....
*Voy a devolverme bastante con algunos comentarios, y voy a responder algunos únicamente desde mi vereda:
Utilización de Tunel Broker - "Porque no hay excusas"
-Utilizo Tunnel Broker desde 2016, desde el primer intento fallido de implementar IPv6.
Esto quedó relegado a solo una porción de nuestra red que sirve de laboratorio ya que realmente las latencias y velocidades no me sirven para ponerlas a disposición del resto de la red.
Nota Explicativa: Aca en Chile nosotros pagamos diferenciado el trafico "Nacional" con el "internacional", por lo que usar Tunnel Broker significa usar BW internacional que es mas caro y normalmente se compra en menor capacidad.
Podría simplemente haber publicado vía BGP mi /32 y haber tenido un IPv6 de papel, pero preferimos esperar a poder hacerlo a mayor escala.
****Algunos comentarios a respuestas anteriores:****
"La decisión de tener operacional o no IPv6 sigue siendo una decisión del
ISP. Esta propuesta no obliga a ninguna organización a implementar el
IPv6 tan pronto como se ratifique esta propuesta. Si lo desea, puede
continuar otros 20 años sin IPv6.
Lo único que hace es establecer una condición que, en el caso de que la
organización desee transferir más y más bloques de IPv4, debe demostrar
tener IPv6 operativo como una forma de compromiso....(cortado)" (@Fernando)
Estamos en 2021, y con la escasez del recurso, en la práctica hará que se convierta en una obligación porque muchas organizaciones se podrian ver en tal urgencia.
(Y con esto ni siquiera estoy hablando por mi ASN, porque nuestra red es bastante acotada, no tenemos clientes residenciales y creo que si mantenemos el orden podemos aguantar de momento.)
Yo puedo tener todo el compromiso del mundo con una iniciativa, pero no por eso debo tomar decisiones apuradas u obligadas, pero normalmente hay muchos otros factores que influyen en la toma de decisión, y va a ser principalmente el negocio lo que mande, y si este nos muestra que no podemos habilitar IPv6 justo ahora, y que necesitamos IPv4 urgente, debemos girar el timon hacia allá, porque al final del día esto es un negocio.
Respecto a lo anterior me quedo con algo que dijo @Jordi:
"Quizás, hay que expresar con mas claridad esas excepciones para llegar a un punto de acuerdo."
Sobre Este otro comentario:
"Alguien podría aprovecharse de las transferencias para acumular IPv4, quizás haciendo trampas en las solicitudes, para luego alquilarlo o volver a transferirlo, y con esta propuesta evitamos ese abuso." (@Jordi)
Completamente de acuerdo!!! creo que el ojo hay que ponerlo ahí, y no en quienes legítimante necesiten el recurso.
Se podrá establecer una suerte de Rate-Limit?? (Dejo abierta la pregunta.)
"Otro aspecto no menor es que nuevamente creo que las políticas de
transferencias no son para “autorizar” las mismas sino para mantener
coherencia y vigencia en el registro de Lacnic... el hecho de poner
cualquier tipo de impedimento forzado no va a evitar la transferencia sino
que lo que seguramente suceda es que no quede registro de la misma en
Lacnic (que es justamente lo que no queremos que suceda no?).(@Nicolas)"
Creo que yo no fui capaz de decirlo así de claro!
Ahora....Un poco de números:
Transferencias Inter-RIR hacia LANIC entre 2020 y 2021
DESDE Cantidad
RIPE 2
ARIN 4
AFRINIC 0 (Solo busque coincidencias con la palabra lacnic en el archivo)
APNIC 0
Fuentes:
https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfer-statistics/inter-rir/inter-rir-ipv4-transfer-statistics
https://www.apnic.net/manage-ip/manage-resources/transfer-resources/transfer-logs/
https://account.arin.net/public/transfer-log
https://ftp.afrinic.net/pub/stats/afrinic/transfers/transfers_latest.json
Transferencias Intra-RIR por país receptor:
https://prensa.lacnic.net/news/wp-content/uploads/2020/10/ips-tramsferidas-por-pais-receptor.png
Transferencias Intra-RIR por país oferente:
https://prensa.lacnic.net/news/wp-content/uploads/2020/10/ips-transferidas-por-pais-oferente.png
No es que estemos recibiendo ua ola de recursos que puedan llegar a "romper" algo significativo, y respecto a las transferencias Intra-RIR, básicamente el que mueve más es Brasil, y dentro de su propio pais! (Todo eso sumado es algo así como unos 130 /22 o 64 /21)
A no ser que haya una cantidad brutal de trafico "Horizontal" dentro del país entre los ISP y que normalmente no es así, no me cuadra que vaya a salir humo del equipamiento por mas conexiones a nuevos recursos IPv4.
Estos numeros por si solo no me indican que se esté agravando el problema de IPv4, sino que estamos en una etapa de ajuste, entre quienes si quieren y pueden tener IPv6, entre quienes queremos y no pueden ( o no podíamos), ente quienes no lo tienen en el roadmap, y entre quienes no les interesa.
Si el futuro es IPv6, de lo cual estoy convencido, lo que pasará en el futuro es que los que sigan usando IPv4 se van a quedar solos en su caja de arena.
(Al magen): De verdad no creo que Amazon o MS, no estén preparando un despliegue de IPv6, simplemente van a encender el arbolito cuando lo tengan listo.
https://aws.amazon.com/es/blogs/aws/aws-ipv6-update-global-support-spanning-15-regions-multiple-aws-services/
"Tenemos un problema real que es la desigualdad que se ha creado desde el
momento en que alguien comienza a recibir recursos IPv4 no solo porque
los justifiquen sino porque pueden pagar más. Esto con el tiempo impacta
negativamente en todo el ecosistema de Internet en la región y en el
mundo, incluso para aquellos que han hecho su parte para implementar
IPv6 y asegúrese de que Internet continúe funcionando según lo esperado."(@Fernando)
Si ese es el problema, pongamos un rate-limit...o algo así...
Luego de esta casi corriente de conciencia, y para ir cerrando:
Sigo, no en contra, sino que no la apoyo por:
- No veo suficiente respaldo para decir que esta política de alguna solución concreta a los problemas que dice atacar.
- Genera atribuciones a Lacnic que en mi opnión no debe tener, como es trucar una decisioń del AS, independiente de si gusta o no.
- Existen y existiran muchas excepciones para no implementar IPv6 de inmediato, y cada AS debe hacerse responsable de las consecuencias, pero no por eso le vas a cortar la posibilidad de recibir IPv4.
- Si o si esto va a traer consecuencias en WHOIS... "hecha la ley, hecha la trampa".
Creo mucho mas en un sistema donde se beneficie a quienes estan aportando al desarrollo de IPv6, pero partiendo de una base que para mi es justa: EL PODER ELEGIR.
Gracias @Fernando por poner esta discusión, y de pasada me he involucrado un poco en la lista.
Re-leyendo algunos mensajes anteriores, quizá pudo leerse como que estaba peleando contigo pero no es así, y me disculpo si se entendió de esa manera. Lamentablemente el texto no permite traspasar entonaciones formas y matices.
Saludos!
Miguel Brante
----- Mensaje original -----
De: "Raúl Echeberría" <raul at echeberria.org>
Para: "Lista para discusion de politicas de la comunidad de LACNIC" <politicas at lacnic.net>
Enviados: Miércoles, 14 de Abril 2021 13:21:56
Asunto: Re: [LACNIC/Politicas] Nueva versión de la propuesta LAC-2020-1
> El 14 abr. 2021, a las 13:25, Fernando Frediani <fhfrediani at gmail.com> escribió:
>
> Hola Raúl, entiendo lo que quieres decir y agradezco la cortesía de tus mensajes.
>
> Sin embargo, no todas las discrepancias pueden o deben aceptarse y deben ser refutadas. Es nuestro papel como autor resolver cuáles son incorrectos o incluso incorrectos.
>
> Un punto que es más tranquilo y fácil de discutir es el que mencionas que impone requisitos operativos a través de políticas. Aunque refuto este argumento porque este no es el caso cuando se habla de IPv6 (que no es solo una buena práctica) y dado que el manual también aborda
> cuestiones operativas, puedo entender su base para argumentar esto.
>
> Sin embargo, cuando alguien mencionan puntos y ejemplos que no concuerdan con lo que está escrito en el texto de la propuesta o en su intención, tengo la obligación de aclarar y demostrar que esa objeción no es válida.
Todas las objeciones son válidas. Es la base del funcionamiento de este tipo de foros.
Ese es el punto.
Raúl
>
> Fernando
>
> On 14/04/2021 12:57, Raúl Echeberría wrote:
>>
>> Fernando
>>
>> Como ya comenté en un mail anterior.
>>
>> Es claro que si, las políticas muchas veces incluyen requerimientos operativos. La discusión se basa en donde colocar el punto de equilibrio (o el trade off) y cuales requerimientos apuntan al uso eficiente del recurso que se asigna y cuales implican otro tipo de obligaciones.
>>
>> Como ya he dicho, para mi (y creo que es lo mismo para varios que han comentado) impondría requerimientos de operación que van más allá de lo que debe hacer una política.
>>
>> Entiendo que tu pienses diferente y eso es bueno. Es bueno que haya discrepancias. En algunos casos las discrepancias son salvables aproximando posiciones, pero en este caso la discrepancia es con el punto central de tu propuesta y tu forma de ver el tema, por lo cual creo que debemos aceptar las discrepancias y ya está.
>>
>> Hay algunas personas que han estado de acuerdo contigo y varios que discrepan con la propuesta. No veo la posibilidad que se llegue a un consenso sobre esta propuesta ya que como decía antes, la discrepancia es sobre el punto central de la misma.
>>
>>
>> Aceptemos las diferencias y no pensemos que los que discrepan es solamente porque están equivocados o porque no leyeron la propuesta.
>>
>>
>> Saludos,
>>
>>
>> Raúl
>>
>>
>>
>>
>>> El 14 abr. 2021, a las 11:55, Fernando Frediani <fhfrediani at gmail.com>
> escribió:
>>>
>>> Bueno, Hernán, citaré algunos de ellos a continuación:
>>> Dado que los requisitos para la transferencia o cesión son inicialmente parte del mismo contexto
>>>
>>> - En 2.3.2.6 - Dice que se uso de VLSM para asignaciones debido a la falta de direcciones IPv4 y en 2.3.3.4.1 dice que en la información proporcionada debes usar VLSM
>>>
>>> - En 2.3.2.7 habla de que ya no se acepta el uso de direccionamiento estático y "por esta razón se espera que las organizaciones investiguen e implementen tecnologías de designación dinámica".
>>>
>>> - En 2.3.2.8 habla del protocolo HTTP1.1 indicando que ya no se aceptará como justificación la necesidad de reservar 1 IPv4 para su uso en Webhosting.
>>>
>>> - En 2.3.3.4.1 en el punto 5 dice que el solicitante *debe* solicitar un bloque IPv6 cumpliendo con la política aceptable
>>> ¿Por qué esto es obligatorio si se argumenta y defiende que es una opción "operativa" para que cada empresa tenga o no IPv6?
>>>
>>> En 2.3.4 punto 7 ¿por qué se le pide al solicitante que detalle "sus avances en la integración del protocolo IPv6" si se argumenta y defiende que es una opción "operativa" que cada empresa tenga o
> no?
>>>
>>> En 4.5.3.1 dice que "se debe dar" al usuario final o al sitio un prefijo que sea un múltiplo de n x /64? ¿No es esto también un problema operativo el tamaño de la red que desea entregar al usuario
> final??
>>>
>>> Saludos
>>> Fernando
>>>
>>> On 14/04/2021 10:54, Hernan Moguilevsky wrote:
>>>> Estimados,
>>>>
>>>> ---
>>>> "Es incorrecto seguir diciendo que no es función del RIR imponer
> este
>>>> requisito para que se realicen transferencias IPv4, ya que existen otros
>>>> requisitos escritos o no, que ya se solicitan en el momento de la
>>>> justificación (y que en general son justos y razonables)."
>>>> ---
>>>>
>>>> No encuentro en la política requisitos para la transferencia que
> se
>>>> refieran a la operación de las organizaciones que reciben o ceden recursos.
>>>>
>>>>
>>>> Saludos
>>>> HM
>>>>
>>>> On 13/04/2021 20:01, Fernando Frediani wrote:
>>>>> Miguel - He visto a distintas personas que se oponen a cuestionar
>>>>> múltiples puntos como si esta propuesta impidiera transferencias y sin
>>>>> la necesaria lectura y comprensión del texto de la propuesta. En el
>>>>> ejemplo que dio sobre sus necesidades de transferencia recientes con
>>>>> esta propuesta implementada, este requisito de IPv6 *no se aplicaría a
>>>>> usted* porque, como se indica en el texto de la propuesta, si el
>>>>> upstream declarar por escrito que no tiene IPv6 disponible la
>>>>> necesidad de demostrar IPv6 operativo se elimina.
>>>>>
>>>>> Herman - Exactamente lo que se busca y la razón por la que este
> es el
>>>>> foro adecuado para hacerlo. Agregue este requisito para que se pueda
>>>>> actualizar el registro de recursos de numeración.
>>>>> Es incorrecto seguir diciendo que no es función del RIR imponer
> este
>>>>> requisito para que se realicen transferencias IPv4, ya que existen
>>>>> otros requisitos escritos o no, que ya se solicitan en el momento de
>>>>> la justificación (y que en general son justos y razonables).
>>>>>
>>>>> Lamentablemente es triste seguir viendo la magnitud del esfuerzo que
>>>>> hacen algunos para oponerse a esta propuesta como si fuera una
>>>>> propuesta para hacer inviables las transferencias y que el efecto
>>>>> práctico es permitir que estos actores malos sigan dañando
> este
>>>>> entorno del que todos dependemos. Me parece que falta un mejor sentido
>>>>> de la proporción de los efectos de seguir sin hacer nada al respecto
>>>>> para "no molestar a algunos" y lo que es peor, seguir diciendo que lo
>>>>> que se propone es una "coacción" que casi transforma a quienes no se
>>>>> preocupan por su entorno en víctimas y no culpables.
>>>>>
>>>>> Fernando
>>>>>
>>>>> On 13/04/2021 19:36, Hernan Moguilevsky wrote:
>>>>>> IMHO, las políticas del RIR deben ser para regular la asignación de los
>>>>>> recursos numéricos de Internet, y *no* la operación de las
>>>>>> organizaciones.
>>>>>> No creo que se deba entrar en ese terreno, ya que implica que el RIR
>>>>>> cumpla otras funciones, que no son las que les delegaron.
>>>>>>
>>>>>> Dicho esto, sigo en contra de la propuesta.
>>>>>>
>>>>>> Saludos
>>>>>> HM
>>>>>>
>>>>>> On 13/04/2021 19:25, Miguel A. Brante wrote:
>>>>>>> Fernando,
>>>>>>>
>>>>>>> Según el citado artículo, que creo que te refieres al numeral 4;
>>>>>>> "Colaborar en el crecimiento de Internet en la región."
>>>>>>>
>>>>>>> Tienes toda la razón en indicar que se deben definir condiciones
>>>>>>> para cada uno de los procesos, como es la asignación y/o transferencia.
>>>>>>>
>>>>>>> Sin embargo, cuando hablo sobre la "no competencia" del RIR, me
>>>>>>> refiero específicamente al posible caso de ejercer una medida
> de
>>>>>>> coerción a los AS para que tomen una decisión forzada para aliviar
>>>>>>> un problema emergente, ya que si están solicitando más recursos
>>>>>>> IPv4, es porque realmente los necesitan, a no ser que alguien los
>>>>>>> tenga como objeto de colección.
>>>>>>>
>>>>>>> Favor no malentiendas esto como una especie de boicot contra IPv6,
>>>>>>> estoy totalmente de acuerdo con que el futuro de la internet es
>>>>>>> sobre IPv6, he participado en todos los entrenamientos, y estamos en
>>>>>>> plena etapa de implementación, pero tampoco puedo cerrar los ojos a
>>>>>>> otras realidades... Y partiendo por la nuestra, nosotros recién hace
>>>>>>> menos de 4 meses que tenemos la factibilidad de poder habilitar IPv6
>>>>>>> (real, no de papel) en nuestra infraestructura, esto es debido a la
>>>>>>> dependencia que teníamos con algunos proveedores (Sin soporte
> de
>>>>>>> IPv6). Entonces, si nos hubiesemos visto en la necesidad urgente de
>>>>>>> solicitar una transferencia de
>>>>> recursos, con esta política simplemente no hubiesemos podido.
>>>>>>> Estoy seguro que hay muchos otros casos, de variados sabores donde
>>>>>>> esta política puede significar una piedra de tropiezo para el
>>>>>>> "Crecimiento de Internet en la Región", ya que finalmente, en
> los
>>>>>>> tiempos que
>>>>> estamos viviendo, al niño que requiere conectarse a la clase virtual,
>>>>> o al trabajador a su reunión de zoom, no termina por afectarle el
>>>>> hecho de que tenga IPv4 o IPv6.
>>>>>>> Saludos
>>>>>>>
>>>>>>> Miguel Brante
>>>>>>>
>>>>>>> ----- Mensaje original -----
>>>>>>> De: "Fernando Frediani" <fhfrediani at gmail.com>
>>>>>>> Para: "Lista para discusion de politicas de la comunidad de LACNIC"
>>>>>>> <politicas at lacnic.net>
>>>>>>> Enviados: Martes, 13 de Abril 2021 17:15:25
>>>>>>> Asunto: Re: [LACNIC/Politicas] Nueva versión de la propuesta
>>>>>>> LAC-2020-1
>>>>>>>
>>>>>>> No Miguel, es un terreno que le toca al RIR, y principalmente a este
>>>>>>> foro de política estipular las condiciones mínimas necesarias para
>>>>>>> realizar un traslado. Algunas personas han dicho esto sin justificación
>>>>>>> suficiente.
>>>>>>> Por otro lado, Jordi, en sus analogías, explicó muy bien
> cómo está
>>>>>>> plenamente justificado y plausible que exista este requisito y que
>>>>>>> no es
>>>>>>> solo una cosa opcional que podamos seguir esperando indefinidamente que
>>>>>>> la buena voluntad de la gente haga a pesar del daño que se les cause
>>>>>>> a
>>>>>>> todos.
>>>>>>>
>>>>>>> Y lo más importante a tener en cuenta en este caso concreto y
> donde
>>>>>>> creo
>>>>>>> que todavía hay mucha confusión por parte de la gente que se
>>>>> opone a
>>>>>>> esta propuesta: IPv6 no es una buena práctica. Es algo fundamental para
>>>>>>> el continuo desarrollo de Internet en la región (y en el mundo) -
>>>>>>> Artículo 2 de los Estatutos Sociales de LACNIC.
>>>>>>>
>>>>>>> Las buenas prácticas son MANRS, estar conectado a un IXP (esto depende
>>>>>>> del punto de vista), usar IRR, RPKI, etc., pero no se puede decir lo
>>>>>>> mismo de IPv6 que solo debería depender de la colaboración.
>>>>>>>
>>>>>>> Finalmente, es realmente muy difícil de entender llamar a la exigencia
>>>>>>> de probar operacional IPv6 "barreras o travas" dada la realidad actual.
>>>>>>> Me parece que mirar demasiado a la teoría y muy poco a la práctica e
>>>>>>> ignorar los graves efectos de seguir sin hacer nada al respecto en
> los
>>>>>>> foros donde es pertinente hacerlo como aquí.
>>>>>>>
>>>>>>> Saludos
>>>>>>> Fernando
>>>>>>>
>>>>>>> On 13/04/2021 17:07, Miguel A. Brante wrote:
>>>>>>>> Hola Fernando,
>>>>>>>>
>>>>>>>> Yo creo que acá el punto de discusión no trata sobre si
> IPv6 es o
>>>>>>>> no es un protocolo que solucionará los problemas de la actual
>>>>> Internet.
>>>>>>>> El punto es que esta política se mete en terreno que no le compete
>>>>>>> al RIR.
>>>>>>>> Creo que esto se trata colaboración, y para lograrlo hay que
> mover
>>>>>>> voluntades, pero no a punta de barreras o trabas.
>>>>>>>> Miguel Brante
>>>>>>>>
>>>>>>>> ----- Mensaje original -----
>>>>>>>> De: "Fernando Frediani" <fhfrediani at gmail.com>
>>>>>>>> Para: "Lista para discusion de politicas de la comunidad de LACNIC"
>>>>>>>> <politicas at lacnic.net>
>>>>>>>> Enviados: Martes, 13 de Abril 2021 15:44:16
>>>>>>>> Asunto: Re: [LACNIC/Politicas] Nueva versión de la propuesta
>>>>>>>> LAC-2020-1
>>>>>>>>
>>>>>>>> Asimismo, IPv6 es el único protocolo capaz de continuar el crecimiento
>>>>>>>> ordenado de Internet y reducir y eliminar los problemas y conflictos
>>>>>>>> derivados de la escasez de IPv4. A menos que alguien quiera estar
> en
>>>>>>>> desacuerdo y decir que la forma correcta es continuar haciendo
>>>>>>>> CGNAT con
>>>>>>>> IPv4.
>>>>>>>>
>>>>>>>> Fernando
>>>>>>>>
>>>>>>>> On 13/04/2021 16:40, JORDI PALET MARTINEZ via Politicas wrote:
>>>>>>>>> Hola Nico,
>>>>>>>>>
>>>>>>>>> El ejemplo de BGP, creo que se comprende si se lee esa sección del
>>>>>>>>> manual. Tal cual está, puede parecer que hay otros protocolos, etc.
>>>>>>>>>
>>>>>>>>> El otro no es un ejemplo (lo pusiste tu, yo lo complete) sino una
>>>>>>>>> realidad.
>>>>>>>>>
>>>>>>>>> Respecto del tema del % de tráfico: No se si se trata de revocar o
>>>>>>>>> de dejar de hacer descuentos en su contribución a las cuotas de
>>>>>>>>> membresía, no he llegado aún a eso.
>>>>>>>>>
>>>>>>>>> Lo que no es correcto es pensar que, si despliegas IPv6 no vas a
>>>>>>>>> poder
>>>>>>> cumplir con esos tráficos, eso es medible en cualquier despliegue
>>>>> de
>>>>>>> todos los que hay en el mundo. Si despliegues al 100% de tus
>>>>>>> residenciales o celulares, si o si tendrás como poco un 75% de
>>>>>>> tráfico IPv6
>>>>>>> respecto del total de tráfico de esos clientes. Insisto, hay que
>>>>>>> parametrizarlo, porque obviamente no todos los operadores dan
>>>>>>> servicio mayoritariamente a residenciales, hay casos que solo dan
>>>>>>> servico a corporativos, etc.
>>>>>>>>> Saludos,
>>>>>>>>> Jordi
>>>>>>>>> @jordipalet
>>>>>>>>> El 13/4/21 20:39, "Nicolas Antoniello" <nantoniello at gmail.com>
>>>>>>>>> escribió:
>>>>>>>>>
>>>>>>>>> Jordi,
>>>>>>>>>
>>>>>>>>> No entremos en discusiones que creo que no tienen sentido
>>>>>>>>> en este caso.
>>>>>>>>> En primer lugar, se pide BGP para un ASN porque es el único
>>>>>>> protocolo
>>>>>>>>> que se utiliza para eso y porque además un ASN solo
> tiene
>>>>>>>>> sentido en
>>>>>>>>> BGP, no hay ningún otro protocolo que lo utilice que no sea
>>>>>>> BGP o
>>>>>>>>> tenga directamente que ver con BGP (antes que me digas que
>>>>>>>>> RPKI lo
>>>>>>>>> utiliza por ejemplo).
>>>>>>>>>
>>>>>>>>> Lo otro era un ejemplo y no quiero seguir esa línea
> de debate.
>>>>>>>>>
>>>>>>>>> A modo de resumen, no estoy para nada de acuerdo en exigir
>>>>>>>>> % de
>>>>>>>>> tráfico de los protocolos como condición de asignación de
>>>>>>>>> recursos,
>>>>>>>>> porque técnicamente además no tiene ningún sentido (el
>>>>>>>>> operador debe
>>>>>>>>> hacer todo el despliegue y asignar los prefijos según las
>>>>>>>>> recomendaciones... pero hasta allí, no me prece que
> hacerlo
>>>>>>>>> responsable de que además de cumplir ciertos niveles de
>>>>>>>>> tráfico sea
>>>>>>>>> razonable, ni que puedas revocarle recursos porque no llega a
>>>>> ciertos
>>>>>>>>> niveles. O acaso le vas a revocar las asignaciones de IPv6 si
>>>>> desplegó
>>>>>>>>> todo correctamente, asignó a todos sus clientes pero no
>>>>>>>>> llega por X
>>>>>>>>> motivo a tener cierto volumen de tráfico... perdona, pero
>>>>>>>>> pensé que lo
>>>>>>>>> que se buscaba era promover el despliegue de IPv6.
>>>>>>>>>
>>>>>>>>> Abrazo,
>>>>>>>>> Nico
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> El mar, 13 de abr. de 2021 a la(s) 15:09, JORDI PALET
>>>>>>>>> MARTINEZ via
>>>>>>>>> Politicas (politicas at lacnic.net) escribió:
>>>>>>>>> >
>>>>>>>>> > Hola Nico,
>>>>>>>>> >
>>>>>>>>> > No concuerdo contigo y te pongo un par de ejemplos:
>>>>>>>>> >
>>>>>>>>> > 1) Para tener ASN, pedimos que se use BGP, es decir
>>>>>>>>> especificamos un protocolo. Ponemos otros requisitos para otras
>>>>>>>>> partes del manual.
>>>>>>>>> >
>>>>>>>>> > 2) El ayuntamiento de muchas ciudades, igual que los
>>>>>>>>> gobiernos, ya están indicando que tu carro debe contaminar menos
>>>>>>>>> de % y una tabla de progresión "negativa" a lo largo de x años o
>>>>>>>>> no te permite usarlo. Igualmente, ya están indicando la
>>>>>>>>> prohibición del uso de vehículos diésel o gasolina en determinadas
>>>>>>>>> ciudades, o zonas de la ciudad, y eso se va extendiendo
>>>>>>>>> progresivamente a regiones o países en los próximos años. Hay
>>>>>>>>> muchas medidas similares, como son que, si se incrementa la
>>>>>>>>> polución en una ciudad y área
>>>>>>> limítrofe, esos días solo acceden vehículos eléctricos, híbridos o
>>>>>>> con pila de combustible (hidrógeno), o que los
>>>>> contaminantes no puedan aparcar en las zonas publicas/calles y por
>>>>> tanto solo en parkings de pago, etc., etc.
>>>>>>>>> >
>>>>>>>>> > Son hechos, no es ficción, igual que he visto en países
>>>>>>>>> de LAC otras medidas como "pico y placa" para circulación por
>>>>> días alternos según las placas, etc.
>>>>>>>>> >
>>>>>>>>> > Al final todo se reduce a decidir si consideramos que
>>>>>>>>> IPv4 es un protocolo que esta "agotado" o que debe de agotarse en
>>>>>>>>> "x" años y
>>>>>>> como fomentarlo al principio (reducciones de impuestos para
>>>>>>> vehículos no contaminantes) y como obligarlo para los rezagados
>>>>>>> (prohibición
>>>>>>> de circular con esos carros). Y hablamos aquí de protocolo, de una
>>>>>>> realidad medible y certera, mientras que, si evaluamos el manual de
>>>>>>> políticas, podríamos ver muchas "subjetividades" que como comunidad
>>>>>>> hemos decidido.
>>>>>>>>> >
>>>>>>>>> > Si quieres conducir por zonas que no "contaminan a nadie"
>>>>>>>>> (y todo es relativo), como montes o desiertos, o donde el impacto
>>>>>>>>> es "menor",
>>>>>>> se te puede dar mas plazo.
>>>>>>>>> >
>>>>>>>>> > Ojo que hay un detalle muy importante, que quizas algunos
>>>>>>>>> no aprecian. No obligamos a dejar de usar IPv4 o a no proporcionar
>>>>>>>>> servicio con él, sino que cuando despliegas IPv6 a tus clientes,
>>>>>>>>> eso "ocurre" de una forma natural, y por eso esos % de tráfico
>>>>>>>>> IPv6 se producen sin mayor esfuerzo (una vez hecho el despliegue)
>>>>>>>>> y en cambio, tu opex y
>>>>> capex IPv4 se pueden reducir, si lo haces bien (ejemplo IPv6-only +
>>>>> IPv4aaS
>>>>>>> frente a dual-stack).
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > Saludos,
>>>>>>>>> > Jordi
>>>>>>>>> > @jordipalet
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > El 13/4/21 19:50, "Politicas en nombre de Nicolas
>>>>>>>>> Antoniello" <politicas-bounces at lacnic.net en nombre de
>>>>>>>>> nantoniello at gmail.com> escribió:
>>>>>>>>> >
>>>>>>>>> > Hola Jordi,
>>>>>>>>> >
>>>>>>>>> > Tratando únicamente uno de los puntos que
>>>>>>>>> mencionaste, una cosa es
>>>>>>>>> > pedir que las direcciones que el RIR asigna sean
>>>>>>>>> utilizadas, esto es,
>>>>>>>>> > asignadas a clientes. Y otra muy diferente (con la
>>>>>>>>> que en principio
>>>>>>>>> > discrepo completamente) es exigir % de tráfico de un
>>>>>>>>> determinado
>>>>>>>>> > protocolo... hay un millón de razones (técnicas y no
>>>>>>>>> técnicas) por las
>>>>>>>>> > cuales eso es sumamente subjetivo y particular de
>>>>>>>>> cada operador y de
>>>>>>>>> > hecho muchas de esas razones son ajenas al propio
>>>>>>>>> operador.
>>>>>>>>> >
>>>>>>>>> > Es como si el Ayuntamiento en tu ciudad te exigiera que
>>>>> para poder
>>>>>>>>> > tener un vehículo tienen que utilizarlo al menos 125
>>>>>>>>> veces al mes...
>>>>>>>>> > no, te piden que tengas todo el regla, pero el % de uso
>>>>> es
>>>>>>> cosa tuya y
>>>>>>>>> > solo tuya.
>>>>>>>>> >
>>>>>>>>> > Saludos,
>>>>>>>>> > Nico
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > El mar, 13 de abr. de 2021 a la(s) 14:38, JORDI PALET
>>>>>>>>> MARTINEZ via
>>>>>>>>> > Politicas (politicas at lacnic.net) escribió:
>>>>>>>>> > >
>>>>>>>>> > > Respecto de la falta de medidas coercitivas, creo que
>>>>> no
>>>>>>> es el caso, si existen.
>>>>>>>>> > >
>>>>>>>>> > > Una vez que tenemos en marcha cualquier política,
>>>>>>>>> hay que intentar que se verifiquen de forma periódica, y eso ya lo
>>>>> tenemos reglamentado con la política que consensuamos no hace tanto:
>>>>>>>>> > >
>>>>>>>>> > > 7. REVOCACIÓN Y DEVOLUCIÓN DE RECURSOS
>>>>>>>>> (https://www.lacnic.net/550/1/lacnic/)
>>>>>>>>> > >
>>>>>>>>> > > Una cosa que podría ayudar, y que considero
> que no
>>>>>>>>> supone mucho trabajo si se hace progresivamente, según la
>>>>>>>>> disponibilidad de recursos, ya lo he comentado con el staff, es
>>>>>>>>> convertir eso en
>>>>> un
>>>>>>> "dashboard" para que los que tienen recursos, puedan ver su nivel de
>>>>>>> cumplimiento de las políticas que se van agregando a ese dashboard,
>>>>>>> incluso que se les envíen alertas, etc. El esfuerzo adicional
> es
>>>>>>> mínimo - una vez que hay un test para una determinada parte del
>>>>>>> manual, que
>>>>>>> es automático y repetitivo, solo hay que agregar el "widget"
>>>>>>> correspondiente en el dashboard. Esta claro que debemos presuponer
>>>>>>> que todos buscamos el cumplimiento y no la mala fe, así que
>>>>>>> cualquier ayuda que se proporcione para advertir de posibles
>>>>>>> incumplimientos, debe ser algo
>>>>> muy positivo, y solo si tras alertas, se mantiene el incumplimiento,
>>>>> entonces el staff debe ser alertado para una verificación manual, etc.
>>>>>>>>> > >
>>>>>>>>> > > Esto es en AFRINIC una propuesta de política
>>>>>>>>> (https://www.afrinic.net/policy/proposals/2020-gen-001-d1?lang=en-GB#proposal),
>>>>>>>>> porque ellos no tienen algo equivalente a nuestra sección 7
> del
>>>>>>>>> manual, pero aquí creo que no necesitamos una política, porque
>>>>>>>>> puede ser algo operacional (convertir en algo gráfico la sección
>>>>>>> 7, dentro de mylacnic).
>>>>>>>>> > >
>>>>>>>>> > > Ahora bien, hay que buscar, en el caso de la
>>>>>>>>> propuesta de Fernando, una forma de "medirlo", que sea automatizable.
>>>>>>>>> > >
>>>>>>>>> > > Por eso en su momento, quizás fue en la primera
>>>>>>>>> versión de esta propuesta, a raíz de un comentario de Nico,
>>>>>>>>> propuse que quizás había que medir el grado de adopción por
>>>>>>>>> niveles de tráfico:
>>>>>>>>> > >
>>>>>>>>> https://mail.lacnic.net/pipermail/politicas/2020-February/005352.html
>>>>>>>>> > >
>>>>>>>>> > > Esto cada vez es mas fácil:
>>>>>>>>> > >
>>>>>>>>> > > 1) Porque esas medidas, las tenemos por ASN
>>>>>>>>> disponibles de forma pública y neutral
>>>>>>>>> (https://stats.labs.apnic.net/ipv6)
>>>>>>>>> > > 2) Porque sabemos que una red que despliega IPv6,
>>>>>>>>> en función de si sus clientes son mayoritariamente residenciales o
>>>>>>>>> corporativos, los % de tráfico IPv6 sobre la parte donde ha
> hecho
>>>>>>>>> el despliegue, son conocidos, crecientes y muy simétricos de unas
>>>>>>>>> a otras redes.
>>>>>>>>> > >
>>>>>>>>> > > Por ejemplo, una red celular alcanza fácilmente el
>>>>>>>>> 90% de tráfico IPv6. Obviamente no tenemos que "pedir" que cumpla
>>>>> el
>>>>>>> 90%, pero y si nos basta con pedir el 30% al cabo de x meses, 60% un
>>>>>>> año después, etc.
>>>>>>>>> > >
>>>>>>>>> > > Igualmente, en una red residencial, sabemos que el
>>>>>>>>> tráfico IPv6 pasa a ser como poco el 75%, y fácilmente
> hasta el 85%,
>>>>>>> pues pidamos inicialmente el 25%.
>>>>>>>>> > >
>>>>>>>>> > > En base a esos parámetros, y teniendo en cuenta que
>>>>>>> en redes corporativas el tráfico es menor, podemos establecer
> un
>>>>>>> baremo y no pedir "todo" inicialmente, si no en pasos progresivos.
>>>>>>>>> > >
>>>>>>>>> > > Y eso puede ser monitorizado de forma periódica y
>>>>>>>>> automática, sin un "gran" esfuerzo de desarrollo, con un acuerdo
>>>>>>>>> con APNIC para que esos datos sean proporcionados (si no lo están ya)
>>>>> con algún mecanismo tipo JSON, etc.
>>>>>>>>> > >
>>>>>>>>> > > Parece mas complejo, pero creo que en realidad es
>>>>>>>>> *menos* complejo que la forma "documental" en la propuesta actual,
>>>>>>>>> y quizas,
>>>>> debe ser otra propuesta, y que aplique a todos los miembros, y que la
>>>>> aplicación de los baremos y plazos, obviamente, dependa de si es para
>>>>> delegaciones iniciales, existentes, o transferencias (donde entraría la
>>>>>>> propuesta de Fernando). E insisto, la gran ventaja es que esos baremos
>>>>> se
>>>>>>> pueden 1) monitorizar de forma automatizada y 2) ajustar cada 2-3
>>>>>>> años, según avance el despliegue de IPv6.
>>>>>>>>> > >
>>>>>>>>> > > Saludos,
>>>>>>>>> > > Jordi
>>>>>>>>> > > @jordipalet
>>>>>>>>> > >
>>>>>>>>> > >
>>>>>>>>> > >
>>>>>>>>> > > El 13/4/21 18:51, "Politicas en nombre de Fernando
>>>>>>>>> Frediani" <politicas-bounces at lacnic.net en nombre de
>>>>>>>>> fhfrediani at gmail.com> escribió:
>>>>>>>>> > >
>>>>>>>>> > > Hola Oscar. Las transferencias de recursos no
>>>>>>>>> registradas son un
>>>>>>>>> > > problema permanente y están presentes en
>>>>>>>>> *cualquier propuesta*, no solo
>>>>>>>>> > > en esta. Existen mecanismos administrativos y
>>>>>>>>> legales para mitigar y en
>>>>>>>>> > > última instancia sancionar a los malos actores
>>>>>>>>> que firmaron un contrato
>>>>>>>>> > > de acuerdo con las normas vigentes.
>>>>>>>>> > >
>>>>>>>>> > > La preocupación planteada por algunos acerca
>>>>> de
>>>>>>> este "pequeño esfuerzo"
>>>>>>>>> > > ya ha sido mencionada algunas veces e incluso
>>>>>>>>> modificada en el texto de
>>>>>>>>> > > la propuesta para dejar aún más claro que no
>>>>>>>>> significa simplemente que
>>>>>>>>> > > se anuncie IPv6 para DFZ, sino poder demostrar
>>>>>>>>> objetivamente bajo
>>>>>>>>> > > criterios a ser definidos por el stafff de LACNIC
>>>>> de
>>>>>>> la misma forma que
>>>>>>>>> > > estos criterios ya existen a la hora de
>>>>>>>>> justificar el uso en una nueva
>>>>>>>>> > > cesión o transferencia de IPv4. Además,
>>>>> en
>>>>>>> la versión 4 de
>>>>>>>>> > > esta
>>>>>>>>> > > propuesta, se hizo aún más claro, sin entrar en
>>>>>>>>> detalles técnicos y
>>>>>>>>> > > operativos, lo que significa el término
> "partes
>>>>>>> significativas de la
>>>>>>>>> > >
>>>>>>>>> > > red" para que no haya dudas sobre los intentos de
>>>>> inventar esta
>>>>>>>>> > > percepción de que IPv6 solo está operativo
>>>>>>> para pasar por la
>>>>>>>>> > > transferencia. En muchos casos, el esfuerzo que
>>>>>>>>> tendrán que hacer para
>>>>>>>>> > > intentar hacer esto puede invertirse en una
>>>>>>>>> implementación de IPv6 real.
>>>>>>>>> > > No tengo muchas dudas de que todas estas
>>>>>>>>> preocupaciones son una pequeña
>>>>>>>>> > > parte de los casos, y cuando lo estén, estarán
>>>>>>>>> muy bien justificadas si
>>>>>>>>> > > tienen que cumplir con este requisito.
>>>>>>>>> > >
>>>>>>>>> > > La falta de "reglas coercitivas" como se cita
>>>>>>>>> en mi opinión hace aún más
>>>>>>>>> > > daño al sistema de control de recursos de
>>>>>>>>> numeración que tener algunas
>>>>>>>>> > > reglas que puede considerarse coercitivo. El
>>>>>>>>> "refuerzo positivo" y la
>>>>>>>>> > > esperanza de buena voluntad no han funcionado
>>>>>>>>> bien hasta ahora.
>>>>>>>>> > > Continuar haciéndolo de la misma manera
> solo
>>>>> traerá los mismos resultados.
>>>>>>>>> > > Vea que esta propuesta no tiene nada que ver
>>>>>>>>> con la coacción, no
>>>>>>>>> > > obligará automáticamente a colocar
> a quienes no
>>>>>>>>> tienen IPv6. Solo
>>>>>>>>> > > aquellos que están creando una pérdida para
>>>>>>>>> otros que tienen un
>>>>>>>>> > > objetivo
>>>>>>>>> > > y una contraparte razonablemente fácil de lograr.
>>>>>>>>> > >
>>>>>>>>> > > Saludos e gracias por su aporte.
>
>>>>>>>>> > > Fernando
>>>>>>>>> > >
>>>>>>>>> > > On 13/04/2021 13:24, Oscar A. Robles-Garay wrote:
>>>>>>>>> > > >
>>>>>>>>> > > > Gracias por el seguimiento Fernando.
>>>>>>>>> > > >
>>>>>>>>> > > > Como en toda política, debemos ser concientes
>>>>>>> no solo de las
>>>>>>>>> > > > consecuencias deseadas (Happy Path), sino
>>>>>>>>> tambén de las consecuencias
>>>>>>>>> > > > inesperadas. No estamos intentando resolver una
>>>>> ecuación matemática,
>>>>>>>>> > > > sino que estamos intentando regular conductas
>>>>>>>>> de actores privados que
>>>>>>>>> > > > toman decisiones en función de sus
>>>>>>>>> necesidades de negocio.
>>>>>>>>> > > >
>>>>>>>>> > > > Por lo anterior, de aceptarse esta propuesta,
>>>>>>>>> debemos asumir que los
>>>>>>>>> > > > operadores encontrarán "otras vías" para
>>>>>>> atender sus necesidades si
>>>>>>>>> > > > los mecanismos actuales no les ayudan a
>>>>>>>>> resolverlas:
>>>>>>>>> > > >
>>>>>>>>> > > > * Transferencias de recursos no registradas
>>>>>>>>> > > > * Renta/alquiler de recursos
>>>>>>>>> > > > * En el mejor de los casos, realizarán un
>>>>>>>>> pequeño esfuerzo para
>>>>>>>>> > > > cumplir el requisito de "despliegue de
>>>>>>>>> IPv6", mismo que apagarán
>>>>>>>>> > > > en cuanto pasen la prueba y encenderán
>>>>> una vez que haga real
>>>>>>>>> > > > sentido de negocio (business case).
>>>>>>>>> > > >
>>>>>>>>> > > > Si logramos que estas consecuencias inesperadas
>>>>> sean la minoría de
>>>>>>>>> > >
>>>>>>>>> > > > casos, entonces tu propuesta habrá sido un
>>>>> éxito (pues la mayoría
>>>>>>>>> > > > siguió el happy path).
>>>>>>>>> > > >
>>>>>>>>> > > > Sin embargo, debido a las dificultades para
>>>>>>>>> determinar con certeza el
>>>>>>>>> > > > nivel de transferencias fuera del sistema (a
>>>>>>>>> menos
>>>>>>> que seas un broker)
>>>>>>>>> > > > nos quedaremos con la incertidumbre y
>>>>>>>>> habremos abonado al
>>>>>>>>> > > > establecimmiento de reglas coercitivas que
> no
>>>>>>>>> sabemos si están
>>>>>>>>> > > > ayudando al desarrollo de Internet, pero sí
>>>>> lo estan haciendo más
>>>>>>>>> > > > complejo y contrario al espíritu de adopción
>>>>>>>>> voluntaria de sus protocolos.
>>>>>>>>> > > >
>>>>>>>>> > > > Saludos,
>>>>>>>>> > > >
>>>>>>>>> > > > Oscar
>>>>>>>>> > > >
>>>>>>>>> > > > On 13/4/21 13:05, Fernando Frediani wrote:
>>>>>>>>> > > >> Hola
>>>>>>>>> > > >>
>>>>>>>>> > > >> Jorge - No hay problema en agregar este
>>>>>>>>> requisito
>>>>>>> para que sea
>>>>>>>>> > > >> posible permitir la transferencia dadas las
>>>>>>>>> justificaciones que ya se
>>>>>>>>> > > >> han presentado en varios mensajes anteriores.
>>>>>>>>> > > >> En cuanto al argumento de que las
>>>>>>>>> transferencias se realizan "fuera
>>>>>>>>> > > >> del registro", ya se ha explicado muchas veces
>>>>> en
>>>>>>> los mensajes
>>>>>>>>> > > >> anteriores cómo esta no puede considerarse
>>>>>>>>> una objeción válida ya que
>>>>>>>>> > > >> existen suficientes garantías para mitigar
>>>>>>>>> este temor que está
>>>>>>>>> > >
>>>>>>>>> > > >> presente en cualquier otra propuesta.
>>>>>>>>> > > >>
>>>>>>>>> > > >> Hernán - No sé qué datos está
>>>>>>> buscando, pero ya se
>>>>>>>>> > > han presentado
>>>>>>>>> > > >> varios escenarios de la vida real y ejemplos
>>>>>>>>> prácticos técnicos y
>>>>>>>>> > > >> económicos, comenzando con aumentos
>>>>>>>>> significativos en el costo de
>>>>>>>>> > >
>>>>>>>>> > > >> aumentar las operaciones con CGNAT y la
>>>>>>>>> creciente
>>>>>>> necesidad de
>>>>>>>>> > > >> utilizar el mercado de transferencia.
>>>>>>>>> Cualquiera que gestione un
>>>>>>>>> > > >> negocio en Internet o una gestión técnica es
>>>>>>>>> consciente de todos los
>>>>>>>>> > > >> problemas y costes que conllevan estos
>>>>>>>>> problemas.
>>>>>>>>> > > >> Con respecto al posible loop, es posible que
>>>>>>>>> no hayas podido leer la
>>>>>>>>> > > >> propuesta en su totalidad, pero predice que
>>>>>>>>> las nuevas organizaciones
>>>>>>>>> > > >> que no tengan ningún bloque de IPv4 podrán
>>>>>>>>> realizar una transferencia
>>>>>>>>> > > >> inicial hasta el límite de un /22 sin la
>>>>>>>>> necesidad para demostrar
>>>>>>>>> > >
>>>>>>>>> > > >> IPv6 operativo.
>>>>>>>>> > > >> No entiendo por qué se considera extraño que
>>>>>>>>> esta política
>>>>>>>>> > > >> "obstaculice" si logra realizar una
>>>>>>>>> transferencia
>>>>>>> IPv4 sin la
>>>>>>>>> > > >> contraparte de IPv6. Desde mi punto de vista
>>>>>>>>> es normal que alguien
>>>>>>>>> > > >> que a mediados de 2021 no tenga IPv6 operativo
>>>>> tenga otros problemas
>>>>>>>>> > > >> que están afectando a todos los demás a
>>>>>>> resolver antes de seguir
>>>>>>>>> > > >> transfiriendo más IPv4.
>>>>>>>>> > > >>
>>>>>>>>> > > >> Oscar - hablando simplemente sí. Una
> empresa
>>>>>>> que se enfrenta a la
>>>>>>>>> > >
>>>>>>>>> > > >> necesidad de transferir más IPv4 para
>>>>>>>>> incrementar su operación (y en
>>>>>>>>> > > >> consecuencia su tráfico) y sin embargo,
>>>>>>>>> hasta ahora no ha hecho
>>>>>>>>> > > >> ningún despliegue de IPv6 está causando
>>>>>>> daño a todos los demás,
>>>>>>>>> > > >> incluidos los que hicieron sus obligaciones,
>>>>>>>>> por eso ya no se debería
>>>>>>>>> > > >> permitir que se realicen transferencias IPv4
>>>>>>>>> sin la consideración
>>>>>>>>> > > de
>>>>>>>>> > > >> demostrar IPv6 y reducir la tasa de
>>>>>>>>> crecimiento de un problema mucho
>>>>>>>>> > > >> más serio de lo que les ha parecido a
>>>>>>>>> algunas personas que desean
>>>>>>>>> > > que
>>>>>>>>> > > >> estos actores se sientan muy cómodos
> para
>>>>> continuar causando estos
>>>>>>>>> > > >> problemas en ecosistema Internet. A menudo
>>>>>>>>> he dicho que este
>>>>>>>>> > > >> requisito no es tan grande ni tan difícil
>>>>> de
>>>>>>> lograr. Quizás algunos
>>>>>>>>> > > >> estén sobrestimando este requisito como algo
>>>>>>> que hará que las
>>>>>>>>> > > >> transferencias IPv4 sean totalmente
>>>>>>>>> inviables y este no es ni nunca
>>>>>>>>> > > >> fue el propósito de esta propuesta.
>>>>>>>>> > > >>
>>>>>>>>> > > >> Saludos
>>>>>>>>> > > >> Fernando
>>>>>>>>> > > >>
>>>>>>>>> > > >> On 13/04/2021 10:28, Oscar A. Robles-Garay
>>>>>>>>> wrote:
>>>>>>>>> > > >>> Fernando,
>>>>>>>>> > > >>>
>>>>>>>>> > > >>> Si estoy entendiendo bien, con tu propuesta
>>>>>>>>> esperas que tenga como
>>>>>>>>> > > >>> consecuencia "deseable" que aquellos ISP's
>>>>>>>>> que necesitan IPv4 y
>>>>>>>>> > > >>> hayan decidido ir al mercado de IPs por
>>>>>>>>> transferencias, se tomen un
>>>>>>>>> > > >>> tiempo para desplegar "algo" de IPv6, es
> así?
>>>>>>>>> > > >>>
>>>>>>>>> > > >>> Saludos,
>>>>>>>>> > > >>>
>>>>>>>>> > > >>> Oscar
>>>>>>>>> > > >>>
>>>>>>>>> > > >>>
>>>>>>>>> > > >>> On 12/4/21 15:23, Fernando Frediani wrote:
>>>>>>>>> > > >>>> Hola Raul
>>>>>>>>> > > >>>> Gracias por tu contribución.
>>>>>>>>> > > >>>>
>>>>>>>>> > > >>>> No podemos confundir IPv4 y IPv6, que son
>>>>>>>>> recursos de numeración,
>>>>>>>>> > > >> el
>>>>>>>>> > > >>>> tema principal de nuestra discusión, con
>>>>>>>>> MANRS y participación en
>>>>>>>>> > > >>>> IXPs. Si bien MANRS es una buena práctica
>>>>>>>>> y la participación
>>>>>>>>> > > >> en IXP
>>>>>>>>> > > >>>> es positiva, el uso de *recursos de
>>>>>>>>> numeración* y el impacto de
>>>>>>>>> > >
>>>>>>>>> > > >>>> cómo el mal uso (o no uso) puede poner en
>>>>>>>>> duda la continuidad de la
>>>>>>>>> > > >>>> evolución de un sistema que depende de
>>>>>>>>> diferentes actores.
>>>>>>>>> > > >>>>
>>>>>>>>> > > >>>> Sí, estas restricciones ciertamente están
>>>>>>>>> relacionadas con
>>>>>>>>> > > el uso
>>>>>>>>> > > >>>> óptimo de los recursos. Si una
>>>>>>>>> organización necesita recursos para
>>>>>>>>> > > >>>> seguir desarrollando y conectando a más
>>>>> personas y ya no puede
>>>>>>>>> > > >>>> acceder a estos recursos y existe una
>>>>>>>>> solución (IPv6) que, de ser
>>>>>>>>> > > >>
>>>>>>>>> > > >>>> operativa, elimina
>>>>>>>>> > > >>>> estas restricciones, es necesario que esta
>>>>>>>>> sea la solución y que sea
>>>>>>>>> > > >>>> estimulado.
>>>>>>>>> > > >>>> Es importante tener en cuenta que *IPv6
> es
>>>>>>>>> el protocolo de Internet
>>>>>>>>> > > >>>> estándar* desde 2017, no solo una buena
>>>>> práctica. No soy yo quien
>>>>>>>>> > > >>>> lo dice, sino el IETF.
>>>>>>>>> > > >>>>
>>>>>>>>> > > >>>> Con respecto a lo trade-off es lo que he
>>>>>>>>> estado
>>>>>>> tratando de decir
>>>>>>>>> > > >>>> que es muy, muy aceptable. No existe nada
>>>>>>>>> difícil, complejo o
>>>>>>>>> > > >>>> imposible de tener, al contrario, es algo
>>>>>>>>> bastante obvio para
>>>>>>>>> > > >>>> cualquier poseedor de recursos de
>>>>>>>>> numeración. Los efectos de no
>>>>>>>>> > >
>>>>>>>>> > > >>>> hacer nada son mucho peores que hacer en
>>>>>>>>> este ejemplo.
>>>>>>>>> > > >>>>
>>>>>>>>> > > >>>> Saludos
>>>>>>>>> > > >>>> Fernando Frediani
>>>>>>>>> > > >>>>
>>>>>>>>> > > >>>> On 12/04/2021 13:28, Raúl Echeberría wrote:
>>>>>>>>> > > >>>>> Fernando,
>>>>>>>>> > > >>>>>
>>>>>>>>> > > >>>>> Por supuesto leí la propuesta completa
>>>>> y los cambios de la última
>>>>>>>>> > > >>>>> versión. No leí el título solamente. En
>>>>>>>>> ese caso no me
>>>>>>>>> > > >> hubiera
>>>>>>>>> > > >>>>> atrevido a hacer comentarios.
>>>>>>>>> > > >>>>>
>>>>>>>>> > > >>>>> Es cierto que todas las políticas
> de
>>>>>>>>> alguna forma fuerzan el
>>>>>>>>> > > >>>>> cumplimiento de ciertos requisitos y
>>>>>>>>> afectan de forma más o menos
>>>>>>>>> > > >>>>> artificial el mercado. El punto es donde
>>>>>>>>> está el “trade off”.
>>>>>>>>> > > >>>>>
>>>>>>>>> > > >>>>> Se supone que esas restricciones tienen que
>>>>> estar vinculadas al
>>>>>>>>> > > >>>>> uso óptimo de los recursos de numeración,
>>>>>>>>> no de Internet en si misma.
>>>>>>>>> > > >>>>>
>>>>>>>>> > > >>>>> Esta propuesta, si bien muy bien
>>>>>>>>> intencionada,
>>>>>>> está desde mi punto
>>>>>>>>> > > >>>> de vista, más allá del "trade
> off"
>>>>> aceptable.
>>>>>>>>> > > >>>>>
>>>>>>>>> > > >>>>>
>>>>>>>>> > > >>>>> Internet es una construcción colaborativa
>>>>>>> donde la base de la
>>>>>>>>> > > >>>>> colaboración y la coordinación es
>>>>> voluntaria. Hacerlo diferente
>>>>>>>>> > > >>>>> cambia la naturaleza de Internet y por
> lo
>>>>>>>>> menos a mi con todo
>>>>>>>>> > > >>>>> respeto, no me
>>>>>>>>> > > >>>> parece lo correcto. Por supuesto es muy
>>>>>>>>> respetable que tengas una
>>>>>>>>> > > >>>> opinión diferente.
>>>>>>>>> > > >>>>>
>>>>>>>>> > > >>>>> Si hoy aprobamos esta política, mañana la
>>>>>>>>> propuesta será
>>>>>>>>> > > >>
>>>>>>>>> > > >>>> hacer que la adopción de MANRS sea
>>>>>>>>> obligatoria y luego será
>>>>>>>>> > > la
>>>>>>>>> > > >>>> conexión a un IXP y luego otra cosa.
>>>>>>>>> Siempre hay prácticas que nos
>>>>>>>>> > > >>>> parecen buenas y que quisiéramos que sean
>>>>>>>>> adoptadas masivamente,
>>>>>>>>> > > >>>> pero pare eso está el trabajo colaborativo
>>>>>>> que, entre otros, hacen los
>>>>>>>>> > > >>
>>>>>>>>> > > >>>> NOGs y los trabajos de extensión y
>>>>>>>>> difusión de organizaciones como
>>>>>>>>> > > >>>> ISOC o los RIRs.
>>>>>>>>> > > >>>>>
>>>>>>>>> > > >>>>> No querramos forzar la implementación de
>>>>>>>>> buenas prácticas
>>>>>>>>> > >
>>>>>>>>> > > >>>>> operativas a través de las políticas.
>>>>>>>>> > > >>>>>
>>>>>>>>> > > >>>>>
>>>>>>>>> > > >>>>>
>>>>>>>>> > > >>>>> Saludos,
>>>>>>>>> > > >>>>>
>>>>>>>>> > > >>>>> Raúl
>>>>>>>>> > > >>>>>
>>>>>>>>> > > >>>>>
>>>>>>>>> > > >>>>>
>>>>>>>>> > > >>>>>
>>>>>>>>> > > >>>>>> El 12 abr. 2021, a las 11:57, Fernando
>>>>>>>>> Frediani
>>>>>>>>> > > >>>>>> <fhfrediani at gmail.com>
>>>>>>>>> > > >>>> escribió:
>>>>>>>>> > > >>>>>>
>>>>>>>>> > > >>>>>> Hola de nuevo Raul
>>>>>>>>> > > >>>>>>
>>>>>>>>> > > >>>>>> Mira, cambiar las políticas como
> propone
>>>>>>> esta propuesta no está
>>>>>>>>> > > >>>>>> obligando a nadie a poner IPv6 o a
>>>>>>>>> convertir a LACNIC en una
>>>>>>>>> > > >>>>>> "policía IPv6". Solo afecta a quienes
>>>>> desean transferir IPv4 y en
>>>>>>>>> > > >>>>>> este caso no hay nada de malo. Y la
>>>>>>>>> empresa que quiere actualizar
>>>>>>>>> > > >>>>>> la base de datos whois que funciona bajo
>>>>>>>>> reglas que se actualizan
>>>>>>>>> > > >>>>>> según el tiempo y según la necesidad de
>>>>>>>>> cada momento. Lo
>>>>>>>>> > > que se
>>>>>>>>> > > >>>>>> está considerando como contraparte no
>>>>> es
>>>>>>> nada que imposibilite el
>>>>>>>>> > > >>>>>> traspaso si la empresa tiene *un
>>>>>>>>> compromiso mínimo* con todos
>>>>>>>>> > > los
>>>>>>>>> > > >>>>>> demás, dado el momento que estamos
>>>>>>>>> atravesando.
>>>>>>>>> > > >>>>>>
>>>>>>>>> > > >>>>>> Otro punto que quiero destacar mucho es
>>>>>>>>> que parece que esta
>>>>>>>>> > > >>>>>> propuesta tiene como objetivo solucionar
>>>>>>>>> todos los problemas del
>>>>>>>>> > > >>>>>> despliegue de IPv6
>>>>>>>>> > > >>>> y no es nada de eso. Es solo una
>>>>>>>>> iniciativa más, pequeña por
>>>>>>>>> > > >> cierto,
>>>>>>>>> > > >>>> para incentivar el despliegue de IPv6 y
>>>>>>>>> sobre todo para evitar que
>>>>>>>>> > > >>>> quienes necesitan seguir transfiriendo
>>>>>>>>> IPv4 sigan causando más
>>>>>>>>> > > >>>> problemas a todos los que están cumpliendo
>>>>>>> con sus obligaciones.
>>>>>>>>> > > >>>>>> Dado el contexto actual, ya no tiene
>>>>>>>>> sentido cerrar los ojos y
>>>>>>>>> > > >>>>>> permitirse seguir registrando
>>>>>>>>> transferencias IPv4 sin tener en
>>>>>>>>> > > >>>>>> cuenta el desarrollo continuo y
>>>>>>>>> saludable del
>>>>>>> ecosistema del que
>>>>>>>>> > > >>>>>> todos dependemos a diario.
>>>>>>>>> > > >>>>>>
>>>>>>>>> > > >>>>>> El tema de las políticas que obligan al
>>>>>>>>> mercado es un tema
>>>>>>>>> > > >>>>>> complejo de discutir, pero para decirlo en
>>>>> pocas palabras si
>>>>>>>>> > > >>>>>> fuera tan indiferente, ni siquiera sería
>>>>>>> necesario justificar
>>>>>>>>> > > la
>>>>>>>>> > > >>>>>> necesidad de IPv4 en el momento de una
>>>>>>>>> asignación inicial o una
>>>>>>>>> > > >>>>>> transferencia. . Hay otros RIR que son
>>>>>>>>> mucho más permisivos que
>>>>>>>>> > > >>>>>> LACNIC, pero aquí felizmente tomamos la
>>>>>>>>> decisión correcta en este
>>>>>>>>> > > >>>>>> contexto.
>>>>>>>>> > > >>>>>>
>>>>>>>>> > > >>>>>> Fernando
>>>>>>>>> > > >>>>>>
>>>>>>>>> > > >>>>>> On 12/04/2021 11:11, Raúl Echeberría wrote:
>>>>>>>>> > > >>>>>>> Olá Gondim
>>>>>>>>> > > >>>>>>>
>>>>>>>>> > > >>>>>>> Concordamos em tudo, exceto em um
>>>>>>>>> elemento importante.
>>>>>>>>> > > >>>>>>> Compartilho sua preocupação e acho
>>>>>>> que algo precisa ser
>>>>>>>>> > > feito.
>>>>>>>>> > > >>>>>>> Onde discordamos
>>>>>>>>> > > >>>>>> é que Eu não acredito que forçar o
>>>>>>>>> comportamento do
>>>>>>>>> > > mercado de
>>>>>>>>> > > >>>>>> esse jeito, seja o papel das políticas, .
>>>>>>>>> > > >>>>>>> É necessário redobrar os esforços na
>>>>>>>>> promoção do IPv6 fornecendo
>>>>>>>>> > > >>>>>>> evidências que mostram os danos
> que
>>>>>>>>> você mencionou. É
>>>>>>>>> > > >> preciso ter
>>>>>>>>> > > >>>>>>> bons estudos, boas métricas e trabalhar
>>>>>>>>> > > >>>> para disseminá-los, capacitar, gerar
>>>>>>>>> capacidades técnicas,
>>>>>>>>> > > contatar
>>>>>>>>> > > >>>> os operadores e trabalhar com eles.
>>>>>>>>> > > >>>>>>>
>>>>>>>>> > > >>>>>>> Mas acredito que não é papel da
>>>>> política forçar
>>>>>>>>> > > >> o
>>>>>>>>> > > >>>> mercado, nem acredito que essa política
>>>>> será eficiente para atingir
>>>>>>>>> > > >>>> o objetivo que se propõe.
>>>>>>>>> > > >>>>>>>
>>>>>>>>> > > >>>>>>> É por isso Gondim, que embora concorde
>>>>>>>>> com você no seu
>>>>>>>>> > > >>>>>>> raciocínio e nas suas preocupações, NÃO
>>>>>>>>> apoio
>>>>>>>>> > > esta proposta.
>>>>>>>>> > > >>>>>>>
>>>>>>>>> > > >>>>>>>
>>>>>>>>> > > >>>>>>> Saudações
>>>>>>>>> > > >>>>>>>
>>>>>>>>> > > >>>>>>> Raúl
>>>>>>>>> > > >>>>>>>
>>>>>>>>> > > >>>>>>>
>>>>>>>>> > > >>>>>>>
>>>>>>>>> > > >>>>>>>> El 12 abr. 2021, a las 10:46, Gondim
>>>>>>>>> <gondim at gmail.com> escribió:
>>>>>>>>> > > >>>>>>>>
>>>>>>>>> > > >>>>>>>> Bom dia Raúl,
>>>>>>>>> > > >>>>>>>>
>>>>>>>>> > > >>>>>>>> O problema é que enquanto não tivermos
>>>>>>>>> uma política
>>>>>>>>> > > >> que
>>>>>>>>> > > >>>>>> alavanque o IPv6, está não irá
>>>>>>> crescer como deveria. É a famosa
>>>>>>>>> > > >>>>>> questão do: "Cão correndo atrás do rabo".
>>>>>>>>> > > >>>>>>>> As empresas não querem modificar seus
>>>>>>>>> sistemas para terem suporte
>>>>>>>>> > > >>>>>> à IPv6 porque as Operadoras que lhes
>>>>>>>>> fornecem Internet, e aos
>>>>>>>>> > >
>>>>>>>>> > > >>>>>> seus clientes, não possuem IPv6
>>>>>>>>> implementado. Em contra partida;
>>>>>>>>> > > >>>>>> as Operadoras não implementam IPv6,
>>>>>>>>> porque não veem conteúdo e
>>>>>>>>> > > >>>>>> nem a necessidade de IPv6, enquanto
>>>>>>>>> tiverem IPv4. Se ninguém sair
>>>>>>>>> > > >>>>>> da inércia vamos continuar a passos de
>>>>>>>>> caroça na implementação de
>>>>>>>>> > > >>>>>> IPv6.
>>>>>>>>> > > >>>>>>>> Diariamente, aqui na minha operação,
>>>>>>>>> eu vejo assinantes meus
>>>>>>>>> > > >>>>>> com problemas para acessarem sistemas
>>>>>>>>> externos e o mesmo ocorre
>>>>>>>>> > > >>>>>> em sentido contrário, de acessos
>>>>>>>>> externos aos nossos assinantes.
>>>>>>>>> > > >>>>>> Quando tento explicar, ao meu assinante,
>>>>>>>>> sobre a necessidade do
>>>>>>>>> > > >>>>>> uso do IPv6, este me diz que sua equipe de
>>>>> TI
>>>>>>> afirma não existir
>>>>>>>>> > > >>>>>> esse problema de falta de IPv4 e que é
>>>>> obrigação do
>>>>>>>>> > > Provedor dar
>>>>>>>>> > > >>>>>> IPv4 público para ele. Porque este é
>>>>>>> "universal". O que vejo é
>>>>>>>>> > > >>>>>> uma total
>>>>>>>>> > > >>>> desinformação do meu cliente mas também um
>>>>>>>>> reflexo de
>>>>>>>>> > > como o
>>>>>>>>> > > >>>> mercado está vendo esse problema.
>>>>>>>>> > > >>>>>>>> Conteúdos informativos e sociais já
>>>>>>> existem em IPv6 e isso
>>>>>>>>> > > >>>> é bom. Ter Google, Facebook, Netflix,
>>>>>>>>> Instagram, Linkedin, Youtube
>>>>>>>>> > > >>>> e outros de conteúdo, ajudam em muito
>>>>>>>>> nossa causa mas estamos
>>>>>>>>> > > >>>> esquecendo
>>>>>>>>> > > >>>>>> de outros sistemas que usamos no dia a
>>>>>>>>> dia. Sistemas
>>>>>>>>> > > >>>>>> empresariais, ERPs, empresas que
>>>>>>>>> desenvolvem software básico para
>>>>>>>>> > > >>>>>> diversas áreas
>>>>>>>>> > > >>>> e que não sentem a menor vontade de
>>>>>>>>> suportar IPv6. Porque muitas
>>>>>>>>> > > >>>> das vezes não conseguem acesso em IPv6 de
>>>>>>>>> seus provedores de
>>>>>>>>> > > >>>> Internet. Acredito que isso desmotive
>>>>>>>>> tecnicamente o esforço deles.
>>>>>>>>> > > >>>>>>>> Cada vez mais estamos investindo em
>>>>>>>>> CGNAT. Comprando
>>>>>>>>> > > >>>>>>>> equipamentos caríssimos para continuar
>>>>>>> usando uma rede
>>>>>>>>> > > >>>>>>>> remendada, debilitada. Porque o
>>>>>>>>> conteúdo em IPv4 continua
>>>>>>>>> > > >>>>>>>> crescendo e outros Sistemas Autônomos
>>>>>>>>> > > >>>>>> não querem implementar IPv6.
>>>>>>>>> > > >>>>>>>> Nós tivemos a época do esclarecimento
>>>>>>>>> sobre o IPv6, do
>>>>>>>>> > >
>>>>>>>>> > > >>>>>>>> incentivo, diversas organizações
>>>>>>>>> ministraram gratuitamente
>>>>>>>>> > > >>>>>>>> cursos de
>>>>>>>>> > > >>>>>> IPv6, palestras, fóruns especializados
>>>>>>>>> com materiais técnicos
>>>>>>>>> > > >>>>>> riquíssimos. Conteúdo informativo e
>>>>>>> educacional foram produzidos
>>>>>>>>> > > >>>>>> e experiências foram compartilhadas com
>>>>>>>>> todos, durante anos.
>>>>>>>>> > > >>>>>> Nesse momento; uma política permissiva
>>>>>>>>> só vai agravar mais a
>>>>>>>>> > > >>>>>> situação e que sabemos que futuramente
>>>>>>>>> será mais difícil resolver
>>>>>>>>> > > >>>>>> os problemas que aparecerão diante de
>>>>> nós.
>>>>>>>>> > > >>>>>>>> Estamos falando aqui da sobrevivência
>>>>>>>>> da Internet como um eco
>>>>>>>>> > > >>
>>>>>>>>> > > >>>>>>>> sistema que conhecemos. Se não
> for do
>>>>>>>>> RIR essa incumbência,
>>>>>>>>> > > >>>>>>>> então que seja de outro mas tenho
>>>>>>>>> convicção que sem isso, não
>>>>>>>>> > > >>>>>>>> iremos muito longe.
>>>>>>>>> > > >>>>>>>>
>>>>>>>>> > > >>>>>>>> O que me parece é que a ideia colocada
>>>>>>> nessa proposta é
>>>>>>>>> > > boa mas
>>>>>>>>> > > >>>>>>>> ninguém quer assumir o papel de
>>>>>>>>> "carrasco" e fazer valer algo
>>>>>>>>> > > >> que
>>>>>>>>> > > >>>>>>>> só vai beneficiar a todos e a
>>>>>>>>> Internet. Quantos anos mais serão
>>>>>>>>> > > >>>>>>>> necessários para percebermos isso?
>>>>>>>>> > > >>>>>>>>
>>>>>>>>> > > >>>>>>>> Saudações,
>>>>>>>>> > > >>>>>>>>
>>>>>>>>> > > >>>>>>>> Gondim
>>>>>>>>> > > >>>>>>>>
>>>>>>>>> > > >>>>>>>> Em 11/04/2021 19:00, Raúl Echeberría
>>>>>>>>> escreveu:
>>>>>>>>> > > >>>>>>>>> Estimados colegas.
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> > > >>>>>>>>> He seguido con atención la discusión
>>>>>>>>> sobre esta propuesta
>>>>>>>>> > > >>>> que me parece muy interesante.
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> > > >>>>>>>>> Debo decir que comparto el espíritu
>>>>>>>>> que fundamenta la
>>>>>>>>> > > >>>>>>>>> propuesta pero NO la apoyo porque
>>>>>>>>> creo que
>>>>>>> excede el rol que
>>>>>>>>> > > >>>>>>>>> debe tener LACNIC y las políticas de
>>>>>>>>> manejo de recursos de
>>>>>>>>> > >
>>>>>>>>> > > >>>>>>>>> numeración.
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> > > >>>>>>>>> Si bien soy totalmente empático con
>>>>>>>>> la idea de que los
>>>>>>>>> > > >>>>>>>>> operadores deberían contribuir
>>>>>>>>> activametne con el despliegue
>>>>>>>>> > > >> de
>>>>>>>>> > > >>>>>>>>> IPv6 creo que
>>>>>>>>> > > >>>>>> es algo que hay que trabajarlo a través
>>>>>>>>> de la promoción de
>>>>>>>>> > > >> IPv6 y
>>>>>>>>> > > >>>>>> no haciéndolo mandatorio en la política
>>>>>>>>> de transferencia.
>>>>>>>>> > > >>>>>>>>> Además de pensar, como decía,
>>>>> que esta propuesta excede
>>>>>>>>> > > >> lo que
>>>>>>>>> > > >>>>>>>>> desde mi punto de vista, deben ser
>>>>>>>>> las políticas de los RIRs,
>>>>>>>>> > > >>>>>>>>> tampoco creo que sea eficiente en
>>>>>>>>> lograr el objetivo que se
>>>>>>>>> > > >>>>>>>>> propone.
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> > > >>>>>>>>> No es claro que es que “IPv6 está
>>>>>>>>> operativo en partes
>>>>>>>>> > > >>>>>>>>> SIGNIFICATIVAS de la red” y tampoco
>>>>>>>>> está claro que
>>>>>>>>> > > sucede si,
>>>>>>>>> > > >>>>>>>>> una vez definido este criterio, la
>>>>>>>>> situación cambia luego de
>>>>>>>>> > > >> ser
>>>>>>>>> > > >>>>>>>>> aprobada la transferencia.
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> > > >>>>>>>>> Muchos operadores tienen IPv6 operativo
>>>>> en
>>>>>>> el core de la red
>>>>>>>>> > > >>>>>>>>> sin dar servicios a usuarios finales, y
>>>>> no
>>>>>>> hay dudas que el
>>>>>>>>> > > >>>>>>>>> core es una parte más que
>>>>>>>>> significativa de la red.
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> > > >>>>>>>>> Creo por supuesto que es y seguirá
>>>>> siendo un tema fundamental
>>>>>>>>> > > >>>>>>>>> seguir trabajando por el incremento del
>>>>> despliegue de IPv6 de
>>>>>>>>> > > >>>>>>>>> forma integral en Internet y eso es
>>>>>>>>> lo que
>>>>>>> ya hacen los RIRs y
>>>>>>>>> > > >>>>>>>>> muchas otras organizaciones. Me
>>>>>>>>> parece que
>>>>>>> hay que continuar
>>>>>>>>> > > >>>>>>>>> trabajando estos temas también
>>>>>>>>> > > >>>>>> en los grupos de operadores pero no
>>>>>>>>> apoyo que
>>>>>>> este requerimiento
>>>>>>>>> > > >>>>>> se incluya en la política de
>>>>>>>>> transferencia tal como se propone.
>>>>>>>>> > > >>>>>>>>> Saludos al autor de la propuesta por
>>>>>>>>> traer
>>>>>>> a discusión un tema
>>>>>>>>> > > >>>> super relevante. La discusión en si misma
>>>>>>>>> contribuye a la
>>>>>>>>> > > >>>> concientización sobre la necesidad
> de la
>>>>>>>>> aceleración del despliegue
>>>>>>>>> > > >>>> de IPv6.
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> > > >>>>>>>>> Saludos,
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> > > >>>>>>>>> Raúl
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> > > >>>>>>>>> 2.3.2.18.3 Los destinatarios en la
>>>>>>>>> región de LACNIC deberán
>>>>>>>>> > > >>>>>> tener espacio IPv6 distribuido/asignado
>>>>>>>>> por LACNIC o por un
>>>>>>>>> > > >>>>>> proveedor y deberán poder probar
> que
>>>>>>>>> este espacio está en uso,
>>>>>>>>> > > >>>>>> para lo cual deberán proporcionarle a
>>>>> LACNIC los detalles
>>>>>>>>> > > >>>>>> documentados del despliegue de la red
> para
>>>>> demostrar que IPv6
>>>>>>>>> > > >>>>>> está operativo
>>>>>>>>> > > >> en
>>>>>>>>> > > >>>>>> partes significativas de la red.
>>>>>>>>> > > >>>>>>>>> El personal de LACNIC definirá
> un
>>>>>>>>> criterio mínimo para
>>>>>>>>> > > >>>>>>>>> garantizar que la información
>>>>>>>>> proporcionada demuestre que IPv6
>>>>>>>>> > > >>>>>>>>> está
>>>>>>>>> > > >>>>>> operativo. De ser necesario, el personal
>>>>>>>>> puede requerir más
>>>>>>>>> > > >>>>>> información para validar este requisito.
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> El 31 mar. 2021, a las 11:37,
>>>>>>>>> info-politicas at lacnic.net
>>>>>>>>> > > >>>>>>>>>> escribió:
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> [Português abaixo]
>>>>>>>>> > > >>>>>>>>>> [English below]
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Estimados suscriptores de la lista
>>>>>>>>> de políticas de LACNIC,
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> La propuesta LAC-2020-1 ha pasado
> de
>>>>>>>>> la versión 3 a la versión 4
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Título: Agregar IPv6 operativo como
>>>>>>>>> requisito para las
>>>>>>>>> > > >>>>>>>>>> transferencias de IPv4
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Resumen: On 15th February 2017
>>>>>>>>> LACNIC started IPv4 Exhaustion
>>>>>>>>> > > >>>>>>>>>> Phase 3 meaning only new entrants
>>>>>>>>> can receive up to a single
>>>>>>>>> > > >>>>>>>>>> /22 of IPv4 space.
>>>>>>>>> > > >>>>>> Since then the amount of IPv4 Transfers
>>>>>>>>> between organizations has
>>>>>>>>> > > >>>>>> increased reasonably as shown by the
>>>>>>>>> official
>>>>>>> LACNIC reports.
>>>>>>>>> > > >>>>>> With the implementation of LAC-2019-1
>>>>>>>>> and possibility of
>>>>>>>>> > > >>>>>> Inter-RIR transfers these numbers have the
>>>>> potential to grow
>>>>>>>>> > > >>>>>> substantially.
>>>>>>>>> > > >>>>>>>>>> The objective of this proposal is
> to
>>>>>>>>> add as a requirement for
>>>>>>>>> > > >>>>>>>>>> organizations in process of
>>>>>>>>> receiving transferred IPv4 space
>>>>>>>>> > > >>>>>>>>>> under 2.3.2.18 to show they have an
>>>>>>>>> IPv6
>>>>>>>>> > > >>>>>>>>>> allocation/assignment by LACNIC or a
>>>>>>>>> provider and that is
>>>>>>>>> > > >>>>>>>>>> operational on their networks. Such
>>>>>>>>> organization must be able
>>>>>>>>> > > >>>>>>>>>> to prove this IPv6 space is being
> used
>>>>> by
>>>>>>> providing LACNIC
>>>>>>>>> > > >>>>>>>>>> the documented network deployment
>>>>>>>>> details
>>>>>>> to prove IPv6 is
>>>>>>>>> > > >>>>>>>>>> operational in significant parts of
>>>>>>>>> the network.
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> On 28th November 2019 LACNIC Board
>>>>>>>>> issued
>>>>>>> a statement
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> (https://www.lacnic.net/4283/2/lacnic/lacnic-board-calls-on-the-community-to-promote-ipv6-deployment)
>>>>>>>>> > > >>>>>>>>>> reinforcing the issue about IPv4
>>>>>>>>> exhaustion, mentioning IPv4
>>>>>>>>> > > >>>>>>>>>> address space will be exhausted by
>>>>>>>>> mid-2020 and calling the
>>>>>>>>> > > >>>>>>>>>> community to promote IPv6 deployment.
>>>>>>>>> > > >>>>>>>>>> In its statement LACNIC Board
>>>>>>>>> “invite the community to
>>>>>>>>> > > work
>>>>>>>>> > > >>>>>>>>>> on promoting the development of
>>>>>>>>> policies that will accelerate
>>>>>>>>> > > >>>>>>>>>> the effective deployment of IPv6 above
>>>>> other policies that
>>>>>>>>> > > >>>>>>>>>> may be discussed at a later date.”
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> In the case the receiver provides
> a
>>>>>>>>> written statement from
>>>>>>>>> > > >>>>>>>>>> its upstream that IPv6 connectivity is
>>>>> unavailable, the IPv6
>>>>>>>>> > > >>>>>>>>>> requirement may be waived. In the
> case
>>>>> LACNIC is not able to
>>>>>>>>> > > >>>>>>>>>> meet a new entrant request for IPv4
>>>>>>>>> space, or the
>>>>>>>>> > > >>>>>>>>>> organization does not hold any IPv4
>>>>>>>>> space
>>>>>>> the IPv6
>>>>>>>>> > > >>>>>>>>>> requirement may be waived for a
>>>>>>>>> transfer up to a /22.
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Para ver el detalle ingrese en:
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1/language/sp
>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Los cambios respecto a la versión
>>>>> anterior se pueden visualizar
>>>>>>>>> > > >>>>>> aquí:
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> https://politicas.lacnic.net/politicas/diff2?id=LAC-2020-1&v=4&v2=3&language=SP
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Los comentarios y los puntos de
>>>>>>>>> vista aportados por la
>>>>>>>>> > > >>>>>>>>>> comunidad son
>>>>>>>>> > > >>>>>> vitales para el correcto desarrollo del
>>>>>>>>> proceso de la propuestas
>>>>>>>>> > > >>>>>>>>>> - ¿Apoya usted o se opone a esta
>>>>>>>>> nueva versión de la
>>>>>>>>> > > propuesta?
>>>>>>>>> > > >>>>>>>>>> - ¿Ve alguna desventaja en esta
>>>>>>>>> nueva versión de la propuesta?
>>>>>>>>> > > >>>>>>>>>> - ¿Qué cambios podrían hacerse a
>>>>>>>>> esta nueva versión de la
>>>>>>>>> > > >>>>>>>>>> propuesta para que sea más eficaz?
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Por más información contacte
>>>>> a info-politicas at lacnic.net
>>>>>>>>> > > >>>>>>>>>> Saludos cordiales,
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> ______________________________________________________________________________________________________
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Prezados assinantes da lista de
>>>>>>>>> políticas de LACNIC,
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> A proposta LAC-2020-1 tem passado
> da
>>>>>>>>> versão 3 para a versão 4
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Título: Adicionar IPv6 operacional
>>>>>>>>> como requisito para as
>>>>>>>>> > >
>>>>>>>>> > > >>>>>>>>>> transferências do IPv4
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Resumo: On 15th February 2017 LACNIC
>>>>>>>>> started IPv4 Exhaustion
>>>>>>>>> > > >>>>>>>>>> Phase
>>>>>>>>> > > >>>> 3
>>>>>>>>> > > >>>>>> meaning only new entrants can receive
> up
>>>>>>>>> to a
>>>>>>> single /22 of IPv4
>>>>>>>>> > > >>>>>> space. Since then the amount of IPv4
>>>>>>>>> Transfers between
>>>>>>>>> > > >>>>>> organizations has increased reasonably
>>>>>>>>> as shown by the official
>>>>>>>>> > > >>>>>> LACNIC reports. With the implementation of
>>>>> LAC-2019-1 and
>>>>>>>>> > > >>>>>> possibility of Inter-RIR transfers these
>>>>>>>>> numbers have the
>>>>>>>>> > > >>>>>> potential to grow substantially.
>>>>>>>>> > > >>>>>>>>>> The objective of this proposal is
> to
>>>>>>>>> add as a requirement for
>>>>>>>>> > > >>>>>>>>>> organizations in process of
>>>>>>>>> receiving transferred IPv4 space
>>>>>>>>> > > >>>>>>>>>> under 2.3.2.18 to show they have an
>>>>>>>>> IPv6
>>>>>>>>> > > >>>>>>>>>> allocation/assignment by LACNIC or a
>>>>>>>>> provider and that is
>>>>>>>>> > > >>>>>>>>>> operational on their networks. Such
>>>>>>>>> organization must be able
>>>>>>>>> > > >>>>>>>>>> to prove this IPv6 space is being
> used
>>>>> by
>>>>>>> providing LACNIC
>>>>>>>>> > > >>>>>>>>>> the documented network deployment
>>>>>>>>> details
>>>>>>> to prove IPv6 is
>>>>>>>>> > > >>>>>>>>>> operational in significant parts of
>>>>>>>>> the network.
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> On 28th November 2019 LACNIC Board
>>>>>>>>> issued
>>>>>>> a statement
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> (https://www.lacnic.net/4283/2/lacnic/lacnic-board-calls-on-the-community-to-promote-ipv6-deployment)
>>>>>>>>> > > >>>>>>>>>> reinforcing the issue about IPv4
>>>>>>>>> exhaustion, mentioning IPv4
>>>>>>>>> > > >>>>>>>>>> address space will be exhausted by
>>>>>>>>> mid-2020 and calling the
>>>>>>>>> > > >>>>>>>>>> community to promote IPv6 deployment.
>>>>>>>>> > > >>>>>>>>>> In its statement LACNIC Board
>>>>>>>>> “invite the community to
>>>>>>>>> > > work
>>>>>>>>> > > >>>>>>>>>> on promoting the development of
>>>>>>>>> policies that will accelerate
>>>>>>>>> > > >>>>>>>>>> the effective deployment of IPv6 above
>>>>> other policies that
>>>>>>>>> > > >>>>>>>>>> may be discussed at a later date.”
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> In the case the receiver provides
> a
>>>>>>>>> written statement from
>>>>>>>>> > > >>>>>>>>>> its upstream that IPv6 connectivity is
>>>>> unavailable, the IPv6
>>>>>>>>> > > >>>>>>>>>> requirement may be waived. In the
> case
>>>>> LACNIC is not able to
>>>>>>>>> > > >>>>>>>>>> meet a new entrant request for IPv4
>>>>>>>>> space, or the
>>>>>>>>> > > >>>>>>>>>> organization does not hold any IPv4
>>>>>>>>> space
>>>>>>> the IPv6
>>>>>>>>> > > >>>>>>>>>> requirement may be waived for a
>>>>>>>>> transfer up to a /22.
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Para ver o detalhe acesse:
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1/language/pt
>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> As alterações da versão
>>>>> anterior podem ser vistas
>>>>>>>>> > > >> aqui:
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> https://politicas.lacnic.net/politicas/diff2?id=LAC-2020-1&v=4&v2=3&language=PT
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Os comentários e os pontos de vista
>>>>>>>>> aportados pela comunidade
>>>>>>>>> > > >>>> são
>>>>>>>>> > > >>>>>>>>>> vitais para o bom desenvolvimento
> do
>>>>>>>>> processo das propostas
>>>>>>>>> > > >>>>>>>>>> - Você está a favor ou em contra
>>>>>>>>> desta nova versão
>>>>>>>>> > > >>>>>>>>>> da proposta?- Vê alguma desvantagem
>>>>>>>>> nesta nova versão
>>>>>>>>> > > >>>>>>>>>> da proposta?
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> - Que mudanças poderiam ser feitas à
>>>>>>>>> esta nova versão
>>>>>>>>> > > >>>>>>>>>> da proposta para que seja mais eficaz?
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Por mais informações entre em
>>>>>>>>> contato conosco através
>>>>>>>>> > > >>>>>> do e-mail:
>>>>>>>>> > > >>>>>>>>>> info-politicas at lacnic.net.
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Atenciosamente,
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> ______________________________________________________________________________________________________
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Dear LACNIC Policy List subscribers,
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Proposal LAC-2020-1 has been updated
>>>>>>>>> from
>>>>>>> version 3 to version
>>>>>>>>> > > 4
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Title: Add IPv6 operational as a
>>>>>>>>> requirement for IPv4 transfers
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Summary: On 15th February 2017
>>>>>>>>> LACNIC started IPv4 Exhaustion
>>>>>>>>> > > >>>>>>>>>> Phase 3 meaning only new entrants
>>>>>>>>> can receive up to a single
>>>>>>>>> > > >>>>>>>>>> /22 of IPv4 space.
>>>>>>>>> > > >>>>>> Since then the amount of IPv4 Transfers
>>>>>>>>> between organizations has
>>>>>>>>> > > >>>>>> increased reasonably as shown by the
>>>>>>>>> official
>>>>>>> LACNIC reports.
>>>>>>>>> > > >>>>>> With the implementation of LAC-2019-1
>>>>>>>>> and possibility of
>>>>>>>>> > > >>>>>> Inter-RIR transfers these numbers have the
>>>>> potential to grow
>>>>>>>>> > > >>>>>> substantially.
>>>>>>>>> > > >>>>>>>>>> The objective of this proposal is
> to
>>>>>>>>> add as a requirement for
>>>>>>>>> > > >>>>>>>>>> organizations in process of
>>>>>>>>> receiving transferred IPv4 space
>>>>>>>>> > > >>>>>>>>>> under 2.3.2.18 to show they have an
>>>>>>>>> IPv6
>>>>>>>>> > > >>>>>>>>>> allocation/assignment by LACNIC or a
>>>>>>>>> provider and that is
>>>>>>>>> > > >>>>>>>>>> operational on their networks. Such
>>>>>>>>> organization must be able
>>>>>>>>> > > >>>>>>>>>> to prove this IPv6 space is being
> used
>>>>> by
>>>>>>> providing LACNIC
>>>>>>>>> > > >>>>>>>>>> the documented network deployment
>>>>>>>>> details
>>>>>>> to prove IPv6 is
>>>>>>>>> > > >>>>>>>>>> operational in significant parts of
>>>>>>>>> the network.
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> On 28th November 2019 LACNIC Board
>>>>>>>>> issued
>>>>>>> a statement
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> (https://www.lacnic.net/4283/2/lacnic/lacnic-board-calls-on-the-community-to-promote-ipv6-deployment)
>>>>>>>>> > > >>>>>>>>>> reinforcing the issue about IPv4
>>>>>>>>> exhaustion, mentioning IPv4
>>>>>>>>> > > >>>>>>>>>> address space will be exhausted by
>>>>>>>>> mid-2020 and calling the
>>>>>>>>> > > >>>>>>>>>> community to promote IPv6 deployment.
>>>>>>>>> > > >>>>>>>>>> In its statement LACNIC Board
>>>>>>>>> “invite the community to
>>>>>>>>> > > work
>>>>>>>>> > > >>>>>>>>>> on promoting the development of
>>>>>>>>> policies that will accelerate
>>>>>>>>> > > >>>>>>>>>> the effective deployment of IPv6 above
>>>>> other policies that
>>>>>>>>> > > >>>>>>>>>> may be discussed at a later date.”
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> In the case the receiver provides
> a
>>>>>>>>> written statement from
>>>>>>>>> > > >>>>>>>>>> its upstream that IPv6 connectivity is
>>>>> unavailable, the IPv6
>>>>>>>>> > > >>>>>>>>>> requirement may be waived. In the
> case
>>>>> LACNIC is not able to
>>>>>>>>> > > >>>>>>>>>> meet a new entrant request for IPv4
>>>>>>>>> space, or the
>>>>>>>>> > > >>>>>>>>>> organization does not hold any IPv4
>>>>>>>>> space
>>>>>>> the IPv6
>>>>>>>>> > > >>>>>>>>>> requirement may be waived for a
>>>>>>>>> transfer up to a /22.
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> To see the details, please click on:
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1/language/en
>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> The changes from the previous
>>>>>>>>> version can
>>>>>>> be seen here:
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> https://politicas.lacnic.net/politicas/diff2?id=LAC-2020-1&v=4&v2=3&language=EN
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> The community's comments and
>>>>>>>>> opinions are
>>>>>>> essential to the
>>>>>>>>> > > >>>>>>>>>> proper functioning of the policy
>>>>>>>>> development process.
>>>>>>>>> > > >>>>>>>>>> - Do you support this new version
> of
>>>>>>>>> the proposal or are you
>>>>>>>>> > > >>>>>>>>>> against
>>>>>>>>> > > >>>>>> it?
>>>>>>>>> > > >>>>>>>>>> - Do you think this new version of the
>>>>> proposal has any
>>>>>>>>> > > >>>>>>>>>> drawbacks?
>>>>>>>>> > > >>>>>>>>>> - What changes could be made to this
>>>>>>>>> new version of the
>>>>>>>>> > > >>>>>>>>>> proposal to make it more effective?
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> For further information, please contact
>>>>>>>>> > > >>>>>>>>>> info-politicas at lacnic.net
>>>>>>>>> > > >>>>>>>>>> Kind regards,
>>>>>>>>> > > >>>>>>>>>> --
>>>>>>>>> > > >>>>>>>>>> LACNIC - Registro de Direcciones de
>>>>>>>>> Internet para América
>>>>>>>>> > >
>>>>>>>>> > > >>>>>>>>>> Latina y Caribe
>>>>>>>>> > > >>>>>>>>>> Rambla Rep. de México 6125, CP 11400
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Montevideo-Uruguay
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> > > >>>>>>>>>> Teléfono: +598 2604 22 22
>>>>>>>>> > > >>>>>>>>>> www.lacnic.net
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> > > >>>>>>>>>> Politicas mailing list
>>>>>>>>> > > >>>>>>>>>> Politicas at lacnic.net
>>>>>>>>> > > >>>>>>>>>>
>>>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> > > >>>>>>>>> Politicas mailing list
>>>>>>>>> > > >>>>>>>>> Politicas at lacnic.net
>>>>>>>>> > > >>>>>>>>>
>>>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>>>> > > >>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> > > >>>>>>>> Politicas mailing list
>>>>>>>>> > > >>>>>>>> Politicas at lacnic.net
>>>>>>>>> > > >>>>>>>>
>>>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>>>> > > >>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> > > >>>>>>> Politicas mailing list
>>>>>>>>> > > >>>>>>> Politicas at lacnic.net
>>>>>>>>> > > >>>>>>>
>>>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>>>> > > >>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> > > >>>>>> Politicas mailing list
>>>>>>>>> > > >>>>>> Politicas at lacnic.net
>>>>>>>>> > > >>>>>>
>>>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>>>> > > >>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> > > >>>>> Politicas mailing list
>>>>>>>>> > > >>>>> Politicas at lacnic.net
>>>>>>>>> > > >>>>>
>>>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>>>> > > >>>>
>>>>>>>>> > > >>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> > > >>>> Politicas mailing list
>>>>>>>>> > > >>>> Politicas at lacnic.net
>>>>>>>>> > > >>>>
>>>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>>>> > > _______________________________________________
>>>>>>>>> > > Politicas mailing list
>>>>>>>>> > > Politicas at lacnic.net
>>>>>>>>> > > https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>>>> > >
>>>>>>>>> > >
>>>>>>>>> > >
>>>>>>>>> > > **********************************************
>>>>>>>>> > > 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
>>>>>>>>> > _______________________________________________
>>>>>>>>> > Politicas mailing list
>>>>>>>>> > Politicas at lacnic.net
>>>>>>>>> > https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> >
>>>>>>>>> > **********************************************
>>>>>>>>> > 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> **********************************************
>>>>>>>>> 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
>>>>>>>> _______________________________________________
>>>>>>>> Politicas mailing list
>>>>>>>> Politicas at lacnic.net
>>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>>> _______________________________________________
>>>>>>>> Politicas mailing list
>>>>>>>> Politicas at lacnic.net
>>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>> _______________________________________________
>>>>>>> Politicas mailing list
>>>>>>> Politicas at lacnic.net
>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>>> _______________________________________________
>>>>>>> Politicas mailing list
>>>>>>> Politicas at lacnic.net
>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>> _______________________________________________
>>>>>> Politicas mailing list
>>>>>> Politicas at lacnic.net
>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>> _______________________________________________
>>>>> Politicas mailing list
>>>>> Politicas at lacnic.net
>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>> _______________________________________________
>>>> Politicas mailing list
>>>> Politicas at lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
_______________________________________________
Politicas mailing list
Politicas at lacnic.net
https://mail.lacnic.net/mailman/listinfo/politicas
More information about the Politicas
mailing list