[LACNIC/Politicas] consulta politica global ASN

Thu Jun 5 09:43:39 BRT 2014

Hola a tod at s, como estan?

El debate ha estado bueno e interesante, pero creo que no estamos apartando 
un poco de la pregunta original de Ricardo acerca de la distincion entre 16 
y 32 bits para los ASN por parte de la IANA. En el pool de ASN de la IANA la 
disponibilidad es del 97% aproximadamente (mas de 4 billones), aunque solo 
existen sin asignar a los RIRs poco mas de 500 ASN (de los llamados de 16 
bits). Esta consulta a la comunidad, viene dada a partir de saber si estos 
500 ASN deben recibir un tratamiento diferenciado (en aras de poder 
satisfacer en algun momento, situaciones especiales en los diferentes RIRs 
que por fuerza mayor necesiten ASN de los de "16 bits" ) o simplemente se le 
pueden asignar totalmente al primer RIR que solicite ASN. Resumiento, la 
idea es saber si estos 500 ASN deberian repartirse entre los cinco RIRs 
(siguiendo alguna formulacion) o da igual como se asignen y a quien se le 
asignen.

Muy buenos los datos que aporta Luisa, para ilustrar las condiciones que 
tenemos en la region. En el caso particular de LACNIC, aunque en estos 
momentos lo que se va a poder asignar de forma mayoritaria son los llamados 
de "16 bits", nos quedaria un remanente de aproximadamente 150 de estos ASN 
en reserva, en el momento de recibir una nueva asignacion de 1024 ASN "de 32 
bits" por parte de IANA.

Saludos,
Jorge

-----Original Message----- 
From: Luisa Villa
Sent: Wednesday, June 4, 2014 7:09 PM
To: politicas at lacnic.net
Subject: Re: [LACNIC/Politicas] consulta politica global ASN

Hola estimados,

La última asignación que recibió LACNIC de parte de IANA se compuso de
un bloque de 512 ASN de 16-bits y 512 ASN de 32-bits, completándose así
la unidad de asignación de 1024 ASN definida en la política de IANA.

La política de IANA establece dos criterios que son los que permiten
solicitar ASN adicionales:

1. Haber asignado el 80% del bloque previamente recibido. Esto quiere
decir, que de ese bloque de 1024 ASN LACNIC debiera tener alrededor de
200 ASN en su stock para poder solicitar más ASN a IANA.
2. Que el stock disponible sea inferior a la necesidad proyectada para
los siguientes dos meses, basada en el promedio de asignación de los 6
meses anteriores.  En los últimos 6 meses LACNIC ha tenido en promedio
76,5 asignaciones por mes, esto quiere decir que para calificar bajo
este disparador, LACNIC debiéra tener en su stock menos de 153 ASN.

Dicho lo anterior, el primer criterio parece ser el que llevaría a
LACNIC a solicitar un bloque nuevo a IANA.

Ahora, de ese último bloque que recibimos de IANA, solamente nos quedan
en stock 6 ASN de 32-bits, por lo que al momento de que se terminen, los
únicos ASN que vamos a tener para asignar van a ser ASN de 16-bits, los
cuáles, de acuerdo a la política, vamos a tener que consumir hasta
llegar a la utilización del 80% del bloque recibido previamente
(recuerden no hay distinción de ASN para IANA). Esto nos llevaría a
quedar con un stock de alrededor de 200 ASN de 16-bits. Cabe mencionar
que como práctica LACNIC asigna por defecto ASN de 32-bits a menos que
el solicitante pida un ASN de 16-bits por no poder usar el de 32-bits.
Pero en los siguientes meses solo podremos que asignar de 16-bits pues
solo tendremos ASN de 16-bits en nuestro stock.

En los últimos dos años y medio las asignaciones de ASN de 32-bits han
representado un 57,08% mientras que las asignaciones de ASN de 16-bits
han representado un 42,91%.

Saludos,

