[LACNIC/Politicas] Nueva propuesta LAC-2020-1 / Nova proposta LAC-2020-1 / New proposal LAC-2020-1

Thu Jan 30 16:55:57 GMT+3 2020

Hola Fernando,

Ese caso que mencionas es uno de los posibles. Otro que se me ocurre mucho
más posible (o igualmente posible) es una organización que este operando
con bloques otorgados por su proveedor (como es el caso de cientos o miles
de organizaciones) y decide "adquirir" bloques como consecuencia de una
transferencia para utilizar en sustitución de los del proveedor y solicite
la membresía a Lacnic para ello. En ese caso no existirá asignación previa
ni de /22 ni de /32 ni de nada... correcto?
Entonces se me ocurre que esos casos no están contemplados.

Una ves más, este y otros casos van a surgir siempre que cruzamos
obligaciones... no se, sigo pensando que no merece la pena los parches que
hay que hacer a las políticas vigentes solo para "forzar" despliegue de
IPv6 cuando el único que se perjudica es quién no hace su despliegue. Creo
que ya es bastante con que se pide IPv6 para solicitar nuevos recursos IPv4
(que ademas es "gratis" porque no implica necesariamente un incremento en
la membresía)... pero creo que una cosa es forzar asignación (que ya se
hace) y otra es forzar y atar "operación significativa" con
"transferencias".

Saludos,
Nico

El jue., 30 de ene. de 2020 a la(s) 15:40, Fernando Frediani (
fhfrediani at gmail.com) escribió:

