[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