[LACNIC/Politicas] Reflexiones acerca del PDP

[JORDI PALET MARTINEZ]

Idem, sigo debajo.

Saludos,
Jordi




> De: Nicolás Ruiz <nicolas at ula.ve>
> Organización: ULA
> Responder a: LACNIC Policy mailling list <politicas at lacnic.net>
> Fecha: Tue, 29 May 2007 18:24:16 -0400
> Para: LACNIC Policy mailling list <politicas at lacnic.net>
> Asunto: Re: [LACNIC/Politicas] Reflexiones acerca del PDP
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Mis comentarios, que ya he repetido, en otros correos. Y perdonen lo
> largo; como dice el dicho, no he tenido tiempo de hacerlo más corto:
> 
> JORDI PALET MARTINEZ wrote:
>> Hola a todos,
>> 
>> Este correo es un poco largo pero ruego que lo leais atentamente, pues es
>> muy importante.
>> 
>> Estoy trabajando en el desarrollo de una propuesta de politica para
>> modificar el PDP, pues creo que tiene ciertas inconsistencias algunas de las
>> cuales han quedado patentes en la ultima reunion, asi que me gustaria tener
>> comentarios al respecto para ultimar la propuesta (algo que, mea culpa,
>> debiera de haber hecho hace un año para haber intentado buscar consenso en
>> esta ultima reunion y asi no perder un año completo).
>> 
>> Voy a utilizar algunos *ejemplos* basados en propuestas discutidas en esta
>> ultima reunion. Que conste que en NINGUN CASO, estoy discutiendo la bondad
>> de las propuestas presentadas, es decir, estoy totalmente deacuerdo con la
>> decision del foro al respecto de los meritos de una propuesta, tanto si ha
>> sido aceptada como si no, pero no necesariamente estoy deacuerdo con que el
>> procedimiento se este siguiendo *limpia* y *correctamente* (en parte por
>> falta de claridad en el mismo, y es lo que intento remediar con esta
>> iniciativa).
>> 
>> 1) No queda claro si el consenso se busca SOLO en el foro o se analiza en
>> consenso conjunto entre la lista y el foro (como es el caso de otras
>> regiones). Es decir, una propuesta que parece tener consenso en el foro,
>> puede no tenerlo en la reunion, pero puede ser que el numero de "objeciones"
>> en la reunion sea muy inferior al numero de "soportes" en la lista. Por
>> supuesto que se puede dar tambien el caso contrario. Creo que la decision
>> debe venir determinada por el consenso de ambos, porque muchos participantes
>> de la lista no necesariamente pueden atender al foro. En otras regiones es
>> como se mide, no solo por la reunion presencial. En IETF incluso, la lista
>> pesa mas que la reunion presencial al buscar consenso.
> 
> De acuerdo en que tenemos que aclararlo. Prefiero que el consenso
> dependa de la cantidad total de opiniones a favor y en contra, en la
> cual la última opinion sea la definitiva, es decir, si primero digo en
> la lista que estoy a favor, luego que estoy en contra y en el foro digo
> que estoy a favor, cuenta como una opinion a favor (por ser la última
> expresión). Si el nivel de discusión/aprobación/rechazo en la lista es
> muy bajo ("muy bajo" queda a juicio del moderador), se trata de alcanzar
> consenso en el foro.

Si pero la ventaja de aceptar el consenso de la lista como suficiente, es
que cambios o politicas sin implicaciones y que se evidente que no hay
oposisicion, podrian avanzar sin esperar a la reunion. Asi es como se hace
en RIPE NCC.

> 
>> 2) Un año para aprobar una propuesta puede ser un tiempo demasiado largo.
>> Deberian de articularse otros medios alternativos como por ejemplo:
>> a) Aprobacion por medio electronico (reunion no presencial)
>> b) Aprobacion solo por la lista cuando no haya objecciones, especialmente en
>> el caso de propuestas cuya urgencia sea importante para la region (a
>> determinacion del moderador ?)
>> c) Procedimiento de urgencia para politicas que puedan ser indispensables ?
> 
> De acuerdo. Que tan factible es una reunion presencial adicional? Al
> menos (a) deberia ser posible.

Supongo que la reunion presencial es una cuestion de recursos para
organizarla, y recursos de los asistentes para participar. Creo que no seria
buena idea hasta que la region avance mas en el campo de las politicas y la
participacion en la lista sea tal que sea evidente que la gente tiene
interes en una reunion para politicas.

