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