[LACNIC/Politicas] Nueva propuesta LAC-2020-1 / Nova proposta LAC-2020-1 / New proposal LAC-2020-1
Fernando Frediani
fhfrediani at gmail.com
Thu Feb 6 16:09:22 GMT+3 2020
Hi Albert
The idea in the propose is not simply that some organization be able to
communicate to some destination via IPv6 of the allocation or
assignment. This would be very easy to circumvent the requirement just
by announcing to the Internet and bringing up a /64 network with a few
hosts and the requirement would become useless. As the text mentions the
organization will also have to provide documented network deployment to
prove IPv6 is really operational there. The minimal criteria will be
defined by LACNIC and will apply according to the size and complexity of
the organization involved. Of course what you suggest below could be one
of the requirements should LACNIC staff find it necessary, but certainly
not the only one. And LACNIC can have their own tools to help validate
the information where possible.
As I have been saying this is no different than what has always been
done by anyone that must justify IPv4 usage in order to receive a new
allocation or do transfers.
Fernando
On 06/02/2020 15:02, hostmaster at uneedus.com wrote:
> I think this kinda depends on what way LACNIC chooses to test if you
> have IPv6 active.
>
> The easiest way would be the LACNIC website itself. Place IPv4 only
> and IPv6 only elements in the code, and look through the logs to
> ensure that both elements came from the LACNIC assigned addresses for
> that entity. If they host their assigned IPv6 with someone else, and
> continue to run an IPv4 network, odds are even if they pay for this
> hosting, the IPv6 only
> elements in the page will not be fetched, giving away this ruse.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
> On Wed, 5 Feb 2020, Arturo Servin wrote:
>
>> 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
>>>
>> _______________________________________________
>> 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