[LACNIC/Politicas] LAC-2012-1
Alejandro Rodriguez
arodriguez at b2ec.net
Fri Sep 7 14:21:51 BRT 2012
Hola Nicolas:
si entiendo el proceso de politicas. Solo quise poner un ejemplo en
caso que se aprobara.
saludos
Alejandro Rodriguez
Gerente Tecnico
Stealth Telecom del Ecuador
www.stealthtelecom.net
Telf: 2248233 / 2248887
El 07/09/2012 12:14, Nicolas Antoniello escribió:
> Hola Alejandro,
>
> Solo una mención como Moderador del foro: las políticas son realizadas por
> la Comunidad de LACNIC y para la Comunidad de LACNIC. Luego, LACNIC como
> entidad no las propone ni decide... sí las aprueba en ultima instancia solo
> sí y luego de que son aprobadas en el Foro Público.
> Es un proceso abierto en el cual TODOS y cada uno de los integrantes de la
> lista puede proponer y discutir políticas.
>
> En resumen, LANIC no está "disponiendo" de nuestro tiempo... por el momento
> es una propuesta y es sano y es parte del proceso el debatir sobre la misma.
> De nada sirve llegar al foro sin debate en la lista.
>
> Asi que... que siga el sano debate que estamos teniendo que es muy
> productivo.
>
> Fraterno saludos,
> Nicolas
>
>
>
> 2012/9/7 Alejandro Rodriguez <arodriguez at b2ec.net>
>
>> Roque:
>> La única diferencia es que se se empezó a solicitar resolución inversa
>> una vez que era una tecnología establecida (el dominio .arpa es de 1985).
>> Tampoco creo que el requerimiento de los servidores de correos tuvieran
>> resolución inversa sea de 1985.
>>
>> - Capacitación. Aprobar esta política implica que todos los responsables
>>> de recursos deben tener conocimientos de RPKI.
>>>
>>> exacto!
>>>
>>
>> O sea que ahora LACNIC decide como debemos los responsables de recursos IP
>> utilizamos nuestro tiempo.
>>
>> 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.
>> 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.
>>
>>
>> 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<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>
>>>>>
>>>>>> <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-****<http://lacnic.net/**documentos/politicas/lac-2012-**>
>>>>>>>>>>>>>>>>>>>>>> 10-EN.pdf<
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 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>
>>>>>>>> <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>
>>>>>
>>>>>> <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-****<http://lacnic.net/**documentos/politicas/lac-2012-**>
>>>>>>>>>>>>>>>>>>>>>> 10-SP.pdf<
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 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>
>>>>>> <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>
>>>>>
>>>>>> <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-****<http://lacnic.net/**documentos/politicas/lac-2012-**>
>>>>>>>>>>>>>>>>>>>>>> 10-PT.pdf<
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 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>
>>>>>
>>>>>> <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>
>>>>>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> 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>
>>>>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 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>
>>>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 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>
>>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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>
>>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> 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>
>>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 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>
>>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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>
>>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 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>
>>>>>>>>>>>>>> <
>>>>>>>>>>>>>>
>>>>>>>>>>>>> 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>
>>>>>>>>>>>>> <
>>>>>>>>>>>>>
>>>>>>>>>>>> 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>
>>>>>>>>>>>> <
>>>>>>>>>>>>
>>>>>>>>>>> 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>
>>>>>>>>>>> <
>>>>>>>>>>>
>>>>>>>>>> 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>
>>>>>>>>>> <
>>>>>>>>>>
>>>>>>>>> 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>
>>>>>>>>> <
>>>>>>>>>
>>>>>>>> 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>
>>>>>>>
>>>>>>>
>>>>>> --
>>>>>>
>>>>>> Regards,
>>>>>> Gustavo Lozano
>>>>>> ______________________________**_________________
>>>>>> 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>
>>>>>
>>>>>
>>>>>
>>>> --
>>>>
>>>> Regards,
>>>> Gustavo Lozano
>>>> ______________________________**_________________
>>>> 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
>
-------------- 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/20120907/a573353d/attachment.bin>
More information about the Politicas
mailing list