[LACNIC/Politicas] LAC-2012-1
Roque Gagliano (rogaglia)
rogaglia at cisco.com
Fri Sep 7 09:17:17 BRT 2012
Alejandro,
> - Capacitación. Aprobar esta política implica que todos los responsables de recursos deben tener conocimientos de RPKI.
>
exacto!
r.
>
> 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>
>>>>>>>>>>>>>>> - LAC-2012-10 Allocation of IPv6 address blocks larger than a
>>>>>>>>>>>>>>> /32<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>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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>
>>>>>>>>>>>>>>> - LAC-2012-10 Distribución de direcciones IPv6 mayores que
>>>>>>>>>>>>>>> /32<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>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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>
>>>>>>>>>>>>>>> - LAC-2012-10 Alocações IPv6 maiores que
>>>>>>>>>>>>>>> /32<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>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> 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
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>
>>>> _______________________________________________
>>>> 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