[LACNIC/Politicas] NP: LAC-2026-3 - ROA para solicitud de recursos

Douglas Fischer fischerdouglas at gmail.com
Thu Aug 13 16:11:43 -03 2026


No em manual de políticas!

Em qui., 13 de ago. de 2026 às 15:18, jordi.palet--- via Politicas <
politicas at lacnic.net> escreveu:

> Hola a todos,
>
> Estoy de acuerdo con la propuesta y concuerdo con Fernando.
>
> Podemos medir el “buen hacer” y no solo de forma instantánea (de hecho,
> diría que no debemos hacerlo así), tanto de RPKI como de IPv6 como de
> resolución inversa, como de lo que queramos. De hecho hace años que
> concretamos esto en una propuesta (
> https://politicas.lacnic.net/politicas/detail/id/LAC-2019-9/language/sp)
> que modificaba la sección 7.1 del manual de políticas (
> https://www.lacnic.net/550/1/lacnic/). Se acordó que LACNIC
> progresivamente iría automatizando los procesos de verificación.
>
> (no se cuales de ellos están ya automatizados, sería bueno que LACNIC lo
> confirmara, y si por ejemplo esta previsto verificar RPKI/ROAs, IPv6, etc.).
>
> Considero que hoy en día, determinadas buenas prácticas, que afectan a
> toda la comunidad, deben incorporarse al manual de políticas de forma
> progresiva. Esta propuesta lo hace, ya que no obliga, si se alcanza
> consenso, a hacerlo de forma inmediata, sino que el plazo es el que cada
> uno pueda (indirectamente pensando que en el futuro puedas necesitar mas
> direcciones), y solo se obliga cuando se quiere una asignación/distribución
> adicional.
>
> Igualmente, independientemente de que esta propuesta alcance o no
> consenso, creo que debemos re-pensar si el uso de IPv6, debe ser un
> requisito no solo para nuevas asignaciones/distribuciones, sino incluso
> para mantener las existentes en un plazo de x años. No quiero abrir el
> debate ahora, pero si alguien quiere entrar, que por favor habrá un nuevo
> hilo para no confundir ambas discusiones.
>
> Saludos,
> Jordi
>
> @jordipalet
>
> > El 13 ago 2026, a las 17:34, Fernando Frediani via Politicas <
> politicas at lacnic.net> escribió:
> >
> > Bom dia Fischer
> > Ótimos pontos levantados.
> >
> > Acredito que existem algumas nuances técnicas para discussão e outras
> mais de administrativas digamos, como perceber e gerir isso no longo prazo.
> >
> > 1 - A questão de mensurar ROA ou IPv6 entendo as diferenças, mas ainda
> sim é igualmente possível. Desde que se estabeleçam métricas simples de
> mensurar é sempre possível.
> > Quando da discussão da minha proposta falei que precisamos ter essa
> coragem e que não necessariamente precisa ser complexo para existir como
> requerimento, mas o espírito é que a organização se esforce em demonstrar
> que está fazendo o certo e não apenas de qualquer jeito. Nem o amor é 100%
> e as vezes falha, então não precisamos tratar a ferro e fogo.
> >
> > 2 - A questão sobre "estar em conformidade" e não ser "point-in-time"
> achei bem interessantemente de se olhar e é verdadeira. O argumento -
> válido - que alguns podem ter é como quem analisar isso (a equipe de LACNIC
> ou dos NIRs) irá fazer para acompanhar se depois de se transferir/receber
> recursos eles seguirão em conformidade.
> > De novo, não é necessário tratar a ferro e fogo. Não é necessário ter
> ferramentas sofisticadas e custosas para monitorar isso. Mas se existir
> algum caso eventual onde foi constatado que a organização deixou de
> cumprir, faz-se óbvio e coloca-se sobre processo de recuperação para que
> ela ajuste e volte a cumprir. A ideia não é de ser um caça as bruxas, mas
> sim de quem operar um Sistema Autônomo tenha um mínimo de disciplina e
> responsabilidade conhecendo bem suas obrigações.
> >
> > 3 - Existe uma diferença entre ter IPv6 operacional e ter ROA.
> > Não ter ROA é algo que pode prejudicar mais o próprio Sistema Autônomo e
> deixará os recursos sob sua responsabilidade desprotegidos contra hijack
> intencional ou não.
> > Já optar por não implantar IPv6 causa prejuízo e  aumento de custos para
> todo o ecosistema de internet, principalmente daqueles que fizeram sua
> parte e implantaram.
> > De qualquer maneira sigo enxergando essas possibilidades mais boas como
> que ruins no resultado final.
> >
> > Fernando Frediani
> >
> > On 8/13/2026 11:25 AM, Douglas Fischer wrote:
> >> Olá Sergio, Fernando, Oscar, e demais membros da lista.
> >>
> >> Tomo a liberdade de responder em portugês, porque creio que conversas
> multilinguais esse seja um hábito que devemos incentivar em nossa
> comunidade.
> >> E também porque me sinto mais à vontade para me expressar.
> >> Caso qualquer membro tenha alguma dificuldade de interpretação nas
> minhas falas em português, peço que solicitem esclarecimentos na conversa
> via lista de e-mail mesmo, ou privadamente.
> >>
> >> O que vou falar a seguir pode parecer confuso...
> >> Mas para resumir
> >> 1- Creio que eu concordo parcialmente com os 3 entes envolvidos.
> >> 2- Creio que falta uma "peça" no nosso conjunto de engrenagens para que
> a coisa toda faça sentido.
> >>
> >> 1-a-
> >> Eu acho que o espírito da proposta do Sérgio é EXCELENTE!
> >> Sim! Antes de que qualquer organização se manifeste querendo se tornar
> responsável por mais recursos, deve demonstrar que é capaz de manter em
> ordem aquilo que já está sob sua responsabilidade.
> >>
> >> 1-b-
> >> Eu concordo com o Frediani de que fazendo referência a esse tipo de
> status (ROA no caso) abre-se precedente para milhares de outros tipos de
> status de diversos tipos.
> >> Mas não concordo que "já que vamos fazer isso, façamos aquilo
> também...".
> >>
> >> 1-c-
> >> Eu concordo com o Oscar de que status de ROA é algo muito mais objetivo
> que um nível de adoção de IPv6.
> >> Mas eu discordo de que o status de ROA seja algo que possa ser
> diretamente referenciado dentro do manual de políticas.
> >>
> >> 2-
> >> Para exemplificar a peça que falta em nosso ecossistema, vou usar
> justamente o caso de um ASN e o status de ROA de seus recursos numéricos.
> >> 2-1-
> >> Primeiro exemplo é para demonstrar que o status não pode ser um
> conveniente snapshot point-in-time.
> >> Imaginemos um ASN que passa o ano inteiro(ou vários anos) fazendo
> bagunça com as ROAs...
> >> Deixando expirar, fazendo prefixos ficarem inválidos... Que bota rota
> mais específica sem estar coberta pelas ROAs. Ou que bota ROA "toda aberta"
> e nunca tem nada no mais específico.
> >> Ou então, imaginemos que nunca teve nada de RPKI ROA em feito em sua
> vida, e apenas 1 dia antes de solicitar novos recursos, resolve ajustar as
> ROAs para refletirem como as suas rotas na DFZ estão agora.
> >> Mas que 2 dias depois de receber o recurso solicitado, abandona
> completamente o cuidado com as ROAs.
> >>
> >> A ideia dessa exemplificação é demonstrar que "estar em conformidade"
> não é "point-in-time" é constância.
> >>
> >> 2-2-
> >> O segundo exemplo é justamente para demonstrar o contrário.
> >> Imaginemos um ASN que tenha seus recursos numéricos. Que tenha um
> histórico de anos sem nenhuma demonstraçaõ de abandono.
> >> Mas justamente por estar precisando reordenar as coisas em casa,
> fazendo alterações, acaba por vazar uma rota fora do mais específico que
> estava previsto na ROA existente... E deixa isso lá por 17m39s, e logo
> corrige. E nunca mais volta a cometer "dedo-gordo".
> >>
> >> Essa exemplificação é para trazer para a mesa o fato de que um evento
> isolado não deve desabonar todo o histórico operacional de um ASN.
> >>
> >> 2-3-
> >> Eu poderia criar dezenas ou centenas de exemplos para demonstrar
> pontos...
> >> Mas entendo que esse thread não é para isso.
> >> E acredito que já consegui demonstrar meu ponto para aqueles que
> realmente se dispuserem a entender o proponho aqui.
> >>
> >>
> >> Diante do que tentei expor(e espero que tenha conseguido)...
> >> Trago à mesa a hipótese de considerarmos a hipótese de ter-se um
> conjunto de melhores práticas operacionais do LACNIC, bem como mecanismos
> de medição recorrente de implementação de tais melhores práticas.
> >>
> >> Sei que propor uma mudança de rumo é quase uma Pivotada de Startupeiro
> sem noção de realidade.
> >> E não quero sequestrar o thread dessa proposta de alteração do manual
> de políticas(sorry Sergio).
> >>
> >> Mas uso esse espaço para iniciar "semi-oficialmente" a discussão sobre
> criação de BCOPs oficiais ratificados pelo LACNIC.
> >> Sobre medição recorrente dos cumprimentos desse BCOPs.
> >> E sobre como, no futuro, esses BCOPs e mecanismos de medições possam
> ser a peça abstrata que falta em nosso manual de políticas.
> >>
> >> Desde já agradeço vossa atenção.
> >>
> >>
> >> Em qua., 12 de ago. de 2026 às 14:11, Oscar Robles via Politicas <
> politicas at lacnic.net> escreveu:
> >>
> >>    Fernando,
> >>
> >>    Entiendo que parecen similares las propuestas. Quizá estoy equivocado
> >>    pues ustedes tienen más experiencia operativa, pero me parece que la
> >>    propuesta de Sergio es más parecida al requisito actual de tener la
> >>    resolución inversa prolija.
> >>
> >>    A diferencia de tu propuesta (IPv6 operativo), este requisito es
> >>    facilmente medible, con menos ambiguedades y dificilmente se puede
> >>    "encender" para cumplir el requisito y "apagar" una vez obtenido los
> >>    recursos.
> >>
> >>    Y coincido contigo que en un escenario ideal donde IPv6 operativo no
> >>    tuviera las dificultades previas, sería un buen requisito.
> >>
> >>    Saludos,
> >>
> >>    Oscar
> >>
> >>
> >>    On 12/08/26 8:27, Fernando Frediani via Politicas wrote:
> >>    > Hola
> >>    >
> >>    > El objetivo de la propuesta es noble y felicito al autor por ella.
> >>    > Sin embargo, si consideramos la aprobación de dicha propuesta,
> >>    > deberíamos retomar mi propuesta de hace algunos años, que
> >>    establecía
> >>    > como condición para recibir o transferir recursos de numeración
> >>    IPv4
> >>    > la comprobación de tener IPv6 operativo.
> >>    >
> >>
> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1/language/sp
> >>    >
> >>    > En aquel tiempo entonces, algunos, temiendo no poder transferir
> >>    > recursos (quizás porque no habían implementado IPv6), la
> >>    rechazaron,
> >>    > argumentando que se trataba de una cuestión operativa.
> >>    >
> >>    > Sigo creyendo que es legítimo establecer políticas como esta
> >>    para ROA
> >>    > y como la que propuse para IPv6, ya que el Foro de Políticas puede
> >>    > editar la propuesta según lo considere oportuno para ajustar las
> >>    > reglas de Whois dello RIR si lo considera apropiado para una mejor
> >>    > gestión de los recursos de numeración.
> >>    >
> >>    > Fernando Frediani
> >>    >
> >>    > On 8/12/2026 10:38 AM, info-politicas--- via Politicas wrote:
> >>    >> [Português abaixo]
> >>    >> [English below]
> >>    >>
> >>    >> ---
> >>    >>
> >>    >> Estimados suscriptores de la Lista de Políticas de LACNIC,
> >>    >>
> >>    >> Se recibió una nueva propuesta de Política, se le asignó el id
> >>    >> LAC-2026-3.
> >>    >>
> >>    >> Título: Cobertura de ROAs válidas para la solicitud de recursos
> >>    >> adicionales
> >>    >>
> >>    >> Título abreviado: ROA para solicitud de recursos
> >>    >>
> >>    >> Resumen: Esta propuesta establece que toda organización que
> >>    solicite
> >>    >> recursos adicionales de numeración IPv4 o IPv6 a LACNIC deberá
> >>    >> demostrar una cobertura del 80% de Autorizaciones de Origen de
> >>    Ruta
> >>    >> (ROA) válidas para los recursos IPv4 e IPv6 registrados a su
> >>    nombre y
> >>    >> distribuidos o asignados por LACNIC. El objetivo de la
> >>    propuesta es
> >>    >> incentivar la adopción de RPKI y fortalecer la seguridad del
> >>    sistema
> >>    >> de enrutamiento de la región. La creación y mantenimiento de ROAs
> >>    >> constituye una práctica ampliamente reconocida para mitigar el
> >>    riesgo
> >>    >> de secuestros de rutas, anuncios no autorizados y errores de
> >>    >> configuración en BGP.
> >>    >>
> >>    >> La propuesta incorpora la adopción de ROAs como un criterio
> >>    adicional
> >>    >> para la evaluación de solicitudes de recursos subsiguientes,
> >>    >> complementando los criterios ya establecidos en el Manual de
> >>    Políticas.
> >>    >>
> >>    >> Propuesta completa:
> >>    >> Adicionar al final del inciso 1 de la sección “2.3.4. Políticas
> >>    para
> >>    >> la distribución de espacio adicional de direcciones IPv4” el
> >>    >> siguiente texto:
> >>    >> Adicionalmente, la organización deberá contar con una cobertura
> >>    del
> >>    >> 80% de Autorizaciones de Origen de Ruta (ROAs) válidas para los
> >>    >> recursos IPv4 e IPv6 que tenga asignados o distribuidos por
> >>    LACNIC.
> >>    >> LACNIC verificará el cumplimiento de este requisito mediante los
> >>    >> mecanismos operativos que determine para tal fin. El
> >>    cumplimiento de
> >>    >> este requisito constituirá una condición necesaria para aprobar la
> >>    >> distribución subsiguiente de recursos.
> >>    >>
> >>    >> Adicionar al final de la sección “4.4.2.1 Criterio de distribución
> >>    >> subsiguiente”:
> >>    >> Adicionalmente, la organización deberá contar con una cobertura
> >>    del
> >>    >> 80% de Autorizaciones de Origen de Ruta (ROAs) válidas para los
> >>    >> recursos IPv4 e IPv6 que tenga asignados o distribuidos por
> >>    LACNIC.
> >>    >> LACNIC verificará el cumplimiento de este requisito mediante los
> >>    >> mecanismos operativos que determine para tal fin. El
> >>    cumplimiento de
> >>    >> este requisito constituirá una condición necesaria para aprobar la
> >>    >> distribución subsiguiente de recursos.
> >>    >>
> >>    >> Para ver el detalle ingrese en:
> >>    >>
> >>
> https://politicas.lacnic.net/politicas/detail/id/LAC-2026-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 propuesta?
> >>    >> - ¿Esta propuesta resolvería un problema que usted está
> >>    >> experimentando?- ¿Ve alguna desventaja en esta propuesta?
> >>    >> - ¿Qué cambios podrían hacerse a esta propuesta para que sea
> >>    más eficaz?
> >>    >>
> >>    >> Por más información contacte ainfo-politicas at lacnic.net
> >>    >> Saludos cordiales,
> >>    >>
> >>    >> ----------------------------------------
> >>    >> Prezados assinantes da lista de políticas de LACNIC,
> >>    >>
> >>    >> Foi recebida uma nova proposta de Política, foi atribuído o id
> >>    >> LAC-2026-3.
> >>    >>
> >>    >> Título: Cobertura de ROAs válidas para la solicitud de recursos
> >>    >> adicionales
> >>    >>
> >>    >> Título abreviado: ROA para solicitud de recursos
> >>    >>
> >>    >> Resumo: Esta propuesta establece que toda organización que
> >>    solicite
> >>    >> recursos adicionales de numeración IPv4 o IPv6 a LACNIC deberá
> >>    >> demostrar una cobertura del 80% de Autorizaciones de Origen de
> >>    Ruta
> >>    >> (ROA) válidas para los recursos IPv4 e IPv6 registrados a su
> >>    nombre y
> >>    >> distribuidos o asignados por LACNIC. El objetivo de la
> >>    propuesta es
> >>    >> incentivar la adopción de RPKI y fortalecer la seguridad del
> >>    sistema
> >>    >> de enrutamiento de la región. La creación y mantenimiento de ROAs
> >>    >> constituye una práctica ampliamente reconocida para mitigar el
> >>    riesgo
> >>    >> de secuestros de rutas, anuncios no autorizados y errores de
> >>    >> configuración en BGP.
> >>    >>
> >>    >> La propuesta incorpora la adopción de ROAs como un criterio
> >>    adicional
> >>    >> para la evaluación de solicitudes de recursos subsiguientes,
> >>    >> complementando los criterios ya establecidos en el Manual de
> >>    Políticas.
> >>    >>
> >>    >> Para ver o detalhe acesse:
> >>    >>
> >>
> https://politicas.lacnic.net/politicas/detail/id/LAC-2026-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ê é a favor ou contra desta proposta?
> >>    >> - ¿Esta proposta iria resolver um problema que você está
> >>    >> experimentando?- ¿Vê alguma alguma desvantagem nesta proposta?
> >>    >> - ¿Que mudanças poderiam ser feitas à proposta para que seja mais
> >>    >> eficaz?
> >>    >>
> >>    >> Por mais informações entre em contato conosco através do seguinte
> >>    >> e-mail:info-politicas at lacnic.net
> >>    <mailto:e-mail%3Ainfo-politicas at lacnic.net> Atenciosamente,
> >>    >> ----------------------------------------
> >>    >>
> >>    >> Dear LACNIC Policy List subscribers,
> >>    >>
> >>    >> A new Policy Proposal has been received and assigned the following
> >>    >> ID: LAC-2026-3.
> >>    >>
> >>    >> Title: Cobertura de ROAs válidas para la solicitud de recursos
> >>    >> adicionales
> >>    >>
> >>    >> Abbreviated title: ROA para solicitud de recursos
> >>    >>
> >>    >> Summary: Esta propuesta establece que toda organización que
> >>    solicite
> >>    >> recursos adicionales de numeración IPv4 o IPv6 a LACNIC deberá
> >>    >> demostrar una cobertura del 80% de Autorizaciones de Origen de
> >>    Ruta
> >>    >> (ROA) válidas para los recursos IPv4 e IPv6 registrados a su
> >>    nombre y
> >>    >> distribuidos o asignados por LACNIC. El objetivo de la
> >>    propuesta es
> >>    >> incentivar la adopción de RPKI y fortalecer la seguridad del
> >>    sistema
> >>    >> de enrutamiento de la región. La creación y mantenimiento de ROAs
> >>    >> constituye una práctica ampliamente reconocida para mitigar el
> >>    riesgo
> >>    >> de secuestros de rutas, anuncios no autorizados y errores de
> >>    >> configuración en BGP.
> >>    >>
> >>    >> La propuesta incorpora la adopción de ROAs como un criterio
> >>    adicional
> >>    >> para la evaluación de solicitudes de recursos subsiguientes,
> >>    >> complementando los criterios ya establecidos en el Manual de
> >>    Políticas.
> >>    >>
> >>    >> To read the proposal, please go to
> >>    >>
> >>
> https://politicas.lacnic.net/politicas/detail/id/LAC-2026-3/language/en
> >>    >>
> >>    >> The community's comments and opinions are essential to the proper
> >>    >> functioning of the policy development process.
> >>    >> - Do you support this policy or are you against it?
> >>    >> - Would this proposal solve a problem you are experiencing?- Do
> >>    you
> >>    >> think this proposal has any drawbacks?
> >>    >> - What changes could be made to this proposal to make it more
> >>    effective?
> >>    >>
> >>    >> For further information, please contactinfo-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 <http://www.lacnic.net>
> >>    >> _______________________________________________
> >>    >> Politicas mailing list
> >>    >> Politicas at lacnic.net
> >>    >> https://mail.lacnic.net/mailman/listinfo/politicas
> >>    >>
> >>    Desuscribirse/Descadastre-se/Unsubscribe:
> https://mail.lacnic.net/mailman/options/politicas
> >>
> >>    >>
> >>    >>
> >>    >> El Codigo de Conducta de la Comunidad de LACNIC
> >>    >> (https://rir.la/codigoconducta-SP) aplica a las listas de
> >>    discusion
> >>    >> de LACNIC.
> >>    >> O Codigo de Conduta da Comunidade do LACNIC
> >>    >> (https://rir.la/codigoconducta-PT) se aplica as listas de
> >>    discussao
> >>    >> do LACNIC.
> >>    >> LACNIC's Community Code of Conduct
> >>    (https://rir.la/codigoconducta-EN)
> >>    >> applies to LACNIC's discussion lists.
> >>    >>
> >>    > _______________________________________________
> >>    > Politicas mailing list
> >>    > Politicas at lacnic.net
> >>    > https://mail.lacnic.net/mailman/listinfo/politicas
> >>    > Desuscribirse/Descadastre-se/Unsubscribe:
> >>    > https://mail.lacnic.net/mailman/options/politicas
> >>    >
> >>    > El Codigo de Conducta de la Comunidad de LACNIC
> >>    > (https://rir.la/codigoconducta-SP) aplica a las listas de
> >>    discusion de
> >>    > LACNIC.
> >>    > O Codigo de Conduta da Comunidade do LACNIC
> >>    > (https://rir.la/codigoconducta-PT) se aplica as listas de
> >>    discussao do
> >>    > LACNIC.
> >>    > LACNIC's Community Code of Conduct
> >>    (https://rir.la/codigoconducta-EN)
> >>    > applies to LACNIC's discussion lists.
> >>    >
> >>    _______________________________________________
> >>    Politicas mailing list
> >>    Politicas at lacnic.net
> >>    https://mail.lacnic.net/mailman/listinfo/politicas
> >>    Desuscribirse/Descadastre-se/Unsubscribe
> >>    <
> https://mail.lacnic.net/mailman/listinfo/politicasDesuscribirse/Descadastre-se/Unsubscribe
> >:
> >>    https://mail.lacnic.net/mailman/options/politicas
> >>
> >>    El Codigo de Conducta de la Comunidad de LACNIC
> >>    (https://rir.la/codigoconducta-SP) aplica a las listas de
> >>    discusion de LACNIC.
> >>    O Codigo de Conduta da Comunidade do LACNIC
> >>    (https://rir.la/codigoconducta-PT) se aplica as listas de
> >>    discussao do LACNIC.
> >>    LACNIC's Community Code of Conduct
> >>    (https://rir.la/codigoconducta-EN) applies to LACNIC's discussion
> >>    lists.
> >>
> >>
> >>
> >> --
> >> Douglas Fernando Fischer
> >> Engº de Controle e Automação
> > _______________________________________________
> > Politicas mailing list
> > Politicas at lacnic.net
> > https://mail.lacnic.net/mailman/listinfo/politicas
> > Desuscribirse/Descadastre-se/Unsubscribe:
> https://mail.lacnic.net/mailman/options/politicas
> >
> > El Codigo de Conducta de la Comunidad de LACNIC (
> https://rir.la/codigoconducta-SP) aplica a las listas de discusion de
> LACNIC.
> > O Codigo de Conduta da Comunidade do LACNIC (
> https://rir.la/codigoconducta-PT) se aplica as listas de discussao do
> LACNIC.
> > LACNIC's Community Code of Conduct (https://rir.la/codigoconducta-EN)
> applies to LACNIC's discussion lists.
> >
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
> Desuscribirse/Descadastre-se/Unsubscribe
> <https://mail.lacnic.net/mailman/listinfo/politicasDesuscribirse/Descadastre-se/Unsubscribe>:
> https://mail.lacnic.net/mailman/options/politicas
>
> El Codigo de Conducta de la Comunidad de LACNIC (
> https://rir.la/codigoconducta-SP) aplica a las listas de discusion de
> LACNIC.
> O Codigo de Conduta da Comunidade do LACNIC (
> https://rir.la/codigoconducta-PT) se aplica as listas de discussao do
> LACNIC.
> LACNIC's Community Code of Conduct (https://rir.la/codigoconducta-EN)
> applies to LACNIC's discussion lists.
>
>

-- 
Douglas Fernando Fischer
Engº de Controle e Automação


More information about the Politicas mailing list