> 
>> 3) Quizas deberia de plantearse la necesidad de que en lugar de un solo
>> moderador, haya 2-3 (co-moderadores), como en APNIC, RIPE NCC y ARIN (en
>> AfricNIC tambien se esta modificando el PDP incluyendo este punto). No solo
>> es una cuestion de que el moderador puede ponerse enfermo o no poder atender
>> todos los temas rapidamente, sino facilitar su trabajo y la objetividad y
>> neutralidad (no digo que no sea el caso ahora, pero todo es mejorable), por
>> ejemplo eligiendo un conjunto de moderadores de diferentes sectores y no
>> solo de ISPs.
> 
> Prefiero la idea del moderador/co-chair suplente.

Me he perdido, entendi en tu correo electronico que preferias la otra opcion
:-)

> 
> Que otros sectores te parecen que deben estar representados?

Por ejemplo, Universidades u otras instituciones que no son "exactamente"
ISPs, pero son tan grandes que funcionan como ISPs para sus propias
entidades, ISPs pequeños y grandes (no solo grandes o pequeños), industrias
relacionadas, etc. En la variedad esta el gusto.

En APNIC y RIPE NCC son 3 co-chairs. En AfriNIC se va a presentar una
propuesta de cambio del PDP para que sean 2 o 3 (aun no esta decidido), y en
ARIN es algo equivalente (AC, Advisory Council) que creo que son 13
miembros.

> 
>> 4) Como medimos el consenso ? Esta claro que no es por mayoria, sino por
>> falta de un numero importante de objeciones a una determinada propuesta. En
>> algunos casos puede no haber ninguna objeccion ni comentario, por eso
>> indicaba antes que en esos casos, especialmente si la politica es necesaria
>> para asignar un recurso (es decir, hay un "cliente" de la politica), no
>> parece logico que tenga que esperar hasta un año completo para obtener ese
>> recurso. Es preciso buscar una definicion lo mas objetiva posible para
>> evitar diferenciaciones injustas entre diversas propuestas.
> 
> Para mi no está bien que un consenso deba definirse como falta de
> objeciones. Entiendo que es una solución tolerable en el caso en que hay
> poca participación y aquellos que tienen mayor incentivo para elevar su
> voz son quienes objetan, y en ese caso acepto esa definición de
> consenso, pero a regañadientes. Prefiero una manifestación explicita a
> favor de una propuesta (incluso si hay un número importante de objeciones).

Concurro contigo, y asi se pide en RIPE NCC.

> 
>> 5) Las propuestas, antes de llegar al plazo de tiempo de discusion en el
>> foro presencial, deben de pasar una revision por parte del staff para
>> indicar posibles fallos, problemas de implementacion, discrepancias con
>> otras politicas, etc. Esto deberia de realizarse a ser posible en un plazo
>> maximo de 48 horas habiles tras el envio de la propuesta por parte del
>> autor(es). Si el staff se demora, y se traspasa el plazo (30 dias) de
>> presentacion para poder ser incluidas en el foro, dicho plazo deberia de ser
>> ampliado para que el autor disponga de un minimo de 48 horas adicionales
>> para una nueva version del texto. Por ejemplo, este ha sido el caso de la
>> propuesta LAC-2006-08 en la que no se ha podido buscar consenso por una
>> discrepancia en el texto que solo ha sido informada por el staff en la
>> propia reunion.
> 
> Que hacemos en el caso que una propuesta es recibida a tiempo, pero las
> 96 horas hábiles (48 de revisión del staff + 48 para introducir una
> versión corregida) terminan a menos de 30 dias del foro? Yo digo que se
> acepta para ser discutida, incluyendo si hay múltiples iteraciones del
> staff + reescritura, siempre y cuando el moderador del foro lo considere
> aceptable.

Mi idea es que estos plazos no corran en contra de la propuesta, es decir,
que si en lugar de 30 dias de discusion antes de la reunion (o de la llamada
a consenso si se hace en la lista, como en RIPE), son solo 26 dias, no pasa
nada.