> Hola Nico
>
> Te entiendo. Mira, para un nuevo miembro creo que es una situación mucho
> más difícil de suceder. Por lo general, la mayoría de las organizaciones
> que necesitan transferir IPv4 ya son organizaciones establecidas y
> operativas.
> Sin embargo, estoy de acuerdo en que, aunque remota, esta posibilidad
> existe.
>
> Para este caso específicamente tampoco será un impedimento.
> La nueva organización recibirá su bloque IPv4 /22, su bloque IPv6 /32 y,
> dado que es una organización nueva y una asignación pequeña, es mucho
> más fácil hacer el despliegue inicial de IPv4 e IPv6 asignado por LACNIC
> y luego solicitar inmediatamente la transferencia más bloques de IPv4
> según sea necesario.
>
> Creo que estamos de acuerdo en que, para que una nueva organización
> pueda utilizar cualquier dirección IPv4 transferida, primero debe ser
> mínimamente operativa y estar lista para operar (con enrutadores,
> servidores, etc listos). Para una organización que acaba de recibir 1 x/
> 22 y 1 x /32 de IPv6, esto es relativamente simple y fácil.
> Tan pronto como esté operativa, podrá ingresar la solicitud de
> transferencia de IPv4 y podrá justificarla tranquilamente de acuerdo con
> los requisitos de esta propuesta.
>
> Diría que en cuestión de unos pocos días entre la recepción de las
> nuevas asignaciones, ya es posible realizar la solicitud para transferir
> espacio IPv4 adicional.
>
> Espero que haya sido posible aclarar su duda, de lo contrario, estoy
> disponible para aclaraciones adicionales.
>
> Saludos
> Fernando Frediani
>
> On 30/01/2020 14:45, Nicolas Antoniello wrote:
> > Fernando,
> >
> > Muchas gracias por las aclaraciones.
> > Me refiero a un nuevo miembro también.
> >
> > Saludos,
> > Nico
> >
> >
> >
> > El El jue, ene. 30, 2020 a la(s) 13:06, Fernando Frediani <
> > fhfrediani at gmail.com> escribió:
> >
> >> Estimados, algunas aclaraciones.
> >>
> >> Uesley - El análisis de la verificación de que IPv6 está operativo será
> >> realizado por el RIR. Como dice el texto de la propuesta, el staff de lo
> >> RIR definirá un criterio mínimo para garantizar que IPv6 esté operativo
> >> en la red y debe llevar a cabo un análisis de la documentación de
> >> implementación que demuestre los detalles donde se implementa IPv6 en la
> >> red.
> >>
> >> Esto no es muy diferente de lo que ya se hace hoy cuando alguien
> >> necesita justificar el uso de IPv4 para recibir una nueva asignación (en
> >> el caso de nuevos participantes) o recibir transferencias de IPv4 de
> >> otro ASN.
> >>
> >> Por lo tanto, no será suficiente simplemente anunciar el prefijo IPv6 a
> >> DMZ y poder comunicarse a través de Internet, sino demostrar de manera
> >> efectiva que se está implementando en partes importantes de la red y no
> >> en una pequeña parte que se hace solo para satisfacer este requisito de
> >> esta propuesta.
> >> Como nadie espera tener el 100% operativo para esto, se definirá un
> >> criterio mínimo razonable.
> >>
> >> Nico - Correcto. Como se mencionó en otros mensajes anteriores, esto
> >> solo se aplica a aquellos que reciben transferencias IPv4 (en la próxima
> >> versión, el texto se ajustará para hacerlo aún más claro). De la misma
> >> manera que para recibir los bloques de IPv4 deben demostrar que tienen
> >> uso para ellos, esta propuesta dice que también tendrán que demostrar
> >> que tienen IPv6 operativo en la red como una demostración de compromiso
> >> con los demás, porque si no lo hacen, agravarán aún más la situación del
> >> problema de escasez
> >>
> >> No estoy seguro de si la otra pregunta se refiere a una organización que
> >> tiene direcciones ASN e IPv4, pero nunca solicitó IPv6. Si es el caso,
> >> primero tendrá que solicitar los bloques IPv6, realizar la
> >> implementación para que pueda cumplir con este requisito mínimo. El
> >> razonamiento para esto es el mismo que en otros casos. No es razonable
> >> para los demás que en 2020 alguien ni siquiera tenga una asignación de
> >> IPv6 y quiera transferir más bloques de IPv4.
> >>
> >> Saludos Cordiales
> >> Fernando Frediani
> >>
> >> On 30/01/2020 11:23, Nicolas Antoniello wrote:
> >>> Estimados,
> >>>
> >>> Me surgen ahora dos consultas:
> >>> - Esto aplicaría solo a quien recibe y no a quien entrega?
> >>> - Que sucede si quien recibe no tiene aún espacio de direccionamiento,
> no
> >>> podría recibir una transferencia pues no tendría IPv6 y menos demostrar
> >> que
> >>> lo tiene operativo?
> >>>
> >>> Saludos,
> >>> Nico
> >>>
> >>>
> >>>
> >>> El El jue, ene. 30, 2020 a la(s) 10:41, Uesley Correa <
> >>> uesleycorrea at gmail.com> escribió:
> >>>
> >>>> Hola a todos,
> >>>>
> >>>> Me parece muy buena la propuesta. La Internet como la vemos hoy es un
> >>>> ecosistema de sistemas autónomos. Y todos sabemos que lo que uno hace
> >> si lo
> >>>> hace mal, va reflejar de manera negativa en buena parte del
> ecosistema.
> >> En
> >>>> este tema, si un miembro no quiere implementar IPv6, excelente. Es
> algo
> >> que
> >>>> puede no perjudicar a los demás. Pero todavía lo veo sin ningún
> sentido
> >> que
> >>>> este mismo miembro pida y pueda recibir cada vez más y más IPv4 (ahí
> si
> >> va
> >>>> dañar el ecosistema pues organizaciones que realmente lo necesitan
> >> pueden
> >>>> comprobarlo por medio de su compromiso con la utilización del IPv6).
> No
> >> me
> >>>> quedó claro cómo será hecha la análisis de implementación y uso del
> IPv6
> >>>> (si solamente basado en DFZ o alguna otra técnica) y si eso puede o no
> >>>> onerar el trabajo del staff de LACNIC. Pero creo que acá en las
> >> discusiones
> >>>> podemos crear técnicas y metodologías para hacer eso posible.
> >>>>
> >>>> Saludos,
> >>>>
> >>>> Uesley Corrêa - Analista de Telecomunicações
> >>>> CEO Telecom Consultoria, Entrenamiento y Servicios
> >>>> CEO Telecom Fiber Solutions
> >>>>
> >>>>
> >>>> Em qui., 30 de jan. de 2020 às 10:14, Rafael Ganascim <
> >> rganascim at gmail.com
> >>>> escreveu:
> >>>>
> >>>>> Olá,
> >>>>>
> >>>>> Eu estou de acordo com a proposta, pois creio que é mais uma forma de
> >>>>> incentivar a implementação e uso do IPv6, ainda mais para as
> >> organizações
> >>>>> sedentas por mais e mais IPv4.
> >>>>> Nos dias de hoje, demonstrar o uso do IPv6 já deveria ser considerado
> >> uma
> >>>>> tarefa básica.
> >>>>>
> >>>>> Com os comentários ajustados dos colegas Fernando e Jordi, entendo
> que
> >> já
> >>>>> tenha sido restrito o item 2.3.2.18.3 a organizações pertencentes a
> >>>> LACNIC,
> >>>>> assim como o caso onde o IPv6 é tecnicamente impossível de funcionar
> >>>>> através da justificativa do upstream e também sobre a validação
> >> periódica
> >>>>> do LACNIC.
> >>>>>
> >>>>>
> >>>>> Em ter., 28 de jan. de 2020 às 12:26, Fernando Frediani <
> >>>>> fhfrediani at gmail.com> escreveu:
> >>>>>
> >>>>>> Hola Nicolas, gracias por tus comentarios.
> >>>>>>
> >>>>>> No sé si viniste a ver los detalles de la justificación de la
> >>>> propuesta,
> >>>>>> pero intentaré reproducirlos aquí para profundizar en las razones y
> >>>>>> motivaciones.
> >>>>>>
> >>>>>> En mi opinión, cuando un ISP que transfiere más y más bloques de
> IPv4
> >>>>>> sin tener IPv6 operativo está agravando aún más el problema de
> >> escasez,
> >>>>>> mucho más de lo que parece. Y este no es solo un problema privado
> que
> >>>>>> afecta solo a la organización misma, sino a todos los demás que *se
> >>>>>> interconectan* en ese ecosistema, después de todo en Internet nadie
> es
> >>>>>> un Sistema Autónomo solo.
> >>>>>> Por lo tanto, lo menos que puede hacer cualquiera que haya
> transferido
> >>>>>> más bloques de IPv4 es ser justo con los demás y demostrar que
> tienen
> >>>>>> IPv6 operativo en un intento por reducir este problema creciente.
> >>>>>>
> >>>>>> Todavía tenemos al menos 10 a 20 años de dependencia significativa
> de
> >>>>>> IPv4 en el futuro, y si acciones como esta no se llevan a cabo,
> muchos
> >>>>>> problemas y conflictos sucederán y empeorarán, y el lugar más
> probable
> >>>>>> en el que tendrán que ser tratados es en el RIR, más especialmente
> en
> >>>>>> esta lista de políticas. No hacer nada ahora dificultará mas la
> >>>>>> resolución de este problema y los conflictos que surjan en el futuro
> >>>>>> cercano.
> >>>>>>
> >>>>>> Además, esta propuesta responde a una llamada del Directorio de
> LACNIC
> >>>>>> para propuestas que promueven la implementación de IPv6.
> >>>>>>
> >>>>>> Finalmente, algo importante a tener en cuenta es que una de las
> >>>>>> prerrogativas de este foro es establecer las reglas mínimas
> necesarias
> >>>>>> para que los registros se realicen en whois y no hay ningún problema
> >> en
> >>>>>> agregar este requisito, ya que hay otros como enviar la
> documentación
> >>>>>> necesaria para probar necesidad, de lo contrario ni siquiera
> podríamos
> >>>>>> exigir que se haga este.
> >>>>>>
> >>>>>> Si este foro comprende que la transferencia de más y más IPv4 sin la
> >>>>>> contrapartida de tener IPv6 operativo perjudica a toda la comunidad,
> >> no
> >>>>>> hay impedimento para exigir este requisito para que se ajusten los
> >>>>>> registros whois.
> >>>>>>
> >>>>>> Un saludo
> >>>>>> Fernando Frediani
> >>>>>>
> >>>>>> On 28/01/2020 12:06, Nicolas Antoniello wrote:
> >>>>>>> Hola Fernando y lista,
> >>>>>>>
> >>>>>>> En principio no estoy de acuerdo con generar políticas que
> obliguen a
> >>>>>> IPv6
> >>>>>>> a cambio de poder transferir bloques IPv4.
> >>>>>>> Me parece que podríamos estar mezclando temas de una forma muy
> >>>> forzada.
> >>>>>>> Se me ocurren varios casos en los que se podrían transferir bloques
> >>>>> IPv4
> >>>>>>> sin que ello implique siquiera probar ningún tipo de operación
> >>>>>> particular.
> >>>>>>> Repito que en principio no me parece razonable. La necesidad de
> >>>>>> despliegue
> >>>>>>> de IPv6 es ya un hecho... y el que no lo haga al único que
> perjudica
> >>>>> es a
> >>>>>>> él mismo (sobre todo pequeños ISPs con necesidad o perspectiva de
> >>>>>>> crecimiento)... entonces para que nuevas obligaciones cruzadas??
> >>>>>>>
> >>>>>>> Otro aspecto no menor es que nuevamente creo que las políticas de
> >>>>>>> transferencias no son para “autorizar” las mismas sino para
> mantener
> >>>>>>> coherencia y vigencia en el registro de Lacnic... el hecho de poner
> >>>>>>> cualquier tipo de impedimento forzado no va a evitar la
> transferencia
> >>>>>> sino
> >>>>>>> que lo que seguramente suceda es que no quede registro de la misma
> en
> >>>>>>> Lacnic (que es justamente lo que no queremos que suceda no?).
> >>>>>>>
> >>>>>>> Saludo fraterno,
> >>>>>>> Nico
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> El vie., 17 de ene. de 2020 a la(s) 13:16, <
> >>>> info-politicas at lacnic.net>
> >>>>>>> escribió:
> >>>>>>>
> >>>>>>>> [Português abaixo]
> >>>>>>>> [English below]
> >>>>>>>>
> >>>>>>>> Estimados suscriptores de la Lista de Políticas de LACNIC,
> >>>>>>>>
> >>>>>>>> Se recibió una nueva propuesta de Política, se le asignó el id
> >>>>>> LAC-2020-1.
> >>>>>>>> Título: Add IPv6 operational as a requirement for IPv4 transfers
> >>>>>>>>
> >>>>>>>> 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 by LACNIC 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.
> >>>>>>>> Para ver el detalle ingrese en:
> >>>>>>>> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1
> >>>>>>>>
> >>>>>>>> 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 propuesta?
> >>>>>>>> - ¿Esta propuesta resolvería un problema que usted está
> >>>>> experimentando?-
> >>>>>>>> ¿Ve alguna desventaja en esta propuesta?
> >>>>>>>> - ¿Qué cambios podrían hacerse a esta 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,
> >>>>>>>>
> >>>>>>>> Foi recebida uma nova proposta de Política, foi atribuído o id
> >>>>>> LAC-2020-1.
> >>>>>>>> Título: Add IPv6 operational as a requirement for IPv4 transfers
> >>>>>>>>
> >>>>>>>> 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 by LACNIC 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.
> >>>>>>>> Para ver o detalhe acesse:
> >>>>>>>> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1
> >>>>>>>>
> >>>>>>>>     Os comentários e os pontos de vista aportados pela comunidade
> são
> >>>>>> vitais
> >>>>>>>> para o bom desenvolvimento do processo das propostas
> >>>>>>>> - ¿Você é a favor ou contra desta proposta?
> >>>>>>>> - ¿Esta proposta iria resolver um problema que você está
> >>>>>> experimentando?-
> >>>>>>>> ¿Vê alguma alguma desvantagem nesta proposta?
> >>>>>>>> - ¿Que mudanças poderiam ser feitas à proposta para que seja mais
> >>>>>> eficaz?
> >>>>>>>>     Por mais informações entre em contato conosco através do
> seguinte
> >>>>>> e-mail:
> >>>>>>>> info-politicas at lacnic.net
> >>>>>>>> Atenciosamente,
> >>>>>>>>
> >>>>>>>>
> >>
> ______________________________________________________________________________________________________
> >>>>>>>> Dear LACNIC Policy List subscribers,
> >>>>>>>>
> >>>>>>>> A new Policy Proposal has been received and assigned the following
> >>>> ID:
> >>>>>>>> LAC-2020-1.
> >>>>>>>>
> >>>>>>>> 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 by LACNIC 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.
> >>>>>>>> To read the proposal, please go to
> >>>>>>>> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1
> >>>>>>>>
> >>>>>>>> The community's comments and opinions are essential to the proper
> >>>>>>>> functioning of the policy development process.
> >>>>>>>> - Do you support this policy or are you against it?
> >>>>>>>> - Would this proposal solve a problem you are experiencing?- Do
> you
> >>>>>> think
> >>>>>>>> this proposal has any drawbacks?
> >>>>>>>> - What changes could be made to this proposal to make it more
> >>>>> effective?
> >>>>>>>> For further information, please contact info-politicas at lacnic.net
> >>>>>>>> Kind regards,
> >>>>>>>>
> >>>>>>>> 
> >>>>>>>> --LACNIC - Latin American and Caribbean Internet Addresses
> Registry
> >>>>>>>> Rambla Rep. de México 6125, CP 11400
> >>>>>>>> Montevideo-Uruguay
> >>>>>>>> Phone number: +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
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>