[LACNIC/Politicas] Nueva propuesta LAC-2020-1 / Nova proposta LAC-2020-1 / New proposal LAC-2020-1
Arturo Servin
arturo.servin at gmail.com
Tue Feb 4 12:01:20 GMT+3 2020
De acuerdo 100% con Jorge.
Lo importante es mantener el registro de las transferencias.
El tema de IPv6 y quien tiene acceso al recurso es un tema de mercado que
no vamos a resolver con esta politica.
Saludos,
as
On Mon, Feb 3, 2020 at 11:25 PM Jorge Villa <villa at reduniv.edu.cu> 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 de arturo.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 de
> arturo.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 de
> mike 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 de
> fhfrediani 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 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
> > > > > ainfo-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
> > > > > > >> contactinfo-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
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> **********************************************
> > > > > > >> > IPv4 is over
> > > > > > >> > Are you ready for the new Internet ?
> > > > > > >> > http://www.theipv6company.com
> > > > > > >> > The IPv6 Company
> > > > > > >> >
> > > > > > >> > This electronic message contains
> information
> > > > which may
> > > > > be privileged
> > > > > > >> or confidential. The information is intended
> to be
> > for
> > > > the
> > > > > exclusive use of
> > > > > > >> the individual(s) named above and further
> > > non-explicilty
> > > > > authorized
> > > > > > >> disclosure, copying, distribution or use of the
> > > contents
> > > > of
> > > > > this
> > > > > > >> information, even if partially, including
> attached
> > > > files, is
> > > > > strictly
> > > > > > >> prohibited and will be considered a criminal
> offense.
> > > If
> > > > you
> > > > > are not the
> > > > > > >> intended recipient be aware that any
> disclosure,
> > > copying,
> > > > > distribution or
> > > > > > >> use of the contents of this information, even
> if
> > > > partially,
> > > > > including
> > > > > > >> attached files, is strictly prohibited, will be
> > > > considered a
> > > > > criminal
> > > > > > >> offense, so you must reply to the original
> sender to
> > > > inform
> > > > > about this
> > > > > > >> communication and delete it.
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > > > > > >> >
> > _______________________________________________
> > > > > > >> > Politicas mailing list
> > > > > > >> > Politicas at lacnic.net
> > > > > > >> >
> > >
> _______________________________________________
> 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