[LACNIC/Politicas] Dar de baja

Juan Ortega juancoo_130 at live.com
Tue Apr 13 17:13:24 -03 2021



Favor de dar de baja este correo como adjunto a su conversación

De: ariel sabiguero yawelak via Politicas<mailto:politicas at lacnic.net>
Enviado: martes, 13 de abril de 2021 03:12 p. m.
Para: politicas at lacnic.net<mailto:politicas at lacnic.net>
CC: ariel sabiguero yawelak<mailto:asabigue at fing.edu.uy>
Asunto: Re: [LACNIC/Politicas] Nueva versión de la propuesta LAC-2020-1

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

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

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

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

saludos


ariel

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

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

El 13/4/21 a las 16:44, Fernando Frediani escribió:
> Asimismo, IPv6 es el único protocolo capaz de continuar el crecimiento
> ordenado de Internet y reducir y eliminar los problemas y conflictos
> derivados de la escasez de IPv4. A menos que alguien quiera estar en
> desacuerdo y decir que la forma correcta es continuar haciendo CGNAT
> con IPv4.
>
> Fernando
>
> On 13/04/2021 16:40, JORDI PALET MARTINEZ via Politicas wrote:
>> Hola Nico,
>>
>> El ejemplo de BGP, creo que se comprende si se lee esa sección del
>> manual. Tal cual está, puede parecer que hay otros protocolos, etc.
>>
>> El otro no es un ejemplo (lo pusiste tu, yo lo complete) sino una
>> realidad.
>>
>> Respecto del tema del % de tráfico: No se si se trata de revocar o de
>> dejar de hacer descuentos en su contribución a las cuotas de
>> membresía, no he llegado aún a eso.
>>
>> Lo que no es correcto es pensar que, si despliegas IPv6 no vas a
>> poder cumplir con esos tráficos, eso es medible en cualquier
>> despliegue de todos los que hay en el mundo. Si despliegues al 100%
>> de tus residenciales o celulares, si o si tendrás como poco un 75% de
>> tráfico IPv6 respecto del total de tráfico de esos clientes. Insisto,
>> hay que parametrizarlo, porque obviamente no todos los operadores dan
>> servicio mayoritariamente a residenciales, hay casos que solo dan
>> servico a corporativos, etc.
>>
>> Saludos,
>> Jordi
>> @jordipalet
>>
>> El 13/4/21 20:39, "Nicolas Antoniello" <nantoniello at gmail.com>
>> escribió:
>>
>>      Jordi,
>>
>>      No entremos en discusiones que creo que no tienen sentido en
>> este caso.
>>      En primer lugar, se pide BGP para un ASN porque es el único
>> protocolo
>>      que se utiliza para eso y porque además un ASN solo tiene
>> sentido en
>>      BGP, no hay ningún otro protocolo que lo utilice que no sea BGP o
>>      tenga directamente que ver con BGP (antes que me digas que RPKI lo
>>      utiliza por ejemplo).
>>
>>      Lo otro era un ejemplo y no quiero seguir esa línea de debate.
>>
>>      A modo de resumen, no estoy para nada de acuerdo en exigir % de
>>      tráfico de los protocolos como condición de asignación de recursos,
>>      porque técnicamente además no tiene ningún sentido (el operador
>> debe
>>      hacer todo el despliegue y asignar los prefijos según las
>>      recomendaciones... pero hasta allí, no me prece que hacerlo
>>      responsable de que además de cumplir ciertos niveles de tráfico sea
>>      razonable, ni que puedas revocarle recursos porque no llega a
>> ciertos
>>      niveles. O acaso le vas a revocar las asignaciones de IPv6 si
>> desplegó
>>      todo correctamente, asignó a todos sus clientes pero no llega por X
>>      motivo a tener cierto volumen de tráfico... perdona, pero pensé
>> que lo
>>      que se buscaba era promover el despliegue de IPv6.
>>
>>      Abrazo,
>>      Nico
>>
>>
>>      El mar, 13 de abr. de 2021 a la(s) 15:09, JORDI PALET MARTINEZ via
>>      Politicas (politicas at lacnic.net) escribió:
>>      >
>>      > Hola Nico,
>>      >
>>      > No concuerdo contigo y te pongo un par de ejemplos:
>>      >
>>      > 1) Para tener ASN, pedimos que se use BGP, es decir
>> especificamos un protocolo. Ponemos otros requisitos para otras
>> partes del manual.
>>      >
>>      > 2) El ayuntamiento de muchas ciudades, igual que los
>> gobiernos, ya están indicando que tu carro debe contaminar menos de %
>> y una tabla de progresión "negativa" a lo largo de x años o no te
>> permite usarlo. Igualmente, ya están indicando la prohibición del uso
>> de vehículos diésel o gasolina en determinadas ciudades, o zonas de
>> la ciudad, y eso se va extendiendo progresivamente a regiones o
>> países en los próximos años. Hay muchas medidas similares, como son
>> que, si se incrementa la polución en una ciudad y área limítrofe,
>> esos días solo acceden vehículos eléctricos, híbridos o con pila de
>> combustible (hidrógeno), o que los contaminantes no puedan aparcar en
>> las zonas publicas/calles y por tanto solo en parkings de pago, etc.,
>> etc.
>>      >
>>      > Son hechos, no es ficción, igual que he visto en países de LAC
>> otras medidas como "pico y placa" para circulación por días alternos
>> según las placas, etc.
>>      >
>>      > Al final todo se reduce a decidir si consideramos que IPv4 es
>> un protocolo que esta "agotado" o que debe de agotarse en "x" años y
>> como fomentarlo al principio (reducciones de impuestos para vehículos
>> no contaminantes) y como obligarlo para los rezagados (prohibición de
>> circular con esos carros). Y hablamos aquí de protocolo, de una
>> realidad medible y certera, mientras que, si evaluamos el manual de
>> políticas, podríamos ver muchas "subjetividades" que como comunidad
>> hemos decidido.
>>      >
>>      > Si quieres conducir por zonas que no "contaminan a nadie" (y
>> todo es relativo), como montes o desiertos, o donde el impacto es
>> "menor", se te puede dar mas plazo.
>>      >
>>      > Ojo que hay un detalle muy importante, que quizas algunos no
>> aprecian. No obligamos a dejar de usar IPv4 o a no proporcionar
>> servicio con él, sino que cuando despliegas IPv6 a tus clientes, eso
>> "ocurre" de una forma natural, y por eso esos % de tráfico IPv6 se
>> producen sin mayor esfuerzo (una vez hecho el despliegue) y en
>> cambio, tu opex y capex IPv4 se pueden reducir, si lo haces bien
>> (ejemplo IPv6-only + IPv4aaS frente a dual-stack).
>>      >
>>      >
>>      > Saludos,
>>      > Jordi
>>      > @jordipalet
>>      >
>>      >
>>      >
>>      > El 13/4/21 19:50, "Politicas en nombre de Nicolas Antoniello"
>> <politicas-bounces at lacnic.net en nombre de nantoniello at gmail.com>
>> escribió:
>>      >
>>      >     Hola Jordi,
>>      >
>>      >     Tratando únicamente uno de los puntos que mencionaste, una
>> cosa es
>>      >     pedir que las direcciones que el RIR asigna sean
>> utilizadas, esto es,
>>      >     asignadas a clientes. Y otra muy diferente (con la que en
>> principio
>>      >     discrepo completamente) es exigir % de tráfico de un
>> determinado
>>      >     protocolo... hay un millón de razones (técnicas y no
>> técnicas) por las
>>      >     cuales eso es sumamente subjetivo y particular de cada
>> operador y de
>>      >     hecho muchas de esas razones son ajenas al propio operador.
>>      >
>>      >     Es como si el Ayuntamiento en tu ciudad te exigiera que
>> para poder
>>      >     tener un vehículo tienen que utilizarlo al menos 125 veces
>> al mes...
>>      >     no, te piden que tengas todo el regla, pero el % de uso es
>> cosa tuya y
>>      >     solo tuya.
>>      >
>>      >     Saludos,
>>      >     Nico
>>      >
>>      >
>>      >     El mar, 13 de abr. de 2021 a la(s) 14:38, JORDI PALET
>> MARTINEZ via
>>      >     Politicas (politicas at lacnic.net) escribió:
>>      >     >
>>      >     > Respecto de la falta de medidas coercitivas, creo que no
>> es el caso, si existen.
>>      >     >
>>      >     > Una vez que tenemos en marcha cualquier política, hay
>> que intentar que se verifiquen de forma periódica, y eso ya lo
>> tenemos reglamentado con la política que consensuamos no hace tanto:
>>      >     >
>>      >     > 7. REVOCACIÓN Y DEVOLUCIÓN DE RECURSOS
>> (https://www.lacnic.net/550/1/lacnic/)
>>      >     >
>>      >     > Una cosa que podría ayudar, y que considero que no
>> supone mucho trabajo si se hace progresivamente, según la
>> disponibilidad de recursos, ya lo he comentado con el staff, es
>> convertir eso en un "dashboard" para que los que tienen recursos,
>> puedan ver su nivel de cumplimiento de las políticas que se van
>> agregando a ese dashboard, incluso que se les envíen alertas, etc. El
>> esfuerzo adicional es mínimo - una vez que hay un test para una
>> determinada parte del manual, que es automático y repetitivo, solo
>> hay que agregar el "widget" correspondiente en el dashboard. Esta
>> claro que debemos presuponer que todos buscamos el cumplimiento y no
>> la mala fe, así que cualquier ayuda que se proporcione para advertir
>> de posibles incumplimientos, debe ser algo muy positivo, y solo si
>> tras alertas, se mantiene el incumplimiento, entonces el staff debe
>> ser alertado para una verificación manual, etc.
>>      >     >
>>      >     > Esto es en AFRINIC una propuesta de política
>> (https://www.afrinic.net/policy/proposals/2020-gen-001-d1?lang=en-GB#proposal),
>> porque ellos no tienen algo equivalente a nuestra sección 7 del
>> manual, pero aquí creo que no necesitamos una política, porque puede
>> ser algo operacional (convertir en algo gráfico la sección 7, dentro
>> de mylacnic).
>>      >     >
>>      >     > Ahora bien, hay que buscar, en el caso de la propuesta
>> de Fernando, una forma de "medirlo", que sea automatizable.
>>      >     >
>>      >     > Por eso en su momento, quizás fue en la primera versión
>> de esta propuesta, a raíz de un comentario de Nico, propuse que
>> quizás había que medir el grado de adopción por niveles de tráfico:
>>      >     >
>> https://mail.lacnic.net/pipermail/politicas/2020-February/005352.html
>>      >     >
>>      >     > Esto cada vez es mas fácil:
>>      >     >
>>      >     > 1) Porque esas medidas, las tenemos por ASN disponibles
>> de forma pública y neutral (https://stats.labs.apnic.net/ipv6)
>>      >     > 2) Porque sabemos que una red que despliega IPv6, en
>> función de si sus clientes son mayoritariamente residenciales o
>> corporativos, los % de tráfico IPv6 sobre la parte donde ha hecho el
>> despliegue, son conocidos, crecientes y muy simétricos de unas a
>> otras redes.
>>      >     >
>>      >     > Por ejemplo, una red celular alcanza fácilmente el 90%
>> de tráfico IPv6. Obviamente no tenemos que "pedir" que cumpla el 90%,
>> pero y si nos basta con pedir el 30% al cabo de x meses, 60% un año
>> después, etc.
>>      >     >
>>      >     > Igualmente, en una red residencial, sabemos que el
>> tráfico IPv6 pasa a ser como poco el 75%, y fácilmente hasta el 85%,
>> pues pidamos inicialmente el 25%.
>>      >     >
>>      >     > En base a esos parámetros, y teniendo en cuenta que en
>> redes corporativas el tráfico es menor, podemos establecer un baremo
>> y no pedir "todo" inicialmente, si no en pasos progresivos.
>>      >     >
>>      >     > Y eso puede ser monitorizado de forma periódica y
>> automática, sin un "gran" esfuerzo de desarrollo, con un acuerdo con
>> APNIC para que esos datos sean proporcionados (si no lo están ya) con
>> algún mecanismo tipo JSON, etc.
>>      >     >
>>      >     > Parece mas complejo, pero creo que en realidad es
>> *menos* complejo que la forma "documental" en la propuesta actual, y
>> quizas, debe ser otra propuesta, y que aplique a todos los miembros,
>> y que la aplicación de los baremos y plazos, obviamente, dependa de
>> si es para delegaciones iniciales, existentes, o transferencias
>> (donde entraría la propuesta de Fernando). E insisto, la gran ventaja
>> es que esos baremos se pueden 1) monitorizar de forma automatizada y
>> 2) ajustar cada 2-3 años, según avance el despliegue de IPv6.
>>      >     >
>>      >     > Saludos,
>>      >     > Jordi
>>      >     > @jordipalet
>>      >     >
>>      >     >
>>      >     >
>>      >     > El 13/4/21 18:51, "Politicas en nombre de Fernando
>> Frediani" <politicas-bounces at lacnic.net en nombre de
>> fhfrediani at gmail.com> escribió:
>>      >     >
>>      >     >     Hola Oscar. Las transferencias de recursos no
>> registradas son un
>>      >     >     problema permanente y están presentes en *cualquier
>> propuesta*, no solo
>>      >     >     en esta. Existen mecanismos administrativos y
>> legales para mitigar y en
>>      >     >     última instancia sancionar a los malos actores que
>> firmaron un contrato
>>      >     >     de acuerdo con las normas vigentes.
>>      >     >
>>      >     >     La preocupación planteada por algunos acerca de este
>> "pequeño esfuerzo"
>>      >     >     ya ha sido mencionada algunas veces e incluso
>> modificada en el texto de
>>      >     >     la propuesta para dejar aún más claro que no
>> significa simplemente que
>>      >     >     se anuncie IPv6 para DFZ, sino poder demostrar
>> objetivamente bajo
>>      >     >     criterios a ser definidos por el stafff de LACNIC de
>> la misma forma que
>>      >     >     estos criterios ya existen a la hora de justificar
>> el uso en una nueva
>>      >     >     cesión o transferencia de IPv4. Además, en la
>> versión 4 de
>>      >     >     esta
>>      >     >     propuesta, se hizo aún más claro, sin entrar en
>> detalles técnicos y
>>      >     >     operativos, lo que significa el término "partes
>> significativas de la
>>      >     >
>>      >     >     red" para que no haya dudas sobre los intentos de
>> inventar esta
>>      >     >     percepción de que IPv6 solo está operativo para
>> pasar por la
>>      >     >     transferencia. En muchos casos, el esfuerzo que
>> tendrán que hacer para
>>      >     >     intentar hacer esto puede invertirse en una
>> implementación de IPv6 real.
>>      >     >     No tengo muchas dudas de que todas estas
>> preocupaciones son una pequeña
>>      >     >     parte de los casos, y cuando lo estén, estarán muy
>> bien justificadas si
>>      >     >     tienen que cumplir con este requisito.
>>      >     >
>>      >     >     La falta de "reglas coercitivas" como se cita en mi
>> opinión hace aún más
>>      >     >     daño al sistema de control de recursos de numeración
>> que tener algunas
>>      >     >     reglas que puede considerarse coercitivo. El
>> "refuerzo positivo" y la
>>      >     >     esperanza de buena voluntad no han funcionado bien
>> hasta ahora.
>>      >     >     Continuar haciéndolo de la misma manera solo traerá
>> los mismos resultados.
>>      >     >     Vea que esta propuesta no tiene nada que ver con la
>> coacción, no
>>      >     >     obligará automáticamente a colocar a quienes no
>> tienen IPv6. Solo
>>      >     >     aquellos que están creando una pérdida para otros
>> que tienen un
>>      >     >     objetivo
>>      >     >     y una contraparte razonablemente fácil de lograr.
>>      >     >
>>      >     >     Saludos e gracias por su aporte.
>>      >     >     Fernando
>>      >     >
>>      >     >     On 13/04/2021 13:24, Oscar A. Robles-Garay wrote:
>>      >     >     >
>>      >     >     > Gracias por el seguimiento Fernando.
>>      >     >     >
>>      >     >     > Como en toda política, debemos ser concientes no
>> solo de las
>>      >     >     > consecuencias deseadas (Happy Path), sino tambén
>> de las consecuencias
>>      >     >     > inesperadas. No estamos intentando resolver una
>> ecuación matemática,
>>      >     >     > sino que estamos intentando regular conductas de
>> actores privados que
>>      >     >     > toman decisiones en función de sus necesidades de
>> negocio.
>>      >     >     >
>>      >     >     > Por lo anterior, de aceptarse esta propuesta,
>> debemos asumir que los
>>      >     >     > operadores encontrarán "otras vías" para atender
>> sus necesidades si
>>      >     >     > los mecanismos actuales no les ayudan a resolverlas:
>>      >     >     >
>>      >     >     >   * Transferencias de recursos no registradas
>>      >     >     >   * Renta/alquiler de recursos
>>      >     >     >   * En el mejor de los casos, realizarán un
>> pequeño esfuerzo para
>>      >     >     >     cumplir el requisito de "despliegue de IPv6",
>> mismo que apagarán
>>      >     >     >     en cuanto pasen la prueba y encenderán una vez
>> que haga real
>>      >     >     >     sentido de negocio (business case).
>>      >     >     >
>>      >     >     > Si logramos que estas consecuencias inesperadas
>> sean la minoría de
>>      >     >
>>      >     >     > casos, entonces tu propuesta habrá sido un éxito
>> (pues la mayoría
>>      >     >     > siguió el happy path).
>>      >     >     >
>>      >     >     > Sin embargo, debido a las dificultades para
>> determinar con certeza el
>>      >     >     > nivel de transferencias fuera del sistema (a menos
>> que seas un broker)
>>      >     >     > nos quedaremos con la incertidumbre y habremos
>> abonado al
>>      >     >     > establecimmiento de reglas coercitivas que no
>> sabemos si están
>>      >     >     > ayudando al desarrollo de Internet, pero sí lo
>> estan haciendo más
>>      >     >     > complejo y contrario al espíritu de adopción
>> voluntaria de sus protocolos.
>>      >     >     >
>>      >     >     > Saludos,
>>      >     >     >
>>      >     >     > Oscar
>>      >     >     >
>>      >     >     > On 13/4/21 13:05, Fernando Frediani wrote:
>>      >     >     >> Hola
>>      >     >     >>
>>      >     >     >> Jorge - No hay problema en agregar este requisito
>> para que sea
>>      >     >     >> posible permitir la transferencia dadas las
>> justificaciones que ya se
>>      >     >     >> han presentado en varios mensajes anteriores.
>>      >     >     >> En cuanto al argumento de que las transferencias
>> se realizan "fuera
>>      >     >     >> del registro", ya se ha explicado muchas veces en
>> los mensajes
>>      >     >     >> anteriores cómo esta no puede considerarse una
>> objeción válida ya que
>>      >     >     >> existen suficientes garantías para mitigar este
>> temor que está
>>      >     >
>>      >     >     >> presente en cualquier otra propuesta.
>>      >     >     >>
>>      >     >     >> Hernán - No sé qué datos está buscando, pero ya se
>>      >     >     han presentado
>>      >     >     >> varios escenarios de la vida real y ejemplos
>> prácticos técnicos y
>>      >     >     >> económicos, comenzando con aumentos
>> significativos en el costo de
>>      >     >
>>      >     >     >> aumentar las operaciones con CGNAT y la creciente
>> necesidad de
>>      >     >     >> utilizar el mercado de transferencia. Cualquiera
>> que gestione un
>>      >     >     >> negocio en Internet o una gestión técnica es
>> consciente de todos los
>>      >     >     >> problemas y costes que conllevan estos problemas.
>>      >     >     >> Con respecto al posible loop, es posible que no
>> hayas podido leer la
>>      >     >     >> propuesta en su totalidad, pero predice que las
>> nuevas organizaciones
>>      >     >     >> que no tengan ningún bloque de IPv4 podrán
>> realizar una transferencia
>>      >     >     >> inicial hasta el límite de un /22 sin la
>> necesidad para demostrar
>>      >     >
>>      >     >     >> IPv6 operativo.
>>      >     >     >> No entiendo por qué se considera extraño que esta
>> política
>>      >     >     >> "obstaculice" si logra realizar una transferencia
>> IPv4 sin la
>>      >     >     >> contraparte de IPv6. Desde mi punto de vista es
>> normal que alguien
>>      >     >     >> que a mediados de 2021 no tenga IPv6 operativo
>> tenga otros problemas
>>      >     >     >> que están afectando a todos los demás a resolver
>> antes de seguir
>>      >     >     >> transfiriendo más IPv4.
>>      >     >     >>
>>      >     >     >> Oscar - hablando simplemente sí. Una empresa que
>> se enfrenta a la
>>      >     >
>>      >     >     >> necesidad de transferir más IPv4 para incrementar
>> su operación (y en
>>      >     >     >> consecuencia su tráfico) y sin embargo, hasta
>> ahora no ha hecho
>>      >     >     >> ningún despliegue de IPv6 está causando daño a
>> todos los demás,
>>      >     >     >> incluidos los que hicieron sus obligaciones, por
>> eso ya no se debería
>>      >     >     >> permitir que se realicen transferencias IPv4 sin
>> la consideración
>>      >     >     de
>>      >     >     >> demostrar IPv6 y reducir la tasa de crecimiento
>> de un problema mucho
>>      >     >     >> más serio de lo que les ha parecido a algunas
>> personas que desean
>>      >     >     que
>>      >     >     >> estos actores se sientan muy cómodos para
>> continuar causando estos
>>      >     >     >> problemas en ecosistema Internet. A menudo he
>> dicho que este
>>      >     >     >> requisito no es tan grande ni tan difícil de
>> lograr. Quizás algunos
>>      >     >     >> estén sobrestimando este requisito como algo que
>> hará que las
>>      >     >     >> transferencias IPv4 sean totalmente inviables y
>> este no es ni nunca
>>      >     >     >> fue el propósito de esta propuesta.
>>      >     >     >>
>>      >     >     >> Saludos
>>      >     >     >> Fernando
>>      >     >     >>
>>      >     >     >> On 13/04/2021 10:28, Oscar A. Robles-Garay wrote:
>>      >     >     >>> Fernando,
>>      >     >     >>>
>>      >     >     >>> Si estoy entendiendo bien, con tu propuesta
>> esperas que tenga como
>>      >     >     >>> consecuencia "deseable" que aquellos ISP's que
>> necesitan IPv4 y
>>      >     >     >>> hayan decidido ir al mercado de IPs por
>> transferencias, se tomen un
>>      >     >     >>> tiempo para desplegar "algo" de IPv6, es así?
>>      >     >     >>>
>>      >     >     >>> Saludos,
>>      >     >     >>>
>>      >     >     >>> Oscar
>>      >     >     >>>
>>      >     >     >>>
>>      >     >     >>> On 12/4/21 15:23, Fernando Frediani wrote:
>>      >     >     >>>> Hola Raul
>>      >     >     >>>> Gracias por tu contribución.
>>      >     >     >>>>
>>      >     >     >>>> No podemos confundir IPv4 y IPv6, que son
>> recursos de numeración,
>>      >     >     >> el
>>      >     >     >>>> tema principal de nuestra discusión, con MANRS
>> y participación en
>>      >     >     >>>> IXPs. Si bien MANRS es una buena práctica y la
>> participación
>>      >     >     >> en IXP
>>      >     >     >>>> es positiva, el uso de *recursos de numeración*
>> y el impacto de
>>      >     >
>>      >     >     >>>> cómo el mal uso (o no uso) puede poner en duda
>> la continuidad de la
>>      >     >     >>>> evolución de un sistema que depende de
>> diferentes actores.
>>      >     >     >>>>
>>      >     >     >>>> Sí, estas restricciones ciertamente están
>> relacionadas con
>>      >     >     el uso
>>      >     >     >>>> óptimo de los recursos. Si una organización
>> necesita recursos para
>>      >     >     >>>> seguir desarrollando y conectando a más
>> personas y ya no puede
>>      >     >     >>>> acceder a estos recursos y existe una solución
>> (IPv6) que, de ser
>>      >     >     >>
>>      >     >     >>>> operativa, elimina
>>      >     >     >>>> estas restricciones, es necesario que esta sea
>> la solución y que sea
>>      >     >     >>>> estimulado.
>>      >     >     >>>> Es importante tener en cuenta que *IPv6 es el
>> protocolo de Internet
>>      >     >     >>>> estándar* desde 2017, no solo una buena
>> práctica. No soy yo quien
>>      >     >     >>>> lo dice, sino el IETF.
>>      >     >     >>>>
>>      >     >     >>>> Con respecto a lo trade-off es lo que he estado
>> tratando de decir
>>      >     >     >>>> que es muy, muy aceptable. No existe nada
>> difícil, complejo o
>>      >     >     >>>> imposible de tener, al contrario, es algo
>> bastante obvio para
>>      >     >     >>>> cualquier poseedor de recursos de numeración.
>> Los efectos de no
>>      >     >
>>      >     >     >>>> hacer nada son mucho peores que hacer en este
>> ejemplo.
>>      >     >     >>>>
>>      >     >     >>>> Saludos
>>      >     >     >>>> Fernando Frediani
>>      >     >     >>>>
>>      >     >     >>>> On 12/04/2021 13:28, Raúl Echeberría wrote:
>>      >     >     >>>>> Fernando,
>>      >     >     >>>>>
>>      >     >     >>>>> Por supuesto leí la propuesta completa y los
>> cambios de la última
>>      >     >     >>>>> versión. No leí el título solamente. En ese
>> caso no me
>>      >     >     >> hubiera
>>      >     >     >>>>> atrevido a hacer comentarios.
>>      >     >     >>>>>
>>      >     >     >>>>> Es cierto que todas las políticas de alguna
>> forma fuerzan el
>>      >     >     >>>>> cumplimiento de ciertos requisitos y afectan
>> de forma más o menos
>>      >     >     >>>>> artificial el mercado. El punto es donde está
>> el “trade off”.
>>      >     >     >>>>>
>>      >     >     >>>>> Se supone que esas restricciones tienen que
>> estar vinculadas al
>>      >     >     >>>>> uso óptimo de los recursos de numeración, no
>> de Internet en si misma.
>>      >     >     >>>>>
>>      >     >     >>>>> Esta propuesta, si bien muy bien intencionada,
>> está desde mi punto
>>      >     >     >>>> de vista, más allá del "trade off" aceptable.
>>      >     >     >>>>>
>>      >     >     >>>>>
>>      >     >     >>>>> Internet es una construcción colaborativa
>> donde la base de la
>>      >     >     >>>>> colaboración y la coordinación es voluntaria.
>> Hacerlo diferente
>>      >     >     >>>>> cambia la naturaleza de Internet y por lo
>> menos a mi con todo
>>      >     >     >>>>> respeto, no me
>>      >     >     >>>> parece lo correcto. Por supuesto es muy
>> respetable que tengas una
>>      >     >     >>>> opinión diferente.
>>      >     >     >>>>>
>>      >     >     >>>>> Si hoy aprobamos esta política, mañana la
>> propuesta será
>>      >     >     >>
>>      >     >     >>>> hacer que la adopción de MANRS sea obligatoria
>> y luego será
>>      >     >     la
>>      >     >     >>>> conexión a un IXP y luego  otra cosa. Siempre
>> hay prácticas que nos
>>      >     >     >>>> parecen buenas y que quisiéramos que sean
>> adoptadas masivamente,
>>      >     >     >>>> pero pare eso está el trabajo colaborativo que,
>> entre otros, hacen los
>>      >     >     >>
>>      >     >     >>>> NOGs y los trabajos de extensión y difusión de
>> organizaciones como
>>      >     >     >>>> ISOC o los RIRs.
>>      >     >     >>>>>
>>      >     >     >>>>> No querramos forzar la implementación de
>> buenas prácticas
>>      >     >
>>      >     >     >>>>> operativas a través de las políticas.
>>      >     >     >>>>>
>>      >     >     >>>>>
>>      >     >     >>>>>
>>      >     >     >>>>> Saludos,
>>      >     >     >>>>>
>>      >     >     >>>>> Raúl
>>      >     >     >>>>>
>>      >     >     >>>>>
>>      >     >     >>>>>
>>      >     >     >>>>>
>>      >     >     >>>>>> El 12 abr. 2021, a las 11:57, Fernando Frediani
>>      >     >     >>>>>> <fhfrediani at gmail.com>
>>      >     >     >>>> escribió:
>>      >     >     >>>>>>
>>      >     >     >>>>>> Hola de nuevo Raul
>>      >     >     >>>>>>
>>      >     >     >>>>>> Mira, cambiar las políticas como propone esta
>> propuesta no está
>>      >     >     >>>>>> obligando a nadie a poner IPv6 o a convertir
>> a LACNIC en una
>>      >     >     >>>>>> "policía IPv6". Solo afecta a quienes desean
>> transferir IPv4 y en
>>      >     >     >>>>>> este caso no hay nada de malo. Y la empresa
>> que quiere actualizar
>>      >     >     >>>>>> la base de datos whois que funciona bajo
>> reglas que se actualizan
>>      >     >     >>>>>> según el tiempo y según la necesidad de cada
>> momento. Lo
>>      >     >     que se
>>      >     >     >>>>>> está considerando como contraparte no es nada
>> que imposibilite el
>>      >     >     >>>>>> traspaso si la empresa tiene *un compromiso
>> mínimo* con todos
>>      >     >     los
>>      >     >     >>>>>> demás, dado el momento que estamos atravesando.
>>      >     >     >>>>>>
>>      >     >     >>>>>> Otro punto que quiero destacar mucho es que
>> parece que esta
>>      >     >     >>>>>> propuesta tiene como objetivo solucionar
>> todos los problemas del
>>      >     >     >>>>>> despliegue de IPv6
>>      >     >     >>>> y no es nada de eso. Es solo una iniciativa
>> más, pequeña por
>>      >     >     >> cierto,
>>      >     >     >>>> para incentivar el despliegue de IPv6 y sobre
>> todo para evitar que
>>      >     >     >>>> quienes necesitan seguir transfiriendo IPv4
>> sigan causando más
>>      >     >     >>>> problemas a todos los que están cumpliendo con
>> sus obligaciones.
>>      >     >     >>>>>> Dado el contexto actual, ya no tiene sentido
>> cerrar los ojos y
>>      >     >     >>>>>> permitirse seguir registrando transferencias
>> IPv4 sin tener en
>>      >     >     >>>>>> cuenta el desarrollo continuo y saludable del
>> ecosistema del que
>>      >     >     >>>>>> todos dependemos a diario.
>>      >     >     >>>>>>
>>      >     >     >>>>>> El tema de las políticas que obligan al
>> mercado es un tema
>>      >     >     >>>>>> complejo de discutir, pero para decirlo en
>> pocas palabras si
>>      >     >     >>>>>> fuera tan indiferente, ni siquiera sería
>> necesario justificar
>>      >     >     la
>>      >     >     >>>>>> necesidad de IPv4 en el momento de una
>> asignación inicial o una
>>      >     >     >>>>>> transferencia. . Hay otros RIR que son mucho
>> más permisivos que
>>      >     >     >>>>>> LACNIC, pero aquí felizmente tomamos la
>> decisión correcta en este
>>      >     >     >>>>>> contexto.
>>      >     >     >>>>>>
>>      >     >     >>>>>> Fernando
>>      >     >     >>>>>>
>>      >     >     >>>>>> On 12/04/2021 11:11, Raúl Echeberría wrote:
>>      >     >     >>>>>>> Olá Gondim
>>      >     >     >>>>>>>
>>      >     >     >>>>>>> Concordamos em tudo, exceto em um elemento
>> importante.
>>      >     >     >>>>>>> Compartilho sua preocupação e acho que algo
>> precisa ser
>>      >     >     feito.
>>      >     >     >>>>>>> Onde discordamos
>>      >     >     >>>>>> é que Eu não acredito que forçar o
>> comportamento do
>>      >     >     mercado de
>>      >     >     >>>>>> esse jeito, seja o papel das políticas, .
>>      >     >     >>>>>>> É necessário redobrar os esforços na
>> promoção do IPv6 fornecendo
>>      >     >     >>>>>>> evidências que mostram os danos que você
>> mencionou. É
>>      >     >     >> preciso ter
>>      >     >     >>>>>>> bons estudos, boas métricas e trabalhar
>>      >     >     >>>> para disseminá-los, capacitar, gerar
>> capacidades técnicas,
>>      >     >     contatar
>>      >     >     >>>> os operadores e trabalhar com eles.
>>      >     >     >>>>>>>
>>      >     >     >>>>>>> Mas acredito que não é papel da política forçar
>>      >     >     >> o
>>      >     >     >>>> mercado, nem acredito que essa política será
>> eficiente para atingir
>>      >     >     >>>> o objetivo que se propõe.
>>      >     >     >>>>>>>
>>      >     >     >>>>>>> É por isso Gondim, que embora concorde com
>> você no seu
>>      >     >     >>>>>>> raciocínio e nas suas preocupações, NÃO apoio
>>      >     >     esta proposta.
>>      >     >     >>>>>>>
>>      >     >     >>>>>>>
>>      >     >     >>>>>>> Saudações
>>      >     >     >>>>>>>
>>      >     >     >>>>>>> Raúl
>>      >     >     >>>>>>>
>>      >     >     >>>>>>>
>>      >     >     >>>>>>>
>>      >     >     >>>>>>>> El 12 abr. 2021, a las 10:46, Gondim
>> <gondim at gmail.com> escribió:
>>      >     >     >>>>>>>>
>>      >     >     >>>>>>>> Bom dia Raúl,
>>      >     >     >>>>>>>>
>>      >     >     >>>>>>>> O problema é que enquanto não tivermos uma
>> política
>>      >     >     >> que
>>      >     >     >>>>>> alavanque o IPv6, está não irá crescer como
>> deveria. É a famosa
>>      >     >     >>>>>> questão do: "Cão correndo atrás do rabo".
>>      >     >     >>>>>>>> As empresas não querem modificar seus
>> sistemas para terem suporte
>>      >     >     >>>>>> à IPv6 porque as Operadoras que lhes fornecem
>> Internet, e aos
>>      >     >
>>      >     >     >>>>>> seus clientes, não possuem IPv6 implementado.
>> Em contra partida;
>>      >     >     >>>>>> as Operadoras não implementam IPv6, porque
>> não veem conteúdo e
>>      >     >     >>>>>> nem a necessidade de IPv6, enquanto tiverem
>> IPv4. Se ninguém sair
>>      >     >     >>>>>> da inércia vamos continuar a passos de caroça
>> na implementação de
>>      >     >     >>>>>> IPv6.
>>      >     >     >>>>>>>> Diariamente, aqui na minha operação, eu
>> vejo assinantes meus
>>      >     >     >>>>>> com problemas para acessarem sistemas
>> externos e o mesmo ocorre
>>      >     >     >>>>>> em sentido contrário, de acessos externos aos
>> nossos assinantes.
>>      >     >     >>>>>> Quando tento explicar, ao meu assinante,
>> sobre a necessidade do
>>      >     >     >>>>>> uso do IPv6, este me diz que sua equipe de TI
>> afirma não existir
>>      >     >     >>>>>> esse problema de falta de IPv4 e que é
>> obrigação do
>>      >     >     Provedor dar
>>      >     >     >>>>>> IPv4 público para ele. Porque este é
>> "universal". O que vejo é
>>      >     >     >>>>>> uma total
>>      >     >     >>>> desinformação do meu cliente mas também um
>> reflexo de
>>      >     >     como o
>>      >     >     >>>> mercado está vendo esse problema.
>>      >     >     >>>>>>>> Conteúdos informativos e sociais já existem
>> em IPv6 e isso
>>      >     >     >>>> é bom. Ter Google, Facebook, Netflix,
>> Instagram, Linkedin, Youtube
>>      >     >     >>>> e outros de conteúdo, ajudam em muito nossa
>> causa mas estamos
>>      >     >     >>>> esquecendo
>>      >     >     >>>>>> de outros sistemas que usamos no dia a dia.
>> Sistemas
>>      >     >     >>>>>> empresariais, ERPs, empresas que desenvolvem
>> software básico para
>>      >     >     >>>>>> diversas áreas
>>      >     >     >>>> e que não sentem a menor vontade de suportar
>> IPv6. Porque muitas
>>      >     >     >>>> das vezes não conseguem acesso em IPv6 de seus
>> provedores de
>>      >     >     >>>> Internet. Acredito que isso desmotive
>> tecnicamente o esforço deles.
>>      >     >     >>>>>>>> Cada vez mais estamos investindo em CGNAT.
>> Comprando
>>      >     >     >>>>>>>> equipamentos caríssimos para continuar
>> usando uma rede
>>      >     >     >>>>>>>> remendada, debilitada. Porque o conteúdo em
>> IPv4 continua
>>      >     >     >>>>>>>> crescendo e outros Sistemas Autônomos
>>      >     >     >>>>>> não querem implementar IPv6.
>>      >     >     >>>>>>>> Nós tivemos a época do esclarecimento sobre
>> o IPv6, do
>>      >     >
>>      >     >     >>>>>>>> incentivo, diversas organizações
>> ministraram gratuitamente
>>      >     >     >>>>>>>> cursos de
>>      >     >     >>>>>> IPv6, palestras, fóruns especializados com
>> materiais técnicos
>>      >     >     >>>>>> riquíssimos. Conteúdo informativo e
>> educacional foram produzidos
>>      >     >     >>>>>> e experiências foram compartilhadas com
>> todos, durante anos.
>>      >     >     >>>>>> Nesse momento; uma política permissiva só vai
>> agravar mais a
>>      >     >     >>>>>> situação e que sabemos que futuramente será
>> mais difícil resolver
>>      >     >     >>>>>> os problemas que aparecerão diante de nós.
>>      >     >     >>>>>>>> Estamos falando aqui da sobrevivência da
>> Internet como um eco
>>      >     >     >>
>>      >     >     >>>>>>>> sistema que conhecemos. Se não for do RIR
>> essa incumbência,
>>      >     >     >>>>>>>> então que seja de outro mas tenho convicção
>> que sem isso, não
>>      >     >     >>>>>>>> iremos muito longe.
>>      >     >     >>>>>>>>
>>      >     >     >>>>>>>> O que me parece é que a ideia colocada
>> nessa proposta é
>>      >     >     boa mas
>>      >     >     >>>>>>>> ninguém quer assumir o papel de "carrasco"
>> e fazer valer algo
>>      >     >     >> que
>>      >     >     >>>>>>>> só vai beneficiar a todos e a Internet.
>> Quantos anos mais serão
>>      >     >     >>>>>>>> necessários para percebermos isso?
>>      >     >     >>>>>>>>
>>      >     >     >>>>>>>> Saudações,
>>      >     >     >>>>>>>>
>>      >     >     >>>>>>>> Gondim
>>      >     >     >>>>>>>>
>>      >     >     >>>>>>>> Em 11/04/2021 19:00, Raúl Echeberría escreveu:
>>      >     >     >>>>>>>>> Estimados colegas.
>>      >     >     >>>>>>>>>
>>      >     >     >>>>>>>>> He seguido con atención la discusión sobre
>> esta propuesta
>>      >     >     >>>> que me parece muy interesante.
>>      >     >     >>>>>>>>>
>>      >     >     >>>>>>>>> Debo decir que comparto el espíritu que
>> fundamenta la
>>      >     >     >>>>>>>>> propuesta pero NO la apoyo porque creo que
>> excede el rol que
>>      >     >     >>>>>>>>> debe tener LACNIC y las políticas de
>> manejo de recursos de
>>      >     >
>>      >     >     >>>>>>>>> numeración.
>>      >     >     >>>>>>>>>
>>      >     >     >>>>>>>>> Si bien soy totalmente empático con la
>> idea de que los
>>      >     >     >>>>>>>>> operadores deberían contribuir activametne
>> con el despliegue
>>      >     >     >> de
>>      >     >     >>>>>>>>> IPv6 creo que
>>      >     >     >>>>>> es algo que hay que trabajarlo a través de la
>> promoción de
>>      >     >     >> IPv6 y
>>      >     >     >>>>>> no haciéndolo mandatorio en la política de
>> transferencia.
>>      >     >     >>>>>>>>> Además de pensar, como decía, que esta
>> propuesta excede
>>      >     >     >> lo que
>>      >     >     >>>>>>>>> desde mi punto de vista, deben ser las
>> políticas de los RIRs,
>>      >     >     >>>>>>>>> tampoco creo que sea eficiente en lograr
>> el objetivo que se
>>      >     >     >>>>>>>>> propone.
>>      >     >     >>>>>>>>>
>>      >     >     >>>>>>>>> No es claro que es que “IPv6 está
>> operativo en partes
>>      >     >     >>>>>>>>> SIGNIFICATIVAS de la red” y tampoco está
>> claro que
>>      >     >     sucede si,
>>      >     >     >>>>>>>>> una vez definido este criterio, la
>> situación cambia luego de
>>      >     >     >> ser
>>      >     >     >>>>>>>>> aprobada la transferencia.
>>      >     >     >>>>>>>>>
>>      >     >     >>>>>>>>> Muchos operadores tienen IPv6 operativo en
>> el core de la red
>>      >     >     >>>>>>>>> sin dar servicios a usuarios finales, y no
>> hay dudas que el
>>      >     >     >>>>>>>>> core es una parte más que significativa de
>> la red.
>>      >     >     >>>>>>>>>
>>      >     >     >>>>>>>>> Creo por supuesto que es y seguirá siendo
>> un tema fundamental
>>      >     >     >>>>>>>>> seguir trabajando por el incremento del
>> despliegue de IPv6 de
>>      >     >     >>>>>>>>> forma integral en Internet y eso es lo que
>> ya hacen los RIRs y
>>      >     >     >>>>>>>>> muchas otras organizaciones. Me parece que
>> hay que continuar
>>      >     >     >>>>>>>>> trabajando estos temas también
>>      >     >     >>>>>> en los grupos de operadores pero no apoyo que
>> este requerimiento
>>      >     >     >>>>>> se incluya en la política de transferencia
>> tal como se propone.
>>      >     >     >>>>>>>>> Saludos al autor de la propuesta por traer
>> a discusión un tema
>>      >     >     >>>> super relevante. La discusión en si misma
>> contribuye a la
>>      >     >     >>>> concientización sobre la necesidad de la
>> aceleración del despliegue
>>      >     >     >>>> de IPv6.
>>      >     >     >>>>>>>>>
>>      >     >     >>>>>>>>>
>>      >     >     >>>>>>>>> Saludos,
>>      >     >     >>>>>>>>>
>>      >     >     >>>>>>>>>
>>      >     >     >>>>>>>>> Raúl
>>      >     >     >>>>>>>>>
>>      >     >     >>>>>>>>>
>>      >     >     >>>>>>>>> 2.3.2.18.3 Los destinatarios en la región
>> de LACNIC deberán
>>      >     >     >>>>>> tener espacio IPv6 distribuido/asignado por
>> LACNIC o por un
>>      >     >     >>>>>> proveedor y deberán poder probar que este
>> espacio está en uso,
>>      >     >     >>>>>> para lo cual deberán proporcionarle a LACNIC
>> los detalles
>>      >     >     >>>>>> documentados del despliegue de la red para
>> demostrar que IPv6
>>      >     >     >>>>>> está operativo
>>      >     >     >> en
>>      >     >     >>>>>> partes significativas de la red.
>>      >     >     >>>>>>>>> El personal de LACNIC definirá un criterio
>> mínimo para
>>      >     >     >>>>>>>>> garantizar que la información
>> proporcionada demuestre que IPv6
>>      >     >     >>>>>>>>> está
>>      >     >     >>>>>> operativo. De ser necesario, el personal
>> puede requerir más
>>      >     >     >>>>>> información para validar este requisito.
>>      >     >     >>>>>>>>>
>>      >     >     >>>>>>>>>
>>      >     >     >>>>>>>>>
>>      >     >     >>>>>>>>>
>>      >     >     >>>>>>>>>> El 31 mar. 2021, a las 11:37,
>> info-politicas at lacnic.net
>>      >     >     >>>>>>>>>> escribió:
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> [Português abaixo]
>>      >     >     >>>>>>>>>> [English below]
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Estimados suscriptores de la lista de
>> políticas de LACNIC,
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> La propuesta LAC-2020-1 ha pasado de la
>> versión 3 a la versión 4
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Título: Agregar IPv6 operativo como
>> requisito para las
>>      >     >     >>>>>>>>>> transferencias de IPv4
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Resumen: On 15th February 2017 LACNIC
>> started IPv4 Exhaustion
>>      >     >     >>>>>>>>>> Phase 3 meaning only new entrants can
>> receive up to a single
>>      >     >     >>>>>>>>>> /22 of IPv4 space.
>>      >     >     >>>>>> Since then the amount of IPv4 Transfers
>> between organizations has
>>      >     >     >>>>>> increased reasonably as shown by the official
>> LACNIC reports.
>>      >     >     >>>>>> With the implementation of LAC-2019-1 and
>> possibility of
>>      >     >     >>>>>> Inter-RIR transfers these numbers have the
>> potential to grow
>>      >     >     >>>>>> substantially.
>>      >     >     >>>>>>>>>> The objective of this proposal is to add
>> as a requirement for
>>      >     >     >>>>>>>>>> organizations in process of receiving
>> transferred IPv4 space
>>      >     >     >>>>>>>>>> under 2.3.2.18 to show they have an IPv6
>>      >     >     >>>>>>>>>> allocation/assignment by LACNIC or a
>> provider and that is
>>      >     >     >>>>>>>>>> operational on their networks. Such
>> organization must be able
>>      >     >     >>>>>>>>>> to prove this IPv6 space is being used by
>> providing LACNIC
>>      >     >     >>>>>>>>>> the documented network deployment details
>> to prove IPv6 is
>>      >     >     >>>>>>>>>> operational in significant parts of the
>> network.
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> On 28th November 2019 LACNIC Board issued
>> a statement
>>      >     >     >>>>>>>>>>
>> (https://www.lacnic.net/4283/2/lacnic/lacnic-board-calls-on-the-community-to-promote-ipv6-deployment)
>>
>>      >     >     >>>>>>>>>> reinforcing the issue about IPv4
>> exhaustion, mentioning IPv4
>>      >     >     >>>>>>>>>> address space will be exhausted by
>> mid-2020 and calling the
>>      >     >     >>>>>>>>>> community to promote IPv6 deployment.
>>      >     >     >>>>>>>>>> In its statement LACNIC Board “invite the
>> community to
>>      >     >     work
>>      >     >     >>>>>>>>>> on promoting the development of policies
>> that will accelerate
>>      >     >     >>>>>>>>>> the effective deployment of IPv6 above
>> other policies that
>>      >     >     >>>>>>>>>> may be discussed at a later date.”
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> In the case the receiver provides a
>> written statement from
>>      >     >     >>>>>>>>>> its upstream that IPv6 connectivity is
>> unavailable, the IPv6
>>      >     >     >>>>>>>>>> requirement may be waived. In the case
>> LACNIC is not able to
>>      >     >     >>>>>>>>>> meet a new entrant request for IPv4
>> space, or the
>>      >     >     >>>>>>>>>> organization does not hold any IPv4 space
>> the IPv6
>>      >     >     >>>>>>>>>> requirement may be waived for a transfer
>> up to a /22.
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Para ver el detalle ingrese en:
>>      >     >     >>>>>>>>>>
>> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1/language/sp
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Los cambios respecto a la versión
>> anterior se pueden visualizar
>>      >     >     >>>>>> aquí:
>>      >     >     >>>>>>>>>>
>> https://politicas.lacnic.net/politicas/diff2?id=LAC-2020-1&v=4&v2=3&language=SP
>>
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Los comentarios y los puntos de vista
>> aportados por la
>>      >     >     >>>>>>>>>> comunidad son
>>      >     >     >>>>>> vitales para el correcto desarrollo del
>> proceso de la propuestas
>>      >     >     >>>>>>>>>> - ¿Apoya usted o se opone a esta nueva
>> versión de la
>>      >     >     propuesta?
>>      >     >     >>>>>>>>>> - ¿Ve alguna desventaja en esta nueva
>> versión de la propuesta?
>>      >     >     >>>>>>>>>> - ¿Qué cambios podrían hacerse a esta
>> nueva versión de la
>>      >     >     >>>>>>>>>> propuesta para que sea más eficaz?
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Por más información contacte a
>> info-politicas at lacnic.net
>>      >     >     >>>>>>>>>> Saludos cordiales,
>>      >     >     >>>>>>>>>>
>> ______________________________________________________________________________________________________
>>
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Prezados assinantes da lista de
>> políticas de LACNIC,
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> A proposta LAC-2020-1 tem passado da
>> versão 3 para a versão 4
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Título: Adicionar IPv6 operacional como
>> requisito para as
>>      >     >
>>      >     >     >>>>>>>>>> transferências do IPv4
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Resumo: On 15th February 2017 LACNIC
>> started IPv4 Exhaustion
>>      >     >     >>>>>>>>>> Phase
>>      >     >     >>>> 3
>>      >     >     >>>>>> meaning only new entrants can receive up to a
>> single /22 of IPv4
>>      >     >     >>>>>> space. Since then the amount of IPv4
>> Transfers between
>>      >     >     >>>>>> organizations has increased reasonably as
>> shown by the official
>>      >     >     >>>>>> LACNIC reports. With the implementation of
>> LAC-2019-1 and
>>      >     >     >>>>>> possibility of Inter-RIR transfers these
>> numbers have the
>>      >     >     >>>>>> potential to grow substantially.
>>      >     >     >>>>>>>>>> The objective of this proposal is to add
>> as a requirement for
>>      >     >     >>>>>>>>>> organizations in process of receiving
>> transferred IPv4 space
>>      >     >     >>>>>>>>>> under 2.3.2.18 to show they have an IPv6
>>      >     >     >>>>>>>>>> allocation/assignment by LACNIC or a
>> provider and that is
>>      >     >     >>>>>>>>>> operational on their networks. Such
>> organization must be able
>>      >     >     >>>>>>>>>> to prove this IPv6 space is being used by
>> providing LACNIC
>>      >     >     >>>>>>>>>> the documented network deployment details
>> to prove IPv6 is
>>      >     >     >>>>>>>>>> operational in significant parts of the
>> network.
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> On 28th November 2019 LACNIC Board issued
>> a statement
>>      >     >     >>>>>>>>>>
>> (https://www.lacnic.net/4283/2/lacnic/lacnic-board-calls-on-the-community-to-promote-ipv6-deployment)
>>
>>      >     >     >>>>>>>>>> reinforcing the issue about IPv4
>> exhaustion, mentioning IPv4
>>      >     >     >>>>>>>>>> address space will be exhausted by
>> mid-2020 and calling the
>>      >     >     >>>>>>>>>> community to promote IPv6 deployment.
>>      >     >     >>>>>>>>>> In its statement LACNIC Board “invite the
>> community to
>>      >     >     work
>>      >     >     >>>>>>>>>> on promoting the development of policies
>> that will accelerate
>>      >     >     >>>>>>>>>> the effective deployment of IPv6 above
>> other policies that
>>      >     >     >>>>>>>>>> may be discussed at a later date.”
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> In the case the receiver provides a
>> written statement from
>>      >     >     >>>>>>>>>> its upstream that IPv6 connectivity is
>> unavailable, the IPv6
>>      >     >     >>>>>>>>>> requirement may be waived. In the case
>> LACNIC is not able to
>>      >     >     >>>>>>>>>> meet a new entrant request for IPv4
>> space, or the
>>      >     >     >>>>>>>>>> organization does not hold any IPv4 space
>> the IPv6
>>      >     >     >>>>>>>>>> requirement may be waived for a transfer
>> up to a /22.
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Para ver o detalhe acesse:
>>      >     >     >>>>>>>>>>
>> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1/language/pt
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> As alterações da versão anterior podem
>> ser vistas
>>      >     >     >> aqui:
>>      >     >     >>>>>>>>>>
>> https://politicas.lacnic.net/politicas/diff2?id=LAC-2020-1&v=4&v2=3&language=PT
>>
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Os comentários e os pontos de vista
>> aportados pela comunidade
>>      >     >     >>>> são
>>      >     >     >>>>>>>>>> vitais para o bom desenvolvimento do
>> processo das propostas
>>      >     >     >>>>>>>>>> - Você está a favor ou em contra desta
>> nova versão
>>      >     >     >>>>>>>>>> da proposta?- Vê alguma desvantagem nesta
>> nova versão
>>      >     >     >>>>>>>>>> da proposta?
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> - Que mudanças poderiam ser feitas à esta
>> nova versão
>>      >     >     >>>>>>>>>> da proposta para que seja mais eficaz?
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Por mais informações entre em contato
>> conosco através
>>      >     >     >>>>>> do e-mail:
>>      >     >     >>>>>>>>>> info-politicas at lacnic.net.
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Atenciosamente,
>>      >     >     >>>>>>>>>>
>> ______________________________________________________________________________________________________
>>
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Dear LACNIC Policy List subscribers,
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Proposal LAC-2020-1 has been updated from
>> version 3 to version
>>      >     >     4
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Title: Add IPv6 operational as a
>> requirement for IPv4 transfers
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Summary: On 15th February 2017 LACNIC
>> started IPv4 Exhaustion
>>      >     >     >>>>>>>>>> Phase 3 meaning only new entrants can
>> receive up to a single
>>      >     >     >>>>>>>>>> /22 of IPv4 space.
>>      >     >     >>>>>> Since then the amount of IPv4 Transfers
>> between organizations has
>>      >     >     >>>>>> increased reasonably as shown by the official
>> LACNIC reports.
>>      >     >     >>>>>> With the implementation of LAC-2019-1 and
>> possibility of
>>      >     >     >>>>>> Inter-RIR transfers these numbers have the
>> potential to grow
>>      >     >     >>>>>> substantially.
>>      >     >     >>>>>>>>>> The objective of this proposal is to add
>> as a requirement for
>>      >     >     >>>>>>>>>> organizations in process of receiving
>> transferred IPv4 space
>>      >     >     >>>>>>>>>> under 2.3.2.18 to show they have an IPv6
>>      >     >     >>>>>>>>>> allocation/assignment by LACNIC or a
>> provider and that is
>>      >     >     >>>>>>>>>> operational on their networks. Such
>> organization must be able
>>      >     >     >>>>>>>>>> to prove this IPv6 space is being used by
>> providing LACNIC
>>      >     >     >>>>>>>>>> the documented network deployment details
>> to prove IPv6 is
>>      >     >     >>>>>>>>>> operational in significant parts of the
>> network.
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> On 28th November 2019 LACNIC Board issued
>> a statement
>>      >     >     >>>>>>>>>>
>> (https://www.lacnic.net/4283/2/lacnic/lacnic-board-calls-on-the-community-to-promote-ipv6-deployment)
>>
>>      >     >     >>>>>>>>>> reinforcing the issue about IPv4
>> exhaustion, mentioning IPv4
>>      >     >     >>>>>>>>>> address space will be exhausted by
>> mid-2020 and calling the
>>      >     >     >>>>>>>>>> community to promote IPv6 deployment.
>>      >     >     >>>>>>>>>> In its statement LACNIC Board “invite the
>> community to
>>      >     >     work
>>      >     >     >>>>>>>>>> on promoting the development of policies
>> that will accelerate
>>      >     >     >>>>>>>>>> the effective deployment of IPv6 above
>> other policies that
>>      >     >     >>>>>>>>>> may be discussed at a later date.”
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> In the case the receiver provides a
>> written statement from
>>      >     >     >>>>>>>>>> its upstream that IPv6 connectivity is
>> unavailable, the IPv6
>>      >     >     >>>>>>>>>> requirement may be waived. In the case
>> LACNIC is not able to
>>      >     >     >>>>>>>>>> meet a new entrant request for IPv4
>> space, or the
>>      >     >     >>>>>>>>>> organization does not hold any IPv4 space
>> the IPv6
>>      >     >     >>>>>>>>>> requirement may be waived for a transfer
>> up to a /22.
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> To see the details, please click on:
>>      >     >     >>>>>>>>>>
>> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1/language/en
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> The changes from the previous version can
>> be seen here:
>>      >     >     >>>>>>>>>>
>> https://politicas.lacnic.net/politicas/diff2?id=LAC-2020-1&v=4&v2=3&language=EN
>>
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> The community's comments and opinions are
>> essential to the
>>      >     >     >>>>>>>>>> proper functioning of the policy
>> development process.
>>      >     >     >>>>>>>>>> - Do you support this new version of the
>> proposal or are you
>>      >     >     >>>>>>>>>> against
>>      >     >     >>>>>> it?
>>      >     >     >>>>>>>>>> - Do you think this new version of the
>> proposal has any
>>      >     >     >>>>>>>>>> drawbacks?
>>      >     >     >>>>>>>>>> - What changes could be made to this new
>> version of the
>>      >     >     >>>>>>>>>> proposal to make it more effective?
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> For further information, please contact
>>      >     >     >>>>>>>>>> info-politicas at lacnic.net
>>      >     >     >>>>>>>>>> Kind regards,
>>      >     >     >>>>>>>>>> --
>>      >     >     >>>>>>>>>> LACNIC - Registro de Direcciones de
>> Internet para América
>>      >     >
>>      >     >     >>>>>>>>>> Latina y Caribe
>>      >     >     >>>>>>>>>> Rambla Rep. de México 6125, CP 11400
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Montevideo-Uruguay
>>      >     >     >>>>>>>>>>
>>      >     >     >>>>>>>>>> Teléfono: +598 2604 22 22
>>      >     >     >>>>>>>>>> www.lacnic.net<http://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



More information about the Politicas mailing list