[LACNIC/Politicas] Nueva versión de la propuesta LAC-2020-1

Tue May 11 09:36:35 -03 2021

Olá, primeiramente peço desculpas pela interação tardia nesta discussão.

Eu vejo que o maior temor desta proposta é que ela possa dificultar o
acesso aos recursos de numeração para certas empresas, um argumento do qual
discordo pois:

1) Temos diversos projetos e cursos gratuitos sobre adoção do IPv6. Cursos
disponíveis em diversos idiomas, oferecidos por organizações privadas e
também públicas;

2) A proposta prevê mecanismos para que, em casos excepcionais, a
comprovação do uso do IPv6 seja dispensada;

3) Um sistema autônomo é capaz de gerir um ambiente complexo, composto por
roteamento estático, BGP e demais atividades fins da empresa. Ora, exigir a
adoção do IPv6 não é uma atividade atípica. Uma organização que se propõe a
gerenciar um AS deve ser capaz de operar seus recursos de numeração com um
bom padrão de qualidade, de modo a favorecer a qualidade, segurança e
desenvolvimento contínuo da Internet como um todo.

Além disso, esta proposta indiretamente também ajudará a reduzir os
incidentes onde as autoridades policias não conseguem identificar os
assinantes responsáveis por delitos cometidos por meios digitais devido ao
CGNAT. Ainda que leis como o Marco Civil da Internet do Brasil legisgem
sobre isso, existem barreiras que dificultam a ação policial, como quando o
ISP guarda as logs de IP de origem + porta, porém a polícia só tem em mãos
o IP de origem do crime cibernético.

Em resumo, estimular de forma mais severa o uso do IPv6 não trará apenas
enormes benefícios técnicos, como também tornará a Internet um ambiente
ainda mais seguro para nós, nossos filhos e toda a comunidade.

Em qui., 22 de abr. de 2021 às 12:35, Fernando Frediani <
fhfrediani at gmail.com> escreveu:

