[LACNIC/Politicas] Nueva propuesta LAC-2020-1 / Nova proposta LAC-2020-1 / New proposal LAC-2020-1
Daniel Damito
contato at danieldamito.com.br
Thu Feb 6 13:36:57 GMT+3 2020
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*
More information about the Politicas
mailing list