[LACNIC/Politicas] LAC-2012-10
Alejandro Rodriguez
arodriguez at b2ec.net
Wed Sep 12 16:52:36 BRT 2012
Me parece que en la discusión de esta política hay 2 puntos de vista.
#1 Punto de vista practico.
Administran recursos propios y/o conocen el accionar diario de los
operadores.
#2 Punto de vista académico.
Interesados en promover la adopción de nuevas tecnologías.
Me parece que va ser imposible reconciliar estos dos puntos de vista y
llegar a un consenso.
Quizás seria mejor dividir entre politicas y BCP . Lacnic podría tener
un documento de BCP en su web.
salu2
Ing. Alejandro Rodriguez
Gerente Técnico
Stealth Telecom del Ecuador
Telf: 2453156 / 2248233/ 2248887
El 12/09/2012 9:41, Gustavo Lozano escribió:
> Clarificando,
>
> Mi comentario respecto a los bugs es que no existe un sistema 100% libre de
> bugs, y que una tecnologia alcanza madurez mediante pruebas y un despliegue
> ordenado y paulatino.
>
> 2012/9/12 Gustavo Lozano <glozano.gli at gmail.com>
>
>> Hola Roque,
>>
>> No he visto en tu propuesta o en los siguientes correos porque debemos
>> forzar una tecnologia X o Y; y no dejar que los operadores que viven la
>> realidad operativa decidan cuando es el mejor momento de implementarla.
>>
>> Comentarios entre lineas.
>>
>> 2012/9/10 Roque Gagliano (rogaglia) <rogaglia at cisco.com>
>>
>>> Hola Gustavo,
>>>
>>> Creo que comparar la resolucion inversa con RPKI es como comparar peras
>>> con
>>> manzanas. Haciendo una analogia (con todo lo problematico que tienen las
>>> anologias), una mejor comparacion seria que los TLDs le dijeran a sus
>>> clientes que no podran renovar sus dominios si no implementan DNSSEC.
>>>
>>> Exacto!, por eso ICANN le obliga a los nuevos gTLD a soportar DNSSEC (
>>> http://newgtlds.icann.org/en/applicants/agb) o incluso el NIC.BR<
>>> http://NIC.BR> obliga a quienes registran en b.br<http://b.br> a
>>> soportar DNSSEC (http://www.nic.br/atividades/dom-bbr.htm).
>>>
>>>
>> La explicacion de Ricardo es clara al respecto.
>>
>>
>> Los TLDs y los RIRs son los eslabones de la parte superior de la cadena,
>> soportan las nuevas tecnologias y nadie esta forzando a los usuarios
>> finales existentes a implementar cierta tecnologia o en su defecto tener
>> repercuciones negativas (no obtener mas recursos por ejemplo), entonces
>> hasta el momento es una igualdad de circunstancias operativas.
>>
>> Mi punto es pasar a tomar una medida activa de promoción para transitar el
>>> camino hacia RPKI y sortear los problemas administrativos. Y si vamos a ser
>>> pioneros....vamos! Lo único que estamos pidiendo es a los miembros que
>>> registren el ASN de origen que usan....
>>>
>>>
>> Creo que todos estamos a favor de implementar nuevas tecnologias pero
>> siguiendo el camino de analisis e implementacion paulatina que demandan los
>> servicios criticos.
>>
>>
>>> Las tecnologias son adoptadas cuando llegan a su madurez y existe una
>>> relacion positiva en el costo/beneficio al utilizarlas.
>>>
>>> Vamos a suponer que tu propuesta es aceptada.
>>>
>>>
>>> Las tecnologias tienen un ciclo tecnologico, en el caso de RPKI estamos en
>>> la etapa de los innovadores y van a pasar años para que llegue a la
>>> madurez.
>>>
>>> El paso que una tecnología se adopta no tiene una escala de años o
>>> tiempos. La mente humana trabaja en forma lineal, pero las tecnologías
>>> pueden avanzar a razón exponencial. Y no debemos olvidar que LACNIC está
>>> invirtiendo activamente (y me refieron a $ de verdad) desde el año 2006 y
>>> tiene un sistema operativo desde el 2009.
>>>
>>> RPKI tiene una característica muy distinta que DNSSEC: sólo se necesita
>>> que 50K entidades lo adopten en el mundo, comparado con los millones para
>>> DNSSEC. Por eso, el desarrollo puede ser mucho más rápido de lo que te
>>> imaginas.
>>>
>>> En esta misma línea, nuestra región sólo tiene que conseguir la adopción
>>> de unas 3000 entidades. Porqué tener que condenarnos a ser seguidores si
>>> podemos ser pioneros? Piénsalo, estamos a sólo unos 6000 clicks en una
>>> página web para que cubramos toda la región!!! Porqué conformarnos con
>>> menos? Es más la gran mayoría de entidades tienen un sólo ASN y un sólo
>>> prefijo...entiendo tus argumentos pero los beneficios son tan grandes que
>>> me parece que estás tapando el océano.
>>>
>>> Y debe agregar dos puntos:
>>> - Esta política va a ser necesaria de todas maneras para intentar
>>> compensar el problema de la vejez de la información de registro, algo que
>>> ya discutimos con Ricardo. Entonces sabemos que vamos a necesitarla en el
>>> futuro, para qué esperar?
>>> - LACNIC tiene el proceso de desarrollo de políticas más flexible que
>>> conozco, si el costo para los ISPs es tan grande que no se pueda soportar o
>>> si realmente no da resultados....tenemos muchas herramientas para volver
>>> atrás! incluso con el proceso expeditivo....en 6 semanas lo podemos
>>> desarmar!
>>>
>>>
>>>
>>> Lo que estas forzando es que los operadores de la region es que asuman
>>> riesgos innecesarios al implementar una parte de RPKI.
>>>
>>>
>>> Actualmente si no creo ROAs para mis prefijos seran clasificados como
>>> UNKNOWN. Si me forzas a usar RPKI entonces mis prefijos solo tienen dos
>>> posibles estados VALID o INVALID.
>>>
>>>
>>> Los prefijos clasificados como UNKNOWN seran clasificados como VALID
>>> mientras la tecnologia no alcance madurez, lo cual es logico, no
>>> implemento
>>> la tecnologia por lo tanto no existe riesgo para mi operacion. Cualquier
>>> operador no quiere poner en riesgo su operacion y la mayoria no van a
>>> crear
>>> ROAs hasta que la tecnologia alcance madurez, sea una practica comun, su
>>> personal este capacitado para poder realizar troubleshooting, etc. Dudo
>>> mucho que la infraestructura actual de RPKI pueda ser considerada carrier
>>> grade para forzar la tecnologia a los operadores.
>>>
>>> Esto es incorrecto.
>>>
>>>
>> Creo que mi mensaje anterior no fue claro.
>>
>>
>> Para que RPKI sea despleagado se necesitan dos cosas:
>>
>>
>> - Que los operadores validen rutas.
>> - Que los operadores generen objetos.
>>
>> Si actualmente no genero objetos ROAs estoy en el status quo, entonces
>> no estoy mas seguro, ni menos inseguro, estoy en el estado UNKNOWN desde la
>> persepectiva de los validadores.En el estado UNKNOWN estoy expuesto a los
>> problemas existentes de hijacking de rutas, en pocas palabras mi exposicion
>> al riesgo es igual. Recordemos que solamente yo puedo generar objetos ROAs
>> para mis prefijos.
>>
>>
>> Conforme los operadores desplieguen los validadores, no van a castigar a
>> los UNKNOWN en un principio. Despues de años, la practica comun sera
>> castigar a los UNKNOWN, y este es el momento donde la realidad operativa
>> forza a un operador a generar objetos.
>>
>>
>> Implementar tu propuesta significa:
>>
>>
>>
>> - Que tengo personal capacitado y herramientas para poder depurar
>> cualquier problema que puedan presenter mis prefijos con operadores que
>> validen rutas. En otras palabras, la queja de un cliente de no puedo
>> accesar a una pagina y mi amigo que usa otro ISP si puede, requeriria
>> incluir en la ecuacion la depuracion de RPKI.
>> - Que no tengo oportunidad de evaluar o modificar mis sistemas para
>> desplegar una parte de RPKI, quizas quiero generar los objetos desde mi
>> sistema de aprovisionamiento, por ejemplo.
>> - Que confio plenamente que el sistema de LACNIC funciona
>> adecuademente. El equipo de TI de LACNIC esta conformado por personas
>> excelentes y capaces, pero los bugs existen y los sistemas maduran con
>> pruebas, pruebas y pruebas. Por ejemplo, LACNIC todavia esta trabajando en
>> el CPS, http://lacnic.net/en/rpki/cps/, lo cual es logico porque el
>> despliegue de una nueva tecnologia es paulatina.
>>
>>
>> Las tecnologias se implementan paulatinamente, analizando riesgos, tomando
>> decisiones de costo/beneficio, no por mandato como lo pretende hacer tu
>> propuesta.
>>
>>
>> Saludos,
>> Gustavo
>>
>>
>>> Primero, la creación de los ROAs no tiene ninguna relación con la
>>> implementación de la validación de rutas en un proveedor. Yo puedo crear
>>> mis ROAs pero no realizar validación de rutas.
>>>
>>> Si una entidad genera sus ROAs, otra entidad (o ella misma) puede
>>> utilizar esta información para generar políticas de rutamiento. La entidad
>>> que crea el ROA no tienen control sobre qué política la entidad que utiliza
>>> esa información establecerá. Las políticas para VALID/NOT FOUND/INVALID son
>>> locales para entidad por lo que tu descripción es incorrecta y no refleja
>>> la implementación que al menos estoy (muy) familiarizado de validación de
>>> origen. Es más, existen mejores prácticas que establecen exactamente lo
>>> contrario a lo que tu escribes.
>>>
>>> Ref: http://tools.ietf.org/html/draft-ietf-sidr-origin-ops-19#section-5
>>> "Announcements with Valid origins SHOULD be preferred over those with
>>> NotFound or Invalid origins, if the latter are accepted at all."
>>>
>>> Roque
>>>
>>>
>>>
>>> Saludos,
>>> Gustavo
>>>
>>> 2012/9/7 Roque Gagliano (rogaglia) <rogaglia at cisco.com<mailto:
>>> rogaglia at cisco.com>>
>>>
>>> Gustavo,
>>>
>>> Me parece que la diferencia radica en que yo veo la generación de material
>>> criptográfico como una inherente a la función misma de LACNIC y no una
>>> tecnología foránea que uno fuerza. O acaso se deberá dejar de pedir que
>>> cumpla con la resolución inversa?
>>>
>>> Roque
>>>
>>> On Sep 7, 2012, at 4:18 PM, Gustavo Lozano wrote:
>>>
>>> Roque,
>>>
>>> Comentarios entre lineas.
>>>
>>> 2012/9/7 Roque Gagliano (rogaglia) <rogaglia at cisco.com<mailto:
>>> rogaglia at cisco.com>>
>>>
>>> Hola Gustavo,
>>>
>>> Gracias por el comentario.
>>>
>>> Yo creo que LACNIC podría generar certificados CA en forma automática
>>> sin
>>> necesidad de una política para todos sus miembros, pues esto es una
>>> simple
>>> extensión de su rol de registro (o notario). Pero esto no ayuda a que el
>>> resto del mundo pueda utilizar esta información a menos que también se
>>> generen los ROAs correspondientes y este paso no se puede hacer
>>> automático
>>> pues muchos proveedores tienen más de un ASN registrado u otras
>>> peculiaridades.
>>>
>>>
>>> Si realmente RPKI es valioso para los operadores entonces ellos mismos se
>>> van a preocupar por generar los objetos que necesiten de forma correcta y
>>> por las personas informadas sobre el tema en la organizacion y no
>>> simplemente por cumplir un requisito dando clicks como detallas en tu
>>> propuesta.
>>>
>>> Mi punto es que queremos utilizar las politicas para forzar tecnologias
>>> en
>>> el mercado.
>>>
>>> Esta comunidad tiene un foco: la asignación de recursos (IPs y ASN) y por
>>> lo tanto tiene un rol e impacto clave en el desarrollo de RPKI. No es lo
>>> mismo para esta comunidad RPKI que FTTH o Cloud o DNSSEC. Incluso ya hay
>>> hoy propuestas sobre la mesa (como LAC-2011-08) para buscar nuevos usos
>>> de
>>> este recurso.
>>>
>>>
>>> Roque lo de FTTH y certificaciones fue un chiste :).
>>>
>>> Entrando en materia, http://lacnic.net/sp/sobre-lacnic/estatuto/i.html,
>>> en
>>> ningun lado dice forzar tecnologias en el mercado.
>>>
>>> La propuesta es un paso muy modesto (pero a mi entender eficaz) para
>>> acelerar el desarrollo de lo que debemos tener consenso va a ser una
>>> nueva
>>> práctica en la industria. Nosotros ya aplicamos esta mismo estrategia
>>> con
>>> IPv6! Comenzamos a exigir muy poco ("tener un plan") y luego fuimos
>>> evaluando el impacto e incrementando los requerimientos....Mi propuesta
>>> es
>>> comenzar ese mismo camino para RPKI, de vuelta con un paso muy modesto y
>>> prácticamente sin costo para el operador. LACNIC puede ayudar con
>>> material
>>> didáctico específico para cumplir con este requerimiento.
>>>
>>>
>>>
>>> No es un paso modesto, es un requisito extra y sin sentido para pedir
>>> recursos.
>>>
>>> Si va a ser una nueva practica en la industria entonces que la industria
>>> lo
>>> adopte como buena practica, no es necesario una politica para crear
>>> buenas
>>> practicas. En teoria es una buena practica agregar tus bloques y quitamos
>>> toda referencia a lo mismo porque son politicas de asignacion de
>>> recursos,
>>> no un conjunto de buenas practicas.
>>>
>>> LACNIC puede crear el material didactico y mandarlo por email,
>>> presentarlo
>>> en talleres, etc, tenemos que entender que las tecnologias son adoptadas
>>> no
>>> forzadas.
>>>
>>> Roque
>>>
>>>
>>>
>>> On Sep 7, 2012, at 1:37 AM, Gustavo Lozano wrote:
>>>
>>> Hola a todos,
>>>
>>>
>>>
>>> Estoy en contra de la propuesta.
>>>
>>>
>>>
>>> Parece que seguimos viendo las políticas de LACNIC como el método para
>>> forzar la adopción de nuevas tecnologías.
>>>
>>>
>>>
>>> Recordemos que ya pasamos por una propuesta no aceptada que requería la
>>> implementación de IPv6 para obtener recursos.
>>>
>>>
>>>
>>> También recuerdo que aprobamos una propuesta para eliminar los términos
>>> de
>>> agregación de bloques con la justificación que en las políticas no
>>> deben
>>> existir requerimientos técnicos.
>>>
>>>
>>>
>>> El objetivo de la propuesta es:
>>>
>>> * educar sobre el RPKI y seguridad en el sistema global de
>>> enrutamiento.
>>>
>>> Propongo entonces que LACNIC mande un email cada "x" tiempo explicando
>>> lo
>>> que es RPKI a los tomadores de decisión o que publique anuncios en los
>>> diarios u otras miles de formas para dar a conocer un tema a una
>>> audiencia.
>>>
>>>
>>>
>>> * inducir la generación de material criptográfico en el RPKI.
>>>
>>> Propongo que se generen objetos en el sistema de forma automática si
>>> creemos que eso agrega valor.
>>>
>>>
>>>
>>> No estoy de acuerdo en usar las políticas para ayudar o forzar el
>>> despliegue de ciertas tecnologías. Ahora bien si creemos que las
>>> políticas
>>> pueden ser usadas para promocionar tecnologías entonces podríamos tener
>>> propuestas que para obtener recursos adicionales necesitas:
>>>
>>> * Activar DNSSEC en tus zonas de reserva.
>>>
>>> * Si quieres IP para hosting entonces que tu hosting ofrezca IPv6 y
>>> DNSSEC.
>>>
>>> * Si eres una telefónica entonces implementa FiOS para el x% de tus
>>> clientes.
>>>
>>> * Tienes que tener al menos un empleado certificado en x o y
>>> tecnología.
>>>
>>> * etc, etc.
>>>
>>>
>>>
>>> El tema de RPKI resulta además delicado porque por muchas personas es
>>> visto
>>> como el mecanismo para que los RIRs sigan obteniendo recursos cuando
>>> IPv4
>>> sea historia y con un bloque de IPv6 sea suficiente para la operación
>>> de
>>> un
>>> ISP por décadas.
>>>
>>> Saludos,
>>> Gustavo Lozano
>>>
>>> 2012/9/6 Nicolas Antoniello <nantoniello at gmail.com<mailto:
>>> nantoniello at gmail.com>>
>>>
>>> Alejandro, Carlos, Roque, todos,
>>>
>>> Agrego algun comentario a los que mencionaba antes:
>>>
>>> - Por un lado, no veo bien el indicar "no hacer algo" hasta que el
>>> resto lo
>>> haga... así claramente no se avanza (en mi opinión es como el problema
>>> de
>>> los comezales en la mesa con menos cubietos que comenzales... si todos
>>> esperan no come nadie, pero no todos pueden comer al mismo tiempo...
>>> en
>>> fin).
>>> Desde ese punto de vista, no veo que el espíritu de la propuesta de
>>> Roque
>>> sea "imponer requerimientos técnicos vía políticas"... sino que más
>>> bien es
>>> un tema de "lo que implica".
>>>
>>> - El rotuer en todo caso dialoga con el repositorio de RPKI para
>>> realizar
>>> la eventual verificación, pero creo que en lo que a hardware respecta
>>> no se
>>> requeriría mayor cambio... más biene es un tema de software.
>>>
>>> ... pero todo eso es más bien técnico...
>>>
>>>
>>> - RPKI claramente tiene usos independientemente de que los routers
>>> verifiquen ROA y los mismos son eventualmente totalmente externos a
>>> los
>>> routers... eso de alguna manera quería indicar en los comentarios
>>> anteriores.
>>>
>>> En definitiva, Roque, tal vez una aproximación que podría resultar más
>>> aceptada (que comentábamos off-line con Carlos M.) podría ser incluir
>>> en
>>> una primer aproximación de política que lo que se solicite al recibir
>>> la
>>> delegación de un prefijo sea la generación de los certificados (el
>>> tema
>>> del
>>> mantenimiento de los mismos vuelve a la mesa de debate, pero eso
>>> entiendo
>>> que es un problema que ya existe con muchos otros recursos o
>>> sistemas).
>>>
>>> Luego, la generación de los ROA si implica una desición de ruteo, pues
>>> allí
>>> se incluye el AS que estaría "autorizado" a generar el prefijo... tal
>>> vez
>>> ese es el punto en que se "filtra" algo más técnico pues implica
>>> deciciones
>>> de ruteo.
>>>
>>> De todas formas en algún momento hay que generar los ROA si lo que se
>>> quiere es validar el origen...
>>>
>>> No me estoy expresando ni a favor ni en contra, sino que planteo
>>> opciones a
>>> la redacción de la política, que podrían resultar más aceptables en
>>> vista
>>> de los comentarios expuestos en la lista.
>>>
>>> Roque?
>>>
>>> Saludos,
>>> Nico
>>>
>>>
>>>
>>>
>>>
>>> 2012/9/6 Alejandro Rodriguez <arodriguez at b2ec.net<mailto:
>>> arodriguez at b2ec.net>>
>>>
>>> Estimados:
>>>
>>> No estoy de acuerdo de acuerdo con esta política. Se esta tratando de
>>> imponer un requerimiento técnico para la solicitud de recursos
>>> adicionales.
>>> Para requerimiento técnico se utiliza un standard de baja adopción y
>>> que
>>> prácticamente nadie utiliza. Al final lo se lograría es aumentar el
>>> costo
>>> administrativo a los ISP , sin prácticamente ningún beneficio. Quizás
>>> en
>>> 5
>>> años, si la adopción de RPKI es masiva, esta política tendría
>>> sentido.
>>>
>>> alguna consideraciones a tener en cuenta:
>>> - Un router que necesite verificar el ROA de 300k rutas, va necesitar
>>> un
>>> hardware mas potente que uno que no realice esta función . O se mas
>>> $$$$.
>>> Por ello no me parece que de forma masiva se vaya a implementar RPKI
>>> en
>>> un
>>> futuro cercano.
>>> - De lo que entiendo el único fabricante que en estos momentos
>>> soporta
>>> RPKI es Cisco. ¿ Se debe implementar una política que beneficie a un
>>> solo
>>> fabricante ?
>>> - Capacitación. Aprobar esta política implica que todos los
>>> responsables
>>> de recursos deben tener conocimientos de RPKI.
>>>
>>>
>>> saludos
>>>
>>> Alejandro Rodriguez
>>> Gerente Tecnico
>>> Stealth Telecom del Ecuador
>>> www.stealthtelecom.net<http://www.stealthtelecom.net>
>>> Telf: 2248233 / 2248887
>>>
>>> El 06/09/2012 13:53, Carlos M. martinez escribió:
>>>
>>> Hola!
>>>
>>> Quiero hacer únicamente algunos comentarios sobre la tecnología y no
>>> sobre la política:
>>>
>>> - No hay que mezclar el concepto de validación de origen (lo que
>>> hacen
>>> los routers) con el concepto de la RPKI.
>>>
>>> - En el contexto de la política, la RPKI es otra base de datos y
>>> puede
>>> no tener ningún impacto operativo.
>>>
>>> Algunos otros comentarios entre líneas:
>>>
>>>
>>> On 9/6/12 2:44 PM, Nicolas Antoniello wrote:
>>>
>>> set chair hat == off;
>>>
>>> Estimados,
>>>
>>> Expongo mi o mis punto/s de vista:
>>>
>>> Si bien la tecnología (por decirlo de alguna manera) de RPKI es una
>>> solución a una parte de los problemas de BGP (tal y como intenta
>>> serlo
>>> BGPsec para otros problemas de seguridad; y si bien RPKI en
>>> comparación
>>> con
>>> BGPsec y otras propuestas está bastante más "aceptado" hoy día (no
>>> era
>>> así
>>> hace unos años)... creo que aún hoy no es "la" tecnología definida
>>> y
>>> aceptada por todos para asegurar el origen de los prefijos.
>>>
>>> Al dia de hoy casi todas las propuestas girar alrededor de la PKI
>>> de
>>> recursos. Hay únicamente otra propuesta que involucra el uso del DNS
>>> reverso pero no esta teniendo gran apoyo. En mi opinión, esta si ya
>>> bastante establecido que la PKI de recursos es una componente
>>> fundacional de las propuestas de enrutamiento seguro de los próximos
>>> 5 o
>>> mas años.
>>>
>>>
>>> Incluso recien hace muy poco tiempo un fabricante publicó la
>>> incorporación
>>> del soporte a sus routers, para chequeo de RPKI en algunos de sus
>>> sistemas
>>> operativos... con esto quiero decir que aún falta camino por
>>> recorrer.
>>> Si bien aunque no se tenga soporte de los sistemas operativos en
>>> los
>>> routers, es posible utilizar los ROA para disparar alarmas, etc...
>>> es
>>> decir, que aún sin el soporte completo por parte de los routers, el
>>> sistema
>>> es útil; creo que no está lo suficiente maduro como para asumir que
>>> va
>>> a
>>> ser la solución aceptada y determinar o pretender impulsarla desde
>>> una
>>> política.
>>>
>>> Al dia de hoy los routers no 'chequean RPKI', los routers arman una
>>> tablita y comparan los UPDATES de BGP contra esa tablita. Creo que
>>> la
>>> falta o no de soporte de validación de origen en los enrutadores es
>>> ortogonal al mérito o no de la política.
>>>
>>> Por un lado, sigo siendo reticente a que por política se incluyan
>>> cuestiones que o bien sean abietamente temas técnicos o bien
>>> indirectamente
>>> cubran aspectos técnicos u operativos que sean ajenos a los que
>>> rijan
>>> asignaciónes, gestión o manejo de recursos de los RIR/NIR.
>>>
>>> Por otro lado, alguien podría entender que la generación de los ROA
>>> está
>>> directamente relacionada con el recurso (en este caso un prefijo
>>> IP)
>>> y
>>> por
>>> lo tanto, podría estar dentro de la política de un RIR la
>>> "securización"
>>> o
>>> "autenticación" de las asignaciones... pero entonces, debería
>>> explicitarse
>>> un mecanismo de mantenimiento/actualización de los ROA, ya que si
>>> la
>>> info.
>>> se vuelve obsoleta por "aging" no tiene sentido que esté en una
>>> política
>>> (sigamos la idea de que no parecen tener mucho sentido políticas
>>> que
>>> desde
>>> su planteo se sepa que son "inaplicables" o "inverificables" por
>>> parte
>>> de
>>> los RIR/NIR).
>>>
>>>
>>> Entonces, ¿Qué opina el resto de la lista?
>>>
>>> Frateno saludo,
>>> Nico
>>>
>>>
>>>
>>> 2012/9/6 Ricardo Patara <patara at registro.br<mailto:patara at registro.br>>
>>>
>>> Hola Roque,
>>>
>>> 1) Valides de la información:
>>> Entiendo que tu comentario era sobre la "forma" de los objetos
>>> firmados. Obviamente si alguien usa el sistema "hospedado" de
>>> LACNIC
>>> o
>>> de un NIR esto está descartado. Por eso no lo consideré en la
>>> propuesta
>>> original. Es cierto que si alguien administra su propia entidad
>>> certificadora, sería bueno hacer un chequeo. Aquí estamos
>>> hablando
>>> de
>>> chequear los objetos.
>>>
>>> No solamente cuanto a la forma, pero que la información sea
>>> "correcta".
>>> Por ejemplo. Para una ROA, que de hecho figure allá el ASN por
>>> lo
>>> cual
>>> el ISP va a originar sus anuncios. Y eso implica en trabajo
>>> extra
>>> para
>>> los RIR/NIRs.
>>> Y
>>>
>>> (Roque) Me estas mezclando de vuelta. La política no pide a los
>>> RIR/NIR que verique nada del ASN que el miembro ingresó.
>>> Verificar
>>> la
>>> "forma" viene gratis en las herramientas existentes. Además, TODA
>>> política tiene costos para los RIR/NIRs.
>>>
>>> no. mi punto es que bajo la presion para obtener recursos
>>> adicionales
>>> uno puede poner lo que quiera en un objeto ROA, por ejemplo
>>> ( y eso tiene relación también con la calidad de la información
>>> que
>>> me
>>> refería )
>>>
>>>
>>> 2) Mantenimiento de la información (o en inglés "information
>>> aging"):
>>> Esto es un problema tradicional de cualquier base de datos de
>>> registro. Existe este problema actualmente con, digamos, la
>>> información
>>> de Whois de LACNIC.
>>> Personalmente, yo creo que la política es incluso una mejora en
>>> este
>>> sentido pues le da los instrumentos al staff para requerirle a
>>> un
>>> miembro a que actualice la información en la base de datos.
>>>
>>> No estoy de acuerdo que eso va a mejorar la calidad de la
>>> información.
>>> Si no hay incentivos para utilizar una tecnología, no habrá
>>> incentivos
>>> para mantener la información actualizada.
>>>
>>> Y la información de RPKI tiene poca relación con información de
>>> asignación/sub asignación (en lo que toca el whois).
>>>
>>> (Roque) Mi comentario sobre la base de registro es que mantener
>>> la
>>> información del email de contacto de una entidad sufre del mismo
>>> problema de mantenimiento de la información. En tu comentario
>>> estás
>>> asumiendo que la mayoría de la información va a caducar
>>> rápidamente.
>>> Yo creo lo contrario, ISPs cambian muy raramente de sistema
>>> autónomo
>>> y por ende la información se va a mantener válida.
>>>
>>> Al fin y al cabo, el objetivo es fomentar la adopción, correcto?
>>>
>>> ok,
>>> pero sigo que la compración no es buena :)
>>>
>>> 3) Verificación de información de ruteo:
>>> Esto no esta incluido en la propuesta, justamente por la
>>> dependencia
>>> en el punto de observación. Por eso mi comentario de que en
>>> general
>>> las herramientas para generar los objetos RPKI (i.e. la web de
>>> rpki.lacnic.net<http://rpki.lacnic.net> o las herramientas que comentaba
>>> Arturo)
>>> ayudan
>>> a
>>> un
>>> operador a crear ROAs "adecuados".
>>>
>>> Okay, pero poner la necesidad de generalos asociada a
>>> justificativa
>>> de
>>> obtener asignación no es adecuado. Ese es mí punto.
>>>
>>> 4) Motivación de despliegue:
>>> Hay diferentes factores que motivan el despliegue de una
>>> tecnología.
>>> Hay factores económicos, regulatorios, políticos, ecológicos,
>>> etc
>>> (i.e. análisis de PESTEL). Personalmente, creo que esta
>>> política
>>> motiva la creación de material criptográfico que aumente el
>>> valor
>>> percibido de la tecnología no para una entidad específica, pero
>>> para
>>> el conjunto de la comunidad.
>>>
>>> Que es mejor, tener un montón de información "sin calidad" o
>>> pocas
>>> pero
>>> de calidad buena?
>>>
>>> (Roque) Porqué sería "sin calidad"?, creo que sobre-estimas el
>>> valor
>>> de mantener información correcta para los miembros.
>>>
>>> si un ISP tiene la presión por obtener recursos adicionales y se
>>> ve
>>> obrigado a tener RPKI, va a poner lo que sea más facil para
>>> cumplir
>>> con
>>> la regla.
>>>
>>> y eso, no es motivación para aprender ni tampoco fomentar la
>>> tecnlogía.
>>>
>>>
>>> 5) Madurez de la tecnología:
>>> Justamente la adopción de esta política va a fomentar más
>>> material
>>> criptográfico y por ende más resultados concretos para seguir
>>> mejorando la madurez de la tecnología. Yo creo realmente en el
>>> valor
>>> de diseños iterativos e incrementales (i.e. ágiles).
>>>
>>> No estoy de acuerdo.
>>> Creo que lo que está haciendo LACNIC está bien, o sea, los
>>> tutoriales,
>>> charlas, etc. Eso crea masa critica no solamente para
>>> implementar
>>> sino
>>> que para discutir
>>>
>>> "Obligar" uno a ir por ese camino no creo que es lo que va a
>>> traer
>>> la
>>> madurez.
>>>
>>>
>>> (Roque) No es "obligar", es como comunidad entender que es una
>>> buena
>>> práctica estimular poblar la base de datos del RPKI. La realidad
>>> es
>>> que en las tareas de difusión es muy difícil llegar a todos los
>>> miembros e incluso a las personas que tienen o la clave del
>>> sistema
>>> de LACNIC o la información de routing. En el momento de pedir
>>> recursos, los canales de diålogo son más fluidos con LACNIC y
>>> dentro
>>> de las empresas. Creo que la región de LACNIC puede avanzar muy
>>> rápidamente en este sentido. Si estamos tan cerca, por qué
>>> frenarnos?
>>>
>>> Es obligar.
>>> Si yo necesito de IPs adicionales, utilice bien los recursos que
>>> me
>>> fueran asignados pero aún así no logro obtener más por esa
>>> cuestión
>>> de
>>> RPKI, me veré obligado a hacer eso, mismo que todavía no sepa
>>> bien,
>>> no
>>> la use, y ella no esté madura lo suficiente.
>>>
>>> Mi punto es que mejor crear masa critica, difundir informaciones,
>>> etc
>>>
>>> Ricardo
>>>
>>>
>>> Roque
>>>
>>>
>>> abrazos.
>>> Ricardo
>>>
>>> Roque
>>>
>>>
>>>
>>> On Sep 6, 2012, at 3:11 PM, Ricardo Patara wrote:
>>>
>>> Hola,
>>>
>>> Como decía, creo que es interesante el esfuerzo en motivar
>>> RPKI,
>>> pero
>>> quería explicitar que no estoy de acuerdo a la propuesta.
>>>
>>> hay ese punto en relación a los NIRs y eso puede ser
>>> interpretado
>>> también que se está intentando poner criterios en las
>>> políticas
>>> con
>>>
>>> base
>>>
>>> en algo "técnico" pero que todavía no está aún en el nível de
>>> madurez
>>> deseado.
>>>
>>> Cuanto al comentario de Roque en se agregar verificación en
>>> los
>>>
>>> objetos
>>>
>>> (roas, certs) de acuerdo rfcs. Es un paso, pero nuevamente, tener
>>> eso
>>>
>>> en
>>>
>>> la política por si solo no va a motivar el uso de la tecnología.
>>>
>>> Por ejemplo. Suponga que estos criterios de verificación
>>> figuren
>>> en
>>> la
>>> política y tal verificación se haga al momento de la solicitud
>>> de
>>> bloques adicionales. Qué motivación va a tener el ISP en
>>> mantener
>>>
>>> estos
>>>
>>> objetos "correctos" y actualizados?
>>>
>>> Y mismo que se agregue ese último comentario de Christian, de
>>> que
>>> la
>>> asignación es válida desde que se mantenga actualizada la
>>> información
>>>
>>> de
>>>
>>> RPKI. Como LACNIC verificaría eso?
>>> Una cosa es registrar información de sub asignación. Otra es
>>> registrar
>>> información de ruteo. Qué parametros seguiría LACNIC para
>>> verificar
>>>
>>> eso?
>>>
>>> Y nuevamente al punto, como les parece que eso motiva el
>>> despliegue
>>> da
>>> la tecnología?
>>> Uno puede tener todo bien registrado, pero qué vale si nadie
>>> lo
>>> usa
>>> porque no sabe, no conoce?
>>>
>>> No me gusta la idea de hacer adoptada una tecnología (en
>>> especial
>>>
>>> nueva
>>>
>>> y no tan madura), a través de políticas de asignación.
>>>
>>> Abrazos.
>>>
>>> Ricardo Patara
>>>
>>> Em 06-09-2012 09:56, Christian O'Flaherty escreveu:
>>>
>>> Apoyo la propuesta incluyendo los comentarios de Ricardo
>>> (hacer
>>>
>>> alguna
>>>
>>> referencia al caso de los NIR e incluir la "verificación" del
>>> ROA).
>>>
>>> Tambien habría que modificar este punto del manual:
>>>
>>> 2.3.2.10. Validez de las distribuciones de direcciones IPv4
>>>
>>> Las distribuciones de direcciones IPv4 son válidas
>>> mientras...
>>>
>>> mantener actualizada la información de las distribuiciones y
>>> asignaciones en la base de datos Whois de LACNIC + RPKI
>>>
>>> Tambien habría que incluirlo en el manual para las
>>> asignaciones
>>> IPv6,
>>> no? (4.5.6, 4.5.2, etc.)
>>>
>>> Christian
>>>
>>> 2012/9/6 Roque Gagliano (rogaglia) <rogaglia at cisco.com<mailto:
>>> rogaglia at cisco.com>>:
>>>
>>> Hola Ricardo,
>>>
>>> On Sep 6, 2012, at 2:10 PM, Ricardo Patara wrote:
>>>
>>> Hola Roque,
>>>
>>> Me pareció interesante la idea. Pero me preocupa en
>>> especial
>>> qué
>>>
>>> pasaría
>>>
>>> con los NIRs que siguen las políticas de LACNIC pero que todavía
>>>
>>> no
>>>
>>> tienen un sistema RPKI?
>>>
>>> Quizás sea un incentivo para que lo implementen? Me
>>> imagino
>>> que
>>>
>>> los NIR tienen su plan y este tipo de discusiones las
>>> deberían
>>> tener con
>>> sus comunidades.
>>>
>>> comprendo. pero mi pregunta es que pasaría si la propuesta es
>>>
>>> aceptada
>>>
>>> pero los NIRs no tiene todavía su RPKI?
>>>
>>> Dicho esto, entiendo que LACNIC, los NIR y sus respectivas
>>>
>>> comunidades se pondrán de acuerdo en una hoja de ruta
>>> razonable
>>> para
>>> implementar la política. No es lo que sucede en todos los casos?
>>>
>>> Además de eso la propuesta no indica nada cuanto a validez de
>>>
>>> los dados
>>>
>>> de RPKI, por ejemplo, no indica que si la ROA tiene o no que ser
>>>
>>> válida,
>>>
>>> tampoco si los certificados tienen o no que estar validos (no
>>>
>>> revocados
>>>
>>> y dentro de las fechas de validez).
>>>
>>> Si la idea es motivar el uso, hay que tener preocupación
>>> con
>>> la
>>>
>>> validez
>>>
>>> y también de alguna forma motivar su uso. Creo que faltaría esa
>>>
>>> parte en
>>>
>>> la propuesta.
>>>
>>> Aquí hay dos cosas:
>>> - "valido" o "invalido" es una clasificación que depende
>>> del
>>>
>>> punto de observación. Por esto no creo que podamos poner
>>> ningún
>>> texto que
>>> ayude aquí. Para mitigar errores de tipeo por parte de los
>>> operadores,
>>> las
>>> herramientas ayudan al operador con información sobre el status de
>>> la
>>> tabla
>>> global de rutas en distintos puntos de observación (RIS o
>>> Routeviews).
>>>
>>> valido y invalido lo queria decir no es en comparación con las
>>>
>>> rutas,
>>>
>>> sino que un objeto ROA "correctamente" creado.
>>>
>>> Uno puede por ejemplo crear un ROA de cualquier forma
>>> solamente
>>>
>>> para
>>>
>>> cumplir con la solicitud de recursos adicionales y poner por
>>>
>>> ejemplo ASN
>>>
>>> 0, o un ASN reservado, o otra cosa.
>>>
>>>
>>> - hay un tema de "aging" de la información. Básicamente
>>> por
>>>
>>> más que la información sea "correcta" en el momento de
>>> crearla,
>>> al pasar el
>>> tiempo la info en el RPKI no acompañe la información en el sistema
>>> de
>>> rutas. Esta propuesta ayuda con la mitigación de este problema
>>> pues
>>> obliga
>>> al ISP a revisar sus ROAs cada vez que pide nuevos bloques.
>>>
>>> y nuevamente, si la idea es motivar el uso, al no hacer controle
>>> o
>>>
>>> tener
>>>
>>> motivaciones para que la información sea valida pueda crear más
>>>
>>> problemas.
>>>
>>> Uno puede crear una ROA "incorrecta", o crear y revocar su
>>>
>>> certificado
>>>
>>> EE solamente para cumprir con los tramites.
>>>
>>> Y si al mismo tiempo un provedor inicia el
>>> uso/verificación,
>>> el
>>>
>>> problema
>>>
>>> al ISP que genero los datos puede ser mayor.
>>>
>>> Lo que quiero decir con eso, que es interesante motivar,
>>> pero
>>>
>>> poner en
>>>
>>> la política puntos que uno puede "cumplir" por "cumplir" sin
>>> otras
>>> medidas que motiven el uso puede ser peor .
>>>
>>> Entiendo tu punto. Perdón por la confusión.
>>>
>>> Te parece agregar que los certificados sean validos según
>>> RFC6481
>>> y
>>>
>>> los ROAs según RFC 6483?
>>>
>>> Roque
>>>
>>> saludos
>>> Ricardo
>>>
>>> Roque
>>>
>>> un abrazo.
>>>
>>> Ricardo Patara
>>>
>>> Em 06-09-2012 04:59, Roque Gagliano (rogaglia) escreveu:
>>>
>>> Hola Gente,
>>>
>>> Yo soy el autor de LAC-2012-11.
>>>
>>> Básicamente la propuesta es muy simple. Lo que dice es
>>> que
>>>
>>> agreguemos a los requerimientos para obtener recursos
>>> adicionales que una
>>> entidad tenga que registrar en el RPKI los recursos que ya tiene.
>>>
>>> El objetivo es simplemente solucionar un problema
>>>
>>> administrativo y lograr acelerar la adopción de RPKI.
>>> Muchas
>>> veces la
>>> persona con la clave del sistema de LACNIC no es la misma que
>>> opera
>>> la
>>> red.
>>> Con este pedido, simplemente les pedimos a ambas entidades que se
>>> "comuniquen" y coloquen la información en el sistema RPKI. También
>>> logramos
>>> que más miembros se eduquen sobre las capacidades RPKI.
>>>
>>> El costo para el miembro es mínimo pues la política no pide que
>>>
>>> registre bloques delegados y pues se puede solucionar con
>>> dos
>>> o tres clicks
>>> en la web RPKI de LACNIC.
>>>
>>> Espero sus comentarios.
>>> Roque
>>>
>>>
>>>
>>> On Sep 6, 2012, at 4:45 AM, Nicolas Antoniello wrote:
>>>
>>> Dear Policy-list Members,
>>>
>>> There are three new Policy Proposals; numbers
>>> LAC-2012-09,
>>>
>>> LAC-2012-10 and
>>>
>>> LAC-2012-11:
>>>
>>> - LAC-2012-09 Update
>>> RIRs-on-48<
>>>
>>>
>>> http://lacnic.net/documentos/**politicas/lac-2012-09-EN.pdf
>>> <http://lacnic.net/documentos/politicas/lac-2012-09-EN.pdf>
>>>
>>>
>>> - LAC-2012-10 Allocation of IPv6 address blocks larger than a
>>> /32<
>>> http://lacnic.net/**documentos/politicas/lac-2012-**
>>> 10-EN.pdf<
>>> http://lacnic.net/documentos/politicas/lac-2012-10-EN.pdf>
>>>
>>> - LAC-2012-11 Requirement to sign up for RPKI when
>>> requesting
>>>
>>> additional
>>>
>>> resources <
>>>
>>>
>>> http://lacnic.net/documentos/**politicas/lac-2012-11-EN.pdf
>>> <http://lacnic.net/documentos/politicas/lac-2012-11-EN.pdf>
>>>
>>>
>>> <http://lacnic.net/documentos/**politicas/lac-2012-11-EN.pdf<
>>> http://lacnic.net/documentos/politicas/lac-2012-11-EN.pdf>
>>>
>>>
>>> As your comments are important, we encourage you to
>>> express
>>>
>>> your views on
>>>
>>> the proposals:
>>>
>>> - Do you support or oppose this proposal?
>>> - Does this proposal solve a problem you are
>>> experiencing?
>>>
>>> If
>>>
>>> so, tell the community about your situation.
>>> - Do you see any disadvantages in this proposal?
>>> - Is there anything in the proposal that is not
>>> clear?
>>> - What changes could be made to this proposal to make
>>> it
>>>
>>> more
>>>
>>> effective?
>>>
>>>
>>> Max Larson Henry
>>> Nicolas Antoniello
>>> co-Chairs of Public Policy Forum - LACNIC
>>>
>>>
>>> ==============================**
>>> ==============================**=======================
>>>
>>> Estimados suscriptores de la lista de políticas de LACNIC,
>>>
>>> Se recibieron tres nuevas propuestas de Política;
>>> números
>>>
>>> LAC-2012-09,
>>>
>>> LAC-2012-10 y LAC-2012-11:
>>>
>>>
>>> - LAC-2012-09 Actualización
>>> RIRs-on-48<
>>>
>>>
>>> http://lacnic.net/documentos/**politicas/lac-2012-09-SP.pdf
>>> <http://lacnic.net/documentos/politicas/lac-2012-09-SP.pdf>
>>>
>>>
>>> - LAC-2012-10 Distribución de direcciones IPv6 mayores que
>>> /32<
>>> http://lacnic.net/**documentos/politicas/lac-2012-**
>>> 10-SP.pdf<
>>> http://lacnic.net/documentos/politicas/lac-2012-10-SP.pdf>
>>>
>>> - LAC-2012-11 Requerimiento de inscripción en RPKI para
>>>
>>> recursos
>>>
>>> adicionales <
>>>
>>>
>>> http://lacnic.net/documentos/**politicas/lac-2012-11-SP.pdf
>>> <http://lacnic.net/documentos/politicas/lac-2012-11-SP.pdf>
>>>
>>>
>>>
>>> Dado que sus comentarios son importantes, solicitamos
>>> que
>>>
>>> exprese sus
>>>
>>> puntos de vista sobre las propuestas:
>>>
>>> - ¿Apoya usted o se opone a esta propuesta?
>>> - ¿Ésta propuesta resolvería un problema que ud. está
>>> experimentado? En caso
>>> afirmativo, podría describir sus situación?
>>> - ¿Ve alguna desventaja en esta propuesta?
>>> - ¿Hay algo en la propuesta que no está claro?
>>> - ¿Qué cambios podrían hacerse a esta propuesta para
>>> que
>>> sea
>>> más eficaz?
>>>
>>>
>>> Max Larson Henry
>>> Nicolas Antoniello
>>> Moderadores del Foro Público de Políticas de LACNIC
>>>
>>>
>>> ==============================**
>>> ==============================**========================
>>>
>>> Prezados membros da lista políticas do LACNIC,
>>>
>>> Se recebeu os três seguintes propostas de Política é
>>> asignó o
>>>
>>> numero
>>>
>>> LAC-2012-09, LAC-2012-10 é LAC-2012-11:
>>>
>>>
>>> - LAC-2012-09 Atualização
>>> RIRs-on-48<
>>>
>>>
>>> http://lacnic.net/documentos/**politicas/lac-2012-09-PT.pdf
>>> <http://lacnic.net/documentos/politicas/lac-2012-09-PT.pdf>
>>>
>>>
>>> - LAC-2012-10 Alocações IPv6 maiores que
>>> /32<
>>> http://lacnic.net/**documentos/politicas/lac-2012-**
>>> 10-PT.pdf<
>>> http://lacnic.net/documentos/politicas/lac-2012-10-PT.pdf>
>>>
>>> - LAC-2012-11 Requerimento de inscrição no RPKI para
>>> recursos
>>> adicionais<
>>>
>>>
>>> http://lacnic.net/documentos/**politicas/lac-2012-11-PT.pdf
>>> <http://lacnic.net/documentos/politicas/lac-2012-11-PT.pdf>
>>>
>>>
>>>
>>> Considerando que seus comentários são importantes,
>>> pedimos
>>> que
>>>
>>> expresse
>>>
>>> suas opiniões sobre as propostas:
>>>
>>> - Você apoia ou se opõe a esta proposta?
>>> - Esta proposta resolveria um problema que você
>>>
>>> experiencia?
>>>
>>> No caso afirmativo, você poderia descrever a sua
>>>
>>> situação?
>>>
>>> - Você vê algum inconveniente com esta proposta?
>>> - Há algo na proposta que não está claro?
>>> - Que mudanças poderiam ser feitas para a presente
>>> proposta
>>> para torná-lo mais eficaz?
>>>
>>>
>>> Max Larson Henry
>>> Nicolás Antoniello
>>> Moderadores do Foro Público de Políticas - LACNIC
>>> ______________________________**_________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>
>>> ______________________________**_________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>
>>> ______________________________**_________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>
>>> ______________________________**_________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>
>>> ______________________________**_________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>
>>> ______________________________**_________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>
>>> ______________________________**_________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>
>>> ______________________________**_________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>
>>> ______________________________**_________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>
>>> ______________________________**_________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>
>>> ______________________________**_________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>
>>> ______________________________**_________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>
>>> ______________________________**_________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>
>>> ______________________________**_________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>
>>>
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Regards,
>>> Gustavo Lozano
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>
>>>
>>>
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Regards,
>>> Gustavo Lozano
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>
>>>
>>>
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Regards,
>>> Gustavo Lozano
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net<mailto:Politicas at lacnic.net>
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>
>>>
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>
>>>
>>
>> --
>>
>> Regards,
>> Gustavo Lozano
>>
>>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3744 bytes
Desc: Firma criptogr??fica S/MIME
URL: <https://mail.lacnic.net/pipermail/politicas/attachments/20120912/781b535a/attachment.bin>
More information about the Politicas
mailing list