[LACNIC/Politicas] Nueva versión de la propuesta LAC-2020-1
Hernan Moguilevsky
noc.hernan at gmail.com
Wed Apr 14 10:54:23 -03 2021
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
More information about the Politicas
mailing list