[LACNIC/Politicas] Nueva propuesta LAC-2020-1 / Nova proposta LAC-2020-1 / New proposal LAC-2020-1
Fernando Frediani
fhfrediani at gmail.com
Wed Feb 5 14:55:12 GMT+3 2020
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
More information about the Politicas
mailing list