[LACNIC/Politicas] Nueva propuesta de pol í tica (modificacion de la existente de asignaci =?ISO-8859-1?B?8yA=?=n y adjudicaci =?ISO-8859-1?B?8yA=?=n de IPv6)

Wed Jun 7 07:17:43 BRT 2006

Hola Marcelo,

Sigo debajo.

Saludos,
Jordi

> De: marcelo bagnulo braun <marcelo at it.uc3m.es>
> Responder a: <marcelo at it.uc3m.es>
> Fecha: Wed, 7 Jun 2006 12:59:19 +0300
> Para: <jordi.palet at consulintel.es>
> CC: <politicas at lacnic.net>
> Asunto: Re: [LACNIC/Politicas] Nueva propuesta de pol í  tica (modificacion de
> la existente de asignaci ó n y adjudicaci ó n de IPv6)
> 
> 
> El 05/06/2006, a las 22:03, JORDI PALET MARTINEZ escribió:
> 
>>>> Para calificar para la adjudicación inicial de un espacio de
>>>> direcciones
>>>> IPv6, una organización debe:
>>>> 
>>>> a)    Ser un LIR o ISP;
>>>> b)    Documentar un plan detallado sobre los servicios y la
>>>> conectividad en
>>>> IPv6 a ofrecer a otras organizaciones (clientes) o a sus
>>>> propios/relacionados(as) departamentos/entidades/sitios, a los cuales
>>>> asignará /48s.
>>>> c)    Anunciar en el sistema de rutas inter-dominio de Internet un
>>>> único
>>>> bloque, que agregue toda la asignación de direcciones IPv6 recibida,
>>>> en un
>>>> plazo no mayor de 12 meses.
>>>> d)    Ofrecer servicios en IPv6 a clientes o entidades
>>>> propias/relacionadas
>>>> (incluyendo departamentos y/o sitios) localizados físicamente en la
>>>> región
>>>> de LACNIC en un plazo no mayor de 24 meses.
>>>> 
>>> 
>>> esto basicamente quiere decir que cualquier que quiera/pueda pagar la
>>> membresia de ser un LIR puede obtener su propio bloque /32
>> 
>> No cualquiera, sigue teniendo que justificar un plan, y ahí esta el
>> criterio
>> del hostmaster, que creo que es lo suficientemente bueno y probado
>> hasta
>> ahora.
> 
> si pero estamos reduciendo los cirteriso definidos para que el host
> master haga su evaluacion y le ponemos mas peso en su criterio propio.
> Digo, segun entiendo, la idea es que las politicas definan unos
> criterios claros para asi facilitar el trabajo del host master y
> evitarle problemas, en el sentido que esta claro cuando una asignacion
> es valida y cuando no. Si solo queda el criterio del hostmaster, se
> abre la posibilidad de quejas y problemas porque las reglas/criterios
> de evaluacion no estan claros

Creo que no hay que pensar que el hostmaster "no sabe", sino al contrario,
creo que es logico dar cierto margen a su criterio.

De hecho, el hostmaster ya ha flexibilizado en algunos casos, porque la
interpretacion de la politica le permitia entender que una universidad era
un ISP. Lo que estamos haciendo ahora es formalizarlo. Creo que es bastante
logico, sino quizas tendriamos que reclamar esos prefijos.

Quiero decir, que por mucho que queramos delimitar una politica, no se puede
ser absolutamente estricto, y si no nos fiamos del criterio del hostmaster,
entonces hagamos que cada solicitud se apruebe por un comite :-) (lo digo
ironicamente porque me parece que no es el camino).

Creo que si la comunidad no esta deacuerdo con el criterio del hostmaster,
igual que si un miembro de la comunidad le es rechazada una peticion,
siempre tiene la posibilidad de hablarlo en la lista y ese proceso puede
ayudar a "aclarar" las politicas e ir mejorando su redaccion si es el caso.

> 
>> 
>>> 
>>> la barrera de entrada en este caso ya no pasa por la condicion de
>>> proveedor de servicios o el tamaño sino simplemente por el dinero....
>> 
>> No, creo que el plan es mas importante,
> 
> claro pero como hacemos para evaluar un plan aceptable para una
> asignacion?
> 
> como menciono antes, creo que pedir un plan, pero no poner ningun tipo
> de requerimiento para el plan, y solo confiar en el criterio del
> hostmaster es psarle el problema al hostmaster y eso creo que
> deberiamos evitarlo.
> 
> creo que deberiamos tratar de explorar si hay cirterios objetivos que
> puedan ser reflejados en los requirmientos
> 

