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

[JORDI PALET MARTINEZ]

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.