Embedded Image
*Luisa Villa*
Gerente de Clientes
Customer Manager
*# 4501*
Embedded Image
*Casa de Internet de
Latinoamérica y el Caribe*
Rambla Rep. de México 6125
11400 Montevideo-Uruguay
+598 2604 22 22 www.lacnic.net <http://www.lacnic.net>
On 6/4/14 6:59 PM, Fabián Mejía wrote:
> Hola Arturo
>
> Por eso, LACNIC no puede pedir más ASN de 32 bits porque tienen en
> stock ASN de 16 bits (IANA ya no hace distinción) y la preocupación es
> que están entregando ASN de 16 bits por defecto a alguien que
> perfectamente puede usar uno de 32 bits (no hay ninguna política que
> lo evite), probablemente se acaben y a futuro no habrá para alguien
> que solo puede usar de 16 bits. De ahí que tal vez conviene reservar
> algo (o no, esa es la preocupación y el motivo de la discusión).  Si
> no simplemente siguen entregando lo que hay y cuando llegue el tiempo
> piden más de 32 bits.
>
> Saludos,
>
> Fabián Mejía
>
> El 2014-06-04 15:15, Arturo Servin escribió:
>> Creo que el problema no son los ASN de 16 bits, si no los de 32 bits
>> que no
>> hay muchos en el stock de LACNIC y no puede pedir más a IANA hasta que
>> asigne un buen porcentaje de los de 16 bits.
>>
>> Slds
>> as
>>
>>
>>
>> 2014-06-04 13:03 GMT-07:00 Fabián Mejía <ing.fabianmejia at gmail.com>:
>>
>>> Hola
>>>
>>> Lo que debería decir la propuesta de política es básicamente los
>>> criterios
>>> que está aplicando ahora el staff de LACNIC, solo que ahora estarían
>>> escritos en el manual y más bien les ayuda a no entregar por defecto
>>> un ASN
>>> de 16 bits a alguien que puede usar uno de 32, motivados por el
>>> hecho de
>>> que no se puede solicitar más recursos a IANA.
>>>
>>> La pregunta para el staff de LACNIC sería:  ¿cuantos ASN de 16 bits
>>> hay en
>>> el stock de LACNIC, hoy? y ¿cuales son las estadísticas de
>>> asignación de
>>> ASN de 16 bits por año desde que entró en vigencia la política
>>> global de no
>>> diferenciar?, con ello se tiene una mejor base para
>>> analizar/discutir si
>>> conviene o no crear el pool y qué cantidad sería bueno reservar.
>>> Cualquier
>>> cosa que exceda el pool de reserva (de existir) puede ser asignado
>>> inmediatamente aunque sea de 16 bits.
>>>
>>>
>>> Saludos,
>>>
>>> Fabián Mejía
>>>
>>> El 2014-06-04 14:31, Matias Niosi escribió:
>>>
>>>   Estoy de acuerdo con Juan.
>>>> Qué pporcentaje de utilización de ASNs hay hoy en LACNIC? Qué parte de
>>>> ellos son del 0 al 65536?
>>>>
>>>> Slds.
>>>>
>>>>
>>>>
>>>>
>>>> El 4 de junio de 2014, 16:28, Juan Alejo Peirano <
>>>> juan.alejo.peirano at gmail.com> escribió:
>>>>
>>>>   Estima at s,
>>>>> Respecto a la propuesta de Fabián, en un primer momento tenía mis
>>>>> dudas
>>>>> respecto a generar una reserva, para no condicionar en el futuro el
>>>>> trabajo
>>>>> de los Hostmsters  cuando la situación no sea tan crítica, pero en
>>>>> vista
>>>>> de
>>>>> los tiempos que se manejan y la necesidad por parte de la
>>>>> comunidad de
>>>>> LACNIC de disponer de ASNs de por encima de 65535 para asignar y
>>>>> "cuidar
>>>>> "
>>>>> un poco mas los que se encuentran por debajo de  65535, apoyo la
>>>>> idea de
>>>>> Fabián Mejía  .Si fuera posible consultarle  al Staff de LACNIC el
>>>>> impacto
>>>>> (en particular negativo si lo hay) que puede tener la creación de
>>>>> esta
>>>>> reserva, puramente desde el punto de vista operativo.
>>>>>
>>>>> Saludos!
>>>>>
>>>>> Juan
>>>>>
>>>>>
>>>>> El 4 de junio de 2014, 15:13, Fabián Mejía
>>>>> <ing.fabianmejia at gmail.com>
>>>>> escribió:
>>>>>
>>>>>   Hola a todos
>>>>>> Primero, gracias Ricardo por poner sobre la mesa este tema.
>>>>>>
>>>>>> Coincido con Juan que en vista de lo largo que puede resultar
>>>>>> alcanzar
>>>>>> consenso en una política global, el punto a poner atención
>>>>>> sería:  la
>>>>>> interpretación de "necesidad" en IANA.
>>>>>>
>>>>>> Por otra parte, puede ser también conveniente mantener una reserva
>>>>>> "adecuada" de ASN de 32 bits con 16 ceros al inicio (acogiendo la
>>>>>> recomendación de Jorge Villa).
>>>>>>
>>>>>> Por lo tanto, me parece que el camino puede ser proponer una
>>>>>> política en
>>>>>> LACNIC que cree una reserva de dichos ASN, que se pueden asignar
>>>>>> solo en
>>>>>> los casos especiales (no por defecto), con ello asumo que si
>>>>>> LACNIC no
>>>>>> puede asignar de ese pool, NECESITA que IANA le asigne otro rango.
>>>>>>    Estonces todo estaría más claro.
>>>>>>
>>>>>> ¿Qué opinan?.
>>>>>>
>>>>>> Saludos,
>>>>>>
>>>>>> Fabián Mejía
>>>>>> AEPROVI
>>>>>>
>>>>>> El 2014-06-04 12:05, Juan Alejo Peirano escribió:
>>>>>>
>>>>>>   Ricardo, tenes razón, pido disculpas por la mala interpretación
>>>>>> de tu
>>>>>>> correo.
>>>>>>>
>>>>>>> Y con la correcta (espero) interpretación de tu correo, me gustaría
>>>>>>> reformular algunas ideas.
>>>>>>> - El proceso por el cual esta política debe ser modificada es el de
>>>>>>> Política Global, como menciona Ricardo. Esto hace que los
>>>>>>> tiempos para
>>>>>>> alcanzar consenso en todas las regiones y luego pasar por el ASO y
>>>>>>> finalmente por el Board de ICANN para ser ratificada, sean mas
>>>>>>> largos
>>>>>>> de
>>>>>>> lo
>>>>>>> que supondría un nuevo pedido a IANA al alcanzar el 80% de
>>>>>>> utilización
>>>>>>> total.
>>>>>>>
>>>>>>> Mas alla que veo  sumamente importante tratar de conseguir ASNs por
>>>>>>>
>>>>>> encima
>>>>>> de 65535 (32 bits) lo antes posible, creo que el camino de
>>>>>> modificación
>>>>>>> como política global no sería el adecuado, a no ser que ya hubiese
>>>>>>> consenso
>>>>>>> por este tema en los otro 4 RIRs y se pudiera resolver todo en el
>>>>>>>
>>>>>> próximo
>>>>>> semestre del 2014 (si alguien tiene información respecto a esto me
>>>>>>> encantaría saberlo)
>>>>>>>
>>>>>>> Dado que LACNIC asigna ASNs por encima de 65535 por omisión a
>>>>>>> nos ser
>>>>>>>
>>>>>> que
>>>>>> se justifiquen carencias tecnológicas que solo permitan utilizar
>>>>>> un ASN
>>>>>> de
>>>>>> 16 bits ¿cual es la interpretación de " necesidad" que aplica
>>>>>> IANA en el
>>>>>>> punto 9.4.3 ?
>>>>>>>
>>>>>>>       - El número de ASNs libres actualmente en poder del RIR es
>>>>>>> menor
>>>>>>> que
>>>>>>> la
>>>>>>>
>>>>>>>       NECESIDAD proyectada para 2 meses. La proyección se basa
>>>>>>> en el
>>>>>>>
>>>>>> número
>>>>>>       promedio de ASNs asignados por el RIR durante los 6 meses
>>>>>> precedentes.
>>>>>>> Se puede justificar la "necesidad" de numero altos de ASNs? Creo
>>>>>>> que si
>>>>>>> utilizamos el promedio de ASNs de 32 bits entregados se podría
>>>>>>>
>>>>>> justificar
>>>>>> la necesidad, ya que mayoritariamente se entregan ASNs de 32 bits
>>>>>> (por
>>>>>>> encima de 65535) , pero de nuevo, todo depende de la
>>>>>>> interpretación de
>>>>>>> IANA
>>>>>>> del concepto de necesidad
>>>>>>>
>>>>>>> Saludos
>>>>>>>
>>>>>>> Juan
>>>>>>>
>>>>>>>
>>>>>>> El 4 de junio de 2014, 13:07, Ricardo Patara <patara at registro.br>
>>>>>>> escribió:
>>>>>>>
>>>>>>>    Estimados,
>>>>>>>
>>>>>>>> Mis disculpas si mi consulta no fue clara.
>>>>>>>>
>>>>>>>> @Juan, la política global *ya no hace* distinción entre ASNs 16
>>>>>>>> y 32
>>>>>>>> bits.
>>>>>>>>
>>>>>>>> La consulta es si la comunidad está de acuerdo en seguir así. O si
>>>>>>>> debido al escenario diferente de lo que se imaginaba cuando se
>>>>>>>> propuso
>>>>>>>> esa política, cambiar el texto para que *sí* se haga distinción.
>>>>>>>>
>>>>>>>> Eso implica en una política global que hay que discutir y pasar
>>>>>>>> en los
>>>>>>>>
>>>>>>> 5
>>>>>> RIRs.
>>>>>>>> Y también hay que aclarar que dentro en poco LACNIC no tendrá
>>>>>>>> más ASNs
>>>>>>>> 32 bits en su estoque con lo que no podrá, como sugerido,
>>>>>>>> asignar 16
>>>>>>>> bits solamente a quién lo solicite (ese es el procedimiento
>>>>>>>> actual,
>>>>>>>>
>>>>>>> pero
>>>>>> desde que haya ASNs 32 bits).
>>>>>>>> Saludos
>>>>>>>>
>>>>>>>> Ricardo Patara
>>>>>>>>
>>>>>>>> On 06/04/2014 12:50 PM, villa at reduniv.edu.cu wrote:
>>>>>>>>
>>>>>>>>   Hola a tod at s, como estan?
>>>>>>>>> Creo que hay dos partes del problema. Uno referente a
>>>>>>>>> terminologia y
>>>>>>>>> otro referente a operacion.
>>>>>>>>>
>>>>>>>>> En realidad todos los ASN son numeros de 32 bits; solo que hay un
>>>>>>>>>
>>>>>>>> grupo
>>>>>>   que tienen los primeros 16 bits en cero (del 0 al 65536) y por
>>>>>> razones
>>>>>>>>> historicas se les dice "de 16 bits"; pero no es correcto hacer
>>>>>>>>> diferenciacion formal, que en algunos casos puede incluso
>>>>>>>>> llevar a
>>>>>>>>> errores conceptuales.
>>>>>>>>>
>>>>>>>>> Desde el punto de vista de operacion, la principal razon de
>>>>>>>>> pretender
>>>>>>>>> emplear numeros de los llamados "de 16 bits" es para satisfacer a
>>>>>>>>> operadores con equipamiento obsoleto que no admiten el manejo
>>>>>>>>> de los
>>>>>>>>>
>>>>>>>> 32
>>>>>>   bits completos del ASN, y concuerdo con Juan Peirano en que
>>>>>> cada vez
>>>>>>>> son
>>>>>>   menos los equipos en esta situacion. Incluso, me parece que
>>>>>> pudiera
>>>>>>>>> haber mas necesidad de estos ASN en los End-Users que en los ISP.
>>>>>>>>> Paradojicamente, donde mayor demanda hay de estos AS de 16
>>>>>>>>> bits en la
>>>>>>>>> region de ARIN. Yo creo que seria interesante tener una
>>>>>>>>> resreva para
>>>>>>>>> esos casos extremos, y como regla general, asignar de 32 bits y
>>>>>>>>> documentar todo con de 32 bits.
>>>>>>>>>
>>>>>>>>> Saludos,
>>>>>>>>> Jorge
>>>>>>>>>
>>>>>>>>> -----Original Message----- From: Dario Tuseddu
>>>>>>>>> Sent: Wednesday, June 4, 2014 11:46 AM
>>>>>>>>> To: politicas at lacnic.net
>>>>>>>>> Subject: Re: [LACNIC/Politicas] consulta politica global ASN
>>>>>>>>>
>>>>>>>>> Buenos días,
>>>>>>>>>
>>>>>>>>> Creo que es importante asignar por default ASN de 32 bits, y
>>>>>>>>> solo en
>>>>>>>>>
>>>>>>>> el
>>>>>>   caso que el usuario puede demostrar la necesidad del ASN de 16
>>>>>> bits
>>>>>>>>> cambiarlo, hoy el común denominante de los dispositivos
>>>>>>>>> disponibles
>>>>>>>>> pueden utilizar ASN de 32 bits o en su defecto disponen de
>>>>>>>>> métodos de
>>>>>>>>> transición
>>>>>>>>>
>>>>>>>>> Saludos!
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Dario Tuseddu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 6/4/14 12:41 PM, Jhonder Depablos wrote:
>>>>>>>>>
>>>>>>>>>   Hola compañeros, estoy muy deacuerdo con Luis y Juan Alejo, sin
>>>>>>>>> embargo
>>>>>>   debe limitarse un rango de reserva y condiciones restrictivas
>>>>>> para su
>>>>>>>>>> asignacion cuando ya estemos en el area de reserva.
>>>>>>>>>>
>>>>>>>>>> Saludos
>>>>>>>>>> El 04/06/2014 11:04, "Juan Alejo Peirano" <
>>>>>>>>>> juan.alejo.peirano at gmail.com
>>>>>>>>>> escribió:
>>>>>>>>>>
>>>>>>>>>>    Estimad at s,
>>>>>>>>>>
>>>>>>>>>>> Creo que sería interesante realizar la modificación para que NO
>>>>>>>>>>> haya
>>>>>>>>>>> distinción entre los ASN de 16 y de 32 bits a la hora de
>>>>>>>>>>> realizar
>>>>>>>>>>> la
>>>>>>>>>>> asignación por parte de IANA.
>>>>>>>>>>>
>>>>>>>>>>> En nuestra región hemos tenido una muy buena "aceptación"
>>>>>>>>>>> (por asi
>>>>>>>>>>> decirlo)
>>>>>>>>>>> de ASNs de 32 bits y es importante continuar con la
>>>>>>>>>>> asignación de
>>>>>>>>>>>
>>>>>>>>>> los
>>>>>>   mismos y que no se entreguen ASNs de 16 bits por falta de los
>>>>>>>>>>> anteriores.
>>>>>>>>>>>
>>>>>>>>>>> Concuerdo con Luis de que la mayoría de los equipos ya soportan
>>>>>>>>>>> ASNs
>>>>>>>>>>> de 32
>>>>>>>>>>> bits, otra razón por la cual la distinción creo que carece de
>>>>>>>>>>>
>>>>>>>>>> sentido.
>>>>>>   Saludos!
>>>>>>>>>>> Juan Alejo Peirano
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> El 4 de junio de 2014, 11:34, Ricardo Patara
>>>>>>>>>>> <patara at registro.br>
>>>>>>>>>>> escribió:
>>>>>>>>>>>
>>>>>>>>>>>    La política global para asignación de ASN por IANA a los
>>>>>>>>>>> RIRs
>>>>>>>>>>>
>>>>>>>>>>>> implementada en 2010 indica que a partir de 1er de enero
>>>>>>>>>>>> 2011 IANA
>>>>>>>>>>>> dejaría de hacer distinción entre ASNs de 16 y de 32 bits.
>>>>>>>>>>>>
>>>>>>>>>>>> Las asignaciones de IANA a los RIRs pasó a ser de rangos de
>>>>>>>>>>>> ASNs
>>>>>>>>>>>>
>>>>>>>>>>> que
>>>>>>   podrían ser menores o mayores a 65535 sin distinción.
>>>>>>>>>>>> Y para el RIR obtener ASNs adicionales ha que demostrar
>>>>>>>>>>>> utilización
>>>>>>>>>>>> de
>>>>>>>>>>>> al menos 80% del rango ya asignado, y nuevamente sin
>>>>>>>>>>>> distinción.
>>>>>>>>>>>>
>>>>>>>>>>>> Algunos RIRs, incluyendo LACNIC, han asignado más ASN
>>>>>>>>>>>> mayores a
>>>>>>>>>>>>
>>>>>>>>>>> 65535
>>>>>>   por defecto. Y han reservado los menores a 65535 para redes que
>>>>>>>>>>>>   todavía
>>>>>>>>>> no soportan los de numero mayor a 65535.
>>>>>>>>>> Pero pasa que estos ASN de numero mayores a 65535 se están
>>>>>>>>>> agotando
>>>>>>>>>>>> en
>>>>>>>>>>>> LACNIC y por eso se está asignado los menores mismo a
>>>>>>>>>>>> "redes" que
>>>>>>>>>>>> soportan y podrían utilizar los de numero mayor.
>>>>>>>>>>>>
>>>>>>>>>>>> Eso asta que se pueda justificar ASNs adicionales.
>>>>>>>>>>>> La proyección de LACNIC para poder justificar asignación
>>>>>>>>>>>> adicional
>>>>>>>>>>>>
>>>>>>>>>>> de
>>>>>>   ASN es para inicio de 2015.
>>>>>>>>>>>> En otras regiones, en especial la de ARIN, pasa lo contrario.
>>>>>>>>>>>> Proveedores allá han solicitado más ASNs menores a 65535 y
>>>>>>>>>>>> una vez
>>>>>>>>>>>> que
>>>>>>>>>>>> se agoten estos numeros, ARIN pasará a asignar los mayores a
>>>>>>>>>>>> 65535.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> La consulta a la comunidad es acerca de la no distinción
>>>>>>>>>>>> por parte
>>>>>>>>>>>>
>>>>>>>>>>> de
>>>>>>   IANA a estos dos "grupos" de ASN como indica la política.
>>>>>>>>>>>> Piensan que hay que proponer ajustes a la misma?
>>>>>>>>>>>>
>>>>>>>>>>>> Y hay que recordar que el "estoque" de ASNs menores a 65535
>>>>>>>>>>>> junto
>>>>>>>>>>>> a
>>>>>>>>>>>> IANA
>>>>>>>>>>>> es de aproximadamente 500 ASNs.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Saludos
>>>>>>>>>>>> -- 
>>>>>>>>>>>> Ricardo Patara
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> 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
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Consulte la enciclopedia colaborativa cubana.
>>>>>>>>> http://www.ecured.cu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Consulte la enciclopedia colaborativa cubana.
>>>>>>>>> http://www.ecured.cu
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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

_______________________________________________
Politicas mailing list
Politicas at lacnic.net
https://mail.lacnic.net/mailman/listinfo/politicas

Consulte la enciclopedia colaborativa cubana. http://www.ecured.cu