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

Fernando Frediani fhfrediani at gmail.com
Wed Apr 14 11:55:09 -03 2021


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


More information about the Politicas mailing list