[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 16:03:27 GMT+3 2020
Si tu politica busca equidad te tengo una mala notiica. No lo va a lograr.
El que tiene los medios para pagar 20 o 30 dolares por IP tiene los medios
para hacer parecer que tiene IPv6 sin tenerlo.
O medio desplegar IPv6 para que parezca que funciona y cumplir con el
requisito.
Saludos,
as
On Wed, Feb 5, 2020 at 6:55 PM Fernando Frediani <fhfrediani at gmail.com>
wrote:
> Nicolas, el ejemplo funciona para ambos casos. Las obligaciones no
> cambian si usted es un proveedor de servicios o contenido.
> Un usuario de banda ancha que necesita comunicarse con otro usuario de
> banda ancha también significa más contenido disponible solo en IPv4. Fue
> un ejemplo para responder a su pregunta de manera simples sobre cómo
> agrava el problema.
>
> Todavía no tenemos suficientes datos para las transferencias Inter-RIR.
> Basado en otros RIR es posible tener una idea, pero cualquier impacto
> que haga si es posible es beneficioso.
>
> La justificación para las transferencias de IPv4 siempre ha afectado las
> transferencias y nunca ha sido cuestionada como un problema o un
> impedimento porque es justo.¿Por qué sería un problema en este caso?
> Para que haya temor a algo que es poco probable que suceda, una
> hipótesis menos probable, e *incluso si sucede, es justo para todos los
> demás* que la transferencia no se pueda procesar porque no hay una
> contraparte de alguien que está empeorando para todos lo demás.
>
> Fernando
>
> On 05/02/2020 14:34, Nicolas Antoniello wrote:
> > Fernando,
> >
> > Yo creo que la gran mayoría de quienes reciben transferencias (compran
> > direcciones) no son proveedores de contenido sino prestadores de servicio
> > de conectividad. No creo que muchos proveedores de contenido utilicen o
> > deban recurrir a CGN pues en comparación con un ISP, los proveedores de
> > contenido no son intensivos en el uso de IPs.
> >
> > Por eso, me parece que el impacto de esta propuesta es ínfimo (sumado a
> que
> > las transferencias representan una mínima parte de los Miembros)...
> > entonces dado que considero que ese impacto es mínimo y que
> potencialmente
> > puede “afectar” el registro de las trasferencias, es que en mi opinión no
> > es necesaria la política.
> > No se trata se que sea una mala política, pero que tenga algún beneficio
> no
> > creo que sea razón suficiente (si necesaria, pero no suficiente) para que
> > debamos tenerla.
> >
> > Abrazo,
> > Nico
> >
> >
> >
> >
> >
> >
> >
> > El El mié, feb. 5, 2020 a la(s) 12:25, Fernando Frediani <
> > fhfrediani at gmail.com> escribió:
> >
> >> Hola
> >>
> >> ¿Estamos de acuerdo en que en la actualidad ya no es posible para
> >> aquellas organizaciones que necesitan más IPv4 para conectar a más
> >> personas a Internet o hacer crecer sus negocios que lo hagan en igualdad
> >> de condiciones con los demás?
> >> Solo aquellos que pueden pagar una cantidad sustancial pueden hacerlo,
> >> por un recurso que no es de propiedad privada o un bien de producción.
> >> Para aquellos que necesitan y no pueden pagar, solo hay una opción:
> IPv6.
> >> Pero no es suficiente que aquellos que solo tienen IPv6 como opción lo
> >> implementen, después de todo, estamos en un ecosistema de interconexión.
> >>
> >> Cuando alguien realiza más y más transferencias de IPv4 sin tener IPv6
> >> operativo, pone disponible más contenido disponible solo en IPv4 y hace
> >> que sea más difícil para aquellos que no tienen las mismas condiciones
> >> de adquirir más espacio IPv4 al tener que invertir en tecnologías más
> >> costosas, complejas y problemáticas como CGNAT y similares. También sin
> >> una contraparte, hace que el costo de hacer estas transferencias sea
> >> cada vez más alto para todos los demás.
> >>
> >> No hay equilibrio, no hay equidad y no hay sostenibilidad en tal
> >> escenario, solo empeoran las desigualdades, aumentan los costos para
> >> aquellos que hacen su tarea y despliegan IPv6 correctamente, debido a la
> >> acción de un tercero.
> >>
> >> Creo que ya es posible comprender el daño a todos los demás a medida que
> >> se realizan más transferencias sin ninguna contraparte.
> >>
> >> Las transferencias no están permitidas solo para mantener actualizado el
> >> registro, esta es una consecuencia lógica de las transferencias. Las
> >> transferencias están permitidas porque es una necesidad para una gran
> >> parte de las organizaciones para lidiar con el problema de la
> >> imposibilidad para IANA y RIRs de proporcionar más direcciones y también
> >> para dar un mejor equilibrio de uso a las direcciones asignadas pero no
> >> utilizadas. Si reconocemos el problema al permitir transferencias (lo
> >> cual es justo para aquellos que las necesitan), ¿por qué es diferente
> >> que también lo reconozcan al pedir la contraparte necesaria para el
> >> momento actual?
> >>
> >> Honestamente, como dije en varios otros mensajes, lo que propone esta
> >> propuesta no es algo complejo o inalcanzable, especialmente a mediados
> >> de 2020. No hay mucha más justificación para decir que es imposible
> >> tener IPv6 operativo cuando se exige, especialmente en esta situación
> >> particular. Pensar que alguien no poder demostrar IPv6 operacional como
> >> una razón para ser contrario este requisito sería tratar la regla por la
> >> rara excepción.
> >>
> >> Saludos e gracias por los comentarios.
> >> Fernando Frediani
> >>
> >> On 04/02/2020 20:05, Nicolas Antoniello wrote:
> >>> Hola Fernando,
> >>>
> >>> Gracias por los comentarios.
> >>> Siguiendo el hilo del problema que se busca resolver entiendo entonces
> >> que
> >>> es una compensación por el perjuicio que las transferencias IPv4
> provocan
> >>> al agravar el problema de agotamiento?
> >>>
> >>> En esa misma línea y si lo que interpreto es correcto, te consulto en
> que
> >>> aspecto o aspectos te parece que se agrava el problema de agotamiento
> de
> >>> IPv4 con las transferencias. De hecho, si alguien tiene dinero y quiere
> >>> gastarlo en más direcciones IPv4, eso le evita solicitar bloques de lo
> >>> reservado para IPv4 al RIR. Por lo que sigo sin visualizar que las
> >>> transferencias agraven el problema del agotamiento de IPv4 y la
> relación
> >> de
> >>> compensación con la exigencia de IPv6.
> >>>
> >>> Nuevamente, si el objetivo fuera acelerar el despliegue de IPv6 (que me
> >>> parece que quedó claro que no lo es según lo que interpreto de tu
> texto),
> >>> no veo que la propuesta así como está sea efectiva.
> >>>
> >>> Por ultimo, yo creo que si, que el principal y prácticamente único
> motivo
> >>> de habilitar las transferencias es mantener el Registro vigente e
> >> íntegro.
> >>> El resto creo que es bastante anecdótico y que no hay mucha capacidad
> de
> >>> exigir compensaciones (me conformo bastante con que cumplan las
> políticas
> >>> de transferencias). Y no me gustaría que la incapacidad o insuficiencia
> >> de
> >>> -demostrar- operación de IPv6 sea un impedimento para que las
> >>> transferencias sean registradas (ese es uno de los riesgos que le veo a
> >>> esta propuesta).
> >>>
> >>> Saludos,
> >>> Nico
> >>>
> >>>
> >>>
> >>> El mar., 4 de feb. de 2020 a la(s) 17:15, Fernando Frediani (
> >>> fhfrediani at gmail.com) escribió:
> >>>
> >>>> 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 nombredearturo.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
> >>>>>>> > >
> > _______________________________________________
> > 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