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

Mon May 28 10:41:23 BRT 2007

Jordi,

On Sun, May 27, 2007 at 10:47:36PM +0200, JORDI PALET MARTINEZ wrote:
> 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.

Atenção, em momento algum isto foi dito nem por mim nem pelas outras
pessoas que comentaram este assunto. A pergunta foi qual a RFC que
trata deste draft referenciado em sua proposta ?

A sua resposta foi que tal documento não existe. A sua proposta deve
se sustentar por si só ou com bases em documentos referenciáveis. O
draft que você cita não existe mais desde agosto de 2005.

Se você tivesse simplesmente adaptado a idéia do falecido draft
diretamente em sua proposta e não o referenciado, ou ao menos tentado
reviver o mesmo, o comentário não teria existido.

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

Esta proposta foi apresentada depois que o processo dentro do WG IDR
já estava praticamente encerrado em Nov/2005. Após 4 anos de discussão
dentro do IETF este assunto já era consensual há época pendente
somente dos tramites finais no processo do IETF. Algo que não ocorre
nem de perto no caso da sua proposta que foi muito controversa dentro
do IETF.

Se alguém tem que se desculpar aqui é você que presume má intenção dos
que comentam contrariamente sua proposta.

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

Ele não disse isto em momento algum, disse que não se aceitam drafts
como referência em propostas, na mesma linha do meu comentário em
relação a estabilidade das referências acima.

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

Concordo com você em relação a lentidão e a necessidade de paralelizar
o processo mas como disse anteriormente acho que não podemos
referenciar algo que não existe.

> Saludos,
> Jordi

Fred