[LACNIC/Politicas] Propuesta de pol í tica para asignar PI IPv6 a Organizaciones-Usuario-Final

Sun Jun 3 14:53:04 BRT 2007

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gustavo Lozano wrote:
> At 11:08 01/06/2007, JORDI PALET MARTINEZ wrote:
>>> De: Roque Gagliano <rgaglian at antel.net.uy>
>>> Organización: ANTELDATA
>>> Responder a: LACNIC Policy mailling list <politicas at lacnic.net>
>>> Fecha: Fri, 01 Jun 2007 12:33:23 -0300
>>> Para: LACNIC Policy mailling list <politicas at lacnic.net>
>>> Asunto: Re: [LACNIC/Politicas] Propuesta de 
>> pol í tica para asignar PI IPv6 a
>>> Organizaciones-Usuario-Final
>>>
>>> Siguen mis comentarios.
>>>
>>>>> On May 31, 2007, at 7:08 PM, Gustavo Lozano wrote:
>>>>>
>>>>>> Hola,
>>>>>>
>>>>>> Después de una conversación entre Jordi y su
>>>>>> servidor queremos poner a consideración de todos
>>>>>> la siguiente propuesta de política para asignar
>>>>>> PI IPv6 a Organizaciones-Usuario-Final que toma
>>>>>> en cuenta las sugerencias escuchadas en el foro público en LACNIC X.
>>>>>>
>>>>>> Nos gustaría escuchar sus comentarios antes de
>>>>>> enviar el template formal a la dirección propuesta at lacnic.net.
>>>>>>
>>>>>> Gracias y esperamos sus comentarios.
>>>>>>
>>>>>> Asignaciones IPv6 Independientes del Proveedor
>>>>>> (PI) para Organizaciones-Usuario-Final
>>>>>>
>>>>>> Si la organización cuenta con un bloque PI
>>>>>> (direcciones independientes del proveedor) IPv4
>>>>>> se le asignará automáticamente un bloque PI IPv6.
>>>>>> En este caso, se asignará un /48, a menos que la
>>>>>> organización justifique la necesidad de un bloque mayor.
>>>>>>
>>> Como alguien mas comento no estoy de acuerdo con utilizar el termino
>>> "automatico". Deberíamos seguir la metodología que ya hemos usado:
>>> "Una organización podrá solicitar una colocación PI si
>>> a) xxxx
>>> b) yyyy
>>> "
>>> Yo particularmente no me parece que debemos atar las políticas de IPv4 a
>>> IPv6. No lo hacemos para los ISPs donde simplemente se dice que la
>>> cantidad de IPv4 asignadas pueden ser usadas como justificativo para el
>>> tamaño del bloque.
>> Es el mismo criterio que se ha seguido en ARIN y APNIC, y es bastante
>> logico, pues *generalmente* quien necesite IPv6 PI tambien tiene o necesita
>> IPv4 PI.
>>
>> De otro modo habria que definir un criterio para IPv6 PI especifico, y en 3
>> años no se logro consenso en ARIN mas que de esta forma.
> 
> * Los criterios para asignar PI IPv4 permite 
> colocar solamente el recurso a las organizaciones 
> que realmente lo requieren, por lo que podemos 
> considerar que son criterios adecuados.
> * Si como organización ya pasaste por el proceso 
> para obtener PI IPv4 porque pasar por el proceso 
> de nuevo para PI IPv6 si al final se terminaran 
> pidiendo requisitos similares.

Y que ocurre cuando la organización no ha pasado por el proceso de
obtener IPv4 PI paro si le interesa IPv6 PI?

