[LACNIC/Politicas] Nueva propuesta LAC-2020-1 / Nova proposta LAC-2020-1 / New proposal LAC-2020-1
Arturo Servin
arturo.servin at gmail.com
Tue Feb 4 14:24:56 GMT+3 2020
Y seguimos tratando de arreglar al mundo con políticas ...
Por favor no.
Saludos
On Tue, 4 Feb 2020, 16:17 JORDI PALET MARTINEZ via Politicas, <
politicas at lacnic.net> wrote:
> Hola Nico,
>
> Adelante, mañana mismo la presento!
>
> Que plazo crees que es adecuado?
>
> O quizás debemos marcar un % de despliegue y diversos plazos, algo así
> como:
>
> (por simplicidad, plazos contados en meses naturales contando desde el
> siguiente inmediato al de la ratificación de la política, y aplica a todos
> los usuarios finales e ISPs de LACNIC)
>
> 1) Tras 3 meses, deben haber obtenido el prefijo IPv6 que les corresponda.
> 2) Tras 6 meses, dicho prefijo tiene que estar siendo anunciado de forma
> estable.
> 3) Tras 9 meses, se debe demostrar que la infraestructura de la red tiene
> IPv6 desplegado.
> 4) Tras 12 meses, las conexiones con los caches/CDNs/IXs, deben tener IPv6.
> 5) Tras 18 meses, se debe demostrar que al menos el 10% del tráfico de la
> red es IPv6.
> 6) Tras 24 meses, se debe demostrar que al menos el 25% del tráfico de la
> red es IPv6.
> 7) Tras 30 meses, se debe demostrar que al menos el 50% del tráfico de la
> red es IPv6.
> 8) Tras 36 meses, se debe demostrar que al menos el 75% del tráfico de la
> red es IPv6.
>
> Creo que son plazos muy razonables, y suficientemente holgados.
>
> Saludos,
> Jordi
> @jordipalet
>
>
>
> El 4/2/20 16:07, "Politicas en nombre de Nicolas Antoniello" <
> politicas-bounces at lacnic.net en nombre de nantoniello at gmail.com> escribió:
>
> 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 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
> > 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
>
More information about the Politicas
mailing list