[LACNIC/Politicas] Nueva propuesta LAC-2020-1 / Nova proposta LAC-2020-1 / New proposal LAC-2020-1
Jorge Villa
villa at reduniv.edu.cu
Mon Feb 3 19:24:41 GMT+3 2020
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
More information about the Politicas
mailing list