[LACNIC/Politicas] LAC-2012-1

Roque Gagliano (rogaglia) rogaglia at cisco.com
Mon Sep 10 12:27:18 BRT 2012 

Ricardo,

On Sep 10, 2012, at 5:15 PM, Ricardo Patara wrote:

> Roque,
> 
>> Alejandro,
>> 
>>> Cuantos han sido victima de "secuestro" de sus recursos. A mi me sucedió, y a pesar de tener as-in y as-out en el whois de Lacnic no sirvió para nada, porque nadie utiliza esa información.
>> 
>> Nadie la usaba porque la implementación de LACNIC no eran compatibles con RPSL, pero esa es otra discusión.
>> 
>>> No me malinterpreten, me parece que RPKI y todos los pasos que se den para mejorar la infraestructura BGP y evitar el secuestro de recursos son geniales. Lo que no me gusta es que ase imponga requerimientos adicionales a como se deben administrar los recursos. Requerimientos que en estos momentos son burocráticos porque nadie los utiliza en la practica. Cuando los Tier 1 como Telefónica, Level 3 y NTT exijan a sus clientes/peers tener RPKI actualizados entonces tendrá sentido.
>>> 
>>> Si finalmente Lacnic desea aprobar esta política, sencillamente entrare a la pagina de RPKI haré unos cuantos click y eso es todo. Creo que muchos harán lo mismo antes de solicitar sus nuevos recursos. Tratar de imponer este tipo de requerimiento técnico solo va crear resistencia y que mucha gente lo ignore, mejor seria seguir educando.
>> 
>> Justamente, eso es todo lo que se te pide :-). No sabes el poder de esos pocos clicks. 
>> 
>> Más aún, la gran mayoría de las entidades en LACNIC son como tu caso (EC-STEC1-LACNIC), un bloque IPv4, un bloque IPv6 y un ASN.....no hay forma que la información sea errada.
> 
> en ese caso hay que aclarar mejor las cosas!
> 
> hay sí posiblidad de que se haga algo errado.
> 
> que es el campo "max length" en la ROA
> el bloque de esa entidad que tomaste como ejemplo, no anuncia un unico
> prefijo!

Correcto. Pero en mi defensa, en realidad uno de los click que contaba era apretar el "qué es esto?" del "max-length".

Roque

PS: Para quienes no lo saben, el max-lenght indica la largo de prefijo máximo que una red puede ser anunciada. En el ejemplo 200.105.112/21 podría tener un "max-length" de 24, por lo que equivale a clasificar como válidos todos los prefijos más específicos hasta un /24 (similar a cómo se hace con listas de prefijos que todo operador está habituado).



> por eso, de la importancia de crear "masa critica" que comprendan qué
> están haciendo más allá de hacer algo "automático" por que la política
> lo pide para que pueda acceder a más recursos (los cuales necesita y
> puede justicar su necesidad)
> Saludos
> 
>> 
>> Es cierto que para los grandes proveedores puede haber un poco más de trabajo. Por eso, la política no los obliga a registrar las re-assignaciones. Otro punto es que los grandes proveedores tienen en general personal dedicado para la tarea e incluso sistemas de gestión de direcciones. LACNIC puede hacer un mecanismo para importar los detalles de un ROA basado en CSV o JSON (creo que esto no está aún implementado).
>> 
>> Totalmente de acuerdo en la educación. Pero es mucho más efectivo educar con un repositorio lleno de información válida....es como eso de "running code".
>> 
>> Roque
>> 
>> 
>>> saludos
>>> 
>>> Alejandro Rodriguez
>>> Gerente Tecnico
>>> Stealth Telecom del Ecuador
>>> www.stealthtelecom.net
>>> Telf: 2248233 / 2248887
>>> 
>>> El 07/09/2012 9:51, Roque Gagliano (rogaglia) escribió:
>>>> 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
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> Politicas mailing list
>>>> Politicas at lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>> 
>>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>> 
>> 
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
>> 
> 
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>

More information about the Politicas mailing list