> 
>> 6) En la reunion se ha indicado que el directorio tenia atribuciones para
>> modificar "ligeramente" una politica que fuera aprobada por la comunidad.
>> Creo que si es el caso, esto es muy peligroso y rompe el PDP. Ademas, creo
>> que es incorrecto, no veo por ningun sitio del PDP actual NINGUN texto que
>> parezca siquiera indicar esto (si estoy equivocado por favor que
>> inmediatamente se indique el texto que lo permite). Por otro lado, ese texto
>> tiene que ser muy claro al respecto de los "limites" de dicha modificacion,
>> y creo que esto es casi imposible, al menos yo no alcanzo a ver como
>> hacerlo. Por otro lado, dado que el PDP esta basado en la comunidad, y el
>> directorio es el organo de direccion de la membresia, y comunidad y
>> membresia no son lo mismo, creo que esto no es posible, pues seria una clara
>> inconsistencia entre ambos grupos (en uno participan todos los interesados,
>> de todo el mundo, y en el otro, solo las entidades con servicios en la
>> region que pagan sus cuotas). El ejemplo en este caso seria la propuesta
>> LAC-2007-07, con lo cual esta votacion estaria viciada y habria de ser
>> declarada nula por el moderador de forma immediata.
>> 
>> 7) Es imprescindible que llege al foro una sola version de una propuesta o
>> pueden llegar 2 o mas y ser votadas para ver cual alcanza el consenso ? Esto
>> esta muy ligado a la decision de si el consenso se busca solo en el foro, o
>> en la lista y el foro solo lo refrenda, o en ambos. Ejemplo la propuesta
>> LAC-2007-01, la cual ha llegado viciada al foro, porque los autores de la
>> idea no contestaron (si no me equivoco) a una propuesta alternativa en
>> busqueda de consenso entre ambas versiones, y el staff de LACNIC indico a
>> los autores de la alternativa que se tratarian/presentarian ambas en la
>> reunion, cosa que sin embargo no fue el caso.
> 
> Es válido que se presenten múltiples propuestas que colisionen. Se
> presentan, discuten y se establece un mecanismo para elegir entre todas
> las competidoras.

Como indique, en ARIN hubo 2 de IPv6 PI, y creo que se hizo una ronda de
votacion para intentar ver puntos en comun y divergentes y buscar consenso o
eliminar una de ellas (o ambas).

> 
>> 8) En la reunion se ha indicado que es preciso que un documento del IETF
>> respalde las politicas. Esto no es correcto, en ningun punto del PDP indica
>> esto. Ademas, los unicos documentos del IETF que son standards son los STD,
>> no los RFCs, con lo cual todas las politicas existentes serian nulas, puesto
>> que todas han sido basadas en RFCs o Internet Drafts. Por ejemplo, la
>> politica de 4-byte ASN ha sido aceptada (el año anterior), cuando los
>> documentos eran Internet Drafts. En cambio se ha argumentado que la
>> propuesta LAC-2007-06. Igualmente, no hay ningun documento del IETF
> 
> Yo prefiero que solamente se hagan referencias a documentos
> "archivables". Creo que un internet draft no es archivable porque se
> espera que se modifiquen antes de alcanzar el status de RFC, STD o BCP o
> similar.

No sirve, hay muchas politicas que no dependen de IETF, y es dificil decidir
de antemano, en el proceso, si algo esta "dentro" o fuera del "IETF", porque
el proceso es bottom-up, y esta comunidad puede decidir dejar algo dentro o
fuera del IETF. No estamos atados al IETF.

Los draft expirados tambien se archivan, asi que eso no es excusa tampoco.

> 
> Por ejemplo, que pasa si discutimos el draft-ietf-v6ops-nap-06, se
> aprueba como política y es finalmente el draft-ietf-v6ops-nap-08 el que
> se convierte en RFC? Hemos definido una política basados en un documento
> obsoleto.

Por eso en mi documento se hacia referencia a la ultima version :-)

> 
> En la misma medida, las politicas de LACNIC deben ser actualizadas
> cuando los documentos a los que hacen referencia se vuelven obsoletos
> por la publicación de una nueva versión.

Perfecto, y cual es el problema ? Ninguno en realidad. Las politicas estan
sujetas SIEMPRE a ser actualizadas.

