[LACNIC/Politicas] Nueva propuesta LAC-2020-1 / Nova proposta LAC-2020-1 / New proposal LAC-2020-1
Arturo Servin
arturo.servin at gmail.com
Mon Feb 3 18:29:42 GMT+3 2020
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
> > > > > >> >
> >
More information about the Politicas
mailing list