Ahora mismo ya se esta haciendo asi. Se pide un plan y se confia en el
criterio del hostmaster. La diferencia es que aplican mas entidades, pero en
la realidad, insisto, ya esta ocurriendo.

Los criterios objetivos no creo que sean validos. Me acuerdo del requisito
de 200 /48. Es objetivo, pero es absurdo, puedes tener un ISP con 2 clientes
muy importantes, y tiene derecho a un prefijo. Aunque la politica dijera que
no, posiblemente las leyes podrian darle la razon. Es algo que comente con
RIPE NCC y nadie se habia dado cuenta (en Europa algo asi muy posiblemtente
seria considerado ilegal por la discriminacion que implica entre diferentes
tamaños de empresas y en contra de las leyes de la competencia).

Si se te ocurre un criterio concreto, proponlo, please. Igual hay cosas que
se nos escapan sin ejemplos concretos de tu vision del tema.

> 
>>  dado que justifica la red, y no
>> calificas por mucho que quieras pagar si no es apropiado.
>> 
>>> 
>>> la verdad que no me convence mucho... sobre todo porque el parametro
>>> utilizado para definir el numero de bloques asignados (el precio de la
>>> membresia) escapa el control de esta lista. Con esta politica, el
>>> precio de membresia afecta el numero de entradas en la tabla global de
>>> rutas... es un poco raro me parece a mi
>> 
>> Como digo no es el caso, bajo mi punto de vista.
>> 
>>> 
>>>> Sección 5.5. actual:
>>>> 
>>>> 5.5. Micro-Asignaciones en IPv6
>>>> 
>>>> LACNIC podrá realizar micro-asignaciones en casos de proyectos e
>>>> infraestructuras de redes claves o críticas para el funcionamiento, y
>>>> desarrollo de IPv6 en la región como son IXP (Internet Exchange
>>>> Point), NAP
>>>> (Network Access Point), RIR, proveedores de DNS ccTLD, entre otros.
>>>> Dichas
>>>> asignaciones se realizarán en bloques menores o igual a un /32 pero
>>>> siempre
>>>> mayores o iguales a un /48.
>>>> 
>>>> Texto sustitutivo propuesto:
>>>> 
>>>> 5.5. Micro-Asignaciones en IPv6
>>>> 
>>>> LACNIC podrá realizar micro-asignaciones en casos de proyectos e
>>>> infraestructuras de redes claves o críticas para el funcionamiento, y
>>>> desarrollo de IPv6 en la región como son IXP (Internet Exchange
>>>> Point), NAP
>>>> (Network Access Point), RIR/NIR, root servers, proveedores de DNS
>>>> TLD,
>>>> entre
>>>> otros. Dichas asignaciones se realizarán en bloques /32 (o mayores si
>>>> se
>>>> jusitifica convenientemente), excepto en el caso de que con seguridad
>>>> se
>>>> sepa que no tiene que ser anunciados, en cuyo caso se podrán utilizar
>>>> bloques mayores o iguales a un /48.
>>>> 
>>> 
>>> estoy de acuerdo con darle un /32 a los TLDs, y capaz que a los RIRs
>>> (si consideramos que las bases de datos que tiene son criticas para
>>> elfuncionamiento)
>>> por otra parte, no entiendo porque es necesario darles un /48 a los IX
>>> y NAPs. Digo, el direccionamiento de estos es interno, correcto. Digo
>>> quienes se conectan a estos puntos tiene sus propios bloques, por que
>>> razon es critico que los equipos del IX/NAP sean accesibles desde el
>>> resto de la internet? es mas, creo que seria deseable que no lo
>>> fuera...
>> 
>> Aquí no he cambiado nada (para los IX/NAP), al contrario, indico
>> claramente
>> que sea un /48 si no se anuncia, que es lo habitual.
>> 
> 
> si ha habido un cambio...
> 
> la politica actual dice:
> 
> Dichas asignaciones se realizarán en bloques menores o
> igual a un /32 pero siempre mayores o iguales a un /48.
> 
> la propuesta nueva dice:
> 
> Dichas asignaciones se realizarán en bloques /32
> (o mayores si se jusitifica convenientemente),
> excepto en el caso de que con seguridad se
> sepa que no tiene que ser anunciados, en cuyo caso
> se podrán utilizar bloques mayores o iguales a un /48.
> 
> como veras, antes la recomendacion sobre el tamaño era cualqueira entre
> /48 y /32
> 
> tu propuesta cambia esto, y dice que por defecto sea un /32 salvo que
> se sepa con seguridad que no se quiera anunciar, en cuyo caso sea un
> /48