> 
>> 9) Manipulacion del proceso. En esta reunion se ha podido producir una
>> manipulacion del proceso, bajo mi punto de vista en dos casos, que de nuevo
>> insisto, en este email son solo ejemplos y no la discusion de los casos en
>> si mismos:
>> a) LAC-2007-07. Se ha votado bajo la premisa de que el directorio puede
>> cambiar un parametro. Si fuera el caso que no se puede demostrar que esto
>> esta documentado de forma precisa, determinante, fehaciente y con antelacion
>> a la reunion, dado que el voto para buscar consenso se produjo bajo esa
>> premisa, seria nulo e impugnable de pleno derecho.
>> b) LAC-2007-06. Se ha manifestado que es imprescindible que haya un RFC,
>> como se ha indicado antes. Ademas IANA ha dado un mensaje contradictorio al
>> dado en una reunion con el autor de la propuesta.
>> 
>> El proceso no solo tiene que ser transparente, sino tambien limpio. Deben de
>> rechazarse radicalmente las posibles manipulaciones y a sus actores. Por
>> ejemplo, si en la presentacion de una politica el autor o cualquier de los
>> participantes, hacen afirmaciones ERRONEAS *acerca de detalles del PDP* (no
>> de la propuesta), que pueden influenciar y de hecho influencian la busqueda
>> del consenso, el moderador *tiene* que detener dichas afirmaciones e
>> informar taxativamente que las mismas no son ciertas, no son relevantes y
>> *bajo ningun concepto* los presentes tienen que teneralas en cuenta a la
>> hora de tomar su decision.
>> 
>> En cualquier caso eso *siempre afecta* a la decision de algunos, porque no
>> todos los asistentes tienen conocimientos de todos los campos (del propio
>> PDP, del IETF, etc.), lo cual es dificilmente evitable, asi que quizas es
>> imprescindible que:
>> a) Se prohiban estos comentarios y solo puedan ser realizados y clarificados
>> a traves del moderador bien por correo privado o bien de forma presencial en
>> la reunion (antes de la discussion de la propuesta en cuestion).
>> b) Los que hagan dichos comentarios y por tanto manipulen, consciente o
>> inconscientemente el PDP, deben de ser excluidos del mismo por un periodo de
>> un año (y si insiten se va multiplicando por dos el plazo de exclusion),
>> para lo cual se les impide participar en la lista y en la reunion presencial
>> siguiente. Especialmente cuando es evidente su malintencion, y se genere una
>> diferencia entre politicas que puedan haber estado en la misma situacion. El
>> desconocimiento no exime del cumplimiento de las normas y los paritipantes
>> deben conocerlas, leer el PDP, y en el foro debe de ser presentado y se
>> deben de explicar las "reglas del juego". Esto es algo que se hace muy bien
>> en ARIN, por ejemplo.
> 
> Apoyo el evitar que se manipule el proceso, pero creo que esto es una
> solución buscando un problema. Prefiero que el moderador/chairs del foro
> manejen estas situaciones en lugar de reglamentarlo.

El problema es que ya es tarde si se ha producido esa brecha. Mi propuesta
es simple y funciona, no le veo trabas: Las discusiones relativas a si una
propuesta esta dentro del PDP o no, deben de consultarse con el moderador
previa la reunion/busqueda de consenso para evitar sentar cualquier tipo de
duda.

Nos deja una mayor claridad y transparencia y evita dudas que generen
suspicacias.

> 
>> Hay que tener en cuenta que las propuestas pasaran a partr de ahora, una
>> revision del staff y del moderador. Por tanto, por definicion es dificil que
>> una propuesta pase a ser discutida si no cumple el PDP. Por tanto es aun mas
>> grave que se de el caso a o b anteriores. Es decir, nadie puede dudar de
>> aspectos del PDP de una determinada propuesta, al menos no publicamente,
>> solo con el moderador, de lo contrario, es de suma gravedad la manifiesta
>> manipulacion.
>> 
>> 10) Hay otras discrepancias en el proceso del que se nos informa y el
>> publicado en la web (http://lacnic.net/sp/politicas/desarrollo.html), por
>> ejemplo, no son 30 dias antes del foro publico, sino 2 semanas (en el texto,
>> el grafico habla de 30 dias). No se cual es lo correcto, pero esta situacion
>> debe de ser clarificada bajo mi parecer, por el bien de todos y
>> especialmente por la transparencia y limpieza del PDP, INMEDIATAMENTE.
> 
> Yo seria menos estricto, proponemos un nuevo PDP, y luego vemos como lo
> aprobamos.
> 
> - --
> 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
> 
> iD8DBQFGXKgPmjsZS9ZBxv8RAt3NAJ96mT3l1G/+pVUawtIPReH9yNrBbgCfe+af
> W8ZrkV47IJWE6lA/DHYhvd8=
> =orY/
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> 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.