From registry at uoc.cw Thu Oct 1 21:58:32 2026 From: registry at uoc.cw (=?utf-8?Q? .CW_Registry_Cura=C3=A7ao_=40UoC ?=) Date: Thu, 1 Oct 2026 20:58:32 -0400 Subject: [LACNIC/Politicas] NP: LAC-2026-6 - Aclaraciones-PDP In-Reply-To: References: Message-ID: <85B7A861-4687-4AC1-ACF0-60D41828145D@uoc.cw> From franco at lacnic.net Mon Oct 5 16:14:34 2026 From: franco at lacnic.net (Franco Cabrera Ferrari) Date: Mon, 5 Oct 2026 16:14:34 -0300 Subject: [LACNIC/Politicas] =?utf-8?q?Webinar=3A_Propuestas_de_Pol=C3=ADt?= =?utf-8?q?icas_FPP?= Message-ID: Estimados suscriptores de la lista, En el marco del pr?ximo LACNIC 46, los invitamos a participar del webinar: "Propuestas de pol?ticas FPP" Fecha: mi?rcoles 7 de octubre, 18:00 UTC. M?s informaci?n: https://lacnic46.lacnic.net/es/programa/actividad-preparatoria En este webinar podr?s conocer los detalles de las propuestas de pol?ticas que se discutir?n en el Foro P?blico de Pol?ticas (FPP) de LACNIC 46. Haremos un repaso general sobre cada propuesta, explicando en qu? etapa del proceso se encuentra, y adem?s, habilitaremos espacios de preguntas para evacuar dudas y facilitar la participaci?n en el Foro. Este webinar es una excelente instancia preparatoria, tanto para quienes asistir?n presencialmente a LACNIC 46 como para quienes participar?n de forma remota. Esperamos contar con su participaci?n tanto en el webinar como en el Foro. Saludos, -- Franco Cabrera Asistente de Pol?ticas Policy Assistant www.lacnic.net Latin American and Caribbean Internet Addresses Registry -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_0xB806FDA6AA8ADBFD.asc Type: application/pgp-keys Size: 4938 bytes Desc: OpenPGP public key URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature.asc Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: From harcidiacono at iplan.com.ar Mon Oct 5 16:33:07 2026 From: harcidiacono at iplan.com.ar (Hernan Arcidiacono) Date: Mon, 5 Oct 2026 16:33:07 -0300 Subject: [LACNIC/Politicas] NP: LAC-2026-4 - reciprocidad inter-rir In-Reply-To: References: <1629217887.20.1789503308063@cf4e0708918d> <56154472-6f2a-413d-a7ee-4f3eff6a3f04@registro.br> <72B82824-1424-4F93-9C4C-6E1EC9503E4D@consulintel.es> <5d990b50-29a2-40b1-a203-dbaa1f0b54ca@registro.br> Message-ID: Hola Ricardo: Estoy de acuerdo con la propuesta. Creo muy importante que existan mecanismos, aunque no sean exactamente iguales a los nuestros, que exijan alg?n tipo de justificaci?n. Cont? con mi apoyo. Hernan Arcidiacono CTO +549 11 5025 5106 <+54%209%2011%205025-5106> On Wed, Sep 16, 2026 at 1:01?PM jordi.palet--- via Politicas < politicas at lacnic.net> wrote: > Hola Ricardo, > > Efectivamente, entonces creo que no lo hab?a entendido al 100%, y > aplicar?a con mas claridad/correcci?n la 2? redacci?n que propuse: > > > > En el caso de trasferencias inter-RIR, s?lo estar?n permitidas si las > pol?ticas entre ambos RIRs son reciprocas y compatibles, de forma que ambas > requieran justificaci?n de la necesidad. > > O se podr?a simplificar, para evitar entrar en discutir que es > rec?proco/compatible: > > En el caso de trasferencias inter-RIR, s?lo estar?n permitidas si las > pol?ticas de ambos RIRs requieren justificaci?n de la necesidad. > > Saludos, > Jordi > > @jordipalet > > > El 16 sept 2026, a las 17:54, Ricardo Patara via Politicas < > politicas at lacnic.net> escribi?: > > > > Hola, > > > > La propuesta tiene como principal objetivo hacer que el receptor > justifique la necesidad de acuerdo las pol?ticas del RIR donde ese est? > ubicado. > > > > La reciprocidad se refiere a que se aplice el an?lisis de necesidad > justificada. > > > > En la regi?n de RIPE no se verifica, por defecto, la necesidad > justificada cuando organizaci?n en su regi?n recibe una transferencia INTER > RIR. > > Pero esta previsto que lo har?an caso la otra parte lo solicite. > > > > Con esa propuesta el RIR destino de la transferencia tendr?a que validar > necesidad justificad y aplicaria lo que esta previsto en sus pol?ticas > > > > > > On 16/09/26 11:15, jordi.palet--- via Politicas wrote: > >> Hola Ricardo, > >> Gracias por la propuesta. > >> Creo que estoy de acuerdo con la propuesta y efectivamente creo que era > su esp?ritu cuando la consensuamos, y digo creo porque me ha costado un > poco entender la redacci?n. > >> Entiendo que el objetivo es evitar que se vayan de LACNIC direcciones a > regiones en las que no hay justificaci?n de la necesidad. Sin embargo, > mencionas RIPE y all? se requiere justificar el uso de al menos el 50% en > un m?ximo de 5 a?os (https://www.ripe.net/publications/docs/ripe-807/). > En LACNIC pedimos que esa justificaci?n sea tambi?n del 50% pero en un a?o. > >> Entonces, la duda es: ?no se podr?an hacer transferencias a RIPE si la > justificaci?n de la necesidad no coincide al 100% entre RIPE y LACNIC? > >> De ser as?, podr?a ocurrir que RIPE cambiara la pol?tica para que no se > pudieran transferir recursos a LACNIC ? Es decir, entrar en una guerra de > transferencias. De hecho, AFRINIC ya aprob? una propuesta, recientemente > ratificada por el nuevo directorio, que tiene restricciones y pr?cticamente > no permite ?sacar? recursos de AFRINIC, pero si ?entrar? (lo estoy > simplificando, es un mecanismo mucho mas complejo de lo habitual, y > pr?cticamente se reduce a recursos legados). > >> Respecto de la redacci?n, si lo he entendido bien, la idea es esta: > >> Esta pol?tica aplica tanto a los casos en que alguna de las entidades > involucradas sea de otra regi?n (transferencias inter-RIR), como para > transferencias dentro de la regi?n LACNIC (transferencias intra-RIR). > >> En el caso de trasferencias inter-RIR, s?lo estar?n permitidas si las > pol?ticas entre ambos RIRs son reciprocas y compatibles respecto de la > justificaci?n de la necesidad. > >> Y me queda la duda de si deben ser 100% compatibles (1 a?o en LACNIC, 5 > en RIPE). Quiz?s har?a falta detallar a que nos referimos con esa > compatibilidad. Tal y como esta, creo que se podr?a hacer de RIPE a LACNIC, > pero no al rev?s. Una alternativa es relajarlo: > >> En el caso de trasferencias inter-RIR, s?lo estar?n permitidas si las > pol?ticas entre ambos RIRs son reciprocas y compatibles, de forma que ambas > requieran justificaci?n de la necesidad. > >> Saludos, > >> Jordi > >> @jordipalet > >>> El 16 sept 2026, a las 15:46, Ricardo Patara via Politicas < > politicas at lacnic.net> escribi?: > >>> > >>> hola, > >>> > >>> como indicado, la propuesta busca un ajuste m?nimo al texto actual: > >>> ---------------------------------------------------------------------- > >>> Texto nuevo > >>> Oprima aqu? para ver/ocultar las diferencias entre el texto actual y > el nuevo > >>> 2.3.2.18. Transferencias de direcciones IPv4 > >>> > >>> Se permitir?n transferencias de direcciones IPv4 entre LIRs y/o > usuarios finales, en adelante entidades, bajo las condiciones establecidas > en la presente secci?n. > >>> > >>> Esta pol?tica aplica tanto a los casos en que alguna de las entidades > involucradas sea de otra regi?n (transferencias inter-RIR), como para > transferencias dentro de la regi?n LACNIC (transferencias intra-RIR). > >>> > >>> Transferencias Inter-RIR bajo esta secci?n solamente ser?n permitidas > entre RIRs que compartan pol?ticas rec?procas y compatibles basadas en > necesidad justificada. > >>> ---------------------------------------------------------------------- > >>> > >>> en resumen, se agrega al ?ltimo p?rrafo: > >>> > >>> "[...] ser?n permitidas entre RIRs que compartan pol?ticas rec?procas > y compatibles basadas en necesidad justificada." > >>> > >>> uno de los principios de las propuestas iniciales para permitir la > transferencia de direcciones IPv4 fue atender la necesidad de aquellos que > a?n no los ten?an pasado el agotamiento. > >>> > >>> de esa forma se busco preservar el principio b?sico y muy valioso de > la *necesidad justificada* > >>> > >>> > >>> > >>> On 15/09/26 17:15, 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-4. > >>>> T?tulo: Justificativa de necesidad Transferencia Inter-rir > >>>> T?tulo abreviado: reciprocidad inter-rir > >>>> Resumen: Se busca ajustar minimamente el texto actual a?n as? en un > punto importante que mantiene el esp?ritu original de la propuesta de poner > en uso en redes que necesiten de direcciones IPv4 que est?n ociosas. > >>>> De esa forma se busca garantizar el an?lisis de necesidad justificada > por parte de receptor > >>>> Propuesta completa: > >>>> 2.3.2.18. Transferencias de direcciones IPv4 > >>>> Se permitir?n transferencias de direcciones IPv4 entre LIRs y/o > usuarios finales, en adelante entidades, bajo las condiciones establecidas > en la presente secci?n. > >>>> Esta pol?tica aplica tanto a los casos en que alguna de las entidades > involucradas sea de otra regi?n (transferencias inter-RIR), como para > transferencias dentro de la regi?n LACNIC (transferencias intra-RIR). > >>>> Transferencias Inter-RIR bajo esta secci?n solamente ser?n permitidas > entre RIRs que compartan pol?ticas rec?procas y compatibles basadas en > necesidad justificada. > >>>> Para ver el detalle ingrese en: > >>>> > https://politicas.lacnic.net/politicas/detail/id/LAC-2026-4/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 a info-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-4. > >>>> T?tulo: Justificativa de necesidad Transferencia Inter-rir > >>>> T?tulo abreviado: reciprocidad inter-rir > >>>> Resumo: Se busca ajustar minimamente el texto actual a?n as? en un > punto importante que mantiene el esp?ritu original de la propuesta de poner > en uso en redes que necesiten de direcciones IPv4 que est?n ociosas. > >>>> De esa forma se busca garantizar el an?lisis de necesidad justificada > por parte de receptor > >>>> Para ver o detalhe acesse: > >>>> > https://politicas.lacnic.net/politicas/detail/id/LAC-2026-4/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 > >>>> Atenciosamente, > >>>> ---------------------------------------- > >>>> Dear LACNIC Policy List subscribers, > >>>> A new Policy Proposal has been received and assigned the following > ID: LAC-2026-4. > >>>> Title: Justificativa de necesidad Transferencia Inter-rir > >>>> Abbreviated title: reciprocidad inter-rir > >>>> Summary: Se busca ajustar minimamente el texto actual a?n as? en un > punto importante que mantiene el esp?ritu original de la propuesta de poner > en uso en redes que necesiten de direcciones IPv4 que est?n ociosas. > >>>> De esa forma se busca garantizar el an?lisis de necesidad justificada > por parte de receptor > >>>> To read the proposal, please go to > >>>> > https://politicas.lacnic.net/politicas/detail/id/LAC-2026-4/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 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 > >>>> 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. > >>> > >> ********************************************** > >> 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/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. > > > > > > ********************************************** > 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/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. > > -- *No Imprimas Digitaliz?*ESTE MENSAJE ES CONFIDENCIAL. Puede contener informaci?n amparada por el secreto profesional. Si usted ha recibido este e-mail por error, por favor comun?quenoslo inmediatamente v?a e-mail y tenga la amabilidad de eliminarlo de su sistema; no deber? copiar el mensaje ni divulgar su contenido a ninguna persona. Muchas gracias. THIS MESSAGE IS CONFIDENTIAL. It may also contain information that is privileged or otherwise legally exempt from disclosure. If you have received it by mistake please let us know by e-mail immediately and delete it from your system; should also not copy the message nor disclose its contents to anyone. Many thanks. NSS S.A. ? IPLAN | CUIT: 30-70265297-5 | IVA Responsable Inscripto | Ingr. Brutos: 901-033512-0?Inscripci?n I.G.J.: 24/02/1999, N? 2588, libro 4, tomo - Sociedades por Acciones | Sede Social:? Reconquista 865 2? Piso, CABA ? C1003ABQ ? Ley 25326 - art.27. - inc. 3. El titular podr? en cualquier momento solicitar el retiro o bloqueo de su nombre de los bancos de datos a los que se refiere el presente art?culo. Decreto 1558/01 - art. 27. - 3er. p?rrafo. En toda comunicaci?n con fines de publicidad que se realice por correo, tel?fono, correo electr?nico, Internet u otro medio a distancia a conocer, se deber? indicar, en forma expresa y destacada, la posibilidad del titular del dato de solicitar el retiro o bloqueo, total o parcial, de su nombre de la base de datos. A pedido del interesado, se deber? informar el nombre del responsable o usuario del banco de datos que provey? la informaci?n. ? El titular de los datos personales tiene la facultad de ejercer el derecho?de acceso a los mismos en forma gratuita y a intervalos no inferiores a 6 meses, salvo que se acredite un inter?s leg?timo al efecto conforme lo establecido por el art?culo 14, inciso 3 de la ley 25326.- La?Agencia de Acceso a la Informaci?n P?blica?, ?rgano de control de la ley N? 25.326, tiene la atribuci?n de atender las denuncias y reclamos que se interpongan con relaci?n al incumplimiento de las normas sobre protecci?n de datos personales. -------------- next part -------------- A non-text attachment was scrubbed... Name: noname Type: image/png Size: 7644 bytes Desc: not available URL: From sergio.kleiman at telefonica.com Wed Oct 7 15:41:15 2026 From: sergio.kleiman at telefonica.com (Sergio Kleiman Schwarzstein) Date: Wed, 7 Oct 2026 18:41:15 +0000 Subject: [LACNIC/Politicas] NP: LAC-2026-3 - ROA para solicitud de recursos In-Reply-To: References: Message-ID: ?Hola a todos! Me gustar?a invitar a la comunidad a revisar y participar en la discusi?n de la propuesta LAC-2026-3: Cobertura de ROAs v?lidas para la solicitud de recursos adicionales. La propuesta busca incentivar la adopci?n de RPKI mediante un requisito de cobertura m?nima de ROAs v?lidas para los recursos ya asignados, previo a la solicitud de recursos adicionales. El objetivo es promover mejores pr?cticas que contribuyan a la seguridad y resiliencia del sistema de enrutamiento de Internet en nuestra regi?n. Adicionalmente, ahora que LACNIC ya ofrece soporte para ASPA, me gustar?a conocer la opini?n de la comunidad sobre si este tipo de mecanismos tambi?n podr?an contribuir a impulsar su adopci?n. ?Consideran que deber?a evaluarse alg?n tipo de incentivo o requisito relacionado con ASPA, o creen que su adopci?n deber?a seguir un camino distinto? Espero sus comentarios y sugerencias. Saludos, ----- PT (Traduzido por IA) ----- Ol? a todos, Gostaria de convidar a comunidade a revisar e participar da discuss?o da proposta LAC-2026-3: Cobertura de ROAs v?lidos para a solicita??o de recursos adicionais. A proposta busca incentivar a ado??o do RPKI por meio de um requisito de cobertura m?nima de ROAs v?lidos para os recursos j? alocados, antes da solicita??o de recursos adicionais. O objetivo ? promover melhores pr?ticas que contribuam para a seguran?a e a resili?ncia do sistema de roteamento da Internet em nossa regi?o. Al?m disso, agora que o LACNIC j? oferece suporte para ASPA, gostaria de conhecer a opini?o da comunidade sobre se esse tipo de mecanismo tamb?m poderia contribuir para impulsionar sua ado??o. Voc?s consideram que, no futuro, deveria ser avaliado algum tipo de incentivo ou requisito relacionado ao ASPA, ou acreditam que sua ado??o deveria seguir um caminho diferente? Aguardarei seus coment?rios e sugest?es. Atenciosamente, ----- EN (Translated by AI) ----- Hi everyone! I would like to invite the community to review and participate in the discussion of proposal LAC-2026-3: Valid ROA Coverage for Additional Resource Requests. The proposal seeks to encourage RPKI adoption through a minimum valid ROA coverage requirement for resources already allocated to an organization before additional resources can be requested. The goal is to promote best practices that contribute to the security and resilience of the Internet routing system in our region. Additionally, now that LACNIC supports ASPA, I would like to hear the community's opinion on whether this type of mechanism could also help drive ASPA adoption. Do you believe that some form of ASPA-related incentive or requirement should be considered in the future, or do you think ASPA adoption should follow a different path? I look forward to your comments and suggestions. Best regards, Sergio Kleiman *** Clasificado P?BLICO por TELEF?NICA. *** Classified PUBLIC by TELEF?NICA. *** Classificado como P?BLICO pela TELEF?NICA. *** Von TELEF?NICA als ?FFENTLICH eingestuft. De: Sergio Kleiman Schwarzstein Enviado el: jueves, 13 de agosto de 2026 11:16 Para: 'politicas at lacnic.net' Asunto: [LACNIC/Politicas] NP: LAC-2026-3 - ROA para solicitud de recursos ?Hola! Gracias a todos por sus comentarios. Estoy seguro de que nos ayudar?n a enriquecer y mejorar la propuesta. El objetivo de esta propuesta es que los miembros que ya cuentan con recursos IPv4 o IPv6 publiquen ROAs para dichos recursos antes de solicitar direccionamiento adicional. La intenci?n no es agregar complejidad al proceso de asignaci?n, sino fomentar la adopci?n de pr?cticas que contribuyan a la seguridad y resiliencia del ruteo en Internet. Quienes administramos recursos num?ricos tenemos la responsabilidad de protegerlos contra posibles usos indebidos o anuncios no autorizados. RPKI y los ROAs son excelentes herramientas que permiten reducir este riesgo, y la creaci?n de ROAs en el portal de miLACNIC es un proceso sencillo que normalmente requiere solo unos minutos. La intenci?n de tener un umbral del 80% es establecer un equilibrio razonable entre incentivar la adopci?n de ROAs y mantener flexibilidad operativa para los miembros. Este porcentaje permite demostrar que la gran mayor?a de los recursos se encuentra protegida mediante ROAs v?lidos, sin exigir una cobertura absoluta que podr?a resultar dif?cil de alcanzar en algunos escenarios operativos o durante procesos de transici?n. En otras palabras, el requisito busca promover una adopci?n significativa de RPKI, manteniendo al mismo tiempo un margen suficiente para evitar afectar innecesariamente las solicitudes leg?timas de recursos adicionales. Nuevamente, agradezco sus comentarios y espero continuar la discusi?n para identificar posibles mejoras al texto y al mecanismo propuesto. Saludos, ----- PT (Traduzido por IA) ----- Ol?, Obrigado a todos pelos coment?rios. Tenho certeza de que eles nos ajudar?o a enriquecer e aperfei?oar a proposta. O objetivo desta proposta ? que os membros que j? possuem recursos IPv4 ou IPv6 publiquem ROAs para esses recursos antes de solicitar endere?amento adicional. A inten??o n?o ? adicionar complexidade ao processo de aloca??o, mas sim incentivar a ado??o de pr?ticas que contribuam para a seguran?a e a resili?ncia do roteamento na Internet. N?s, que administramos recursos num?ricos, temos a responsabilidade de proteg?-los contra poss?veis usos indevidos ou an?ncios n?o autorizados. O RPKI e os ROAs s?o excelentes ferramentas para reduzir esse risco, e a cria??o de ROAs no portal miLACNIC ? um processo simples que normalmente leva apenas alguns minutos. A inten??o de estabelecer um limite de 80% ? encontrar um equil?brio razo?vel entre incentivar a ado??o de ROAs e manter flexibilidade operacional para os membros. Esse percentual permite demonstrar que a grande maioria dos recursos est? protegida por ROAs v?lidos, sem exigir uma cobertura absoluta que poderia ser dif?cil de alcan?ar em alguns cen?rios operacionais ou durante processos de transi??o. Em outras palavras, o requisito busca promover uma ado??o significativa do RPKI, mantendo ao mesmo tempo uma margem suficiente para evitar impactos desnecess?rios em solicita??es leg?timas de recursos adicionais. Mais uma vez, agrade?o os coment?rios e espero continuar a discuss?o para identificar poss?veis melhorias no texto e no mecanismo proposto. Atenciosamente, ----- EN (Translated by AI) ----- Hello, Thank you all for your comments. I am confident that they will help us enrich and improve the proposal. The goal of this proposal is for members who already hold IPv4 or IPv6 resources to publish ROAs for those resources before requesting additional address space. The intention is not to add complexity to the allocation process, but rather to encourage the adoption of practices that contribute to the security and resilience of Internet routing. Those of us who manage number resources have a responsibility to protect them against potential misuse or unauthorized route announcements. RPKI and ROAs are excellent tools for reducing this risk, and creating ROAs through the miLACNIC portal is a straightforward process that typically takes only a few minutes. The purpose of establishing an 80% threshold is to strike a reasonable balance between encouraging ROA adoption and maintaining operational flexibility for members. This percentage allows members to demonstrate that the vast majority of their resources are protected by valid ROAs without requiring absolute coverage, which may be difficult to achieve in certain operational scenarios or during transition periods. In other words, the requirement seeks to promote meaningful RPKI adoption while maintaining sufficient flexibility to avoid unnecessarily impacting legitimate requests for additional resources. Once again, I appreciate your comments and look forward to continuing the discussion in order to identify possible improvements to both the text and the proposed mechanism. Best regards, Sergio Kleiman ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci?n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n puede estar prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su destrucci?n. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat?rio, pode conter informa??o privilegiada ou confidencial e ? para uso exclusivo da pessoa ou entidade de destino. Se n?o ? vossa senhoria o destinat?rio indicado, fica notificado de que a leitura, utiliza??o, divulga??o e/ou c?pia sem autoriza??o pode estar proibida em virtude da legisla??o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui??o From fbonadiman at redesul.com.br Wed Oct 7 22:27:52 2026 From: fbonadiman at redesul.com.br (fbonadiman at redesul.com.br) Date: Wed, 7 Oct 2026 22:27:52 -0300 Subject: [LACNIC/Politicas] NP: LAC-2026-3 - ROA para solicitud de recursos In-Reply-To: References: Message-ID: <50eef9b6-6fb0-48d1-b6fe-91b6affa8c4e@Spark> Hola Sergio, Gracias por compartir la propuesta y abrir el debate con la comunidad sobre RPKI y ASPA. Saludos, F?bio Bonadiman On Oct 7, 2026 at 18:41 +0000, Sergio Kleiman Schwarzstein via Politicas , wrote: > ?Hola a todos! > > Me gustar?a invitar a la comunidad a revisar y participar en la discusi?n de la propuesta LAC-2026-3: Cobertura de ROAs v?lidas para la solicitud de recursos adicionales. > > La propuesta busca incentivar la adopci?n de RPKI mediante un requisito de cobertura m?nima de ROAs v?lidas para los recursos ya asignados, previo a la solicitud de recursos adicionales. El objetivo es promover mejores pr?cticas que contribuyan a la seguridad y resiliencia del sistema de enrutamiento de Internet en nuestra regi?n. > > Adicionalmente, ahora que LACNIC ya ofrece soporte para ASPA, me gustar?a conocer la opini?n de la comunidad sobre si este tipo de mecanismos tambi?n podr?an contribuir a impulsar su adopci?n. > > ?Consideran que deber?a evaluarse alg?n tipo de incentivo o requisito relacionado con ASPA, o creen que su adopci?n deber?a seguir un camino distinto? > > Espero sus comentarios y sugerencias. > > Saludos, > > > ----- PT (Traduzido por IA) ----- > Ol? a todos, > > Gostaria de convidar a comunidade a revisar e participar da discuss?o da proposta LAC-2026-3: Cobertura de ROAs v?lidos para a solicita??o de recursos adicionais. > > A proposta busca incentivar a ado??o do RPKI por meio de um requisito de cobertura m?nima de ROAs v?lidos para os recursos j? alocados, antes da solicita??o de recursos adicionais. O objetivo ? promover melhores pr?ticas que contribuam para a seguran?a e a resili?ncia do sistema de roteamento da Internet em nossa regi?o. > > Al?m disso, agora que o LACNIC j? oferece suporte para ASPA, gostaria de conhecer a opini?o da comunidade sobre se esse tipo de mecanismo tamb?m poderia contribuir para impulsionar sua ado??o. > > Voc?s consideram que, no futuro, deveria ser avaliado algum tipo de incentivo ou requisito relacionado ao ASPA, ou acreditam que sua ado??o deveria seguir um caminho diferente? > > Aguardarei seus coment?rios e sugest?es. > > Atenciosamente, > > > > ----- EN (Translated by AI) ----- > Hi everyone! > > I would like to invite the community to review and participate in the discussion of proposal LAC-2026-3: Valid ROA Coverage for Additional Resource Requests. > > The proposal seeks to encourage RPKI adoption through a minimum valid ROA coverage requirement for resources already allocated to an organization before additional resources can be requested. The goal is to promote best practices that contribute to the security and resilience of the Internet routing system in our region. > > Additionally, now that LACNIC supports ASPA, I would like to hear the community's opinion on whether this type of mechanism could also help drive ASPA adoption. Do you believe that some form of ASPA-related incentive or requirement should be considered in the future, or do you think ASPA adoption should follow a different path? > > I look forward to your comments and suggestions. > > Best regards, > > > Sergio Kleiman > > > > *** Clasificado P?BLICO por TELEF?NICA. *** Classified PUBLIC by TELEF?NICA. > *** Classificado como P?BLICO pela TELEF?NICA. *** Von TELEF?NICA als ?FFENTLICH eingestuft. > De: Sergio Kleiman Schwarzstein > Enviado el: jueves, 13 de agosto de 2026 11:16 > Para: 'politicas at lacnic.net' > Asunto: [LACNIC/Politicas] NP: LAC-2026-3 - ROA para solicitud de recursos > > ?Hola! > > Gracias a todos por sus comentarios. Estoy seguro de que nos ayudar?n a enriquecer y mejorar la propuesta. > > El objetivo de esta propuesta es que los miembros que ya cuentan con recursos IPv4 o IPv6 publiquen ROAs para dichos recursos antes de solicitar direccionamiento adicional. La intenci?n no es agregar complejidad al proceso de asignaci?n, sino fomentar la adopci?n de pr?cticas que contribuyan a la seguridad y resiliencia del ruteo en Internet. > > Quienes administramos recursos num?ricos tenemos la responsabilidad de protegerlos contra posibles usos indebidos o anuncios no autorizados. RPKI y los ROAs son excelentes herramientas que permiten reducir este riesgo, y la creaci?n de ROAs en el portal de miLACNIC es un proceso sencillo que normalmente requiere solo unos minutos. La intenci?n de tener un umbral del 80% es establecer un equilibrio razonable entre incentivar la adopci?n de ROAs y mantener flexibilidad operativa para los miembros. Este porcentaje permite demostrar que la gran mayor?a de los recursos se encuentra protegida mediante ROAs v?lidos, sin exigir una cobertura absoluta que podr?a resultar dif?cil de alcanzar en algunos escenarios operativos o durante procesos de transici?n. > > En otras palabras, el requisito busca promover una adopci?n significativa de RPKI, manteniendo al mismo tiempo un margen suficiente para evitar afectar innecesariamente las solicitudes leg?timas de recursos adicionales. > > Nuevamente, agradezco sus comentarios y espero continuar la discusi?n para identificar posibles mejoras al texto y al mecanismo propuesto. > > > Saludos, > > > ----- PT (Traduzido por IA) ----- > > Ol?, > > Obrigado a todos pelos coment?rios. Tenho certeza de que eles nos ajudar?o a enriquecer e aperfei?oar a proposta. > > O objetivo desta proposta ? que os membros que j? possuem recursos IPv4 ou IPv6 publiquem ROAs para esses recursos antes de solicitar endere?amento adicional. A inten??o n?o ? adicionar complexidade ao processo de aloca??o, mas sim incentivar a ado??o de pr?ticas que contribuam para a seguran?a e a resili?ncia do roteamento na Internet. > > N?s, que administramos recursos num?ricos, temos a responsabilidade de proteg?-los contra poss?veis usos indevidos ou an?ncios n?o autorizados. O RPKI e os ROAs s?o excelentes ferramentas para reduzir esse risco, e a cria??o de ROAs no portal miLACNIC ? um processo simples que normalmente leva apenas alguns minutos. A inten??o de estabelecer um limite de 80% ? encontrar um equil?brio razo?vel entre incentivar a ado??o de ROAs e manter flexibilidade operacional para os membros. Esse percentual permite demonstrar que a grande maioria dos recursos est? protegida por ROAs v?lidos, sem exigir uma cobertura absoluta que poderia ser dif?cil de alcan?ar em alguns cen?rios operacionais ou durante processos de transi??o. > > Em outras palavras, o requisito busca promover uma ado??o significativa do RPKI, mantendo ao mesmo tempo uma margem suficiente para evitar impactos desnecess?rios em solicita??es leg?timas de recursos adicionais. > > Mais uma vez, agrade?o os coment?rios e espero continuar a discuss?o para identificar poss?veis melhorias no texto e no mecanismo proposto. > > Atenciosamente, > > > ----- EN (Translated by AI) ----- > Hello, > > Thank you all for your comments. I am confident that they will help us enrich and improve the proposal. > > The goal of this proposal is for members who already hold IPv4 or IPv6 resources to publish ROAs for those resources before requesting additional address space. The intention is not to add complexity to the allocation process, but rather to encourage the adoption of practices that contribute to the security and resilience of Internet routing. > > Those of us who manage number resources have a responsibility to protect them against potential misuse or unauthorized route announcements. RPKI and ROAs are excellent tools for reducing this risk, and creating ROAs through the miLACNIC portal is a straightforward process that typically takes only a few minutes. The purpose of establishing an 80% threshold is to strike a reasonable balance between encouraging ROA adoption and maintaining operational flexibility for members. This percentage allows members to demonstrate that the vast majority of their resources are protected by valid ROAs without requiring absolute coverage, which may be difficult to achieve in certain operational scenarios or during transition periods. > > In other words, the requirement seeks to promote meaningful RPKI adoption while maintaining sufficient flexibility to avoid unnecessarily impacting legitimate requests for additional resources. > > Once again, I appreciate your comments and look forward to continuing the discussion in order to identify possible improvements to both the text and the proposed mechanism. > > Best regards, > > > Sergio Kleiman > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci?n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n puede estar prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su destrucci?n. > > The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat?rio, pode conter informa??o privilegiada ou confidencial e ? para uso exclusivo da pessoa ou entidade de destino. Se n?o ? vossa senhoria o destinat?rio indicado, fica notificado de que a leitura, utiliza??o, divulga??o e/ou c?pia sem autoriza??o pode estar proibida em virtude da legisla??o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui??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. > From jordi.palet at theipv6company.com Thu Oct 8 06:20:03 2026 From: jordi.palet at theipv6company.com (jordi.palet at theipv6company.com) Date: Thu, 8 Oct 2026 11:20:03 +0200 Subject: [LACNIC/Politicas] NP: LAC-2026-3 - ROA para solicitud de recursos In-Reply-To: References: Message-ID: <9C93CBDC-5DD9-4702-AF63-4BAC8AA25417@theipv6company.com> Hola Sergio, Disculpas porque se me pas? el anuncio original de la propuesta. En principio de acuerdo con la propuesta. Entiendo que tal y como est? redactada, tambi?n aplicar?a para quien quiera recibir transferencias, dado que en estos casos tambi?n se pasa por el proceso de justificaci?n de necesidad. En el caso de IPv6, creo que apenas tiene impacto, pues si alguien necesita mas direcciones IPv6, en muchos casos ser? porque no planific? sus necesidades y se acogi? al ?/32 por defecto?, con lo cual la mejor alternativa en estos casos es acudir a una rectificaci?n (4.4.1.4 o 4.4.4.3). Lo comento, porque si no has tenido en cuenta este detalla, una (posible) mejora de la propuesta seria, en lugar de agregarlo al final del 4.4.2.1, que sea una secci?n nueva y modificar el texto para que tambi?n aplique en el caso de rectificaciones del espacio. Por otro lado, no s? si puedes comentar si hay alg?n motivo por el que tu propuesta solo est? contemplando distribuciones y no asignaciones directas por LACNIC? Creo que se debe fomentar tambi?n el uso de RPKI entre usuarios finales que reciben recursos directamente de LACNIC. Respecto del tema de ASPA, creo que tambi?n ser?a bueno incorporarlo, sin embargo tengo mis dudas de si hacerlo en el mismo plazo que esta propuesta (asumiendo que alcanzara consenso), o dar un poco mas de margen (lo cual podr?a incluirse como parte de la redacci?n, +6 meses, por poner un ejemplo). Es decir, no necesariamente hace falta una propuesta nueva posteriormente. Como comentario adicional, en diversas ocasiones hemos discutido propuestas para fomentar el uso de ?x?, creo que la que m?s se ha debatido ha sido el uso de IPv6. Hasta ahora, no hemos alcanzado consenso generalmente. Quiz?s esta propuesta nos sirve para reaccionar y pensar que exigir requisitos como el uso de medidas que aportan seguridad, estabilidad, escalabilidad y fiabilidad a Internet, como son RPKI e IPv6, son un beneficio para todos y deber?an ser de obligado cumplimiento, teniendo en cuenta que hay ya experiencia en estos campos y no son ya nuevas tecnolog?as, y que hay que despedirse, poco a poco, de nuestro viejo amigo ?legacy? IPv4. Saludos, Jordi @jordipalet > El 7 oct 2026, a las 20:41, Sergio Kleiman Schwarzstein via Politicas escribi?: > > ?Hola a todos! > > Me gustar?a invitar a la comunidad a revisar y participar en la discusi?n de la propuesta LAC-2026-3: Cobertura de ROAs v?lidas para la solicitud de recursos adicionales. > > La propuesta busca incentivar la adopci?n de RPKI mediante un requisito de cobertura m?nima de ROAs v?lidas para los recursos ya asignados, previo a la solicitud de recursos adicionales. El objetivo es promover mejores pr?cticas que contribuyan a la seguridad y resiliencia del sistema de enrutamiento de Internet en nuestra regi?n. > > Adicionalmente, ahora que LACNIC ya ofrece soporte para ASPA, me gustar?a conocer la opini?n de la comunidad sobre si este tipo de mecanismos tambi?n podr?an contribuir a impulsar su adopci?n. > > ?Consideran que deber?a evaluarse alg?n tipo de incentivo o requisito relacionado con ASPA, o creen que su adopci?n deber?a seguir un camino distinto? > > Espero sus comentarios y sugerencias. > > Saludos, > > > ----- PT (Traduzido por IA) ----- > Ol? a todos, > > Gostaria de convidar a comunidade a revisar e participar da discuss?o da proposta LAC-2026-3: Cobertura de ROAs v?lidos para a solicita??o de recursos adicionais. > > A proposta busca incentivar a ado??o do RPKI por meio de um requisito de cobertura m?nima de ROAs v?lidos para os recursos j? alocados, antes da solicita??o de recursos adicionais. O objetivo ? promover melhores pr?ticas que contribuam para a seguran?a e a resili?ncia do sistema de roteamento da Internet em nossa regi?o. > > Al?m disso, agora que o LACNIC j? oferece suporte para ASPA, gostaria de conhecer a opini?o da comunidade sobre se esse tipo de mecanismo tamb?m poderia contribuir para impulsionar sua ado??o. > > Voc?s consideram que, no futuro, deveria ser avaliado algum tipo de incentivo ou requisito relacionado ao ASPA, ou acreditam que sua ado??o deveria seguir um caminho diferente? > > Aguardarei seus coment?rios e sugest?es. > > Atenciosamente, > > > > ----- EN (Translated by AI) ----- > Hi everyone! > > I would like to invite the community to review and participate in the discussion of proposal LAC-2026-3: Valid ROA Coverage for Additional Resource Requests. > > The proposal seeks to encourage RPKI adoption through a minimum valid ROA coverage requirement for resources already allocated to an organization before additional resources can be requested. The goal is to promote best practices that contribute to the security and resilience of the Internet routing system in our region. > > Additionally, now that LACNIC supports ASPA, I would like to hear the community's opinion on whether this type of mechanism could also help drive ASPA adoption. Do you believe that some form of ASPA-related incentive or requirement should be considered in the future, or do you think ASPA adoption should follow a different path? > > I look forward to your comments and suggestions. > > Best regards, > > > Sergio Kleiman > > > > *** Clasificado P?BLICO por TELEF?NICA. *** Classified PUBLIC by TELEF?NICA. > *** Classificado como P?BLICO pela TELEF?NICA. *** Von TELEF?NICA als ?FFENTLICH eingestuft. > De: Sergio Kleiman Schwarzstein > Enviado el: jueves, 13 de agosto de 2026 11:16 > Para: 'politicas at lacnic.net' > Asunto: [LACNIC/Politicas] NP: LAC-2026-3 - ROA para solicitud de recursos > > ?Hola! > > Gracias a todos por sus comentarios. Estoy seguro de que nos ayudar?n a enriquecer y mejorar la propuesta. > > El objetivo de esta propuesta es que los miembros que ya cuentan con recursos IPv4 o IPv6 publiquen ROAs para dichos recursos antes de solicitar direccionamiento adicional. La intenci?n no es agregar complejidad al proceso de asignaci?n, sino fomentar la adopci?n de pr?cticas que contribuyan a la seguridad y resiliencia del ruteo en Internet. > > Quienes administramos recursos num?ricos tenemos la responsabilidad de protegerlos contra posibles usos indebidos o anuncios no autorizados. RPKI y los ROAs son excelentes herramientas que permiten reducir este riesgo, y la creaci?n de ROAs en el portal de miLACNIC es un proceso sencillo que normalmente requiere solo unos minutos. La intenci?n de tener un umbral del 80% es establecer un equilibrio razonable entre incentivar la adopci?n de ROAs y mantener flexibilidad operativa para los miembros. Este porcentaje permite demostrar que la gran mayor?a de los recursos se encuentra protegida mediante ROAs v?lidos, sin exigir una cobertura absoluta que podr?a resultar dif?cil de alcanzar en algunos escenarios operativos o durante procesos de transici?n. > > En otras palabras, el requisito busca promover una adopci?n significativa de RPKI, manteniendo al mismo tiempo un margen suficiente para evitar afectar innecesariamente las solicitudes leg?timas de recursos adicionales. > > Nuevamente, agradezco sus comentarios y espero continuar la discusi?n para identificar posibles mejoras al texto y al mecanismo propuesto. > > > Saludos, > > > ----- PT (Traduzido por IA) ----- > > Ol?, > > Obrigado a todos pelos coment?rios. Tenho certeza de que eles nos ajudar?o a enriquecer e aperfei?oar a proposta. > > O objetivo desta proposta ? que os membros que j? possuem recursos IPv4 ou IPv6 publiquem ROAs para esses recursos antes de solicitar endere?amento adicional. A inten??o n?o ? adicionar complexidade ao processo de aloca??o, mas sim incentivar a ado??o de pr?ticas que contribuam para a seguran?a e a resili?ncia do roteamento na Internet. > > N?s, que administramos recursos num?ricos, temos a responsabilidade de proteg?-los contra poss?veis usos indevidos ou an?ncios n?o autorizados. O RPKI e os ROAs s?o excelentes ferramentas para reduzir esse risco, e a cria??o de ROAs no portal miLACNIC ? um processo simples que normalmente leva apenas alguns minutos. A inten??o de estabelecer um limite de 80% ? encontrar um equil?brio razo?vel entre incentivar a ado??o de ROAs e manter flexibilidade operacional para os membros. Esse percentual permite demonstrar que a grande maioria dos recursos est? protegida por ROAs v?lidos, sem exigir uma cobertura absoluta que poderia ser dif?cil de alcan?ar em alguns cen?rios operacionais ou durante processos de transi??o. > > Em outras palavras, o requisito busca promover uma ado??o significativa do RPKI, mantendo ao mesmo tempo uma margem suficiente para evitar impactos desnecess?rios em solicita??es leg?timas de recursos adicionais. > > Mais uma vez, agrade?o os coment?rios e espero continuar a discuss?o para identificar poss?veis melhorias no texto e no mecanismo proposto. > > Atenciosamente, > > > ----- EN (Translated by AI) ----- > Hello, > > Thank you all for your comments. I am confident that they will help us enrich and improve the proposal. > > The goal of this proposal is for members who already hold IPv4 or IPv6 resources to publish ROAs for those resources before requesting additional address space. The intention is not to add complexity to the allocation process, but rather to encourage the adoption of practices that contribute to the security and resilience of Internet routing. > > Those of us who manage number resources have a responsibility to protect them against potential misuse or unauthorized route announcements. RPKI and ROAs are excellent tools for reducing this risk, and creating ROAs through the miLACNIC portal is a straightforward process that typically takes only a few minutes. The purpose of establishing an 80% threshold is to strike a reasonable balance between encouraging ROA adoption and maintaining operational flexibility for members. This percentage allows members to demonstrate that the vast majority of their resources are protected by valid ROAs without requiring absolute coverage, which may be difficult to achieve in certain operational scenarios or during transition periods. > > In other words, the requirement seeks to promote meaningful RPKI adoption while maintaining sufficient flexibility to avoid unnecessarily impacting legitimate requests for additional resources. > > Once again, I appreciate your comments and look forward to continuing the discussion in order to identify possible improvements to both the text and the proposed mechanism. > > Best regards, > > > Sergio Kleiman > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci?n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n puede estar prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su destrucci?n. > > The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat?rio, pode conter informa??o privilegiada ou confidencial e ? para uso exclusivo da pessoa ou entidade de destino. Se n?o ? vossa senhoria o destinat?rio indicado, fica notificado de que a leitura, utiliza??o, divulga??o e/ou c?pia sem autoriza??o pode estar proibida em virtude da legisla??o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui??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. From sergio.kleiman at telefonica.com Sun Oct 11 23:17:55 2026 From: sergio.kleiman at telefonica.com (Sergio Kleiman Schwarzstein) Date: Mon, 12 Oct 2026 02:17:55 +0000 Subject: [LACNIC/Politicas] NP: LAC-2026-3 - ROA para solicitud de recursos In-Reply-To: <9C93CBDC-5DD9-4702-AF63-4BAC8AA25417@theipv6company.com> References: <9C93CBDC-5DD9-4702-AF63-4BAC8AA25417@theipv6company.com> Message-ID: ?Hola Jordi! Gracias por tus comentarios. S?, como est? redactado aplica tambi?n para transferencias entrantes. S?, es posible agregarlo adicionalmente en 4.4.1.4 y7o 4.4.4.3 para clarificar. Esta propuesta introduje antes de que se pudieran crear objetos ASPA en miLACNIC; ahora que se puede, se podr?a incorporar a la redacci?n sin problema. Saludos, ----- PT (Traduzido por IA) ----- Ol?, Jordi! Obrigado pelos seus coment?rios. Sim, da forma como est? redigido, tamb?m se aplica ?s transfer?ncias recebidas. Sim, ? poss?vel acrescent?-lo adicionalmente nos itens 4.4.1.4 e/ou 4.4.4.3 para maior clareza. Introduzi esta proposta antes de ser poss?vel criar objetos ASPA no miLACNIC; agora que isso j? ? poss?vel, ela pode ser incorporada ? reda??o sem qualquer problema. Atenciosamente, ----- EN (Translated by AI) ----- Hello Jordi, Thank you for your comments. Yes, as currently drafted, it also applies to incoming transfers. Yes, it is possible to add it additionally to sections 4.4.1.4 and/or 4.4.4.3 for clarification. I introduced this proposal before ASPA objects could be created in miLACNIC; now that this is possible, it could be incorporated into the wording without any issue. Regards, Sergio Kleiman -----Mensaje original----- De: jordi.palet at theipv6company.com Enviado el: jueves, 8 de octubre de 2026 03:20 Para: Lista para discusion de politicas de la comunidad de LACNIC Asunto: Re: [LACNIC/Politicas] NP: LAC-2026-3 - ROA para solicitud de recursos Hola Sergio, Disculpas porque se me pas? el anuncio original de la propuesta. En principio de acuerdo con la propuesta. Entiendo que tal y como est? redactada, tambi?n aplicar?a para quien quiera recibir transferencias, dado que en estos casos tambi?n se pasa por el proceso de justificaci?n de necesidad. En el caso de IPv6, creo que apenas tiene impacto, pues si alguien necesita mas direcciones IPv6, en muchos casos ser? porque no planific? sus necesidades y se acogi? al ?/32 por defecto?, con lo cual la mejor alternativa en estos casos es acudir a una rectificaci?n (4.4.1.4 o 4.4.4.3). Lo comento, porque si no has tenido en cuenta este detalla, una (posible) mejora de la propuesta seria, en lugar de agregarlo al final del 4.4.2.1, que sea una secci?n nueva y modificar el texto para que tambi?n aplique en el caso de rectificaciones del espacio. Por otro lado, no s? si puedes comentar si hay alg?n motivo por el que tu propuesta solo est? contemplando distribuciones y no asignaciones directas por LACNIC? Creo que se debe fomentar tambi?n el uso de RPKI entre usuarios finales que reciben recursos directamente de LACNIC. Respecto del tema de ASPA, creo que tambi?n ser?a bueno incorporarlo, sin embargo tengo mis dudas de si hacerlo en el mismo plazo que esta propuesta (asumiendo que alcanzara consenso), o dar un poco mas de margen (lo cual podr?a incluirse como parte de la redacci?n, +6 meses, por poner un ejemplo). Es decir, no necesariamente hace falta una propuesta nueva posteriormente. Como comentario adicional, en diversas ocasiones hemos discutido propuestas para fomentar el uso de ?x?, creo que la que m?s se ha debatido ha sido el uso de IPv6. Hasta ahora, no hemos alcanzado consenso generalmente. Quiz?s esta propuesta nos sirve para reaccionar y pensar que exigir requisitos como el uso de medidas que aportan seguridad, estabilidad, escalabilidad y fiabilidad a Internet, como son RPKI e IPv6, son un beneficio para todos y deber?an ser de obligado cumplimiento, teniendo en cuenta que hay ya experiencia en estos campos y no son ya nuevas tecnolog?as, y que hay que despedirse, poco a poco, de nuestro viejo amigo ?legacy? IPv4. Saludos, Jordi @jordipalet > El 7 oct 2026, a las 20:41, Sergio Kleiman Schwarzstein via Politicas escribi?: > > ?Hola a todos! > > Me gustar?a invitar a la comunidad a revisar y participar en la discusi?n de la propuesta LAC-2026-3: Cobertura de ROAs v?lidas para la solicitud de recursos adicionales. > > La propuesta busca incentivar la adopci?n de RPKI mediante un requisito de cobertura m?nima de ROAs v?lidas para los recursos ya asignados, previo a la solicitud de recursos adicionales. El objetivo es promover mejores pr?cticas que contribuyan a la seguridad y resiliencia del sistema de enrutamiento de Internet en nuestra regi?n. > > Adicionalmente, ahora que LACNIC ya ofrece soporte para ASPA, me gustar?a conocer la opini?n de la comunidad sobre si este tipo de mecanismos tambi?n podr?an contribuir a impulsar su adopci?n. > > ?Consideran que deber?a evaluarse alg?n tipo de incentivo o requisito relacionado con ASPA, o creen que su adopci?n deber?a seguir un camino distinto? > > Espero sus comentarios y sugerencias. > > Saludos, > > > ----- PT (Traduzido por IA) ----- > Ol? a todos, > > Gostaria de convidar a comunidade a revisar e participar da discuss?o da proposta LAC-2026-3: Cobertura de ROAs v?lidos para a solicita??o de recursos adicionais. > > A proposta busca incentivar a ado??o do RPKI por meio de um requisito de cobertura m?nima de ROAs v?lidos para os recursos j? alocados, antes da solicita??o de recursos adicionais. O objetivo ? promover melhores pr?ticas que contribuam para a seguran?a e a resili?ncia do sistema de roteamento da Internet em nossa regi?o. > > Al?m disso, agora que o LACNIC j? oferece suporte para ASPA, gostaria de conhecer a opini?o da comunidade sobre se esse tipo de mecanismo tamb?m poderia contribuir para impulsionar sua ado??o. > > Voc?s consideram que, no futuro, deveria ser avaliado algum tipo de incentivo ou requisito relacionado ao ASPA, ou acreditam que sua ado??o deveria seguir um caminho diferente? > > Aguardarei seus coment?rios e sugest?es. > > Atenciosamente, > > > > ----- EN (Translated by AI) ----- > Hi everyone! > > I would like to invite the community to review and participate in the discussion of proposal LAC-2026-3: Valid ROA Coverage for Additional Resource Requests. > > The proposal seeks to encourage RPKI adoption through a minimum valid ROA coverage requirement for resources already allocated to an organization before additional resources can be requested. The goal is to promote best practices that contribute to the security and resilience of the Internet routing system in our region. > > Additionally, now that LACNIC supports ASPA, I would like to hear the community's opinion on whether this type of mechanism could also help drive ASPA adoption. Do you believe that some form of ASPA-related incentive or requirement should be considered in the future, or do you think ASPA adoption should follow a different path? > > I look forward to your comments and suggestions. > > Best regards, > > > Sergio Kleiman > > > > *** Clasificado P?BLICO por TELEF?NICA. *** Classified PUBLIC by TELEF?NICA. > *** Classificado como P?BLICO pela TELEF?NICA. *** Von TELEF?NICA als ?FFENTLICH eingestuft. > De: Sergio Kleiman Schwarzstein > Enviado el: jueves, 13 de agosto de 2026 11:16 > Para: 'politicas at lacnic.net' > Asunto: [LACNIC/Politicas] NP: LAC-2026-3 - ROA para solicitud de > recursos > > ?Hola! > > Gracias a todos por sus comentarios. Estoy seguro de que nos ayudar?n a enriquecer y mejorar la propuesta. > > El objetivo de esta propuesta es que los miembros que ya cuentan con recursos IPv4 o IPv6 publiquen ROAs para dichos recursos antes de solicitar direccionamiento adicional. La intenci?n no es agregar complejidad al proceso de asignaci?n, sino fomentar la adopci?n de pr?cticas que contribuyan a la seguridad y resiliencia del ruteo en Internet. > > Quienes administramos recursos num?ricos tenemos la responsabilidad de protegerlos contra posibles usos indebidos o anuncios no autorizados. RPKI y los ROAs son excelentes herramientas que permiten reducir este riesgo, y la creaci?n de ROAs en el portal de miLACNIC es un proceso sencillo que normalmente requiere solo unos minutos. La intenci?n de tener un umbral del 80% es establecer un equilibrio razonable entre incentivar la adopci?n de ROAs y mantener flexibilidad operativa para los miembros. Este porcentaje permite demostrar que la gran mayor?a de los recursos se encuentra protegida mediante ROAs v?lidos, sin exigir una cobertura absoluta que podr?a resultar dif?cil de alcanzar en algunos escenarios operativos o durante procesos de transici?n. > > En otras palabras, el requisito busca promover una adopci?n significativa de RPKI, manteniendo al mismo tiempo un margen suficiente para evitar afectar innecesariamente las solicitudes leg?timas de recursos adicionales. > > Nuevamente, agradezco sus comentarios y espero continuar la discusi?n para identificar posibles mejoras al texto y al mecanismo propuesto. > > > Saludos, > > > ----- PT (Traduzido por IA) ----- > > Ol?, > > Obrigado a todos pelos coment?rios. Tenho certeza de que eles nos ajudar?o a enriquecer e aperfei?oar a proposta. > > O objetivo desta proposta ? que os membros que j? possuem recursos IPv4 ou IPv6 publiquem ROAs para esses recursos antes de solicitar endere?amento adicional. A inten??o n?o ? adicionar complexidade ao processo de aloca??o, mas sim incentivar a ado??o de pr?ticas que contribuam para a seguran?a e a resili?ncia do roteamento na Internet. > > N?s, que administramos recursos num?ricos, temos a responsabilidade de proteg?-los contra poss?veis usos indevidos ou an?ncios n?o autorizados. O RPKI e os ROAs s?o excelentes ferramentas para reduzir esse risco, e a cria??o de ROAs no portal miLACNIC ? um processo simples que normalmente leva apenas alguns minutos. A inten??o de estabelecer um limite de 80% ? encontrar um equil?brio razo?vel entre incentivar a ado??o de ROAs e manter flexibilidade operacional para os membros. Esse percentual permite demonstrar que a grande maioria dos recursos est? protegida por ROAs v?lidos, sem exigir uma cobertura absoluta que poderia ser dif?cil de alcan?ar em alguns cen?rios operacionais ou durante processos de transi??o. > > Em outras palavras, o requisito busca promover uma ado??o significativa do RPKI, mantendo ao mesmo tempo uma margem suficiente para evitar impactos desnecess?rios em solicita??es leg?timas de recursos adicionais. > > Mais uma vez, agrade?o os coment?rios e espero continuar a discuss?o para identificar poss?veis melhorias no texto e no mecanismo proposto. > > Atenciosamente, > > > ----- EN (Translated by AI) ----- > Hello, > > Thank you all for your comments. I am confident that they will help us enrich and improve the proposal. > > The goal of this proposal is for members who already hold IPv4 or IPv6 resources to publish ROAs for those resources before requesting additional address space. The intention is not to add complexity to the allocation process, but rather to encourage the adoption of practices that contribute to the security and resilience of Internet routing. > > Those of us who manage number resources have a responsibility to protect them against potential misuse or unauthorized route announcements. RPKI and ROAs are excellent tools for reducing this risk, and creating ROAs through the miLACNIC portal is a straightforward process that typically takes only a few minutes. The purpose of establishing an 80% threshold is to strike a reasonable balance between encouraging ROA adoption and maintaining operational flexibility for members. This percentage allows members to demonstrate that the vast majority of their resources are protected by valid ROAs without requiring absolute coverage, which may be difficult to achieve in certain operational scenarios or during transition periods. > > In other words, the requirement seeks to promote meaningful RPKI adoption while maintaining sufficient flexibility to avoid unnecessarily impacting legitimate requests for additional resources. > > Once again, I appreciate your comments and look forward to continuing the discussion in order to identify possible improvements to both the text and the proposed mechanism. > > Best regards, > > > Sergio Kleiman > > ________________________________ > > Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci?n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n puede estar prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su destrucci?n. > > The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. > > Esta mensagem e seus anexos se dirigem exclusivamente ao seu > destinat?rio, pode conter informa??o privilegiada ou confidencial e ? > para uso exclusivo da pessoa ou entidade de destino. Se n?o ? vossa > senhoria o destinat?rio indicado, fica notificado de que a leitura, > utiliza??o, divulga??o e/ou c?pia sem autoriza??o pode estar proibida > em virtude da legisla??o vigente. Se recebeu esta mensagem por erro, > rogamos-lhe que nos o comunique imediatamente por esta mesma via e > proceda a sua destrui??o > _______________________________________________ > Politicas mailing list > Politicas at lacnic.net > https://protect.checkpoint.com/v2/r02/___https://mail.lacnic.net/rfnqr > fsdqnxynsktdutqnynhfx___.YzJlOnRlbGVmb25pY2FtZXhpY286YzpvOmU0MTcwYzA2N > GVhMDE3MjJmMmIwMWYwOWM0ZjMxY2VjOjc6MzNhYjo5NTEyZTUxMTk0OThmMDk3MzkxYmJ > iNDIwODU0ODEzYTliODk4ZGU0ZmZlOWNhODI5NTU4MTM1NmIwZGY0MmViOnA6VDpU > Desuscribirse/Descadastre-se/Unsubscribe: > https://protect.checkpoint.com/v2/r02/___https://mail.lacnic.net/rfnqr > fsdtuyntsxdutqnynhfx___.YzJlOnRlbGVmb25pY2FtZXhpY286YzpvOmU0MTcwYzA2NG > VhMDE3MjJmMmIwMWYwOWM0ZjMxY2VjOjc6M2EyZjo1MjVkZmRkOTdmODk0NzIwYjkwODFl > N2E5YTQ4MWIxMWUyYmUwYjk2NjUwNjY1ZWJiY2VhY2YwMTViNGM3MjJlOnA6VDpU > > El Codigo de Conducta de la Comunidad de LACNIC (https://protect.checkpoint.com/v2/r02/___https://rir.la/htinlthtsizhyf-XU___.YzJlOnRlbGVmb25pY2FtZXhpY286YzpvOmU0MTcwYzA2NGVhMDE3MjJmMmIwMWYwOWM0ZjMxY2VjOjc6NTE5NzowNmM0MjIxODQ3MWJmYzVjOTU1OWYyMGExYWJhYTY3N2ZmYTI1MTc1YjQ2MDRhNjY0Y2Y5MDA3YzA0NTFiODQyOnA6VDpU) aplica a las listas de discusion de LACNIC. > O Codigo de Conduta da Comunidade do LACNIC (https://protect.checkpoint.com/v2/r02/___https://rir.la/htinlthtsizhyf-UY___.YzJlOnRlbGVmb25pY2FtZXhpY286YzpvOmU0MTcwYzA2NGVhMDE3MjJmMmIwMWYwOWM0ZjMxY2VjOjc6ZDk3ZjphODg2M2Q4NTA1ZGUzYTNlNjY2YTU4YWU1MWI3NDk5MTdmYjQ0NWFkY2IwY2RlNmUwZTczMmJkNWMxNjVjMWMyOnA6VDpU) se aplica as listas de discussao do LACNIC. > LACNIC's Community Code of Conduct (https://protect.checkpoint.com/v2/r02/___https://rir.la/htinlthtsizhyf-JS___.YzJlOnRlbGVmb25pY2FtZXhpY286YzpvOmU0MTcwYzA2NGVhMDE3MjJmMmIwMWYwOWM0ZjMxY2VjOjc6ZTgwNTo3MzA4YjNiMzYxYzMzNThjODBjYTdjYzg2ZmZiNzUyYWJkOTZjYzJjOTRiZjU4YzlkZWFlOTVjMDkxN2Q2NzFlOnA6VDpU) applies to LACNIC's discussion lists. > ********************************************** IPv4 is over Are you ready for the new Internet ? https://protect.checkpoint.com/v2/r02/___http://www.theipv6company.com___.YzJlOnRlbGVmb25pY2FtZXhpY286YzpvOmU0MTcwYzA2NGVhMDE3MjJmMmIwMWYwOWM0ZjMxY2VjOjc6NjQ4MTozNDdkNGExZTBmMTRmMWU0MGM4ZmVjMDMzZmZkNzliMmYyMTc5NGZmNjdhMWNmM2ZmMTlkZmQ4YWJmMmNkYWU1OnA6VDpU 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. ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener informaci?n privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n puede estar prohibida en virtud de la legislaci?n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma v?a y proceda a su destrucci?n. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat?rio, pode conter informa??o privilegiada ou confidencial e ? para uso exclusivo da pessoa ou entidade de destino. Se n?o ? vossa senhoria o destinat?rio indicado, fica notificado de que a leitura, utiliza??o, divulga??o e/ou c?pia sem autoriza??o pode estar proibida em virtude da legisla??o vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destrui??o