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

Mon May 28 10:45:47 BRT 2007

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