[LACNIC/Politicas] LAC-2012-1

Gustavo Lozano glozano.gli at gmail.com
Thu Sep 6 20:37:46 BRT 2012


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



More information about the Politicas mailing list