[LACNIC/Politicas] Reflexiones acerca del PDP

[Nicolás Ruiz]

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

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

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

Que otros sectores te parecen que deben estar representados?

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

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

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

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

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.

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.

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

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