[LACNIC/Politicas] Nueva propuesta LAC-2020-1 / Nova proposta LAC-2020-1 / New proposal LAC-2020-1
Carlos Friaças
cfriacas at fccn.pt
Thu Feb 6 13:50:44 GMT+3 2020
Hi,
(english this time, and short)
100% agree with Daniel.
For me, the problem that this proposal tries to solve (within LACNIC,
but the problem is common to other regions...) is the complete refusal by
some players (which are also active in the transfer market) to deploy
IPv6.
Regards,
Carlos
On Thu, 6 Feb 2020, Daniel Damito wrote:
> A transferência de recursos IPv4 acontece porque a parte que recebe
> necessita de mais endereços.
> Se ela necessita de mais endereços IPv4, é esperado que ela já tenha
> cumprido a sua obrigação moral de ter o IPv6 operacional.
> Não existem hoje mais argumentos plausíveis para que uma rede tenha apenas
> IPv4. Ainda que esta rede tenha problemas com IPv6 em alguns segmentos, é
> esperado que ela tenha IPv6 em vários outros, visto que o protocolo existe
> há mais de 20 anos, é o protocolo oficial desde 2012 e é amplamente
> suportado em roteadores, switchs e CPEs. Por isso não existem mais
> barreiras para não conseguir demonstrar o uso do IPv6.
>
> A não adoção do IPv6 é um problema coletivo, e não individual, visto que
> obriga que toda a Internet mantenha compatibilidade com as duas famílias de
> protocolo - o que gera muito mais custo operacional e financeiro para todas
> as organizações.
>
> Portanto é justa essa contrapartida pedida para que as transferências de
> IPv4 exijam a comprovação de que o IPv6 está operacional.
>
> Em qua., 5 de fev. de 2020 às 16:04, Arturo Servin <arturo.servin at gmail.com>
> escreveu:
>
>> 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
>>
>
>
> --
>
> *Atenciosamente,Daniel Damito*
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>
More information about the Politicas
mailing list