[LACNIC/Politicas] Nueva versión de la propuesta LAC-2020-1

ariel sabiguero yawelak asabigue at fing.edu.uy
Tue Apr 13 17:11:49 -03 2021


Quizás no  sea la lista para esta discusión... pero el problema del 
CGNAT y del NAT es la pérdida de conectividad end-to-end.

Pero ya perdimos la conectividad end-to-end cuando todo el correo del 
mundo se mueve entre servidores de gmail y yahoo y la nube nos ha 
"comido". Ese viejo concepto del P2P donde ofrecemos un puerto donde 
atendemos conexiones desde nuestra IP pública se cambió por tener una 
conexión establecida contra "el cloud" y nos notifican o comunican 
cualquier cosa por dentro de la misma...

Pasamos de un mundo "federado" donde corríamos nuestros propios 
servidores de correo y elegíamos nuestro "user agent" a un mundo donde 
descargamos la app del servicio específico que usamos (sea whatsapp, 
telegram o signal). ¿para qué importa que me den la misma IP que a mi 
vecino si no me voy a conectar con él? si el CGNAT logra barajar bien 
los puertos, todo va a funcionar. Audio por TCP, video por TCP, Internet 
por TCP.

Seamos honestos ¿quién no usa webmail? ¿quién no usa web-todo? Internet 
hoy es el puerto 443 de la nube. Preciso ir a la nube para ajustar el 
A/C y para apagar la luz...

saludos


ariel

PS: bueno, tal vez lo dramaticé un poco para hacerlo más divertido!

PS2: PRESAGIO: llegará el IPv6 cuando ya no puedan hacer más plata con 
la NUBEv4, no antes...

El 13/4/21 a las 16:44, Fernando Frediani escribió:
> 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


More information about the Politicas mailing list