[LACNIC/Politicas] Nueva propuesta LAC-2020-1 / Nova proposta LAC-2020-1 / New proposal LAC-2020-1
Fernando Frediani
fhfrediani at gmail.com
Tue Feb 4 17:15:18 GMT+3 2020
Hola
Arturo: hacer que parezca que la única función es realizar la
actualización de las transferencias es una forma muy "simplista" de
abordar este problema dada la realidad actual.
Mantener registros actualizados es una de las funciones, tal vez la
principal, pero no la única. El contexto actual y los impactos de dejar
todo como está debe analizarse si está de acuerdo con el interés de la
comunidad involucrada, de lo contrario, tampoco necesitaríamos reglas de
justificación para IPv4.
Esta propuesta no tiene la intención de resolver un problema de mercado,
sino un problema de la existencia continua del ecosistema de Internet
con menos conflictos y problemas para todos los involucrados.
Nico - Mi opinión es que las transferencias de IPv4 sin contrapartes
agravan el problema de la escasez, y agravan mucho más de lo que parece.
Como dice el texto en la justificación, es justo pro parte de las
organizaciones que necesiten transferir para con todos los demás.
Esta propuesta NO es contraria a las transferencias. Simplemente pone
una contraparte, justa para todos los demás, como un requisito para que
se realicen y, por lo tanto, compensa el problema que empeora.
Vea, esta propuesta ni siquiera coloca una gran barrera o algo
inalcanzable para que las transferencias de IPv4 continúen realizándose.
Simplemente pide lo obvio, que IPv6 estaba operativo en un escenario
específico que tiene consecuencias para los demás. Es solo un requisito
pequeño, justo y equilibrado. Estamos uniendo esfuerzos para tratar de
reducir todos los problemas derivados de la escasez de IPv4. Esta
propuesta no pretende resolver todos los problemas de implementación de
IPv6.
Como Oscar dijo en su mensaje, tenemos un rol técnico que agregado a las
necesidades del mercado de las empresas serán responsables de resolver
otros problemas relacionados con la escasez de IPv4 que y que no sería
posible resolver solo a través de políticas.
Estamos en 2020 y lo que exige la propuesta es algo a lo que cualquier
organización, grande o pequeña, que tenga un compromiso con el sector y
el ecosistema del que depende y está conectada, no pueda hacerlo.
Con respecto a la pregunta sobre "¿Qué problema quieres resolver?" Creo
que mis mensajes recientes desde que se hizo la pregunta ya han
respondido en detalle la intención. No puedo pensar y nada más por ahora
para producir otro tipo de respuesta.
Me gustaría entender cuál es la preocupación del grande daño o pérdida
si esta propuesta se convierte en una política que puede causar a la
comunidad u organizaciones y estaré dispuesto a ajustar el texto para
evitar que cualquier problema empeore el escenario actual. Por otro
lado, creo que sin tales políticas, el empeoramiento no es una
suposición, ¡es una certeza!
Saludos
Fernando Frediani
On 04/02/2020 12:06, Nicolas Antoniello wrote:
> Hola Fernando y todos,
>
> En lo personal no veo tan claro que las transferencias agravan algún
> problema. Creo que no agravan sino que para algunos es una opción de
> negocio (no creo que deba serlo, pero la realidad dice que lo es).
>
> No se por qué se menciona reiteradamente el Whois... creo que no se trata
> del Whois solamente, sino del registro de Lacnic, de RPKI, del ruteo de los
> bloques en la región, del correcto registro en los IRR...
>
> Si lo que se quiere es (convengamos que Lacnic, así como otras
> organizaciones, vienen hace años haciendo esfuerzos para ello) acelerar el
> despliegue y operación de IPv6 en la región, por que no proponer una
> política que diga que a X fecha todos los miembros de Lacnic deberán
> demostrar que utilizan IPv6 para sus servicios y/o clientes?
> Eso sería mucho mas “fuerte” pero también mucho mas concreto que mezclarlo
> con las transferencias.
>
> Sigo pensando que con el criterio y justificación de esta propuesta se
> podría poner esa condición para casi cualquier obligación de los
> Miembros... y no es muy concreto pues las transferencias alcanzan a una
> ínfima parte de los mismos por lo que tampoco visualizo la efectividad de
> la propuesta.
>
> Saludos,
> Nico
>
>
>
>
> El El mar, feb. 4, 2020 a la(s) 11:45, Fernando Frediani <
> fhfrediani at gmail.com> escribió:
>
>> Hola
>>
>> ¿Parece justo que exista un requisito de que todas las organizaciones
>> tengan que justificar mediante documentación y otros medios el uso de un
>> *recurso escaso* siempre que necesiten recibir o transferir más IPv4?
>> ¿Se consideró esto alguna vez una carga innecesaria? Creo que el interés
>> de todos por distribuir los recursos de la manera más justa posible
>> siempre ha compensado esta "carga"
>>
>> De manera similar, esta propuesta requiere solamente a todos aquellos
>> que están *agravando el problema de la escasez* y, como consecuencia,
>> afectando a todos los demás, demostrar una contraparte en la dirección
>> opuesta a una Internet con menos disputas e injusticias para todos los
>> que se conectan a él. Y, sinceramente, no es una contraparte tan grande
>> en el escenario actual.
>>
>> Sí, una de las funciones principales de un RIR es mantener whois
>> actualizado, pero no es la única. En el Capítulo I (Constitución),
>> Artículo 2 del Estatuto de LACNIC donde describe sus propósitos, entre
>> otras cosas también dice:
>> "Colaborar en el crecimiento de Internet en la región".
>>
>> ¿Cómo podemos creer que es posible promover el crecimiento de Internet
>> en la región sin ningún tipo de contrapartida a las transferencias IPv4
>> que solo agravan el problema real para todos?
>>
>> No me parece razonable pensar que este tipo de requisito es una gran
>> barrera y solo "los grandes que tienen suficiente dinero pueden tener
>> IPv6 operativo".
>> Para un pequeño proveedor con 250 clientes, es relativamente sencillo
>> tener IPv6 en funcionamiento dada la simplicidad del entorno. Para un
>> gran proveedor, lo más probable es que lo haya desde hace mucho tiempo.
>>
>> ¿Sabes a quién le costará más? Para aquellos medianos y grandes que a
>> mediados de 2020 no hicieron absolutamente nada a este respecto.
>> ¿Sabes quién tendrá privilegios si no se propone un requisito como este?
>> Solo aquellos que tienen mucho dinero y pueden pagar para transferir más
>> y más IPv4.
>>
>> Finalmente, decir que las transferencias continuarán ocurriendo 'de
>> todos modos' no es una justificación para no tener este requisito, ya
>> que la obligación de tener los datos actualizados correctamente en el
>> whois no es opcional a los participantes. Si hay un nuevo requisito que
>> en este momento interesa a esa comunidad, es más importante que no
>> tenerlo debido al supuesto de que no se cumplirá.
>>
>> Saludos cordiales
>> Fernando Frediani
>>
>> On 03/02/2020 19:24, Jorge Villa wrote:
>>> Hola a tod at s, buenas tardes
>>>
>>> Solo quisiera recordar, que para la comunidad (ya sea por temas de
>> operación, seguridad, etc,) lo mas importante de estas políticas de
>> transferencia, es que se logre mantener la exactitud el registro en cuanto
>> al uso de los bloques de direcciones. Las transferencias van a seguir
>> ocurriendo de todos modos, y mientras mas requisitos se pongan o mas
>> complejo sea el camino para que ocurran, van a terminar sucediendo y
>> favoreciendo única y exclusivamente a "los grandes", que siempre pueden
>> cumplir con todo o tienen dinero suficiente y opciones para comprar lo que
>> necesitan por una u otra via.
>>> Saludos,
>>> Jorge
>>>
>>> El 2/3/20 4:29 p. m., "Politicas en nombre de Arturo Servin"<
>> politicas-bounces at lacnic.net en nombre dearturo.servin at gmail.com>
>> escribió:
>>> Jordi
>>>
>>> Concuerdo que es necesario cuidar los recursos escasos, pero está
>> política
>>> está lejos de cumplir con ese objetivo.
>>>
>>> Y vuelo a preguntar, cual es el problema a resolver.
>>>
>>> Si es cuidar un recurso escaso entonces mejor pongamosle precio a
>> las
>>> transferencias, eso realmente va a controlar el uso de un recurso
>> escaso.
>>> Querer tapar el sol con un dedo creyendo que pidiendole a un
>> operador que
>>> demuestre que tiene IPv6 funcionando realmente es "bullet proof" y
>> nadie va
>>> a encontrar formas de vencer al "sistema" es bastante ingenuo.
>>>
>>> Saludos
>>> as
>>>
>>>
>>> On Mon, 3 Feb 2020, 18:53 Fernando Frediani,<fhfrediani at gmail.com>
>> wrote:
>>> > Hola Nico
>>> >
>>> > Correcto, el nuevo ASN recibirá IPv6, pero no es suficiente
>> tenerlos, sino
>>> > que también estén operativos.
>>> > También está la cuestión de los ASN más antiguos que, por alguna
>> razón, aún
>>> > no tienen la asignación y tendrán que ajustarse en ese caso, es
>> decir,
>>> > recibir la asignación y hacerla operativa ...
>>> >
>>> > Creo que para la mayoría de los casos esto no será una gran carga
>> ni
>>> > ninguna complicación porque en el caso de los ISP más grandes es
>> mucho más
>>> > probable que ya tengan IPv6 operativo (quizás no sea 100%, pero
>> este no es
>>> > el requisito), y en el caso de los más pequeños debido a la
>> simplicidad del
>>> > escenario también podrá cumplir los requisitos mínimos definidos
>> por el
>>> > RIR.
>>> >
>>> > Gracias por las preguntas y consideraciones.
>>> > Saludos
>>> > Fernando
>>> >
>>> > On Mon, 3 Feb 2020, 14:28 Nicolas Antoniello,<
>> nantoniello at gmail.com>
>>> > wrote:
>>> >
>>> > > Hola Jordi,
>>> > >
>>> > > Comparto la pregunta de Arturo y agrego que tengamos en cuneta
>> que YA
>>> > > EXISTE la obligatoriedad de disponer de IPv6 al solicitar
>> recursos
>>> > > adicionales IPv4 o al solicitar recursos por primera vez (se
>> asigna
>>> > también
>>> > > IPv6).
>>> > >
>>> > > Creo que no agrega nada entonces esta política pues la
>> transferencia va a
>>> > > darse igual (esto ya lo hemos debatido mucho en el pasado). El
>> agregar
>>> > > condiciones no parece ser ni efectivo ni sano cuando en si el
>> problema de
>>> > > las transferencias ya es bastante complejo por si solo.
>>> > >
>>> > > Saludos,
>>> > > Nico
>>> > >
>>> > >
>>> > >
>>> > > El El lun, feb. 3, 2020 a la(s) 13:27, JORDI PALET MARTINEZ via
>>> > Politicas <
>>> > >politicas at lacnic.net> escribió:
>>> > >
>>> > > > Hola Arturo,
>>> > > >
>>> > > > Sin ser autor, te contesto mi punto de vista, en cierto modo
>> parecido a
>>> > > lo
>>> > > > que le acabo de contestar a Mike.
>>> > > >
>>> > > > Si hay un recurso de la humanidad que es escaso, y hay una
>> solución,
>>> > que
>>> > > > requiere un uso "parcial" del recurso escaso, me parece
>> oportuno que
>>> > > > quienes quieran ignorar la solución, tengan más dificultades o
>>> > > sobrecoste,
>>> > > > para obtener el recurso escaso, porque de otro modo, en lugar
>> de
>>> > permitir
>>> > > > la nueva solución a mas "población", ofrecemos el recurso
>> escaso al
>>> > mejor
>>> > > > postor.
>>> > > >
>>> > > > Saludos,
>>> > > > Jordi
>>> > > > @jordipalet
>>> > > >
>>> > > >
>>> > > >
>>> > > > El 3/2/20 17:20, "Politicas en nombre de Arturo Servin" <
>>> > > >politicas-bounces at lacnic.net en nombre
>> dearturo.servin at gmail.com>
>>> > > > escribió:
>>> > > >
>>> > > > Pregunta sencilla a los autores. Qué problema intentan
>> resolver con
>>> > > > esta
>>> > > > política?
>>> > > >
>>> > > > Y por favor no digan que el despliegue de IPv6 porque eso
>> sería una
>>> > > > falacia
>>> > > > total.
>>> > > >
>>> > > > Saludos
>>> > > > as
>>> > > >
>>> > > >
>>> > > >
>>> > > > On Mon, Feb 3, 2020 at 4:59 PM Mike Burns<
>> mike at iptrading.com>
>>> > > wrote:
>>> > > >
>>> > > > > Hi Jordi,
>>> > > > >
>>> > > > > Inter-RIR or not, the number of transfers
>> intra-regionally is
>>> > > really
>>> > > > > shockingly low by other regions' intra-regional
>> transfer counts.
>>> > > > >
>>> > > > > I have perspective. I have brokered close to 1000
>> transfers in
>>> > > more
>>> > > > than
>>> > > > > 80 countries.
>>> > > > > There is something really wrong with the LACNIC
>> transfer market,
>>> > > and
>>> > > > it's
>>> > > > > not simply the lack of Inter-RIR.
>>> > > > >
>>> > > > > If every recipient of an IPv4 transfer in LACNIC
>> demonstrated the
>>> > > > ability
>>> > > > > to route an IPv6 block, would that have made any dent
>> in IPv6
>>> > > > penetration?
>>> > > > >
>>> > > > > Highly doubtful. Do you think it's appropriate to add
>> this
>>> > > > regulation on
>>> > > > > top of an anemic market before waiting to see if the
>> Inter-RIR
>>> > > > policy will
>>> > > > > accelerate transfers? Only with more transfers could
>> this policy
>>> > > > make any
>>> > > > > sense at all, unless the intent is to simply strangle
>> the LACNIC
>>> > > IPv4
>>> > > > > market in its crib.
>>> > > > >
>>> > > > > Regards,
>>> > > > > Mike
>>> > > > >
>>> > > > >
>>> > > > > -----Original Message-----
>>> > > > > From: Politicas<politicas-bounces at lacnic.net> On
>> Behalf Of
>>> > JORDI
>>> > > > PALET
>>> > > > > MARTINEZ via Politicas
>>> > > > > Sent: Monday, February 03, 2020 10:43 AM
>>> > > > > To: Lista para discusion de politicas de la comunidad
>> de LACNIC <
>>> > > > >politicas at lacnic.net>
>>> > > > > Cc: JORDI PALET MARTINEZ<jordi.palet at consulintel.es>
>>> > > > > Subject: Re: [LACNIC/Politicas] Nueva propuesta
>> LAC-2020-1 / Nova
>>> > > > proposta
>>> > > > > LAC-2020-1 / New proposal LAC-2020-1
>>> > > > >
>>> > > > > Hi Mike,
>>> > > > >
>>> > > > > With all the respect, as I explained in a previous
>> email, we
>>> > can't
>>> > > > "at
>>> > > > > this time" compare the number of transfers in LACNIC vs
>> other
>>> > > regions
>>> > > > > (unless you compare them with AFRINIC only), because the
>>> > inter-RIR
>>> > > > > transfers have not been yet implemented.
>>> > > > >
>>> > > > > May be by this time, next year, when the inter-RIR
>> transfers have
>>> > > > been
>>> > > > > running for a few months (if I recall correctly, they
>> are
>>> > expected
>>> > > > to be
>>> > > > > implemented around July 2020), we can do that
>> comparison in
>>> > similar
>>> > > > terms.
>>> > > > >
>>> > > > > I also see that Carlos is right here. Let's see if the
>> staff can
>>> > > > provide
>>> > > > > some stats about how many of the resource holders
>> involve in the
>>> > 77
>>> > > > > transfers, are already doing IPv6.
>>> > > > >
>>> > > > > Regards,
>>> > > > > Jordi
>>> > > > > @jordipalet
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > El 3/2/20 16:30, "Politicas en nombre de Mike Burns" <
>>> > > > >politicas-bounces at lacnic.net en nombre
>> demike at iptrading.com>
>>> > > > escribió:
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > Hola/Olá/Hi Mike, Jordi, Fernando, ...,
>>> > > > >
>>> > > > > Parece que el comercio de direcciones no es una
>> gran cosa
>>> > > dentro
>>> > > > de la
>>> > > > > región de LACNIC!
>>> > > > >
>>> > > > >
>>> > > > > Hi Carlos,
>>> > > > >
>>> > > > > That seems to be uncontested. Thank you for
>> noticing my
>>> > post.
>>> > > > Despite
>>> > > > > proponents of this policy scaring the community, the
>> market in
>>> > > > LACNIC is
>>> > > > > the "sick man" of the IPv4 world. Nobody is acquiring
>> much IPv4
>>> > > via
>>> > > > > transfer in LACNIC, but the proponents would indicate
>> that
>>> > without
>>> > > > adding
>>> > > > > an additional burden, some entities would acquire "more
>> and more"
>>> > > > IPv4
>>> > > > > without deploying IPv6.
>>> > > > >
>>> > > > > This policy will do nothing to increase IPv4
>> because the
>>> > > > population of
>>> > > > > transferrers in this community is so small. So why make
>> it
>>> > smaller
>>> > > > still
>>> > > > > through worthless burdens for participants and for
>> LACNIC staff?
>>> > > > >
>>> > > > > There is something wrong with a group of number
>> stewards
>>> > > > aggrandizing
>>> > > > > other roles for themselves by leveraging their
>> legitimate number
>>> > > > > registration role. So we have the right to register
>> numbers, why
>>> > > > not use
>>> > > > > that to demand things from those over whom we have some
>> power?
>>> > Why
>>> > > > not
>>> > > > > mandate any IPv4 market participant must have a diverse
>> workforce
>>> > > or
>>> > > > > boardroom? Why not mandate that they should only run
>> hardware
>>> > newer
>>> > > > than
>>> > > > > five years old? Why not mandate anything we think is a
>> good
>>> > thing?
>>> > > > >
>>> > > > > Because that is not our role, and doing these
>> things work
>>> > > > directly
>>> > > > > against our role.
>>> > > > > Our primary role is to keep an accurate Whois
>> database. If
>>> > you
>>> > > > want
>>> > > > > un-recorded transfers, you are providing additional
>> incentive
>>> > with
>>> > > > this
>>> > > > > policy.
>>> > > > >
>>> > > > > The market is adaptable and will provide a
>> workaround, like
>>> > > > > out-of-region registrations and leasing, neither of
>> which this
>>> > > > community
>>> > > > > has much control over.
>>> > > > > Should this proposal pass, it will begin a
>> cat-and-mouse game
>>> > > > with
>>> > > > > network providers offering a cheap IPv6-announcement
>> service to
>>> > > jump
>>> > > > > through this hoop, and LACNIC staff trying to move the
>> hoop and
>>> > > make
>>> > > > it
>>> > > > > smaller.
>>> > > > > Pointless in terms of moving the needle on IPv6,
>> which will
>>> > > only
>>> > > > > respond to more rational inputs.
>>> > > > >
>>> > > > >
>>> > > > > Regards,
>>> > > > > Mike
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > Sería bueno saber cuántas organizaciones estaban en
>> el
>>> > extremo
>>> > > > > receptor de esas 77 transferencias.
>>> > > > >
>>> > > > > Entonces, sería bueno comprobar cuántos de ellos NO
>> están
>>> > > > haciendo
>>> > > > > ningún IPv6.
>>> > > > >
>>> > > > > No entiendo este posible nuevo requisito como una
>> carga.
>>> > > > >
>>> > > > > Por lo tanto deseo expresar pleno apoyo para 2020-1!
>>> > > > >
>>> > > > > Saludos/Cumprimentos/Regards,
>>> > > > > Carlos
>>> > > > >
>>> > > > >
>>> > > > >
>>> > > > > On Tue, 21 Jan 2020, Mike Burns wrote:
>>> > > > >
>>> > > > > > Hi Jordi,
>>> > > > > >
>>> > > > > > I hope you are well.
>>> > > > > >
>>> > > > > > LACNIC has only had 77 successful transfers in
>> its history.
>>> > > > > > Take a moment to think about that.
>>> > > > > > In the same time period ARIN and RIPE did over
>> 20,000.
>>> > > > > > And you want to impose more burdens?
>>> > > > > >
>>> > > > > > Opposed.
>>> > > > > >
>>> > > > > > Regards,
>>> > > > > > Mike
>>> > > > > >
>>> > > > > >
>>> > > > > > -----Original Message-----
>>> > > > > > From: Politicas<politicas-bounces at lacnic.net>
>> On Behalf
>>> > Of
>>> > > > JORDI
>>> > > > > > PALET MARTINEZ via Politicas
>>> > > > > > Sent: Tuesday, January 21, 2020 9:50 AM
>>> > > > > > To: Lista para discusion de politicas de la
>> comunidad de
>>> > > LACNIC
>>> > > > > ><politicas at lacnic.net>
>>> > > > > > Cc: JORDI PALET MARTINEZ<
>> jordi.palet at consulintel.es>
>>> > > > > > Subject: Re: [LACNIC/Politicas] Nueva propuesta
>> LAC-2020-1
>>> > /
>>> > > > Nova
>>> > > > > > proposta LAC-2020-1 / New proposal LAC-2020-1
>>> > > > > >
>>> > > > > > Hola Fernando, Arturo,
>>> > > > > >
>>> > > > > > El 21/1/20 15:13, "Politicas en nombre de
>> Fernando
>>> > > Frediani" <
>>> > > > >politicas-bounces at lacnic.net en nombre
>> defhfrediani at gmail.com>
>>> > > > escribió:
>>> > > > > >
>>> > > > > > Hola Arturo
>>> > > > > >
>>> > > > > > Estoy convencido de que los requisitos de
>> transferencia
>>> > NO
>>> > > > los
>>> > > > > hacen
>>> > > > > > incompatibles. Cada RIR puede tener sus
>> requisitos de
>>> > > > > transferencia. Es
>>> > > > > > precisamente por esta razón que el texto dice
>> en
>>> > > > 2.3.2.18.2: "If
>>> > > > > the
>>> > > > > > receiving organization is part of another
>> region, it
>>> > will
>>> > > be
>>> > > > > subject to
>>> > > > > > the criteria, verifications and requirements
>> of the
>>> > > > corresponding
>>> > > > > RIR.".
>>> > > > > > De lo contrario, esto texto no sería necesario
>> y todas
>>> > las
>>> > > > > políticas y
>>> > > > > > requisitos en los 5 RIR tendrían que ser
>> idénticas.
>>> > > > > >
>>> > > > > > Aunque Fernando puede tener razón, creo que se
>> presta a
>>> > > > > interpretación, ya que el punto 2.3.2.18.2 se refiere a
>> la
>>> > > > justificación de
>>> > > > > la necesidad, o al menos se lee como tal. Por ese
>> motivo, en la
>>> > > > propuesta
>>> > > > > de transferencias redactamos el punto 2.3.2.18.10. como
>> "Legacy
>>> > > > resources
>>> > > > > transferred into the LACNIC region will no longer be
>> considered
>>> > > > legacy
>>> > > > > resources.".
>>> > > > > >
>>> > > > > > Creo que es mejor evitar la duda o posibilidades
>> de
>>> > > > interpretación
>>> > > > > para no perder la reciprocidad con ARIN (creo que sería
>> el único
>>> > > > caso,
>>> > > > > salvo que la propuesta de AFRINIC que se apruebe en el
>> futuro,
>>> > haga
>>> > > > algo
>>> > > > > parecido a lo que hace ARIN).
>>> > > > > >
>>> > > > > > Es diferente, por ejemplo, de otras propuestas
>> que solo
>>> > > > preveían
>>> > > > > > transferencias unidireccionales, estos sí no
>> tendrían
>>> > > > > reciprocidad. Esta
>>> > > > > > continúa permitiendo transferencias en ambas
>>> > direcciones y
>>> > > > no
>>> > > > > cambia
>>> > > > > > nada en los requisitos de organizaciones en
>> otros RIR.
>>> > > > > >
>>> > > > > > No solo, ARIN según me consta, pide que no haya
>> otros
>>> > > aspectos
>>> > > > que
>>> > > > > les limiten a ellos. Si se interpreta (aunque no sea tu
>>> > intención,
>>> > > > que creo
>>> > > > > que no lo es), que en transferencias de LACNIC a ARIN
>> también el
>>> > > > (receptor)
>>> > > > > tiene que justificar que tiene IPv6 operativo, no sería
>>> > reciproco y
>>> > > > además
>>> > > > > es absurdo que una política de LACNIC pretenda imponer
>> reglas en
>>> > > otra
>>> > > > > región.
>>> > > > > >
>>> > > > > > Creo que está claro que esta propuesta solo
>> agrega un
>>> > > > requisito
>>> > > > > para las
>>> > > > > > transferencias IPv4 Intra o Inter RIR de las
>>> > > organizaciones
>>> > > > > *receptoras
>>> > > > > > dentro de LACNIC*, sin embargo, si es
>> necesario, podemos
>>> > > > ajustar
>>> > > > > el
>>> > > > > > texto de la propuesta a: "2.3.2.18.3 Receiving
>>> > > organization
>>> > > > in
>>> > > > > LACNIC
>>> > > > > > must have LACNIC allocated/assigned IPv6 space
>> and be
>>> > able
>>> > > > to
>>> > > > > prove it
>>> > > > > > is being used by providing LACNIC documented
>> network
>>> > > > deployment
>>> > > > > details
>>> > > > > > to prove IPv6 is operational in significant
>> parts of the
>>> > > > network."
>>> > > > > >
>>> > > > > > Perfecto! Así no hay dudas!
>>> > > > > >
>>> > > > > > Observe también que la demostración de tener
>> IPv6
>>> > > operativo
>>> > > > no
>>> > > > > presupone
>>> > > > > > simplemente subir una red IPv6 pequeña y poder
>>> > > comunicarse a
>>> > > > > través de
>>> > > > > > ella. Como dice el texto, la organización debe
>> demostrar
>>> > > > detalles
>>> > > > > de la
>>> > > > > > implementación y demostrar que IPv6 está
>> operativo *en
>>> > > > partes
>>> > > > > > significativas* de la red. Además, el staff de
>> LACNIC
>>> > > > definirá los
>>> > > > > > criterios mínimos para llevar a cabo estos
>> controles.
>>> > Por
>>> > > lo
>>> > > > > tanto, de
>>> > > > > > ninguna manera es un proceso trivial.
>>> > > > > >
>>> > > > > > Exacto y de acuerdo con ello! Evitamos entrar en
>> aspectos
>>> > > > > operacionales de la implementación de la propuesta, si
>> lo podemos
>>> > > > evitar.
>>> > > > > >
>>> > > > > > Siempre se ha hecho un proceso muy similar y
>> sigue
>>> > siendo
>>> > > > para
>>> > > > > IPv4.
>>> > > > > > Quien recibe IPv4 por primera vez o quien
>> transfiere
>>> > IPv4
>>> > > ya
>>> > > > > tiene que
>>> > > > > > demostrar, mediante documentación y otros
>> métodos, que
>>> > > > tienen la
>>> > > > > > necesidad de ese espacio. No hay mucha
>> diferencia en
>>> > hacer
>>> > > > lo
>>> > > > > mismo para
>>> > > > > > IPv6.
>>> > > > > >
>>> > > > > > Con respecto al comentario de añadir
>> operaciones a
>>> > LACNIC
>>> > > en
>>> > > > > tener que
>>> > > > > > verificar que IPv6 continúa funcionando *no es
>> el objeto
>>> > > de
>>> > > > esta
>>> > > > > > propuesta*, por lo que no se aplica.
>>> > > > > >
>>> > > > > > Así es, eso ya lo hace la propuesta que permite
>> recibir
>>> > IPv6.
>>> > > > Dice
>>> > > > > bien claro que es para usarlo, no para acumularlo sin
>> mas.
>>> > > > > >
>>> > > > > > La decisión de tener operacional o no IPv6
>> sigue siendo
>>> > > una
>>> > > > > decisión del
>>> > > > > > ISP. Esta propuesta no obliga a ninguna
>> organización a
>>> > > > > implementar el
>>> > > > > > IPv6 tan pronto como se ratifique esta
>> propuesta. Si lo
>>> > > > desea,
>>> > > > > puede
>>> > > > > > continuar otros 20 años sin IPv6.
>>> > > > > >
>>> > > > > > Estaría loco, pero es correcto.
>>> > > > > >
>>> > > > > > Lo único que hace es establecer una condición
>> que, en el
>>> > > > caso de
>>> > > > > que la
>>> > > > > > organización desee transferir más y más
>> bloques de IPv4,
>>> > > > debe
>>> > > > > demostrar
>>> > > > > > tener IPv6 operativo como una forma de
>> compromiso con
>>> > los
>>> > > > demás
>>> > > > > porque
>>> > > > > > no es solo algo privado y eso afecta solo a esa
>>> > > > organización,
>>> > > > > sino que
>>> > > > > > todos los demás que se interconectan con él en
>> este
>>> > > > ecosistema.
>>> > > > > > LACNIC no perseguirá a nadie porque esta
>> propuesta no
>>> > dice
>>> > > > que
>>> > > > > debería
>>> > > > > > ir de una organización a otra y les ordena
>> implementar
>>> > > IPv6
>>> > > > en
>>> > > > > ningún
>>> > > > > > momento.
>>> > > > > >
>>> > > > > > Y me parece lo lógico. Si pides IPv6 es para
>> utilizarlo,
>>> > sino
>>> > > > no lo
>>> > > > > pidas. Si pides IPv4 es para utilizarlo, sino no lo
>> pidas. Ahora
>>> > > > bien, como
>>> > > > > no hay mas IPv4, no pretendas recibir mas, aunque sea
>> con
>>> > > > transferencias,
>>> > > > > si no haces un esfuerzo con IPv6, porque entonces,
>> estas evitando
>>> > > > que otros
>>> > > > > que, si que lo harán, puedan obtener IPv4.
>>> > > > > >
>>> > > > > > Alguien podría aprovecharse de las transferencias
>> para
>>> > > acumular
>>> > > > > IPv4, quizás haciendo trampas en las solicitudes, para
>> luego
>>> > > > alquilarlo o
>>> > > > > volver a transferirlo, y con esta propuesta evitamos
>> ese abuso.
>>> > > > > >
>>> > > > > > Saludos
>>> > > > > > Fernando Frediani
>>> > > > > >
>>> > > > > > On 21/01/2020 06:32, Arturo Servin wrote:
>>> > > > > > > En contra de la politica.
>>> > > > > > >
>>> > > > > > > - No creo que sea necesaria
>>> > > > > > > - Dado que añade requisitos para una
>> transferencia
>>> > puede
>>> > > > hacer
>>> > > > > las
>>> > > > > > > politicas de transferencias inter-RIR
>> incompatibles (o
>>> > > mas
>>> > > > > incompatibles)
>>> > > > > > > con otros RIRs
>>> > > > > > > - No creo que ayude a acelerar la
>> implementacion de
>>> > IPv6
>>> > > > ya que
>>> > > > > es trivial
>>> > > > > > > demostrar que se usa IPv6 sin en realidad
>> tener una
>>> > > > > implementación.
>>> > > > > > > - Añade operación a LACNIC en tener que
>> verificar que
>>> > > > IPv6 siga
>>> > > > > funcionando
>>> > > > > > > en el ISP.
>>> > > > > > > - Al dia de hoy con el despliegue que existe
>> de IPv6,
>>> > es
>>> > > > en
>>> > > > > realidad una
>>> > > > > > > decision del ISP de riesgo y negocio el
>> seguir en
>>> > IPv4 y
>>> > > > no
>>> > > > > implementar
>>> > > > > > > IPv6. Es decir, no es necesario que LACNIC
>> persiga
>>> > ISPs.
>>> > > > > > >
>>> > > > > > > Saludos
>>> > > > > > > as
>>> > > > > > >
>>> > > > > > >
>>> > > > > > >
>>> > > > > > > On Mon, Jan 20, 2020 at 11:10 PM JORDI PALET
>> MARTINEZ
>>> > > via
>>> > > > > Politicas <
>>> > > > > > >politicas at lacnic.net> wrote:
>>> > > > > > >
>>> > > > > > >> Hola Fernando,
>>> > > > > > >>
>>> > > > > > >>
>>> > > > > > >>
>>> > > > > > >> El 20/1/20 22:56, "Politicas en nombre de
>> Fernando
>>> > > > Frediani" <
>>> > > > > > >>politicas-bounces at lacnic.net en nombre de
>>> > > >fhfrediani at gmail.com>
>>> > > > > escribió:
>>> > > > > > >>
>>> > > > > > >> Hola Jordi
>>> > > > > > >>
>>> > > > > > >> Gracias por tus comentarios
>>> > > > > > >> La exención para IPv6 fue colocada
>> pensando en
>>> > los
>>> > > > pocos
>>> > > > > casos que
>>> > > > > > >> ocurrirán en los que algunas upstreams
>>> > > 'retrasadas'
>>> > > > aún
>>> > > > > no tienen
>>> > > > > > >> soporte para IPv6 y esto no podría
>> dañar a una
>>> > > > > organización que se
>>> > > > > > >> encuentra en la situación de
>> transferencia
>>> > debido
>>> > > a
>>> > > > una
>>> > > > > deficiencia de
>>> > > > > > >> un tercero sobre el cual ella no tiene
>> control.
>>> > > > > > >> Sí, es cierto que esto podría tratarse
>> de otras
>>> > > > maneras,
>>> > > > > pero podría
>>> > > > > > >> generar conflictos entre el cliente y
>> el
>>> > upstream
>>> > > > y, a
>>> > > > > menudo, hay
>>> > > > > > >> contratos vigentes que deben cumplirse
>> (con o
>>> > sin
>>> > > > IPv6).
>>> > > > > La intención
>>> > > > > > >> de
>>> > > > > > >> la propuesta no es causar conflictos
>> entre
>>> > > > > organizaciones, sino solo
>>> > > > > > >> tener el compromiso de que aquellos
>> que están
>>> > > > > transfiriendo cada vez
>>> > > > > > >> más
>>> > > > > > >> IPv4 tendrán el IPv6 asignado por
>> LACNIC
>>> > operativo
>>> > > > en sus
>>> > > > > > >> organizaciones.
>>> > > > > > >> Creo que en la práctica habrá muy
>> pocos casos,
>>> > así
>>> > > > que
>>> > > > > considero justo
>>> > > > > > >> que en tales casos se pueda renunciar
>> a la
>>> > > > obligación.
>>> > > > > > >>
>>> > > > > > >> Si dejas abierta la puerta a la excepción,
>> bajo mi
>>> > > punto
>>> > > > de
>>> > > > > vista, surgen
>>> > > > > > >> mas y mas casos. No quería mencionarlo
>>> > explícitamente,
>>> > > > por
>>> > > > > aquello de no
>>> > > > > > >> hacer publicidad a nadie, pero dado que al
>> menos hay
>>> > un
>>> > > > > proveedor HE, que
>>> > > > > > >> proporciona IPv6 con túneles y con BGP, sin
>> cargo,
>>> > creo
>>> > > > que la
>>> > > > > excepción es
>>> > > > > > >> innecesaria.
>>> > > > > > >>
>>> > > > > > >> También tenga en cuenta que las
>> organizaciones
>>> > que
>>> > > > > declaran por
>>> > > > > > >> escrito
>>> > > > > > >> que no tienen IPv6 si algún día les
>> toca
>>> > > transferir
>>> > > > > direcciones IPv4,
>>> > > > > > >> pueden ser impedidas debido a este
>> hecho hasta
>>> > que
>>> > > > > demuestren que IPv6
>>> > > > > > >> ya está operativo.
>>> > > > > > >>
>>> > > > > > >> No entendí esto. Te refieres como donantes
>> o como
>>> > > > receptores?
>>> > > > > Entiendo que
>>> > > > > > >> el texto solo se refiere a receptores, pero
>> insisto
>>> > en
>>> > > > que, si
>>> > > > > el problema
>>> > > > > > >> es el upstream provider, ese problema no
>> existe en
>>> > > > realidad.
>>> > > > > > >>
>>> > > > > > >> Y que dependerá del staff de LACNIC
>> definir los
>>> > > > > requisitos mínimos,
>>> > > > > > >> que
>>> > > > > > >> pueden o no ser el caso para
>> escenarios de
>>> > > > multihoming.
>>> > > > > > >>
>>> > > > > > >> Creo que no debemos mezclar si hay o no
>> multihoming.
>>> > Si
>>> > > > hay un
>>> > > > > solo
>>> > > > > > >> proveedor de IPv6, a mi me parece
>> suficiente, haya o
>>> > no
>>> > > > haya
>>> > > > > varios
>>> > > > > > >> proveedores de IPv4.
>>> > > > > > >>
>>> > > > > > >> Con respecto a la pregunta sobre
>> afectar solo a
>>> > > los
>>> > > > ISP y
>>> > > > > no a los
>>> > > > > > >> usuarios finales, no creo que sea así
>> porque
>>> > esta
>>> > > > parte
>>> > > > > del manual se
>>> > > > > > >> aplica a cualquier organización que
>> desee
>>> > > transferir
>>> > > > > direcciones IPv4.
>>> > > > > > >> Dice el texto de la sección 2.3.2.18:
>> "*Se
>>> > > > permitirán
>>> > > > > transferencias
>>> > > > > > >> de
>>> > > > > > >> direcciones IPv4 entre LIRs y/o
>> usuarios
>>> > > > finales...*".
>>> > > > > Con respecto a
>>> > > > > > >> la
>>> > > > > > >> falta de la palabra "assigned", esto
>> se puede
>>> > > dejar
>>> > > > mas
>>> > > > > claro en una
>>> > > > > > >> nueva version. Gracias.
>>> > > > > > >>
>>> > > > > > >> Si mejor, porque en caso contrario puede
>> parecer una
>>> > > > > contradicción, aunque
>>> > > > > > >> me queda claro que tu intención es que
>> afecte a
>>> > ambos.
>>> > > > > > >>
>>> > > > > > >> Con respecto a las verificaciones
>> periódicas, no
>>> > > sé
>>> > > > si
>>> > > > > entendí
>>> > > > > > >> correctamente, pero veo que la
>> verificación debe
>>> > > > hacerse
>>> > > > > en el momento
>>> > > > > > >> de la justificación y una vez
>> aprobada, no se
>>> > > > realizarán
>>> > > > > futuras
>>> > > > > > >> verificaciones. Como analogía, tomemos
>> como
>>> > > ejemplo
>>> > > > la
>>> > > > > validación del
>>> > > > > > >> contacto de abuso, que fue una
>> discusión muy
>>> > > extensa
>>> > > > > sobre cómo se
>>> > > > > > >> podría hacer automatizado. Una
>> validación como
>>> > la
>>> > > > que
>>> > > > > usted sugiere
>>> > > > > > >> sería aún más compleja y tal vez no
>> sea muy
>>> > > > efectiva,
>>> > > > > quizás poniendo
>>> > > > > > >> una carga de trabajo muy grande en el
>> equipo de
>>> > > > LACNIC.
>>> > > > > > >>
>>> > > > > > >> Yo no lo veo así. El texto que propones no
>> busca
>>> > > > "promesas de
>>> > > > > que se va a
>>> > > > > > >> utilizar IPv6", sino que ya esta está
>> usando. Por lo
>>> > > > tanto, si
>>> > > > > esta
>>> > > > > > >> propuesta alcanza consenso y LACNIC ha
>> puesto en
>>> > marcha
>>> > > > (al
>>> > > > > implementar
>>> > > > > > >> LAC-2019-9), las verificaciones periódicas,
>> ya sabe
>>> > si
>>> > > > ese
>>> > > > > ISP/usuario esta
>>> > > > > > >> usando realmente IPv6 y por lo tanto no
>> hace falta
>>> > (en
>>> > > > > principio) mirar
>>> > > > > > >> documentación adicional (aunque la puede
>> pedir). Es
>>> > > más,
>>> > > > se
>>> > > > > puede ver el
>>> > > > > > >> historial de verificaciones periódicas
>> anteriores. Si
>>> > > el
>>> > > > > proveedor lo acaba
>>> > > > > > >> de poner en marcha, vasca con que LACNIC
>> haga "click"
>>> > > en
>>> > > > la
>>> > > > > verificación
>>> > > > > > >> automática para que se compruebe cual es el
>> estado en
>>> > > ese
>>> > > > > momento.
>>> > > > > > >>
>>> > > > > > >> Sin embargo, veo que no es algo
>> totalmente
>>> > > > irracional y
>>> > > > > quién sabe en
>>> > > > > > >> el
>>> > > > > > >> futuro que podría ser algo para
>> evaluar y el
>>> > > > resultado de
>>> > > > > una
>>> > > > > > >> propuesta
>>> > > > > > >> futura cuando, si llega a un consenso,
>> está
>>> > > > entrando en
>>> > > > > vigor.
>>> > > > > > >>
>>> > > > > > >> Saludos cordiales.
>>> > > > > > >> Fernando Frediani
>>> > > > > > >>
>>> > > > > > >> On 19/01/2020 19:23, JORDI PALET
>> MARTINEZ via
>>> > > > Politicas
>>> > > > > wrote:
>>> > > > > > >> > Hola Fernando,
>>> > > > > > >> >
>>> > > > > > >> > Mil gracias por esta propuesta. Me
>> parece muy
>>> > > > > importante y necesaria.
>>> > > > > > >> >
>>> > > > > > >> > Mis comentarios podrían variar en
>> función de
>>> > la
>>> > > > > traducción al
>>> > > > > > >> Castellano, tal y como comenté en otra
>> propuesta
>>> > > > anterior, ya
>>> > > > > que solo el
>>> > > > > > >> texto en Castellano es el oficial para el
>> manual de
>>> > > > políticas,
>>> > > > > pero supongo
>>> > > > > > >> que sería fácil resolverlo (si fuera el
>> caso) cuando
>>> > > > tengamos
>>> > > > > la traducción.
>>> > > > > > >> >
>>> > > > > > >> > Aunque no es texto de la política (y
>> por lo
>>> > > tanto
>>> > > > no
>>> > > > > podría ser
>>> > > > > > >> hecho efectivo), no estoy de acuerdo con
>> "In the case
>>> > > the
>>> > > > > receiver provides
>>> > > > > > >> a written statement from its upstream that
>> IPv6
>>> > > > connectivity is
>>> > > > > > >> unavailable, the IPv6 requirement may be
>> waived.".
>>> > > > > > >> >
>>> > > > > > >> > NO hay excusas, bajo mi punto de
>> vista, para
>>> > > > tener un
>>> > > > > upstream
>>> > > > > > >> provider que tenga soporte de IPv6, ya que,
>> si es
>>> > > > preciso, se
>>> > > > > puede usar un
>>> > > > > > >> túnel, incluso con soporte BGP. Yo he
>> trabajado en
>>> > > varios
>>> > > > > casos en los que
>>> > > > > > >> esto ocurría y siempre lo hemos podido
>> resolver, pues
>>> > > los
>>> > > > > "upstream"
>>> > > > > > >> providers del uptream provider, lo pueden
>>> > proporcionar,
>>> > > > además
>>> > > > > que hay
>>> > > > > > >> upstream providers que lo ofrecen incluso
>> sin coste.
>>> > > > > > >> >
>>> > > > > > >> > Para el texto de la propuesta, he
>> hecho un
>>> > > > diff-online
>>> > > > > que me ha
>>> > > > > > >> ayudado a revisar las diferencias y supongo
>> que puede
>>> > > > ser útil
>>> > > > > para otros:
>>> > > > > > >> >
>>> > > > > > >> >https://www.diffchecker.com/MaapyXNc
>>> > > > > > >> >
>>> > > > > > >> > Creo que hay algo que debemos
>> considerar, y es
>>> > > > que tal
>>> > > > > y como esta
>>> > > > > > >> redactada la propuesta solo afectaría a los
>> ISPs
>>> > > > > (allocations), y no a los
>>> > > > > > >> end-users (assignments). Creo que esto no es
>>> > correcto y
>>> > > > > debería ser igual
>>> > > > > > >> para ambos.
>>> > > > > > >> >
>>> > > > > > >> > Por lo tanto, sugiero este cambio,
>> que también
>>> > > > tiene en
>>> > > > > cuenta mi
>>> > > > > > >> comentario anterior de los upstream
>> providers así
>>> > como
>>> > > > que en
>>> > > > > lugar de
>>> > > > > > >> documentación, creo que el staff puede usar
>> la recién
>>> > > > aprobado
>>> > > > > política
>>> > > > > > >> LAC-2019-9 para hacer esas verificaciones
>> de forma
>>> > > > > automatizada y por tanto
>>> > > > > > >> evitar la necesidad de generar documentación
>>> > adicional
>>> > > o
>>> > > > de
>>> > > > > revisarla, a
>>> > > > > > >> ambas partes, en los casos en los que sea
>> obvio que
>>> > hay
>>> > > > > despliegue real de
>>> > > > > > >> IPv6.
>>> > > > > > >> >
>>> > > > > > >> > 2.3.2.18.3 Receiving organization
>> must have
>>> > > LACNIC
>>> > > > > > >> allocated/assigned IPv6 space and be able
>> to prove it
>>> > > is
>>> > > > being
>>> > > > > used by
>>> > > > > > >> providing LACNIC documented network
>> deployment
>>> > details
>>> > > to
>>> > > > > prove IPv6 is
>>> > > > > > >> operational in significant parts of the
>> network.
>>> > > > > > >> >
>>> > > > > > >> > Regular LACNIC periodical
>> verification (7.1)
>>> > > will
>>> > > > be
>>> > > > > used to assess
>>> > > > > > >> that IPv6 is operational, and if necessary,
>> the staff
>>> > > may
>>> > > > > require further
>>> > > > > > >> information to validate this requirement.
>>> > > > > > >> >
>>> > > > > > >> >
>>> > > > > > >> >
>>> > > > > > >> > Saludos,
>>> > > > > > >> > Jordi
>>> > > > > > >> > @jordipalet
>>> > > > > > >> >
>>> > > > > > >> >
>>> > > > > > >> >
>>> > > > > > >> > El 17/1/20 17:47, "Politicas en
>> nombre de
>>> > > > Fernando
>>> > > > > Frediani"<
>>> > > > > > >>politicas-bounces at lacnic.net en nombre de
>>> > > >fhfrediani at gmail.com>
>>> > > > > escribió:
>>> > > > > > >> >
>>> > > > > > >> > Hola a todos.
>>> > > > > > >> >
>>> > > > > > >> > Dos aclaraciones:
>>> > > > > > >> >
>>> > > > > > >> > - El cambio principal en el
>> texto
>>> > propuesto
>>> > > > se
>>> > > > > encuentra en el
>>> > > > > > >> ítem
>>> > > > > > >> > 2.3.2.18.3. Todos los demás
>> elementos
>>> > > > siguientes
>>> > > > > permanecen sin
>>> > > > > > >> cambios
>>> > > > > > >> > y solo se vuelven a numerar al
>> número
>>> > > > siguiente .
>>> > > > > > >> > - La forma en que se analizará
>> esto no es
>>> > > > > diferente de lo que
>>> > > > > > >> se ha
>>> > > > > > >> > hecho para la justificativas de
>>> > > asignaciones
>>> > > > de
>>> > > > > IPv4 a lo largo
>>> > > > > > >> de los
>>> > > > > > >> > años. El staff de RIR/NIR de la
>> misma
>>> > > manera
>>> > > > > revisará las
>>> > > > > > >> > justificaciones y también
>> establecerá los
>>> > > > > criterios mínimos
>>> > > > > > >> para esto.
>>> > > > > > >> >
>>> > > > > > >> > Saludos cordiales
>>> > > > > > >> > Fernando Frediani
>>> > > > > > >> >
>>> > > > > > >> > On 17/01/2020 13:15,
>>> > > >info-politicas at lacnic.net
>>> > > > > wrote:
>>> > > > > > >> > > [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
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
More information about the Politicas
mailing list