[LACNIC/Politicas] LAC-2012-1
Roque Gagliano (rogaglia)
rogaglia at cisco.com
Fri Sep 7 11:51:57 BRT 2012
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>
>
>> 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>
>>>
>>>> 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>
>>>>
>>>>> 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
>>>>> 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>
>>>>>>>
>>>>>>> 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 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>:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> ______________________________**_________________
>>>>>>>>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> ______________________________**_________________
>>>>>>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ______________________________**_________________
>>>>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>>>>> 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
>>>>>>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>>>>>>>
>>>>>>>>>>>>> ______________________________**_________________
>>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>>> 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
>>>>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>>>>>
>>>>>>>>>>> ______________________________**_________________
>>>>>>>>>> Politicas mailing list
>>>>>>>>>> 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
>>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>>>
>>>>>>>>> ______________________________**_________________
>>>>>>>> Politicas mailing list
>>>>>>>> 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
>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>
>>>>>>> ______________________________**_________________
>>>>>> Politicas mailing list
>>>>>> 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
>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Politicas mailing list
>>>> Politicas at lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Regards,
>>> Gustavo Lozano
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>
>>
>>
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
>>
>>
>
>
> --
>
> Regards,
> Gustavo Lozano
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>
More information about the Politicas
mailing list