[LACNIC/Politicas] LAC-2012-1

Roque Gagliano (rogaglia) rogaglia at cisco.com
Fri Sep 7 11:51:57 BRT 2012


Gustavo,

Me parece que la diferencia radica en que yo veo la generación de material criptográfico como una inherente a la función misma de LACNIC y no una tecnología foránea que uno fuerza. O acaso se deberá dejar de pedir que cumpla con la resolución inversa?

Roque

On Sep 7, 2012, at 4:18 PM, Gustavo Lozano wrote:

> Roque,
> 
> Comentarios entre lineas.
> 
> 2012/9/7 Roque Gagliano (rogaglia) <rogaglia at cisco.com>
> 
>> Hola Gustavo,
>> 
>> Gracias por el comentario.
>> 
>> Yo creo que LACNIC podría generar certificados CA en forma automática sin
>> necesidad de una política para todos sus miembros, pues esto es una simple
>> extensión de su rol de registro (o notario). Pero esto no ayuda a que el
>> resto del mundo pueda utilizar esta información a menos que también se
>> generen los ROAs correspondientes y este paso no se puede hacer automático
>> pues muchos proveedores tienen más de un ASN registrado u otras
>> peculiaridades.
>> 
>> 
> Si realmente RPKI es valioso para los operadores entonces ellos mismos se
> van a preocupar por generar los objetos que necesiten de forma correcta y
> por las personas informadas sobre el tema en la organizacion y no
> simplemente por cumplir un requisito dando clicks como detallas en tu
> propuesta.
> 
> Mi punto es que queremos utilizar las politicas para forzar tecnologias en
> el mercado.
> 
> Esta comunidad tiene un foco: la asignación de recursos (IPs y ASN) y por
>> lo tanto tiene un rol e impacto clave en el desarrollo de RPKI. No es lo
>> mismo para esta comunidad RPKI que FTTH o Cloud o DNSSEC. Incluso ya hay
>> hoy propuestas sobre la mesa (como LAC-2011-08) para buscar nuevos usos de
>> este recurso.
>> 
>> 
> Roque lo de FTTH y certificaciones fue un chiste :).
> 
> Entrando en materia, http://lacnic.net/sp/sobre-lacnic/estatuto/i.html, en
> ningun lado dice forzar tecnologias en el mercado.
> 
> La propuesta es un paso muy modesto (pero a mi entender eficaz) para
>> acelerar el desarrollo de lo que debemos tener consenso va a ser una nueva
>> práctica en la industria. Nosotros ya aplicamos esta mismo estrategia con
>> IPv6! Comenzamos a exigir muy poco ("tener un plan") y luego fuimos
>> evaluando el impacto e incrementando los requerimientos....Mi propuesta es
>> comenzar ese mismo camino para RPKI, de vuelta con un paso muy modesto y
>> prácticamente sin costo para el operador. LACNIC puede ayudar con material
>> didáctico específico para cumplir con este requerimiento.
>> 
>> 
>> 
> No es un paso modesto, es un requisito extra y sin sentido para pedir
> recursos.
> 
> Si va a ser una nueva practica en la industria entonces que la industria lo
> adopte como buena practica, no es necesario una politica para crear buenas
> practicas. En teoria es una buena practica agregar tus bloques y quitamos
> toda referencia a lo mismo porque son politicas de asignacion de recursos,
> no un conjunto de buenas practicas.
> 
> LACNIC puede crear el material didactico y mandarlo por email, presentarlo
> en talleres, etc, tenemos que entender que las tecnologias son adoptadas no
> forzadas.
> 
> Roque
>> 
>> 
>> 
>> On Sep 7, 2012, at 1:37 AM, Gustavo Lozano wrote:
>> 
>>> Hola a todos,
>>> 
>>> 
>>> 
>>> Estoy en contra de la propuesta.
>>> 
>>> 
>>> 
>>> Parece que seguimos viendo las políticas de LACNIC como el método para
>>> forzar la adopción de nuevas tecnologías.
>>> 
>>> 
>>> 
>>> Recordemos que ya pasamos por una propuesta no aceptada que requería la
>>> implementación de IPv6 para obtener recursos.
>>> 
>>> 
>>> 
>>> También recuerdo que aprobamos una propuesta para eliminar los términos
>> de
>>> agregación de bloques con la justificación que en las políticas no deben
>>> existir requerimientos técnicos.
>>> 
>>> 
>>> 
>>> El objetivo de la propuesta es:
>>> 
>>> * educar sobre el RPKI y seguridad en el sistema global de enrutamiento.
>>> 
>>> Propongo entonces que LACNIC mande un email cada "x" tiempo explicando lo
>>> que es RPKI a los tomadores de decisión o que publique anuncios en los
>>> diarios u otras miles de formas para dar a conocer un tema a una
>> audiencia.
>>> 
>>> 
>>> 
>>> * inducir la generación de material criptográfico en el RPKI.
>>> 
>>> Propongo  que se generen objetos en el sistema de forma automática si
>>> creemos que eso agrega valor.
>>> 
>>> 
>>> 
>>> No estoy de acuerdo en usar las políticas para ayudar o forzar el
>>> despliegue de ciertas tecnologías. Ahora bien si creemos que las
>> políticas
>>> pueden ser usadas para promocionar tecnologías entonces podríamos tener
>>> propuestas que para obtener recursos adicionales necesitas:
>>> 
>>> * Activar DNSSEC en tus zonas de reserva.
>>> 
>>> * Si quieres IP para hosting entonces que tu hosting ofrezca IPv6 y
>> DNSSEC.
>>> 
>>> * Si eres una telefónica entonces implementa FiOS para el x% de tus
>>> clientes.
>>> 
>>> * Tienes que tener al menos un empleado certificado en x o y tecnología.
>>> 
>>> * etc, etc.
>>> 
>>> 
>>> 
>>> El tema de RPKI resulta además delicado porque por muchas personas es
>> visto
>>> como el mecanismo para que los RIRs sigan obteniendo recursos cuando IPv4
>>> sea historia y con un bloque de IPv6 sea suficiente para la operación de
>> un
>>> ISP por décadas.
>>> 
>>> Saludos,
>>> Gustavo Lozano
>>> 
>>> 2012/9/6 Nicolas Antoniello <nantoniello at gmail.com>
>>> 
>>>> Alejandro, Carlos, Roque, todos,
>>>> 
>>>> Agrego algun comentario a los que mencionaba antes:
>>>> 
>>>> - Por un lado, no veo bien el indicar "no hacer algo" hasta que el
>> resto lo
>>>> haga... así claramente no se avanza (en mi opinión es como el problema
>> de
>>>> los comezales en la mesa con menos cubietos que comenzales... si todos
>>>> esperan no come nadie, pero no todos pueden comer al mismo tiempo... en
>>>> fin).
>>>> Desde ese punto de vista, no veo que el espíritu de la propuesta de
>> Roque
>>>> sea "imponer requerimientos técnicos vía políticas"... sino que más
>> bien es
>>>> un tema de "lo que implica".
>>>> 
>>>> - El rotuer en todo caso dialoga con el repositorio de RPKI para
>> realizar
>>>> la eventual verificación, pero creo que en lo que a hardware respecta
>> no se
>>>> requeriría mayor cambio... más biene es un tema de software.
>>>> 
>>>> ... pero todo eso es más bien técnico...
>>>> 
>>>> 
>>>> - RPKI claramente tiene usos independientemente de que los routers
>>>> verifiquen ROA y los mismos son eventualmente totalmente externos a los
>>>> routers... eso de alguna manera quería indicar en los comentarios
>>>> anteriores.
>>>> 
>>>> En definitiva, Roque, tal vez una aproximación que podría resultar más
>>>> aceptada (que comentábamos off-line con Carlos M.) podría ser incluir en
>>>> una primer aproximación de política que lo que se solicite al recibir la
>>>> delegación de un prefijo sea la generación de los certificados (el tema
>> del
>>>> mantenimiento de los mismos vuelve a la mesa de debate, pero eso
>> entiendo
>>>> que es un problema que ya existe con muchos otros recursos o sistemas).
>>>> 
>>>> Luego, la generación de los ROA si implica una desición de ruteo, pues
>> allí
>>>> se incluye el AS que estaría "autorizado" a generar el prefijo... tal
>> vez
>>>> ese es el punto en que se "filtra" algo más técnico pues implica
>> deciciones
>>>> de ruteo.
>>>> 
>>>> De todas formas en algún momento hay que generar los ROA si lo que se
>>>> quiere es validar el origen...
>>>> 
>>>> No me estoy expresando ni a favor ni en contra, sino que planteo
>> opciones a
>>>> la redacción de la política, que podrían resultar más aceptables en
>> vista
>>>> de los comentarios expuestos en la lista.
>>>> 
>>>> Roque?
>>>> 
>>>> Saludos,
>>>> Nico
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 2012/9/6 Alejandro Rodriguez <arodriguez at b2ec.net>
>>>> 
>>>>> Estimados:
>>>>> 
>>>>> No estoy de acuerdo de acuerdo con esta política. Se esta tratando de
>>>>> imponer un requerimiento técnico para la solicitud de recursos
>>>> adicionales.
>>>>> Para requerimiento técnico se utiliza un standard de baja adopción y
>> que
>>>>> prácticamente nadie utiliza.  Al final lo se lograría es aumentar el
>>>> costo
>>>>> administrativo a los ISP , sin prácticamente ningún beneficio. Quizás
>> en
>>>> 5
>>>>> años, si la adopción de RPKI es masiva, esta política tendría sentido.
>>>>> 
>>>>> alguna consideraciones a tener en cuenta:
>>>>> - Un router que necesite verificar el ROA de 300k rutas, va necesitar
>> un
>>>>> hardware mas potente que uno que no realice esta función . O se mas
>> $$$$.
>>>>> Por ello no me parece que de forma masiva se vaya a implementar RPKI en
>>>> un
>>>>> futuro cercano.
>>>>> - De lo que entiendo el único fabricante que en estos momentos soporta
>>>>> RPKI es Cisco. ¿ Se debe implementar una política que beneficie a un
>> solo
>>>>> fabricante ?
>>>>> - Capacitación. Aprobar esta política implica que todos los
>> responsables
>>>>> de recursos deben tener conocimientos de RPKI.
>>>>> 
>>>>> 
>>>>> saludos
>>>>> 
>>>>> Alejandro Rodriguez
>>>>> Gerente Tecnico
>>>>> Stealth Telecom del Ecuador
>>>>> www.stealthtelecom.net
>>>>> Telf: 2248233 / 2248887
>>>>> 
>>>>> El 06/09/2012 13:53, Carlos M. martinez escribió:
>>>>> 
>>>>> Hola!
>>>>>> 
>>>>>> Quiero hacer únicamente algunos comentarios sobre la tecnología y no
>>>>>> sobre la política:
>>>>>> 
>>>>>> - No hay que mezclar el concepto de validación de origen (lo que hacen
>>>>>> los routers) con el concepto de la RPKI.
>>>>>> 
>>>>>> - En el contexto de la política, la RPKI es otra base de datos y puede
>>>>>> no tener ningún impacto operativo.
>>>>>> 
>>>>>> Algunos otros comentarios entre líneas:
>>>>>> 
>>>>>> 
>>>>>> On 9/6/12 2:44 PM, Nicolas Antoniello wrote:
>>>>>> 
>>>>>>> set chair hat == off;
>>>>>>> 
>>>>>>> Estimados,
>>>>>>> 
>>>>>>> Expongo mi o mis punto/s de vista:
>>>>>>> 
>>>>>>> Si bien la tecnología (por decirlo de alguna manera) de RPKI es una
>>>>>>> solución a una parte de los problemas de BGP (tal y como intenta
>> serlo
>>>>>>> BGPsec para otros problemas de seguridad; y si bien RPKI en
>> comparación
>>>>>>> con
>>>>>>> BGPsec y otras propuestas está bastante más "aceptado" hoy día (no
>> era
>>>>>>> así
>>>>>>> hace unos años)... creo que aún hoy no es "la" tecnología definida y
>>>>>>> aceptada por todos para asegurar el origen de los prefijos.
>>>>>>> 
>>>>>>> Al dia de hoy casi todas las propuestas girar alrededor de la PKI de
>>>>>> recursos. Hay únicamente otra propuesta que involucra el uso del DNS
>>>>>> reverso pero no esta teniendo gran apoyo. En mi opinión, esta si ya
>>>>>> bastante establecido que la PKI de recursos es una componente
>>>>>> fundacional de las propuestas de enrutamiento seguro de los próximos
>> 5 o
>>>>>> mas años.
>>>>>> 
>>>>>> 
>>>>>> Incluso recien hace muy poco tiempo un fabricante publicó la
>>>>>>> incorporación
>>>>>>> del soporte a sus routers, para chequeo de RPKI en algunos de sus
>>>>>>> sistemas
>>>>>>> operativos... con esto quiero decir que aún falta camino por
>> recorrer.
>>>>>>> Si bien aunque no se tenga soporte de los sistemas operativos en los
>>>>>>> routers, es posible utilizar los ROA para disparar alarmas, etc... es
>>>>>>> decir, que aún sin el soporte completo por parte de los routers, el
>>>>>>> sistema
>>>>>>> es útil; creo que no está lo suficiente maduro como para asumir que
>> va
>>>> a
>>>>>>> ser la solución aceptada y determinar o pretender impulsarla desde
>> una
>>>>>>> política.
>>>>>>> 
>>>>>>> Al dia de hoy los routers no 'chequean RPKI', los routers arman una
>>>>>> tablita y comparan los UPDATES de BGP contra esa tablita. Creo que la
>>>>>> falta o no de soporte de validación de origen en los enrutadores es
>>>>>> ortogonal al mérito o no de la política.
>>>>>> 
>>>>>> Por un lado, sigo siendo reticente a que por política se incluyan
>>>>>>> cuestiones que o bien sean abietamente temas técnicos o bien
>>>>>>> indirectamente
>>>>>>> cubran aspectos técnicos u operativos que sean ajenos a los que rijan
>>>>>>> asignaciónes, gestión o manejo de recursos de los RIR/NIR.
>>>>>>> 
>>>>>>> Por otro lado, alguien podría entender que la generación de los ROA
>>>> está
>>>>>>> directamente relacionada con el recurso (en este caso un prefijo IP)
>> y
>>>>>>> por
>>>>>>> lo tanto, podría estar dentro de la política de un RIR la
>>>> "securización"
>>>>>>> o
>>>>>>> "autenticación" de las asignaciones... pero entonces, debería
>>>>>>> explicitarse
>>>>>>> un mecanismo de mantenimiento/actualización de los ROA, ya que si la
>>>>>>> info.
>>>>>>> se vuelve obsoleta por "aging" no tiene sentido que esté en una
>>>> política
>>>>>>> (sigamos la idea de que no parecen tener mucho sentido políticas que
>>>>>>> desde
>>>>>>> su planteo se sepa que son "inaplicables" o "inverificables" por
>> parte
>>>> de
>>>>>>> los RIR/NIR).
>>>>>>> 
>>>>>>> 
>>>>>> Entonces, ¿Qué opina el resto de la lista?
>>>>>>> 
>>>>>>> Frateno saludo,
>>>>>>> Nico
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 2012/9/6 Ricardo Patara <patara at registro.br>
>>>>>>> 
>>>>>>> Hola Roque,
>>>>>>>> 
>>>>>>>> 1) Valides de la información:
>>>>>>>>>>> Entiendo que tu comentario era sobre la "forma" de los objetos
>>>>>>>>>>> firmados. Obviamente si alguien usa el sistema "hospedado" de
>>>> LACNIC
>>>>>>>>>>> o
>>>>>>>>>>> de un NIR esto está descartado. Por eso no lo consideré en la
>>>>>>>>>>> propuesta
>>>>>>>>>>> original. Es cierto que si alguien administra su propia entidad
>>>>>>>>>>> certificadora, sería bueno hacer un chequeo. Aquí estamos
>> hablando
>>>> de
>>>>>>>>>>> chequear los objetos.
>>>>>>>>>>> 
>>>>>>>>>> No solamente cuanto a la forma, pero que la información sea
>>>>>>>>>> "correcta".
>>>>>>>>>> Por ejemplo. Para una ROA, que de hecho figure allá el ASN por lo
>>>> cual
>>>>>>>>>> el ISP va a originar sus anuncios. Y eso implica en trabajo extra
>>>> para
>>>>>>>>>> los RIR/NIRs.
>>>>>>>>>> Y
>>>>>>>>>> 
>>>>>>>>> (Roque) Me estas mezclando de vuelta. La política no pide a los
>>>>>>>>> RIR/NIR que verique nada del ASN que el miembro ingresó. Verificar
>> la
>>>>>>>>> "forma" viene gratis en las herramientas existentes. Además, TODA
>>>>>>>>> política tiene costos para los RIR/NIRs.
>>>>>>>>> 
>>>>>>>> no. mi punto es que bajo la presion para obtener recursos
>> adicionales
>>>>>>>> uno puede poner lo que quiera en un objeto ROA, por ejemplo
>>>>>>>> ( y eso tiene relación también con la calidad de la información que
>> me
>>>>>>>> refería )
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 2) Mantenimiento de la información (o en inglés "information
>> aging"):
>>>>>>>>>>> Esto es un problema tradicional de cualquier base de datos de
>>>>>>>>>>> registro. Existe este problema actualmente con, digamos, la
>>>>>>>>>>> información
>>>>>>>>>>> de Whois de LACNIC.
>>>>>>>>>>> Personalmente, yo creo que la política es incluso una mejora en
>>>> este
>>>>>>>>>>> sentido pues le da los instrumentos al staff para requerirle a un
>>>>>>>>>>> miembro a que actualice la información en la base de datos.
>>>>>>>>>>> 
>>>>>>>>>> No estoy de acuerdo que eso va a mejorar la calidad de la
>>>> información.
>>>>>>>>>> Si no hay incentivos para utilizar una tecnología, no habrá
>>>> incentivos
>>>>>>>>>> para mantener la información actualizada.
>>>>>>>>>> 
>>>>>>>>>> Y la información de RPKI tiene poca relación con información de
>>>>>>>>>> asignación/sub asignación (en lo que toca el whois).
>>>>>>>>>> 
>>>>>>>>>> (Roque) Mi comentario sobre la base de registro es que mantener la
>>>>>>>>> información del email de contacto de una entidad sufre del mismo
>>>>>>>>> problema de mantenimiento de la información. En tu comentario estás
>>>>>>>>> asumiendo que la mayoría de la información va a caducar
>> rápidamente.
>>>>>>>>> Yo creo lo contrario, ISPs cambian muy raramente de sistema
>> autónomo
>>>>>>>>> y por ende la información se va a mantener válida.
>>>>>>>>> 
>>>>>>>>> Al fin y al cabo, el objetivo es fomentar la adopción, correcto?
>>>>>>>>> 
>>>>>>>> ok,
>>>>>>>> pero sigo que la compración no es buena :)
>>>>>>>> 
>>>>>>>> 3) Verificación de información de ruteo:
>>>>>>>>>>> Esto no esta incluido en la propuesta, justamente por la
>>>> dependencia
>>>>>>>>>>> en el punto de observación. Por eso mi comentario de que en
>> general
>>>>>>>>>>> las herramientas para generar los objetos RPKI (i.e. la web de
>>>>>>>>>>> rpki.lacnic.net o las herramientas que comentaba Arturo) ayudan
>> a
>>>> un
>>>>>>>>>>> operador a crear ROAs "adecuados".
>>>>>>>>>>> 
>>>>>>>>>> Okay, pero poner la necesidad de generalos asociada a
>> justificativa
>>>> de
>>>>>>>>>> obtener asignación no es adecuado. Ese es mí punto.
>>>>>>>>>> 
>>>>>>>>>>> 4) Motivación de despliegue:
>>>>>>>>>>> Hay diferentes factores que motivan el despliegue de una
>>>> tecnología.
>>>>>>>>>>> Hay factores económicos, regulatorios, políticos, ecológicos, etc
>>>>>>>>>>> (i.e. análisis de PESTEL). Personalmente, creo que esta política
>>>>>>>>>>> motiva la creación de material criptográfico que aumente el valor
>>>>>>>>>>> percibido de la tecnología no para una entidad específica, pero
>>>> para
>>>>>>>>>>> el conjunto de la comunidad.
>>>>>>>>>>> 
>>>>>>>>>> Que es mejor, tener un montón de información "sin calidad" o pocas
>>>>>>>>>> pero
>>>>>>>>>> de calidad buena?
>>>>>>>>>> 
>>>>>>>>> (Roque) Porqué sería "sin calidad"?, creo que sobre-estimas el
>> valor
>>>>>>>>> de mantener información correcta para los miembros.
>>>>>>>>> 
>>>>>>>> si un ISP tiene la presión por obtener recursos adicionales y se ve
>>>>>>>> obrigado a tener RPKI, va a poner lo que sea más facil para cumplir
>>>> con
>>>>>>>> la regla.
>>>>>>>> 
>>>>>>>> y eso, no es motivación para aprender ni tampoco fomentar la
>>>> tecnlogía.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 5) Madurez de la tecnología:
>>>>>>>>>>> Justamente la adopción de esta política va a fomentar más
>> material
>>>>>>>>>>> criptográfico y por ende más resultados concretos para seguir
>>>>>>>>>>> mejorando la madurez de la tecnología. Yo creo realmente en el
>>>> valor
>>>>>>>>>>> de diseños iterativos e incrementales (i.e. ágiles).
>>>>>>>>>>> 
>>>>>>>>>> No estoy de acuerdo.
>>>>>>>>>> Creo que lo que está haciendo LACNIC está bien, o sea, los
>>>> tutoriales,
>>>>>>>>>> charlas, etc. Eso crea masa critica no solamente para implementar
>>>> sino
>>>>>>>>>> que para discutir
>>>>>>>>>> 
>>>>>>>>>> "Obligar" uno a ir por ese camino no creo que es lo que va a traer
>>>> la
>>>>>>>>>> madurez.
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> (Roque) No es "obligar", es como comunidad entender que es una
>> buena
>>>>>>>>> práctica estimular poblar la base de datos del RPKI. La realidad es
>>>>>>>>> que en las tareas de difusión es muy difícil llegar a todos los
>>>>>>>>> miembros e incluso a las personas que tienen o la clave del sistema
>>>>>>>>> de LACNIC o la información de routing. En el momento de pedir
>>>>>>>>> recursos, los canales de diålogo son más fluidos con LACNIC y
>> dentro
>>>>>>>>> de las empresas. Creo que la región de LACNIC puede avanzar muy
>>>>>>>>> rápidamente en este sentido. Si estamos tan cerca, por qué
>> frenarnos?
>>>>>>>>> 
>>>>>>>> Es obligar.
>>>>>>>> Si yo necesito de IPs adicionales, utilice bien los recursos que me
>>>>>>>> fueran asignados pero aún así no logro obtener más por esa cuestión
>> de
>>>>>>>> RPKI, me veré obligado a hacer eso, mismo que todavía no sepa bien,
>> no
>>>>>>>> la use, y ella no esté madura lo suficiente.
>>>>>>>> 
>>>>>>>> Mi punto es que mejor crear masa critica, difundir informaciones,
>> etc
>>>>>>>> 
>>>>>>>> Ricardo
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Roque
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> abrazos.
>>>>>>>>>> Ricardo
>>>>>>>>>> 
>>>>>>>>>> Roque
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Sep 6, 2012, at 3:11 PM, Ricardo Patara wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hola,
>>>>>>>>>>>> 
>>>>>>>>>>>> Como decía, creo que es interesante el esfuerzo en motivar RPKI,
>>>>>>>>>>>> pero
>>>>>>>>>>>> quería explicitar que no estoy de acuerdo a la propuesta.
>>>>>>>>>>>> 
>>>>>>>>>>>> hay ese punto en relación a los NIRs y eso puede ser
>> interpretado
>>>>>>>>>>>> también que se está intentando poner criterios en las políticas
>>>> con
>>>>>>>>>>>> 
>>>>>>>>>>> base
>>>>>>>> 
>>>>>>>>> en algo "técnico" pero que todavía no está aún en el nível de
>>>> madurez
>>>>>>>>>>>> deseado.
>>>>>>>>>>>> 
>>>>>>>>>>>> Cuanto al comentario de Roque en se agregar verificación en los
>>>>>>>>>>>> 
>>>>>>>>>>> objetos
>>>>>>>> 
>>>>>>>>> (roas, certs) de acuerdo rfcs. Es un paso, pero nuevamente, tener
>>>> eso
>>>>>>>>>>>> 
>>>>>>>>>>> en
>>>>>>>> 
>>>>>>>>> la política por si solo no va a motivar el uso de la tecnología.
>>>>>>>>>>>> 
>>>>>>>>>>>> Por ejemplo. Suponga que estos criterios de verificación figuren
>>>> en
>>>>>>>>>>>> la
>>>>>>>>>>>> política y tal verificación se haga al momento de la solicitud
>> de
>>>>>>>>>>>> bloques adicionales. Qué motivación va a tener el ISP en
>> mantener
>>>>>>>>>>>> 
>>>>>>>>>>> estos
>>>>>>>> 
>>>>>>>>> objetos "correctos" y actualizados?
>>>>>>>>>>>> 
>>>>>>>>>>>> Y mismo que se agregue ese último comentario de Christian, de
>> que
>>>> la
>>>>>>>>>>>> asignación es válida desde que se mantenga actualizada la
>>>>>>>>>>>> información
>>>>>>>>>>>> 
>>>>>>>>>>> de
>>>>>>>> 
>>>>>>>>> RPKI. Como LACNIC verificaría eso?
>>>>>>>>>>>> Una cosa es registrar información de sub asignación. Otra es
>>>>>>>>>>>> registrar
>>>>>>>>>>>> información de ruteo. Qué parametros seguiría LACNIC para
>>>> verificar
>>>>>>>>>>>> 
>>>>>>>>>>> eso?
>>>>>>>> 
>>>>>>>>> Y nuevamente al punto, como les parece que eso motiva el despliegue
>>>> da
>>>>>>>>>>>> la tecnología?
>>>>>>>>>>>> Uno puede tener todo bien registrado, pero qué vale si nadie lo
>>>> usa
>>>>>>>>>>>> porque no sabe, no conoce?
>>>>>>>>>>>> 
>>>>>>>>>>>> No me gusta la idea de hacer adoptada una tecnología (en
>> especial
>>>>>>>>>>>> 
>>>>>>>>>>> nueva
>>>>>>>> 
>>>>>>>>> y no tan madura), a través de políticas de asignación.
>>>>>>>>>>>> 
>>>>>>>>>>>> Abrazos.
>>>>>>>>>>>> 
>>>>>>>>>>>> Ricardo Patara
>>>>>>>>>>>> 
>>>>>>>>>>>> Em 06-09-2012 09:56, Christian O'Flaherty escreveu:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Apoyo la propuesta incluyendo los comentarios de Ricardo (hacer
>>>>>>>>>>>>> 
>>>>>>>>>>>> alguna
>>>>>>>> 
>>>>>>>>> referencia al caso de los NIR e incluir la "verificación" del ROA).
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Tambien habría que modificar este punto del manual:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 2.3.2.10. Validez de las distribuciones de direcciones IPv4
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Las distribuciones de direcciones IPv4 son válidas mientras...
>>>>>>>>>>>>> 
>>>>>>>>>>>>> mantener actualizada la información de las distribuiciones y
>>>>>>>>>>>>> asignaciones en la base de datos Whois de LACNIC + RPKI
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Tambien habría que incluirlo en el manual para las asignaciones
>>>>>>>>>>>>> IPv6,
>>>>>>>>>>>>> no? (4.5.6, 4.5.2, etc.)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Christian
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 2012/9/6 Roque Gagliano (rogaglia) <rogaglia at cisco.com>:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hola Ricardo,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Sep 6, 2012, at 2:10 PM, Ricardo Patara wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hola Roque,
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Me pareció interesante la idea. Pero me preocupa en especial
>>>> qué
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> pasaría
>>>>>>>> 
>>>>>>>>> con los NIRs que siguen las políticas de LACNIC pero que todavía
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> no
>>>>>>>> 
>>>>>>>>> tienen un sistema RPKI?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Quizás sea un incentivo para que lo implementen? Me imagino
>>>> que
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> los NIR tienen su plan y este tipo de discusiones las
>> deberían
>>>>>>>> tener con
>>>>>>>> sus comunidades.
>>>>>>>> 
>>>>>>>>> comprendo. pero mi pregunta es que pasaría si la propuesta es
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> aceptada
>>>>>>>> 
>>>>>>>>> pero los NIRs no tiene todavía su RPKI?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Dicho esto, entiendo que LACNIC, los NIR y sus respectivas
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> comunidades se pondrán de acuerdo en una hoja de ruta razonable
>>>>>>>> para
>>>>>>>> implementar la política. No es lo que sucede en todos los casos?
>>>>>>>> 
>>>>>>>>> Además de eso la propuesta no indica nada cuanto a validez de
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> los dados
>>>>>>>> 
>>>>>>>>> de RPKI, por ejemplo, no indica que si la ROA tiene o no que ser
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> válida,
>>>>>>>> 
>>>>>>>>> tampoco si los certificados tienen o no que estar validos (no
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> revocados
>>>>>>>> 
>>>>>>>>> y dentro de las fechas de validez).
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Si la idea es motivar el uso, hay que tener preocupación
>> con
>>>> la
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> validez
>>>>>>>> 
>>>>>>>>> y también de alguna forma motivar su uso. Creo que faltaría esa
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> parte en
>>>>>>>> 
>>>>>>>>> la propuesta.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Aquí hay dos cosas:
>>>>>>>>>>>>>>>>   - "valido" o "invalido" es una clasificación que depende
>>>> del
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> punto de observación. Por esto no creo que podamos poner
>> ningún
>>>>>>>> texto que
>>>>>>>> ayude aquí. Para mitigar errores de tipeo por parte de los
>> operadores,
>>>>>>>> las
>>>>>>>> herramientas ayudan al operador con información sobre el status de
>> la
>>>>>>>> tabla
>>>>>>>> global de rutas en distintos puntos de observación (RIS o
>> Routeviews).
>>>>>>>> 
>>>>>>>>> valido y invalido lo queria decir no es en comparación con las
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> rutas,
>>>>>>>> 
>>>>>>>>> sino que un objeto ROA "correctamente" creado.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Uno puede por ejemplo crear un ROA de cualquier forma
>> solamente
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> para
>>>>>>>> 
>>>>>>>>> cumplir con la solicitud de recursos adicionales y poner por
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> ejemplo ASN
>>>>>>>> 
>>>>>>>>> 0, o un ASN reservado, o otra cosa.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>    - hay un tema de "aging" de la información. Básicamente
>>>> por
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> más que la información sea "correcta" en el momento de
>> crearla,
>>>>>>>> al pasar el
>>>>>>>> tiempo la info en el RPKI no acompañe la información en el sistema
>> de
>>>>>>>> rutas. Esta propuesta ayuda con la mitigación de este problema pues
>>>>>>>> obliga
>>>>>>>> al ISP a revisar sus ROAs cada vez que pide nuevos  bloques.
>>>>>>>> 
>>>>>>>>> y nuevamente, si la idea es motivar el uso, al no hacer controle o
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> tener
>>>>>>>> 
>>>>>>>>> motivaciones para que la información sea valida pueda crear más
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> problemas.
>>>>>>>> 
>>>>>>>>> Uno puede crear una ROA "incorrecta", o crear y revocar su
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> certificado
>>>>>>>> 
>>>>>>>>> EE solamente para cumprir con los tramites.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Y si al mismo tiempo un provedor inicia el uso/verificación,
>> el
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> problema
>>>>>>>> 
>>>>>>>>> al ISP que genero los datos puede ser mayor.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Lo que quiero decir con eso, que es interesante motivar, pero
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> poner en
>>>>>>>> 
>>>>>>>>> la política puntos que uno puede "cumplir" por "cumplir" sin otras
>>>>>>>>>>>>>>> medidas que motiven el uso puede ser peor .
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Entiendo tu punto. Perdón por la confusión.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Te parece agregar que los certificados sean validos según
>>>> RFC6481
>>>>>>>>>>>>>> y
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> los ROAs según RFC 6483?
>>>>>>>> 
>>>>>>>>> Roque
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> saludos
>>>>>>>>>>>>>>> Ricardo
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Roque
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> un abrazo.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Ricardo Patara
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Em 06-09-2012 04:59, Roque Gagliano (rogaglia) escreveu:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Hola Gente,
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Yo soy el autor de LAC-2012-11.
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Básicamente la propuesta es muy simple. Lo que dice es que
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> agreguemos a los requerimientos para obtener recursos
>>>>>>>> adicionales que una
>>>>>>>> entidad tenga que registrar en el RPKI los recursos que ya tiene.
>>>>>>>> 
>>>>>>>>> El objetivo es simplemente solucionar un problema
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> administrativo y lograr acelerar la adopción de RPKI.
>> Muchas
>>>>>>>> veces la
>>>>>>>> persona con la clave del sistema de LACNIC no es la misma que opera
>> la
>>>>>>>> red.
>>>>>>>> Con este pedido, simplemente les pedimos a ambas entidades que se
>>>>>>>> "comuniquen" y coloquen la información en el sistema RPKI. También
>>>>>>>> logramos
>>>>>>>> que más miembros se eduquen sobre las capacidades RPKI.
>>>>>>>> 
>>>>>>>>> El costo para el miembro es mínimo pues la política no pide que
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> registre bloques delegados y pues se puede solucionar con
>> dos
>>>>>>>> o tres clicks
>>>>>>>> en la web RPKI de LACNIC.
>>>>>>>> 
>>>>>>>>> Espero sus comentarios.
>>>>>>>>>>>>>>>>>> Roque
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Sep 6, 2012, at 4:45 AM, Nicolas Antoniello wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Dear Policy-list Members,
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> There are three new Policy Proposals; numbers
>> LAC-2012-09,
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> LAC-2012-10 and
>>>>>>>> 
>>>>>>>>> LAC-2012-11:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> - LAC-2012-09 Update
>>>>>>>>>>>>>>>>>>> RIRs-on-48<
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>> http://lacnic.net/documentos/**politicas/lac-2012-09-EN.pdf
>>>> <http://lacnic.net/documentos/politicas/lac-2012-09-EN.pdf>
>>>>>>>>> 
>>>>>>>> 
>>>>>>>>> - LAC-2012-10 Allocation of IPv6 address blocks larger than a
>>>>>>>>>>>>>>>>>>> /32<http://lacnic.net/**documentos/politicas/lac-2012-**
>>>>>>>>>>>>>>>>>>> 10-EN.pdf<
>>>> http://lacnic.net/documentos/politicas/lac-2012-10-EN.pdf>
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> - LAC-2012-11 Requirement to sign up for RPKI when
>>>> requesting
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> additional
>>>>>>>> 
>>>>>>>>> resources <
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>> http://lacnic.net/documentos/**politicas/lac-2012-11-EN.pdf
>>>> <http://lacnic.net/documentos/politicas/lac-2012-11-EN.pdf>
>>>>>>>>> 
>>>>>>>> 
>>>>>>>>> <http://lacnic.net/documentos/**politicas/lac-2012-11-EN.pdf<
>>>> http://lacnic.net/documentos/politicas/lac-2012-11-EN.pdf>
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> As your comments are important, we encourage you to
>> express
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> your views on
>>>>>>>> 
>>>>>>>>> the proposals:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>   - Do you support or oppose this proposal?
>>>>>>>>>>>>>>>>>>>   - Does this proposal solve a problem you are
>>>>>>>>>>>>>>>>>>> experiencing?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> If
>>>>>>>> 
>>>>>>>>>       so, tell the community about your situation.
>>>>>>>>>>>>>>>>>>>   - Do you see any disadvantages in this proposal?
>>>>>>>>>>>>>>>>>>>   - Is there anything in the proposal that is not clear?
>>>>>>>>>>>>>>>>>>>   - What changes could be made to this proposal to make
>>>> it
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> more
>>>>>>>> 
>>>>>>>>>       effective?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Max Larson Henry
>>>>>>>>>>>>>>>>>>> Nicolas Antoniello
>>>>>>>>>>>>>>>>>>> co-Chairs of Public Policy Forum - LACNIC
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> ==============================**
>>>>>>>> ==============================**=======================
>>>>>>>> 
>>>>>>>>> Estimados suscriptores de la lista de políticas de LACNIC,
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Se recibieron tres nuevas propuestas de Política; números
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> LAC-2012-09,
>>>>>>>> 
>>>>>>>>> LAC-2012-10 y LAC-2012-11:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> - LAC-2012-09 Actualización
>>>>>>>>>>>>>>>>>>> RIRs-on-48<
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>> http://lacnic.net/documentos/**politicas/lac-2012-09-SP.pdf
>>>> <http://lacnic.net/documentos/politicas/lac-2012-09-SP.pdf>
>>>>>>>>> 
>>>>>>>> 
>>>>>>>>> - LAC-2012-10 Distribución de direcciones IPv6 mayores que
>>>>>>>>>>>>>>>>>>> /32<http://lacnic.net/**documentos/politicas/lac-2012-**
>>>>>>>>>>>>>>>>>>> 10-SP.pdf<
>>>> http://lacnic.net/documentos/politicas/lac-2012-10-SP.pdf>
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> - LAC-2012-11 Requerimiento de inscripción en RPKI para
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> recursos
>>>>>>>> 
>>>>>>>>> adicionales <
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>> http://lacnic.net/documentos/**politicas/lac-2012-11-SP.pdf
>>>> <http://lacnic.net/documentos/politicas/lac-2012-11-SP.pdf>
>>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Dado que sus comentarios son importantes, solicitamos que
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> exprese sus
>>>>>>>> 
>>>>>>>>> puntos de vista sobre las propuestas:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>   - ¿Apoya usted o se opone a esta propuesta?
>>>>>>>>>>>>>>>>>>>   - ¿Ésta propuesta resolvería un problema que ud. está
>>>>>>>>>>>>>>>>>>> experimentado? En caso
>>>>>>>>>>>>>>>>>>>       afirmativo, podría describir sus situación?
>>>>>>>>>>>>>>>>>>>   - ¿Ve alguna desventaja en esta propuesta?
>>>>>>>>>>>>>>>>>>>   - ¿Hay algo en la propuesta que no está claro?
>>>>>>>>>>>>>>>>>>>   - ¿Qué cambios podrían hacerse a esta propuesta para
>>>> que
>>>>>>>>>>>>>>>>>>> sea
>>>>>>>>>>>>>>>>>>> más eficaz?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Max Larson Henry
>>>>>>>>>>>>>>>>>>> Nicolas Antoniello
>>>>>>>>>>>>>>>>>>> Moderadores del Foro Público de Políticas de LACNIC
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> ==============================**
>>>>>>>> ==============================**========================
>>>>>>>> 
>>>>>>>>> Prezados membros da lista políticas do LACNIC,
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Se recebeu os três seguintes propostas de Política é
>>>> asignó o
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> numero
>>>>>>>> 
>>>>>>>>> LAC-2012-09, LAC-2012-10 é LAC-2012-11:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> - LAC-2012-09 Atualização
>>>>>>>>>>>>>>>>>>> RIRs-on-48<
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>> http://lacnic.net/documentos/**politicas/lac-2012-09-PT.pdf
>>>> <http://lacnic.net/documentos/politicas/lac-2012-09-PT.pdf>
>>>>>>>>> 
>>>>>>>> 
>>>>>>>>> - LAC-2012-10 Alocações IPv6 maiores que
>>>>>>>>>>>>>>>>>>> /32<http://lacnic.net/**documentos/politicas/lac-2012-**
>>>>>>>>>>>>>>>>>>> 10-PT.pdf<
>>>> http://lacnic.net/documentos/politicas/lac-2012-10-PT.pdf>
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> - LAC-2012-11 Requerimento de inscrição no RPKI para
>>>> recursos
>>>>>>>>>>>>>>>>>>> adicionais<
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>> http://lacnic.net/documentos/**politicas/lac-2012-11-PT.pdf
>>>> <http://lacnic.net/documentos/politicas/lac-2012-11-PT.pdf>
>>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Considerando que seus comentários são importantes,
>> pedimos
>>>>>>>>>>>>>>>>>>> que
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> expresse
>>>>>>>> 
>>>>>>>>> suas opiniões sobre as propostas:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>    - Você apoia ou se opõe a esta proposta?
>>>>>>>>>>>>>>>>>>>    - Esta proposta resolveria um problema que você
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> experiencia?
>>>>>>>> 
>>>>>>>>>         No caso afirmativo, você poderia descrever a sua
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> situação?
>>>>>>>> 
>>>>>>>>>      - Você vê algum inconveniente com esta proposta?
>>>>>>>>>>>>>>>>>>>    - Há algo na proposta que não está claro?
>>>>>>>>>>>>>>>>>>>    - Que mudanças poderiam ser feitas para a presente
>>>>>>>>>>>>>>>>>>> proposta
>>>>>>>>>>>>>>>>>>>       para torná-lo mais eficaz?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Max Larson Henry
>>>>>>>>>>>>>>>>>>> Nicolás Antoniello
>>>>>>>>>>>>>>>>>>> Moderadores do Foro Público de Políticas - LACNIC
>>>>>>>>>>>>>>>>>>> ______________________________**_________________
>>>>>>>>>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>>>>>>>>>> Politicas at lacnic.net
>>>>>>>>>>>>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> ______________________________**_________________
>>>>>>>>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>>>>>>>>> Politicas at lacnic.net
>>>>>>>>>>>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> ______________________________**_________________
>>>>>>>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>>>>>>>> Politicas at lacnic.net
>>>>>>>>>>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> ______________________________**_________________
>>>>>>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>>>>>>> Politicas at lacnic.net
>>>>>>>>>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> ______________________________**_________________
>>>>>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>>>>>> Politicas at lacnic.net
>>>>>>>>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> ______________________________**_________________
>>>>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>>>>> Politicas at lacnic.net
>>>>>>>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> ______________________________**_________________
>>>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>>>> Politicas at lacnic.net
>>>>>>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ______________________________**_________________
>>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>>> Politicas at lacnic.net
>>>>>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>>>>>> 
>>>>>>>>>>> ______________________________**_________________
>>>>>>>>>>> Politicas mailing list
>>>>>>>>>>> Politicas at lacnic.net
>>>>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>>>>> 
>>>>>>>>>>> ______________________________**_________________
>>>>>>>>>> Politicas mailing list
>>>>>>>>>> Politicas at lacnic.net
>>>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>>>> 
>>>>>>>>> ______________________________**_________________
>>>>>>>>> Politicas mailing list
>>>>>>>>> Politicas at lacnic.net
>>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>>> 
>>>>>>>>> ______________________________**_________________
>>>>>>>> Politicas mailing list
>>>>>>>> Politicas at lacnic.net
>>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>>> 
>>>>>>>> ______________________________**_________________
>>>>>>> Politicas mailing list
>>>>>>> Politicas at lacnic.net
>>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>>> 
>>>>>>> ______________________________**_________________
>>>>>> Politicas mailing list
>>>>>> Politicas at lacnic.net
>>>>>> https://mail.lacnic.net/**mailman/listinfo/politicas<
>>>> https://mail.lacnic.net/mailman/listinfo/politicas>
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Politicas mailing list
>>>>> Politicas at lacnic.net
>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>> 
>>>>> 
>>>> _______________________________________________
>>>> Politicas mailing list
>>>> Politicas at lacnic.net
>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> 
>>> Regards,
>>> Gustavo Lozano
>>> _______________________________________________
>>> Politicas mailing list
>>> Politicas at lacnic.net
>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>> 
>> 
>> 
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
>> 
>> 
> 
> 
> -- 
> 
> Regards,
> Gustavo Lozano
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
> 





More information about the Politicas mailing list