Si pero me circunscribo a la realidad de la aplicación de la politica. Se
esta entregando siempre un /32. Y creo que es mejor que la politica refleje
el criterio real que se sigue.

Fijate que te contradices, en el sentido de que dices que no caiga el peso
en el hostmaster, y actualmente esta siendo asi. No ?

Yo creo que en este caso el criterio objetivo si que es definible por la
cuestion de mejorar en la medida de lo posible la garantia de
encaminamiento, por eso prefiero ser mas explicito.

> 
> Lo que digo es que por ejemplo en el caso de los IX y NAPs, es posible
> que los quieran anunciar (por alguna razon) pero que no por esto
> califican para tener un /32.

Bueno, es la discusion de hasta que punto asignar a los IX/NAP /32 en lugar
de /48 es problemático y es malgastar espacio frente a empeorar
posibilidades de encaminamiento, sobre todo teniendo en cuenta que lo
habitual es no anunciarlo y que dudo que se den siquiera un par de casos en
la region (que lo quieran anunciar).

> 
>> 
>>> 
>>> 
>>>> 
>>>> Texto adicional a ser eliminado de la política actual:
>>>> 
>>>> 1.1. Alcance
>>>> 
>>>> Esta política es considerada interina. Será revisada en el futuro,
>>>> cuando se
>>>> disponga de mayor experiencia en la administración de IPv6.
>>>> 
>>> 
>>> no veo porque eliminar esta parte... creo que todaia estamos
>>> aprendiendo y claramente las reglas lazas de asignacion inical indican
>>> que esto deba ser revisado en un futuro...
>> 
>> Creo que discrepo. Ya hemos aprendido, ya somos "bastante mas mayores"
>> con
>> IPv6, y este comentario sobra. Si hay que revisar la politica, se
>> revisa
>> siempre que sea preciso, y sin este comentario. Luego simplifiquemos el
>> texto y no seamos ingenuos.
>> 
> 
> :-)
> si creo que discrepamos
> 
> creo que IPv6 todavia esta empezando y todavia tenemos mucho que
> aprender sobre como hacer etas politicas...

Creo que esto tambien aplica a IPv4 :-(

> 
> pero bueno, esto no es normativo y no tiene concequencias, por lo que
> me resulta menos relevante
> 
> 
>>> 
>>>> 
>>>> 5.4.2. Asignación de multiples /48s a un solo site
>>>> 
>>>> Cuando un solo end site requiere un bloque de direcciones de /48
>>>> adicional,
>>>> debe pedir la asignación con documentación o materiales que
>>>> justifiquen el
>>>> pedido. Los pedidos de bloques múltiples o adicionales de /48s serán
>>>> procesados y revisados (ej: evaluación de la justificación) al nivel
>>>> de los
>>>> RIR/NIR.
>>>> 
>>> 
>>> porque quieres quitar esto? por lo de las asignaciones de /56? no
>>> habria que sustituirlo con un comentario en la misma linea pero con
>>> /56? capaz que eso ya esta en otra parte tal vez...?
>>> 
>>> saludos, marcelo
>>> 
>> 
>> No tieen nada que ver con el tema del /56, al menos no mientras no se
>> apruebe que no es el caso por el momento. Lo que digo es que no tiene
>> ningun
>> sentido a estas alturas, sea cual sea el tamaño del prefijo que un LIR
>> entrega al cliente, que lo tenga que evaluar el RIR. Es el ISP el que
>> lo
>> evaluara y registrara en el whois para que le cuente de cara a su
>> proxima
>> peticion al RIR.
>> 
> 
> ok, ya lo entiendo....
> si puedo estar de acuerdo con esto...
> 
> saludos, marcelo
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Barcelona 2005 Global IPv6 Summit
Slides available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.