[LACNIC/Politicas] Discusion de LAC-2007-06 Asignaciones IPv6 ULA-Central

Tue May 29 19:21:26 BRT 2007

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

JORDI PALET MARTINEZ wrote:
> El draft *siempre* existe. Aun cuando expire, se archiva y esta disponible,
> por eso hablo de la ultima version, porque lo que me interesa es el texto
> del draft.
> 
> Si, es una alternativa incluir el texto del draft, pero no lo hice asi,
> porque:
> 1) Creo que el draft va a evolucionar hasta RFC.
> 2) Incluir el texto del draft supondria tener una politica de varias paginas
> de longitud !

El utilizar un internet draft (sobre todo si queda al aire como "última
versión") va en contra del objetivo de tener un texto estable en la
propuesta, que tu mismo mencionas:

JORDI PALET MARTINEZ wrote:
> Tambien discrepo, y en este caso mucho mas, en el hecho de que el
> texto pueda sufrir modificaciones menores durante esos 30 dias. En
> ninguna region se acepta esto.

Por lo que creo que es preferible hacer referencia solamente a
documentos "archivables": RFCs, STD, BCP o similares y no hacer
referencia a internet drafts, que se espera que sean temporales.

Estoy de acuerdo con avanzar en paralelo en el IETF y en los RIRs.

> 
> Saludos,
> Jordi
> 
> 
> 
> 
>> De: Ricardo Patara <patara at lacnic.net>
>> Organización: LACNIC
>> Responder a: LACNIC Policy mailling list <politicas at lacnic.net>
>> Fecha: Mon, 28 May 2007 10:45:47 -0300
>> Para: <politicas at lacnic.net>
>> Asunto: Re: [LACNIC/Politicas] Discusion de LAC-2007-06 Asignaciones IPv6
>> ULA-Central
>>
>> Jordi,
>> Permitame un comentario.
>>
>> Yo creo que el problema que se verifico en esa propuesta fue hacer no
>> solamente
>> referencia a un texto externo, pero indicar que los criterios y justificativas
>> para acceder a un bloque ULA central serian aquellos indicados en el draft.
>>
>> El texto de la propuesta indica:
>>
>> "ULA-central se refiere a direcciones unicast locales y únicas, centralmente
>> asignadas, como se describe en el documento de IETF
>> "ietf-ipv6-ula-central" (cualquiera que sea la ultima versión disponible, bien
>> sea Internet Draft, RFC o STD). El bloque ULA-central esta dentro del prefijo
>> FC00::/7, con el bit 8 a 0."
>>
>> Lo que me preocupa como staff y creo que era la preocupación de los que
>> demostraran contrarios a la propuesta fue evaluar algo que estaria en un
>> documento externo. Lo cual no existe en ese momento... el draft a que te
>> refieres esta muerto. Se uno lo intenta buscarlo en el sitio de ietf no lo
>> encontraras ... por lo menos yo no lo encontre :(
>> quizas lo busque en lugar errado...
>>
>> creo que se quedaria mas claro si la propuesta no hiciera referencia a un
>> documento externo que no existe en ese momento....
>>
>> Saludos
>> Ricardo
>>
>>> Hola a todos,
>>>
>>> Como sabeis, soy el autor de esta propuesta, pero en este correo no quiero
>>> defenderla, sino aclarar aspectos que a mi juicio han roto el PDP y deben de
>>> evitarse en el futuro, incluso comparandolo con casos similares para que se
>>> evidencie el trato diferenciado.
>>>
>>> A nadie se le pide que este deacuerdo o no con una determinada propuesta,
>>> pero pedir el juego limpio es una regla fundamental del proceso.
>>>
>>> 1) En ningun punto del PDP se exige que una propuesta dependa de un RFC. De
>>> hecho los RFCs no son estandards, solo lo son los STDs, y muchas politicas
>>> estan basadas en RFC. Tanto los Internet Drafts como los RFCs pueden
>>> cambiar, ambos por *igual*.
>>>
>>> Sin embargo algunos asistentes indicaron que si que era preciso, manipulando
>>> asi la opinion de los asistentes.
>>>
>>> Esto NO PUEDE PERMITIRSE, porque NO ES CIERTO. Es mas, creo que los que
>>> hicieron esas manifestaciones deberian de pedir disculpas a la comunidad y
>>> si no se hace, desde luego, a partir de ahora su credibilidad debe de ser
>>> puesta en duda por todos los demas participantes desde este momento.
>>>
>>> Por si hay alguna duda, basta decir, y esto es LITERALMENTE CIERTO, que la
>>> politica global de 4-byte ASN, ha sido aprobada en todas las regiones cuando
>>> solo era un conjunto de Internet Draft. Es decir, se puede interpretar que
>>> se ha intentado manipular el proceso no por simple error, sino
>>> malintencionadamente, pues habia un precedente muy reciente.
>>>
>>> Igualmente es importante aclarar, que hay muchas politicas que no tienen
>>> RFCs que las respalden, por ejemplo la politica global de IPv6 para entregar
>>> los /12 a los RIRs, que *contradice* un documento previo del IETF que
>>> entregaba /23, y ademas no tiene un documento del IETF que respalde el /12.
>>>
>>> Para mas detalle, tal y como indica el RFC4147, "The IPv6 address management
>>> function was formally delegated to IANA in December 1995 (RFC1881)". Es
>>> decir, TODO el espacio IPv6 lo pueden utilizar IANA y los RIRs (leyendo el
>>> RFC1881 queda claro que son ambos).
>>>
>>> Por ultimo, los RIRs si que pueden hacer politicas idenpendientemente del
>>> IETF, y de hecho lo hacemos muy a menudo.
>>>
>>> Recientemente ha habido esta discusion en la lista general del IETF, copiada
>>> en ARIN y RIPE. El propio ultimo chair del IETF, Brian Carpenter, que asumo
>>> conoce bien el tema y el MoU con IANA (porque ha sido terminado bajo su
>>> mandato), asi lo confirmado:
>>> http://www1.ietf.org/mail-archive/web/ietf/current/msg46102.html
>>> http://www1.ietf.org/mail-archive/web/ietf/current/msg46101.html
>>>
>>> 2) Leo de IANA, indico que preferia un RFC y esa es tambien mi preferncia,
>>> pero no es excluyente que no lo haya. En una conversacion mantenida con el
>>> en San Juan de Puerto Rico durante la pasada reunion de ARIN, hace 5
>>> semanas, quedo claro que habia dos opciones, el RFC, o bien una politica
>>> global. No se si el ha cambiado de opinion, no me quedo claro en la reunion.
>>> Pero su cambio de opinion no es vinculante. Es decir, los RIRs pueden
>>> prescindir del IETF y decidir por si mismos mediante politicas globales, y
>>> asi lo hemos hecho en otros casos (como el indicado antes para /12 y la
>>> ultima propuesta para el reparto de los bloques de 4byte-ASN presentada por
>>> RIPE, ambos aprobados sin ningun tipo de consideracion a documentos del
>>> IETF, que por supuesto no existen).
>>>
>>> Por otro lado, el ejemplo de superman y spiderman es totalmente incoherente.
>>> No creo que sea apropiado ni bueno bajo ningun punto de vista intentar hacer
>>> un chiste de ciencia-ficcion para decir que no ganarian los RIRs ni el IETF.
>>> Lo siento, pero creo que si el proceso del IETF no se completa (que por
>>> supuesto seria lo ideal) con un determinado documento, es evidente que tiene
>>> que haber un camino alternativo.
>>>
>>> Y digo esto como participante muy activo del IETF y defensor a ultranza del
>>> mismo. Los cuellos de botella se producen en cualquier organización y otras
>>> no tienen porque estancarse a causa de ello, especialmente cuando hay un
>>> mecanismo alternativo.
>>>
>>> 3) Según entendi de Ray de ARIN, en esta region no se acepta una propuesta
>>> que no sea un RFC, sin embargo, se ha aceptado 4-byte ASN, al igual que ya
>>> he indicado antes, como en el resto de las regiones, cuando aun no eran
>>> RFCs. Igualmente, el PDP de la region NO
>>> (http://www.arin.net/policy/irpep.html) indica nada al respecto. Entiendo
>>> que el advisory council (AC), que revisa las propuestas, podria rechazar
>>> estos casos, pero aun asi, el autor podria utilizar el proceso de peticion
>>> para saltarse la decision del AC. El directorio de ARIN, tambien podria
>>> oponerse. No esta claro bajo que circunstancias, asi que supongo que se
>>> podria argumentar que no es un RFC, pero entonces, se estaria haciendo una
>>> diferencia con otros RFCs, y entiendo que podria haber implicaciones legales
>>> u otras. En cualquier caso creo que seria incorrecto y deberia de no ser
>>> aceptado por la comunidad si se da el caso.
>>>
>>> Para terminar, teniendo en cuenta la lentitud de todos estos procesos (tanto
>>> IETF como PDP), es por tanto deseable que se hagan en paralelo en lugar de
>>> secuencialmente, y de hecho, entiendo que esto es lo que se ha hecho en
>>> otros casos, y creo que por esta misma razon (habria que confirmarlo con los
>>> autores) como el 4-byte ASN.
>>>
>>>
>>> Saludos,
>>> Jordi
>>>
>>>
>>>
>>>
>>>
>>>
>>> **********************************************
>>> 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
>>
>> -- 
>> BOFH excuse #46:
>>
>> waste water tank overflowed onto computer
>> _______________________________________________
>> 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
> 
> 

- --
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

iD8DBQFGXKdmmjsZS9ZBxv8RAootAJ0aY7OoN6pltfJ3vI0yswGNbYlrwACeJ+n6
BJQUV2KDc7Xx1NQA0RycHn0=
=LlIb
-----END PGP SIGNATURE-----