> Buenos dias Miguel
>
> Menciono el miedo a lo desconocido en base a algunas manifestaciones que
> tuvimos al cuestionar la efectividad de la propuesta y los "posibles
> efectos que podría causar", todo, en mi opinión, basado en temores y
> sospechas inverosímiles, quizás sobrestimando los efectos negativos de
> esta propuesta.
>
> El precedente para entrar en ciertas cuestiones operativas ya existe y
> es normal que exista porque es necesario que para poder participar en un
> sistema de interconexión que es la Internet y también aceptar ciertas
> justificaciones para IPv4, sea necesario tener en cuenta protocolos y
> estándares operativos (ver mensaje que cita diferentes puntos existentes
> del Manual de Políticas) y de la misma manera la necesidad de demostrar
> que IPv6 operacional se ajusta a los demás. Sin embargo, se refuerza
> que
> este tipo de requisitos para IPv6 no se pueden confundir con otros
> requisitos que son solo buenas prácticas, que son opcionales para cada
> organización.
>
> No creo que esta propuesta sea coercitiva, solo requiere el cumplimiento
> de un estándar necesario para la continuidad del desarrollo y en
> beneficio de todos. IPv6 es la condición 'sine qua non' para este
> desarrollo. Y más que eso, para reducir los problemas y los aumentos
> de
> costos causados por la escasez.
> Pero supongamos por un momento que hay algo coercitivo, crees que hay
> escenarios donde es necesario y justificado en beneficio de la mayoría y
> para el mantenimiento de un estándar. Para ilustrar en el manual de
> políticas, existen requisitos con respecto al uso de recursos que, si no
> se cumplen, pueden conducir a la revocación. Esto también podría
> denominarse 'coercitivo' y de hecho no es más que un requisito necesario
> para asegurar que los recursos se utilicen siempre de forma justa para
> todos, independientemente de las particularidades y cuestiones
> operativas de cada organización.
>
> Gracias por la cuestiones.
> Saludos
> Fernando Frediani
>
> On 22/04/2021 11:40, Miguel A. Brante wrote:
> > Hola Fernando, cómo estas?
> >
> > Creo que es importante aclarar un par de cosas, porque me doy cuenta que
> se están malentendiendo algunos argumentos. Acá algunas consultas,
> comentarios y preguntas:
> >
> > -Porque nombras el "miedo a la desconocido"?
> >
> > "raising points which I believe are invalid like that the RIR
> > doesn't have the power to make this requirement while there are several
> > others in place already for a long time."
> >
> > - La mayor parte de los argumentos sobre este punto es que al RIR "No
> debería / Should not" tener tales atribuciones o "poder", porque entraría a
> interferir en las deciones internas del AS, por lo tanto  no le compete.
> > Ahora, si esta política es aceptada, marcaría un mal precedente, ya que
> así como primero se impone una cosa, luego se podrá imponer otra, y así
> sucesivamente.
> >
> >
> > "One last thing is that this proposal is NOT against the transfer of the
> > IPv4. It completely understandable that organization still need to keep
> > going, but rather it just request a counterpart from those in such
> > situations."
> >
> > - Estoy casi seguro que nadie ha argumentado que esta propuesta está
> en contra de la transferencia de IPv4, sino que impone una acción que se
> considera según algunos puntos de vista, coercitiva.
> >
> > - Toda tu argumentación sobre los problemas con IPv4 creo que son
> válidos, sin embargo soy enfático en decir que no comparto la forma en que
> se plantea "ayudar" a solventar dichos problemas.
> >
> >
> > Saludos!
> >
> > Miguel Brante
> >
> >
> > ----- Mensaje original -----
> > De: "Fernando Frediani" <fhfrediani at gmail.com>
> > Para: "Lista para discusion de politicas de la comunidad de LACNIC" <
> politicas at lacnic.net>
> > Enviados: Miércoles, 21 de Abril 2021 14:54:53
> > Asunto: Re: [LACNIC/Politicas]  Nueva versión de la propuesta LAC-2020-1
> >
> > Hello Albert
> > Thanks for sharing these very good points about the need of this
> proposal.
> >
> > Unfortunately there is still people with the fear of the unknown to
> > oppose raising points which I believe are invalid like that the RIR
> > doesn't have the power to make this requirement while there are several
> > others in place already for a long time.
> >
> > But the main point I believe is the sustainability and continuous
> > development of this very same Internet ecosystem we are all in. The lack
> > of keep requiring nothing and keep us in the same situation we have been
> > for a couple of years, with the aggravating that this is causing this is
> > causing damage to a growing number of organizations that either have to
> > spend a lot of more resources in order to cope with the problems caused
> > by others who keep flying the flag of "my network, my rules" ignoring
> > the fact that in order to live in a interconnected environment you must
> > abide to certain rules, standards and usage of protocols.
> >
> > One last thing is that this proposal is NOT against the transfer of the
> > IPv4. It completely understandable that organization still need to keep
> > going, but rather it just request a counterpart from those in such
> > situations.
> >
> > Regards
> > Fernando
> >
> > On 21/04/2021 13:04, hostmaster at uneedus.com wrote:
> >> I have a harder time keeping up with this discussion, since I am not a
> >> native speaker of Spanish, and rely on translation tools. Nearly all
> >> discussion up to this point has been in Spanish.
> >>
> >> I speak in favor of the proposal and move its adoption.
> >>
> >> I proposed a similar proposal in the ARIN region, and do believe that
> >> the time has long since arrived for parties that receive transferred
> >> IPv4 addresses be able to use what will clearly become the protocol of
> >> the future, which is IPv6.  Ten years ago in Miami is when the last
> >> /8's of IPv4 were given out to the 5 RIR's, so this issue is clearly
> >> timely.
> >>
> >> A lot of incumbent network operators have a "my network, my rules"
> >> policy, and they are perfectly happy to keep running only IPv4
> >> forever. However that hand dragging on IPv6 adoption, causes a
> >> worldwide issue for all the networks that have adopted IPv6 because of
> >> its lack of address space, and the many whose networks are now mostly
> >> IPv6.
> >>
> >> These operators would like the day of finally being able to sunset our
> >> IPv4 networks and get back to running only one protocol.  Many major
> >> networks have already adopted IPv6 internally, and ONLY run IPv4 at
> >> the edge.  Devices like CGnat are expensive to run and require logging
> >> to meet CALEA requirements.  High IPv6 adoption will bring the day
> > of
> >> that sunset closer, and policies that drag that date further into the
> >> future are wrong.
> >>
> >> RIR's clearly have the power to set reasonable conditions on
> >> transfers. Some things that we require that are not contested are
> >> paying your fees and keeping up proper contact information.
> >>
> >> I see being able to communicate using IPv6, which is rapidly becoming
> >> the majority of traffic at many exchange points is not an unreasonable
> >> requirement.  Of course, there does exist parts of the world where
> >> IPv6 is not available and thus the exception which is provided in the
> >> proposal.
> >>
> >> I say it is about time, and see no issue in saying to someone that if
> >> you want to get more IPv6 address space via transfer, that it is about
> >> time that you step up to the future, which is IPv6.
> >>
> >> There has also been a discussion regarding copyrighted ideas being
> >> part of this proposal.  In every nation I am aware of, ideas cannot be
> >> copyrighted, but only a specfic expression of ideas. Clearly the idea
> >> that RIR's should adopt a policy to require use of IPv6 before
> >> authorizing transfer of more IPv4 to that entity is not a protected
> idea.
> >>
> >> I am the author of what I think was the first proposal to do this in
> >> the ARIN region, and by no means do I consider this proposal a
> >> copyright violation of that idea.  Only expression is protected, not
> >> the underlying idea, and I see this proposal as needed as a stick to
> >> get those IPv4 operators to make the right choice for everyone on the
> >> internet.
> >>
> >> Albert Erdmann
> >> Network Administrator
> >> Paradise On Line Inc.
> >>
> >> On Tue, 13 Apr 2021, Fernando Frediani wrote:
> >>
> >>> Hola
> >>>
> >>> Jorge - No hay problema en agregar este requisito para que sea
> >>> posible permitir la transferencia dadas las justificaciones que ya se
> >>> han presentado en varios mensajes anteriores.
> >>> En cuanto al argumento de que las transferencias se realizan "fuera
> >>> del registro", ya se ha explicado muchas veces en los mensajes
> >>> anteriores cómo esta no puede considerarse una objeción válida ya que
> >>> existen suficientes garantías para mitigar este temor que está
> >>> presente en cualquier otra propuesta.
> >>>
> >>> Hernán - No sé qué datos está buscando, pero ya se
> > han presentado
> >>> varios escenarios de la vida real y ejemplos prácticos técnicos y
> >>> económicos, comenzando con aumentos significativos en el costo de
> >>> aumentar las operaciones con CGNAT y la creciente necesidad de
> >>> utilizar el mercado de transferencia. Cualquiera que gestione un
> >>> negocio en Internet o una gestión técnica es consciente de todos los
> >>> problemas y costes que conllevan estos problemas.
> >>> Con respecto al posible loop, es posible que no hayas podido leer la
> >>> propuesta en su totalidad, pero predice que las nuevas organizaciones
> >>> que no tengan ningún bloque de IPv4 podrán realizar una transferencia
> >>> inicial hasta el límite de un /22 sin la necesidad para demostrar
> >>> IPv6 operativo.
> >>> No entiendo por qué se considera extraño que esta política
> >>> "obstaculice" si logra realizar una transferencia IPv4 sin la
> >>> contraparte de IPv6. Desde mi punto de vista es normal que alguien
> >>> que a mediados de 2021 no tenga IPv6 operativo tenga otros problemas
> >>> que están afectando a todos los demás a resolver antes de seguir
> >>> transfiriendo más IPv4.
> >>>
> >>> Oscar - hablando simplemente sí. Una empresa que se enfrenta a la
> >>> necesidad de transferir más IPv4 para incrementar su operación (y en
> >>> consecuencia su tráfico) y sin embargo, hasta ahora no ha hecho
> >>> ningún despliegue de IPv6 está causando daño a todos los demás,
> >>> incluidos los que hicieron sus obligaciones, por eso ya no se debería
> >>> permitir que se realicen transferencias IPv4 sin la consideración
> > de
> >>> demostrar IPv6 y reducir la tasa de crecimiento de un problema mucho
> >>> más serio de lo que les ha parecido a algunas personas que desean
> > que
> >>> estos actores se sientan muy cómodos para continuar causando estos
> >>> problemas en ecosistema Internet. A menudo he dicho que este
> >>> requisito no es tan grande ni tan difícil de lograr. Quizás
> algunos
> >>> estén sobrestimando este requisito como algo que hará que las
> >>> transferencias IPv4 sean totalmente inviables y este no es ni nunca
> >>> fue el propósito de esta propuesta.
> >>>
> >>> Saludos
> >>> Fernando
> >>>
> >>> On 13/04/2021 10:28, Oscar A. Robles-Garay wrote:
> >>>> Fernando,
> >>>>
> >>>> Si estoy entendiendo bien, con tu propuesta esperas que tenga como
> >>>> consecuencia "deseable" que aquellos ISP's que necesitan IPv4 y
> >>>> hayan decidido ir al mercado de IPs por transferencias, se tomen un
> >>>> tiempo para desplegar "algo" de IPv6, es así?
> >>>>
> >>>> Saludos,
> >>>>
> >>>> Oscar
> >>>>
> >>>>
> >>>> On 12/4/21 15:23, Fernando Frediani wrote:
> >>>>> Hola Raul
> >>>>> Gracias por tu contribución.
> >>>>>
> >>>>> No podemos confundir IPv4 y IPv6, que son recursos de numeración,
> >>> el
> >>>>> tema principal de nuestra discusión, con MANRS y participación en
> >>>>> IXPs. Si bien MANRS es una buena práctica y la participación
> >>> en IXP
> >>>>> es positiva, el uso de *recursos de numeración* y el impacto de
> >>>>> cómo el mal uso (o no uso) puede poner en duda la continuidad de la
> >>>>> evolución de un sistema que depende de diferentes actores.
> >>>>>
> >>>>> Sí, estas restricciones ciertamente están relacionadas con
> > el uso
> >>>>> óptimo de los recursos. Si una organización necesita recursos para
> >>>>> seguir desarrollando y conectando a más personas y ya no puede
> >>>>> acceder a estos recursos y existe una solución (IPv6) que, de ser
> >>>>> operativa, elimina
> >>>>> estas restricciones, es necesario que esta sea la solución y que sea
> >>>>> estimulado.
> >>>>> Es importante tener en cuenta que *IPv6 es el protocolo de Internet
> >>>>> estándar* desde 2017, no solo una buena práctica. No soy yo quien
> >>>>> lo dice, sino el IETF.
> >>>>>
> >>>>> Con respecto a lo trade-off es lo que he estado tratando de decir
> >>>>> que es muy, muy aceptable. No existe nada difícil, complejo o
> >>>>> imposible de tener, al contrario, es algo bastante obvio para
> >>>>> cualquier poseedor de recursos de numeración. Los efectos de no
> >>>>> hacer nada son mucho peores que hacer en este ejemplo.
> >>>>>
> >>>>> Saludos
> >>>>> Fernando Frediani
> >>>>>
> >>>>> On 12/04/2021 13:28, Raúl Echeberría wrote:
> >>>>>> Fernando,
> >>>>>>
> >>>>>> Por supuesto leí la propuesta completa y los cambios de la última
> >>>>>> versión. No leí el título solamente. En ese caso no
> me
> >>> hubiera
> >>>>>> atrevido a hacer comentarios.
> >>>>>>
> >>>>>> Es cierto que todas las políticas de alguna forma fuerzan el
> >>>>>> cumplimiento de ciertos requisitos y afectan de forma más o menos
> >>>>>> artificial el mercado. El punto es donde está el “trade off”.
> >>>>>>
> >>>>>> Se supone que esas restricciones tienen que estar vinculadas al
> >>>>>> uso óptimo de los recursos de numeración, no de Internet
> en si misma.
> >>>>>>
> >>>>>> Esta propuesta, si bien muy bien intencionada, está desde mi punto
> >>>>> de vista, más allá del "trade off" aceptable.
> >>>>>>
> >>>>>> Internet es una construcción colaborativa donde la base de la
> >>>>>> colaboración y la coordinación es voluntaria. Hacerlo diferente
> >>>>>> cambia la naturaleza de Internet y por lo menos a mi con todo
> >>>>>> respeto, no me
> >>>>> parece lo correcto. Por supuesto es muy respetable que tengas una
> >>>>> opinión diferente.
> >>>>>> Si hoy aprobamos esta política, mañana la propuesta será
> >>>>> hacer que la adopción de MANRS sea obligatoria y luego será
> > la
> >>>>> conexión a un IXP y luego  otra cosa. Siempre hay prácticas que nos
> >>>>> parecen buenas y que quisiéramos que sean adoptadas masivamente,
> >>>>> pero pare eso está el trabajo colaborativo que, entre otros, hacen
> los
> >>>>> NOGs y los trabajos de extensión y difusión de organizaciones como
> >>>>> ISOC o los RIRs.
> >>>>>> No querramos forzar la implementación de buenas prácticas
> >>>>>> operativas a través de las políticas.
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Saludos,
> >>>>>>
> >>>>>> Raúl
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>> El 12 abr. 2021, a las 11:57, Fernando Frediani
> >>>>>>> <fhfrediani at gmail.com>
> >>>>> escribió:
> >>>>>>> Hola de nuevo Raul
> >>>>>>>
> >>>>>>> Mira, cambiar las políticas como propone esta propuesta no está
> >>>>>>> obligando a nadie a poner IPv6 o a convertir a LACNIC en una
> >>>>>>> "policía IPv6". Solo afecta a quienes desean transferir IPv4
> y en
> >>>>>>> este caso no hay nada de malo. Y la empresa que quiere actualizar
> >>>>>>> la base de datos whois que funciona bajo reglas que se actualizan
> >>>>>>> según el tiempo y según la necesidad de cada momento. Lo
> > que se
> >>>>>>> está considerando como contraparte no es nada que imposibilite el
> >>>>>>> traspaso si la empresa tiene *un compromiso mínimo* con todos
> > los
> >>>>>>> demás, dado el momento que estamos atravesando.
> >>>>>>>
> >>>>>>> Otro punto que quiero destacar mucho es que parece que esta
> >>>>>>> propuesta tiene como objetivo solucionar todos los problemas del
> >>>>>>> despliegue de IPv6
> >>>>> y no es nada de eso. Es solo una iniciativa más, pequeña por
> >>> cierto,
> >>>>> para incentivar el despliegue de IPv6 y sobre todo para evitar que
> >>>>> quienes necesitan seguir transfiriendo IPv4 sigan causando más
> >>>>> problemas a todos los que están cumpliendo con sus obligaciones.
> >>>>>>> Dado el contexto actual, ya no tiene sentido cerrar los ojos y
> >>>>>>> permitirse seguir registrando transferencias IPv4 sin tener en
> >>>>>>> cuenta el desarrollo continuo y saludable del ecosistema del que
> >>>>>>> todos dependemos a diario.
> >>>>>>>
> >>>>>>> El tema de las políticas que obligan al mercado es un tema
> >>>>>>> complejo de discutir, pero para decirlo en pocas palabras si
> >>>>>>> fuera tan indiferente, ni siquiera sería necesario justificar
> > la
> >>>>>>> necesidad de IPv4 en el momento de una asignación inicial o una
> >>>>>>> transferencia. . Hay otros RIR que son mucho más permisivos que
> >>>>>>> LACNIC, pero aquí felizmente tomamos la decisión correcta en este
> >>>>>>> contexto.
> >>>>>>>
> >>>>>>> Fernando
> >>>>>>>
> >>>>>>> On 12/04/2021 11:11, Raúl Echeberría wrote:
> >>>>>>>> Olá Gondim
> >>>>>>>>
> >>>>>>>> Concordamos em tudo, exceto em um elemento importante.
> >>>>>>>> Compartilho sua preocupação e acho que algo precisa ser
> > feito.
> >>>>>>>> Onde discordamos
> >>>>>>> é que Eu não acredito que forçar o comportamento do
> > mercado de
> >>>>>>> esse jeito,   seja o papel das políticas, .
> >>>>>>>> É necessário redobrar os esforços na promoção do IPv6 fornecendo
> >>>>>>>> evidências que mostram os danos que você mencionou. É
> >>> preciso ter
> >>>>>>>> bons estudos, boas métricas e trabalhar
> >>>>> para disseminá-los, capacitar, gerar capacidades técnicas,
> > contatar
> >>>>> os operadores e trabalhar com eles.
> >>>>>>>> Mas acredito que não é papel da política forçar
> >>> o
> >>>>> mercado, nem acredito que essa política será eficiente para atingir
> >>>>> o objetivo que se propõe.
> >>>>>>>> É por isso Gondim, que embora concorde com você no seu
> >>>>>>>> raciocínio e nas suas preocupações, NÃO apoio
> > esta proposta.
> >>>>>>>>
> >>>>>>>> Saudações
> >>>>>>>>
> >>>>>>>> Raúl
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> El 12 abr. 2021, a las 10:46, Gondim <gondim at gmail.com>
> escribió:
> >>>>>>>>>
> >>>>>>>>> Bom dia Raúl,
> >>>>>>>>>
> >>>>>>>>> O problema é que enquanto não tivermos uma política
> >>> que
> >>>>>>> alavanque o IPv6, está não irá crescer como deveria. É a famosa
> >>>>>>> questão do: "Cão correndo atrás do rabo".
> >>>>>>>>> As empresas não querem modificar seus sistemas para terem suporte
> >>>>>>> à IPv6 porque as Operadoras que lhes fornecem Internet, e aos
> >>>>>>> seus clientes, não possuem IPv6 implementado. Em contra partida;
> >>>>>>> as Operadoras não implementam IPv6, porque não veem conteúdo e
> >>>>>>> nem a necessidade de IPv6, enquanto tiverem IPv4. Se ninguém
> sair
> >>>>>>> da inércia vamos continuar a passos de caroça na implementação de
> >>>>>>> IPv6.
> >>>>>>>>> Diariamente, aqui na minha operação, eu vejo assinantes meus
> >>>>>>> com problemas para acessarem sistemas externos e o mesmo ocorre
> >>>>>>> em sentido contrário, de acessos externos aos nossos assinantes.
> >>>>>>> Quando tento explicar, ao meu assinante, sobre a necessidade do
> >>>>>>> uso do IPv6, este me diz que sua equipe de TI afirma não existir
> >>>>>>> esse problema de falta de IPv4 e que é obrigação do
> > Provedor dar
> >>>>>>> IPv4 público para ele. Porque este é "universal". O que
> vejo é
> >>>>>>> uma total
> >>>>> desinformação do meu cliente mas também um reflexo de
> > como o
> >>>>> mercado está vendo esse problema.
> >>>>>>>>> Conteúdos informativos e sociais já existem em IPv6 e
> isso
> >>>>> é bom. Ter Google, Facebook, Netflix, Instagram, Linkedin, Youtube
> >>>>> e outros de conteúdo, ajudam em muito nossa causa mas estamos
> >>>>> esquecendo
> >>>>>>> de outros sistemas que usamos no dia a dia. Sistemas
> >>>>>>> empresariais, ERPs, empresas que desenvolvem software básico
> para
> >>>>>>> diversas áreas
> >>>>> e que não sentem a menor vontade de suportar IPv6. Porque muitas
> >>>>> das vezes não conseguem acesso em IPv6 de seus provedores de
> >>>>> Internet. Acredito que isso desmotive tecnicamente o esforço deles.
> >>>>>>>>> Cada vez mais estamos investindo em CGNAT. Comprando
> >>>>>>>>> equipamentos caríssimos para continuar usando uma rede
> >>>>>>>>> remendada, debilitada. Porque o conteúdo em IPv4 continua
> >>>>>>>>> crescendo e outros Sistemas Autônomos
> >>>>>>> não querem implementar IPv6.
> >>>>>>>>> Nós tivemos a época do esclarecimento sobre o IPv6, do
> >>>>>>>>> incentivo, diversas organizações ministraram gratuitamente
> >>>>>>>>> cursos de
> >>>>>>> IPv6, palestras, fóruns especializados com materiais técnicos
> >>>>>>> riquíssimos. Conteúdo informativo e educacional foram produzidos
> >>>>>>> e experiências foram compartilhadas com todos, durante anos.
> >>>>>>> Nesse momento; uma política permissiva só vai agravar mais a
> >>>>>>> situação e que sabemos que futuramente será mais difícil resolver
> >>>>>>> os problemas que aparecerão diante de nós.
> >>>>>>>>> Estamos falando aqui da sobrevivência da Internet como um eco
> >>>>>>>>> sistema que conhecemos. Se não for do RIR essa incumbência,
> >>>>>>>>> então que seja de outro mas tenho convicção que sem isso, não
> >>>>>>>>> iremos muito longe.
> >>>>>>>>>
> >>>>>>>>> O que me parece é que a ideia colocada nessa proposta é
> > boa mas
> >>>>>>>>> ninguém quer assumir o papel de "carrasco" e fazer valer algo
> >>> que
> >>>>>>>>> só vai beneficiar a todos e a Internet. Quantos anos mais serão
> >>>>>>>>> necessários para percebermos isso?
> >>>>>>>>>
> >>>>>>>>> Saudações,
> >>>>>>>>>
> >>>>>>>>> Gondim
> >>>>>>>>>
> >>>>>>>>> Em 11/04/2021 19:00, Raúl Echeberría escreveu:
> >>>>>>>>>> Estimados colegas.
> >>>>>>>>>>
> >>>>>>>>>> He seguido con atención la discusión sobre esta propuesta
> >>>>> que me parece muy interesante.
> >>>>>>>>>> Debo decir que comparto el espíritu que fundamenta la
> >>>>>>>>>> propuesta pero NO la apoyo porque creo que excede el rol que
> >>>>>>>>>> debe tener LACNIC y las políticas de manejo de recursos de
> >>>>>>>>>> numeración.
> >>>>>>>>>>
> >>>>>>>>>> Si bien soy totalmente empático con la idea de que los
> >>>>>>>>>> operadores deberían contribuir activametne con el despliegue
> >>> de
> >>>>>>>>>> IPv6 creo que
> >>>>>>> es algo que hay que trabajarlo a través de la promoción
> de
> >>> IPv6 y
> >>>>>>> no haciéndolo mandatorio en la política de transferencia.
> >>>>>>>>>> Además de pensar, como decía, que esta propuesta excede
> >>> lo que
> >>>>>>>>>> desde mi punto de vista, deben ser las políticas de los RIRs,
> >>>>>>>>>> tampoco creo que sea eficiente en lograr el objetivo que se
> >>>>>>>>>> propone.
> >>>>>>>>>>
> >>>>>>>>>> No es claro que es que “IPv6 está operativo en partes
> >>>>>>>>>> SIGNIFICATIVAS de la red” y tampoco está claro que
> > sucede si,
> >>>>>>>>>> una vez definido este criterio, la situación cambia luego
> de
> >>> ser
> >>>>>>>>>> aprobada la transferencia.
> >>>>>>>>>>
> >>>>>>>>>> Muchos operadores tienen IPv6 operativo en el core de la red
> >>>>>>>>>> sin dar servicios a usuarios finales, y no hay dudas que el
> >>>>>>>>>> core es una parte más que significativa de la red.
> >>>>>>>>>>
> >>>>>>>>>> Creo por supuesto que es y seguirá siendo un tema fundamental
> >>>>>>>>>> seguir trabajando por el incremento del despliegue de IPv6 de
> >>>>>>>>>> forma integral en Internet y eso es lo que ya hacen los RIRs y
> >>>>>>>>>> muchas otras organizaciones. Me parece que hay que continuar
> >>>>>>>>>> trabajando estos temas también
> >>>>>>> en los grupos de operadores pero no apoyo que este requerimiento
> >>>>>>> se incluya en la política de transferencia tal como se propone.
> >>>>>>>>>> Saludos al autor de la propuesta por traer a discusión un
> tema
> >>>>> super relevante. La discusión en si misma contribuye a la
> >>>>> concientización sobre la necesidad de la aceleración del despliegue
> >>>>> de IPv6.
> >>>>>>>>>>
> >>>>>>>>>> Saludos,
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Raúl
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> 2.3.2.18.3 Los destinatarios en la región de LACNIC deberán
> >>>>>>> tener espacio IPv6 distribuido/asignado por LACNIC o por un
> >>>>>>> proveedor y deberán poder probar que este espacio está en uso,
> >>>>>>> para lo cual deberán proporcionarle a LACNIC los detalles
> >>>>>>> documentados del despliegue de la red para demostrar que IPv6
> >>>>>>> está operativo
> >>> en
> >>>>>>> partes significativas de la red.
> >>>>>>>>>> El personal de LACNIC definirá un criterio mínimo para
> >>>>>>>>>> garantizar que la información proporcionada demuestre que
> IPv6
> >>>>>>>>>> está
> >>>>>>> operativo. De ser necesario, el personal puede requerir más
> >>>>>>> información para validar este requisito.
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>> El 31 mar. 2021, a las 11:37, info-politicas at lacnic.net
> >>>>>>>>>>> escribió:
> >>>>>>>>>>>
> >>>>>>>>>>> [Português abaixo]
> >>>>>>>>>>> [English below]
> >>>>>>>>>>>
> >>>>>>>>>>> Estimados suscriptores de la lista de políticas de LACNIC,
> >>>>>>>>>>>
> >>>>>>>>>>> La propuesta LAC-2020-1 ha pasado de la versión 3 a la versión
> 4
> >>>>>>>>>>>
> >>>>>>>>>>> Título: Agregar IPv6 operativo como requisito para las
> >>>>>>>>>>> transferencias de IPv4
> >>>>>>>>>>>
> >>>>>>>>>>> Resumen: On 15th February 2017 LACNIC started IPv4 Exhaustion
> >>>>>>>>>>> Phase 3 meaning only new entrants can receive up to a single
> >>>>>>>>>>> /22 of IPv4 space.
> >>>>>>> Since then the amount of IPv4 Transfers between organizations has
> >>>>>>> increased reasonably as shown by the official LACNIC reports.
> >>>>>>> With the implementation of LAC-2019-1 and possibility of
> >>>>>>> Inter-RIR transfers these numbers have the potential to grow
> >>>>>>> substantially.
> >>>>>>>>>>> The objective of this proposal is to add as a requirement for
> >>>>>>>>>>> organizations in process of receiving transferred IPv4 space
> >>>>>>>>>>> under 2.3.2.18 to show they have an IPv6
> >>>>>>>>>>> allocation/assignment by LACNIC or a provider and that is
> >>>>>>>>>>> operational on their networks. Such organization must be able
> >>>>>>>>>>> to prove this IPv6 space is being used by providing LACNIC
> >>>>>>>>>>> the documented network deployment details to prove IPv6 is
> >>>>>>>>>>> operational in significant parts of the network.
> >>>>>>>>>>>
> >>>>>>>>>>> On 28th November 2019 LACNIC Board issued a statement
> >>>>>>>>>>> (
> https://www.lacnic.net/4283/2/lacnic/lacnic-board-calls-on-the-community-to-promote-ipv6-deployment
> )
> >>>>>>>>>>> reinforcing the issue about IPv4 exhaustion, mentioning IPv4
> >>>>>>>>>>> address space will be exhausted by mid-2020 and calling the
> >>>>>>>>>>> community to promote IPv6 deployment.
> >>>>>>>>>>> In its statement LACNIC Board “invite the community to
> > work
> >>>>>>>>>>> on promoting the development of policies that will accelerate
> >>>>>>>>>>> the effective deployment of IPv6 above other policies that
> >>>>>>>>>>> may be discussed at a later date.”
> >>>>>>>>>>>
> >>>>>>>>>>> In the case the receiver provides a written statement from
> >>>>>>>>>>> its upstream that IPv6 connectivity is unavailable, the IPv6
> >>>>>>>>>>> requirement may be waived. In the case LACNIC is not able to
> >>>>>>>>>>> meet a new entrant request for IPv4 space, or the
> >>>>>>>>>>> organization does not hold any IPv4 space the IPv6
> >>>>>>>>>>> requirement may be waived for a transfer up to a /22.
> >>>>>>>>>>>
> >>>>>>>>>>> Para ver el detalle ingrese en:
> >>>>>>>>>>>
> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1/language/sp
> >>>>>>>>>>>
> >>>>>>>>>>> Los cambios respecto a la versión anterior se pueden visualizar
> >>>>>>> aquí:
> >>>>>>>>>>>
> https://politicas.lacnic.net/politicas/diff2?id=LAC-2020-1&v=4&v2=3&language=SP
> >>>>>>>>>>>
> >>>>>>>>>>> Los comentarios y los puntos de vista aportados por la
> >>>>>>>>>>> comunidad son
> >>>>>>> vitales para el correcto desarrollo del proceso de la propuestas
> >>>>>>>>>>> - ¿Apoya usted o se opone a esta nueva versión de la
> > propuesta?
> >>>>>>>>>>> - ¿Ve alguna desventaja en esta nueva versión de la
> propuesta?
> >>>>>>>>>>> - ¿Qué cambios podrían hacerse a esta nueva versión de la
> >>>>>>>>>>> propuesta para que sea más eficaz?
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Por más información contacte a info-politicas at lacnic.net
> >>>>>>>>>>> Saludos cordiales,
> >>>>>>>>>>>
> ______________________________________________________________________________________________________
> >>>>>>>>>>> Prezados assinantes da lista de políticas de LACNIC,
> >>>>>>>>>>>
> >>>>>>>>>>> A proposta LAC-2020-1 tem passado da versão 3 para a versão 4
> >>>>>>>>>>>
> >>>>>>>>>>> Título: Adicionar IPv6 operacional como requisito para as
> >>>>>>>>>>> transferências do IPv4
> >>>>>>>>>>>
> >>>>>>>>>>> Resumo: On 15th February 2017 LACNIC started IPv4 Exhaustion
> >>>>>>>>>>> Phase
> >>>>> 3
> >>>>>>> meaning only new entrants can receive up to a single /22 of IPv4
> >>>>>>> space. Since then the amount of IPv4 Transfers between
> >>>>>>> organizations has increased reasonably as shown by the official
> >>>>>>> LACNIC reports. With the implementation of LAC-2019-1 and
> >>>>>>> possibility of Inter-RIR transfers these numbers have the
> >>>>>>> potential to grow substantially.
> >>>>>>>>>>> The objective of this proposal is to add as a requirement for
> >>>>>>>>>>> organizations in process of receiving transferred IPv4 space
> >>>>>>>>>>> under 2.3.2.18 to show they have an IPv6
> >>>>>>>>>>> allocation/assignment by LACNIC or a provider and that is
> >>>>>>>>>>> operational on their networks. Such organization must be able
> >>>>>>>>>>> to prove this IPv6 space is being used by providing LACNIC
> >>>>>>>>>>> the documented network deployment details to prove IPv6 is
> >>>>>>>>>>> operational in significant parts of the network.
> >>>>>>>>>>>
> >>>>>>>>>>> On 28th November 2019 LACNIC Board issued a statement
> >>>>>>>>>>> (
> https://www.lacnic.net/4283/2/lacnic/lacnic-board-calls-on-the-community-to-promote-ipv6-deployment
> )
> >>>>>>>>>>> reinforcing the issue about IPv4 exhaustion, mentioning IPv4
> >>>>>>>>>>> address space will be exhausted by mid-2020 and calling the
> >>>>>>>>>>> community to promote IPv6 deployment.
> >>>>>>>>>>> In its statement LACNIC Board “invite the community to
> > work
> >>>>>>>>>>> on promoting the development of policies that will accelerate
> >>>>>>>>>>> the effective deployment of IPv6 above other policies that
> >>>>>>>>>>> may be discussed at a later date.”
> >>>>>>>>>>>
> >>>>>>>>>>> In the case the receiver provides a written statement from
> >>>>>>>>>>> its upstream that IPv6 connectivity is unavailable, the IPv6
> >>>>>>>>>>> requirement may be waived. In the case LACNIC is not able to
> >>>>>>>>>>> meet a new entrant request for IPv4 space, or the
> >>>>>>>>>>> organization does not hold any IPv4 space the IPv6
> >>>>>>>>>>> requirement may be waived for a transfer up to a /22.
> >>>>>>>>>>>
> >>>>>>>>>>> Para ver o detalhe acesse:
> >>>>>>>>>>>
> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1/language/pt
> >>>>>>>>>>>
> >>>>>>>>>>> As alterações da versão anterior podem ser vistas
> >>> aqui:
> >>>>>>>>>>>
> https://politicas.lacnic.net/politicas/diff2?id=LAC-2020-1&v=4&v2=3&language=PT
> >>>>>>>>>>>
> >>>>>>>>>>> Os comentários e os pontos de vista aportados pela comunidade
> >>>>> são
> >>>>>>>>>>> vitais para o bom desenvolvimento do processo das propostas
> >>>>>>>>>>> - Você está a favor ou em contra desta nova versão
> >>>>>>>>>>> da proposta?- Vê alguma desvantagem nesta nova versão
> >>>>>>>>>>> da proposta?
> >>>>>>>>>>>
> >>>>>>>>>>> - Que mudanças poderiam ser feitas à esta nova versão
> >>>>>>>>>>> da proposta para que seja mais eficaz?
> >>>>>>>>>>>
> >>>>>>>>>>> Por mais informações entre em contato conosco através
> >>>>>>> do e-mail:
> >>>>>>>>>>> info-politicas at lacnic.net.
> >>>>>>>>>>>
> >>>>>>>>>>> Atenciosamente,
> >>>>>>>>>>>
> ______________________________________________________________________________________________________
> >>>>>>>>>>>
> >>>>>>>>>>> Dear LACNIC Policy List subscribers,
> >>>>>>>>>>>
> >>>>>>>>>>> Proposal LAC-2020-1 has been updated from version 3 to version
> > 4
> >>>>>>>>>>> Title: Add IPv6 operational as a requirement for IPv4 transfers
> >>>>>>>>>>>
> >>>>>>>>>>> Summary: On 15th February 2017 LACNIC started IPv4 Exhaustion
> >>>>>>>>>>> Phase 3 meaning only new entrants can receive up to a single
> >>>>>>>>>>> /22 of IPv4 space.
> >>>>>>> Since then the amount of IPv4 Transfers between organizations has
> >>>>>>> increased reasonably as shown by the official LACNIC reports.
> >>>>>>> With the implementation of LAC-2019-1 and possibility of
> >>>>>>> Inter-RIR transfers these numbers have the potential to grow
> >>>>>>> substantially.
> >>>>>>>>>>> The objective of this proposal is to add as a requirement for
> >>>>>>>>>>> organizations in process of receiving transferred IPv4 space
> >>>>>>>>>>> under 2.3.2.18 to show they have an IPv6
> >>>>>>>>>>> allocation/assignment by LACNIC or a provider and that is
> >>>>>>>>>>> operational on their networks. Such organization must be able
> >>>>>>>>>>> to prove this IPv6 space is being used by providing LACNIC
> >>>>>>>>>>> the documented network deployment details to prove IPv6 is
> >>>>>>>>>>> operational in significant parts of the network.
> >>>>>>>>>>>
> >>>>>>>>>>> On 28th November 2019 LACNIC Board issued a statement
> >>>>>>>>>>> (
> https://www.lacnic.net/4283/2/lacnic/lacnic-board-calls-on-the-community-to-promote-ipv6-deployment
> )
> >>>>>>>>>>> reinforcing the issue about IPv4 exhaustion, mentioning IPv4
> >>>>>>>>>>> address space will be exhausted by mid-2020 and calling the
> >>>>>>>>>>> community to promote IPv6 deployment.
> >>>>>>>>>>> In its statement LACNIC Board “invite the community to
> > work
> >>>>>>>>>>> on promoting the development of policies that will accelerate
> >>>>>>>>>>> the effective deployment of IPv6 above other policies that
> >>>>>>>>>>> may be discussed at a later date.”
> >>>>>>>>>>>
> >>>>>>>>>>> In the case the receiver provides a written statement from
> >>>>>>>>>>> its upstream that IPv6 connectivity is unavailable, the IPv6
> >>>>>>>>>>> requirement may be waived. In the case LACNIC is not able to
> >>>>>>>>>>> meet a new entrant request for IPv4 space, or the
> >>>>>>>>>>> organization does not hold any IPv4 space the IPv6
> >>>>>>>>>>> requirement may be waived for a transfer up to a /22.
> >>>>>>>>>>>
> >>>>>>>>>>> To see the details, please click on:
> >>>>>>>>>>>
> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1/language/en
> >>>>>>>>>>>
> >>>>>>>>>>> The changes from the previous version can be seen here:
> >>>>>>>>>>>
> https://politicas.lacnic.net/politicas/diff2?id=LAC-2020-1&v=4&v2=3&language=EN
> >>>>>>>>>>>
> >>>>>>>>>>> The community's comments and opinions are essential to the
> >>>>>>>>>>> proper functioning of the policy development process.
> >>>>>>>>>>> - Do you support this new version of the proposal or are you
> >>>>>>>>>>> against
> >>>>>>> it?
> >>>>>>>>>>> - Do you think this new version of the proposal has any
> >>>>>>>>>>> drawbacks?
> >>>>>>>>>>> - What changes could be made to this new version of the
> >>>>>>>>>>> proposal to make it more effective?
> >>>>>>>>>>>
> >>>>>>>>>>> For further information, please contact
> >>>>>>>>>>> info-politicas at lacnic.net
> >>>>>>>>>>> Kind regards,
> >>>>>>>>>>> --
> >>>>>>>>>>> LACNIC - Registro de Direcciones de Internet para América
> >>>>>>>>>>> Latina y Caribe
> >>>>>>>>>>> Rambla Rep. de México 6125, CP 11400
> >>>>>>>>>>>
> >>>>>>>>>>> Montevideo-Uruguay
> >>>>>>>>>>>
> >>>>>>>>>>> Teléfono: +598 2604 22 22
> >>>>>>>>>>> www.lacnic.net
> >>>>>>>>>>> _______________________________________________
> >>>>>>>>>>> Politicas mailing list
> >>>>>>>>>>> Politicas at lacnic.net
> >>>>>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
> >>>>>>>>>> _______________________________________________
> >>>>>>>>>> Politicas mailing list
> >>>>>>>>>> Politicas at lacnic.net
> >>>>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
> >>>>>>>>> _______________________________________________
> >>>>>>>>> Politicas mailing list
> >>>>>>>>> Politicas at lacnic.net
> >>>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
> >>>>>>>> _______________________________________________
> >>>>>>>> Politicas mailing list
> >>>>>>>> Politicas at lacnic.net
> >>>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
> >>>>>>> _______________________________________________
> >>>>>>> Politicas mailing list
> >>>>>>> Politicas at lacnic.net
> >>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
> >>>>>> _______________________________________________
> >>>>>> Politicas mailing list
> >>>>>> Politicas at lacnic.net
> >>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
> >>>>> _______________________________________________
> >>>>> Politicas mailing list
> >>>>> Politicas at lacnic.net
> >>>>> https://mail.lacnic.net/mailman/listinfo/politicas
> >>> _______________________________________________
> >>> Politicas mailing list
> >>> Politicas at lacnic.net
> >>> https://mail.lacnic.net/mailman/listinfo/politicas
> >>>
> >> _______________________________________________
> >> Politicas mailing list
> >> Politicas at lacnic.net
> >> https://mail.lacnic.net/mailman/listinfo/politicas
> > _______________________________________________
> > Politicas mailing list
> > Politicas at lacnic.net
> > https://mail.lacnic.net/mailman/listinfo/politicas
> > _______________________________________________
> > Politicas mailing list
> > Politicas at lacnic.net
> > https://mail.lacnic.net/mailman/listinfo/politicas
>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>

-- 

*Atenciosamente,Daniel Damito*