[LACNIC/Politicas] Nueva versión de la propuesta LAC-2020-1
Oscar A. Robles-Garay
oscar at lacnic.net
Tue Apr 13 10:28:45 -03 2021
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
More information about the Politicas
mailing list