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

Mon May 28 12:18:00 BRT 2007

Hola Frederico,

Contesto debajo.

Saludos,
Jordi

> De: Frederico A C Neves <fneves at registro.br>
> Responder a: <fneves at registro.br>
> Fecha: Mon, 28 May 2007 10:41:23 -0300
> Para: <jordi.palet at consulintel.es>, LACNIC Policy mailling list
> <politicas at lacnic.net>
> Asunto: Re: [LACNIC/Politicas] Discusion de LAC-2007-06 Asignaciones IPv6
> ULA-Central
> 
> 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.

Creo que la respuesta que ha dado en los correos anteriores es clara.

Hay un documento, esta archivado y estara ahí por siempre, luego la
referencia es valida, aunque no sea un RFC, que no tiene por que serlo.

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

No estoy de acuerdo. Son dos casos exactamente iguales. En ambos casos es
una propuesta de politica basada de un draft. Es irrelevante que estuviera o
no en el ultimo tramo para ser RFC. Tu sabes bien que hasta que no es RFC
puede pasar cualquier cosa en el IESG. Y de hecho ese fue el caso de
ULA-central, estaba en el IESG y por un proceso "oculto y manipulador"
*distinto* del propio de IETF, un informe de los RIRs aborto su
continuacion, algo que el IETF jamas debiera de haber aceptado. Error del
IETF, pero afortunadamente la comunidad puede corregirlo, bien en el propio
IETF o a traves del PDP.

Los RIRs tendrian que haber acudido a la lista del IETF, no al IESG.

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

Bien, aunque que yo haya interpreado mal lo que Ray indico, y dijera que no
se aceptan draft como referencias, he estudiado detenidamente todo su PDP y
NO indica nada asi en ningun punto.

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

Gracias, creo que esto es importante. Al final parece que todo se deduce a
la discrepancia en aceptar la referencia porque no se encuentra el
documento, sin embargo, como he indicado en otro correo anterior esta ahí.

Yo no creo que sea interesante incluir el texto del draft (varias paginas)
en la politica dado que el documento esta ahí, pero si ese fuera el caso, la
nueva version tendra que seguir ese camino para evitar esta situacion.

> 
>> Saludos,
>> Jordi
> 
> Fred

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