[LACNIC/Politicas] Nueva propuesta LAC-2020-1 / Nova proposta LAC-2020-1 / New proposal LAC-2020-1
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Tue Feb 4 17:03:25 GMT+3 2020
Hola Oscar,
Entiendo que te refieres a la propuesta del asunto (no a mi propuesta respondiendo a Nico), y por tanto a Fernando.
Sin embargo, bajo mi punto de vista, ha quedado claro muchas veces, y no hay mas que repasar el manual de políticas (de cualquier RIR), que nuestro rol (como comunidad "cliente" del PDP) no es exclusivamente técnico.
No pretendo generar un nuevo hilo de debate al respecto de este punto, pienso que ya lo hemos discutido en otras ocasiones y no merece la pena darle mas vueltas. La importancia radica en que, si solo fuera técnico, es relativamente sencillo definir el problema, pero no siempre lo es en otros casos, y de hecho el PDP no lo pide.
En este caso concreto (y bajo mi punto de vista, no como autor, eso se lo dejo a Fernando), yo si que veo que puede ser un problema que se interprete el hecho de tener transferencias como la solución (posiblemente desde el punto de vista de algunos ejecutivos, creo que los técnicos tenemos claro que no es el caso), y por tanto la "no-necesidad" de IPv6 (o su baja prioridad).
Al mismo tiempo, como he indicado en emails anteriores, el hecho de que haya un recurso escaso "es un problema", y una distribución desequilibrada de los "sobrantes" del mismo "es un problema", al igual que "es un problema" que los mas poderosos, porque pueden pagar mas por esos "sobrantes", creen esos desequilibrios y dificulten o demoren el despliegue de IPv6.
No son problemas técnicos, sino "políticos", o si son problemas técnicos porque el incremento del uso de IPv4 y prolongar artificialmente con CGN su longevidad, si son problemas?
Creo que es difícil no estar de acuerdo con esos "problemas", pero para gustos colores! Totalmente de acuerdo, en que si podemos articular esos "problemas" en la parte de "justificación" de la propuesta (la leí cuando se publico, así que no recuerdo de memoria si esta claramente articulado en este sentido o en otros), mucho mejor.
Sin embargo, recuerdo que cuando he trabajado en las últimas propuestas, se me limitaba (a pesar de que el PDP no lo hace), el texto que podía poner en las diversas secciones del formulario. A veces hace falta mas texto, otras menos, pero creo que no debe limitarse, y menos si pedimos claridad en especificar el problema o problemas, que pueden requerir "ejemplos y mas ejemplos", y por lo tanto "texto y mas texto".
Saludos,
Jordi
@jordipalet
El 4/2/20 20:25, "Oscar A. Robles-Garay" <oscar at lacnic.net> escribió:
Hola a todos,
Sin ánimo de interferir en el trabajo de los moderadores, les recuerdo
que un aspecto que surgió al menos en un par de ocasiones durante los
foros del año pasado fue que el problema a resolver no estaba claramente
identificado/definido en algunas propuestas de políticas.
Creo que, considerando nuestro rol técnico, esto tendría que ser un
elemento escencial de nuestras conversaciones. Es imposible que podamos
resolver un problema de manera adecuada o consensuada si no somos claros
en la definición del problema.
Sería deseable, además, que la comunidad estuviera de acuerdo que dicho
problema es un tema prioritario a resolverse. Por más que todas las
soluciones "sumen", finalmente deben pasar por un filtro de sensatez y
de impacto real (costo/beneficio), no sólo en la implementación sino en
el impacto para toda la comunidad.
Específicamente en esta propuesta, como staff, quisiéramos conocer la
respuesta a la pregunta que hace Arturo Servin, cuál es el problema a
resolver? (respondido por el autor) con ello nuestro análisis puede ser
más preciso y la comunidad podrá manifestarse de manera más puntual.
Saludos,
Oscar
On 2/4/20 15:47, JORDI PALET MARTINEZ via Politicas wrote:
> Entonces tendremos que eliminar de la faz de la tierra a los políticos, que mucho mas que nosotros, se dedican a eso … tengo claro que luego voy yo y luego todos los demás autores de políticas en todos los RIRs!
>
>
>
> ;-)
>
>
>
> Si no arreglamos las cosas con políticas, no necesitamos un PDP, ni probablemente un RIR.
>
>
>
> Saludos,
>
> Jordi
>
> @jordipalet
>
>
>
>
>
>
>
> El 4/2/20 19:14, "Arturo Servin" <arturo.servin at gmail.com> escribió:
>
>
>
>
>
> 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
>
>
>
> **********************************************
> 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
> 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.
More information about the Politicas
mailing list