> 
>>>>>> Si la organización no cuenta con un bloque PI
>>>>>> IPv4, deberá realizar la solicitud de un bloque
>>>>>> PI IPv4 y cumplir con el criterio
>>>>>> correspondiente.
>>> Que pasa cuando no hayan mas direcciones IPv4 para colocar? de vuelta no
>>> creo que debamos relacionar las dos políticas.
>> No importa, porque si cumples el criterio aunque las pidas y no se te puedan
>> dar, o no las pidas, lo importante es cumplir el criterio.
> 
> El Internet IPv4 no llega a su fin cuando no 
> queden direcciones en el pool de IANA o en el 
> pool de los RIRs. Despues del dia ?D? van a 
> seguir habiendo colocaciones PI IPv4 en uso y 
> esas empresas van a querer espacio PI IPv6, y lo 
> podran obtener mediante esta propuesta.
> 
>>>>  Una vez que haya calificado para
>>>>>> un bloque PI IPv4, se asignará también un bloque
>>>>>> PI IPv6; se asignará un /48 por defecto, salvo
>>>>>> que, como en el caso anterior, justifique la
>>>>>> necesidad de un bloque mayor. En caso de que la
>>>>>> organización no necesite direccionamiento IPv4
>>>>>> podrá especificarlo en la solicitud y solo recibir un bloque PI IPv6.
>>>>>>
>>>>>> El tamaño mínimo para la asignación es un /48.
>>>>>> LACNIC realizará una reserva de bloques contiguos
>>>>>> en función de la documentación ofrecida por el
>>>>>> interesado. Un bloque mayor (un prefijo de menor
>>>>>> longitud) podría ser asignado, según criterio del
>>>>>> staff de LACNIC, si se documenta y justifica por parte del
>>>>>> solicitante.
>>> este ultimo parrafo me parece que no se necesita. se sabe que las
>>> políticas las implementa el staff.
>> No estamos "fijando la operativa del staff" (cosa que no queremos hacer),
>> sino simplemente aclarandolo (no todo el mundo sabe tanto del funcionamiento
>> de LACNIC como algunos de nosotros), pero el parrafo tiene detalles que si
>> que hay que indicar en la politica.
>>
>>>>>> Asignaciones subsecuentes:
>>>>>> Siempre que sea posible, sucesivas asignaciones
>>>>>> se realizarían de un bloque de direcciones
>>>>>> adyacente, pero solo si se documenta y justifica convenientemente.
>>>>>>
>>> lo importanta cuando hablamos de colocaciones subsecuentes es establecer
>>> el criterio de entrada de cuando clasifica y como se calcula el tamaño,
>>> el resto de vuelta lo realiza el staff.
>> En todas las regiones tenemos textos parecidos. Creo que es logico tener
>> esto para facilitar la agregacion.
> 
> Roque, te propongo que envies criterios para 
> permitir al staff de LACNIC evaluar si es 
> necesario o no, la asignacion de otro bolque.
> 
>>>>>> "Super-Bloque" de asignación:
>>>>>> Las asignaciones serán asignadas desde un
>>>>>> "super-bloque" separado, para facilitar a los RIR el filtrado de
>>>>>> las mismas.
>>>>>>
>>>>>>
>>>>>> Saludos,
>>>>>>
>>>>>> Gustavo Lozano
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Politicas mailing list
>>>>>> Politicas at lacnic.net
>>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>> -------------------------------------------------------------
>>>>> Roque Gagliano
>>>>> ANTEL - URUGUAY
>>>>> rgaglian at antel.net.uy
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Politicas mailing list
>>>>> Politicas at lacnic.net
>>>>> https://mail.lacnic.net/mailman/listinfo/politicas
>>>>
>>>>
>>>>
>>>> **********************************************
>>>> The IPv6 Portal: http://www.ipv6tf.org
>>>>
>>>> Bye 6Bone. Hi, IPv6 !
>>>> http://www.ipv6day.org
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>>
>>
>> **********************************************
>> The IPv6 Portal: http://www.ipv6tf.org
>>
>> Bye 6Bone. Hi, IPv6 !
>> http://www.ipv6day.org
>>
>> 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.
>>
>>
>>
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/politicas
> 
> Saludos,
> 
> Gustavo Lozano
> 
> 
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
> 
> 

- --
A: Because it destroys the flow of conversation.
Q: Why is top posting dumb?
- --
Juan Nicolás Ruiz    | Corporación Parque Tecnológico de Mérida
                     | Centro de Cálculo Cientifico ULA
nicolas at ula.ve       | Avenida 4, Edif. Gral Masini, Ofic. B-32
+58-(0)274-252-4192  | Mérida - Edo. Mérida. Venezuela
PGP Key fingerprint = CDA7 9892 50F7 22F8 E379  08DA 9A3B 194B D641 C6FF
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGYwAAmjsZS9ZBxv8RApCTAJ4zJbXLN4fIkELrWB/nae4A/NkTNQCfXahN
FJsuE2L4Pd09gDNy+2hoRxc=
=bwUF
-----END PGP SIGNATURE-----