[LACNIC/Politicas] Nueva propuesta LAC-2020-7 / Nova propostaLAC-2020-7 / New proposal LAC-2020-7

Fri Oct 2 14:44:20 -03 2020

Jordi, gracias por tus comentarios.

No vamos a responder punto a punto para no hacerlo largo, pero tienes unos
puntos valiosos que valdrá la pena incorporar en una segunda versión. Para
resumirlos:

   -

   Agregar la posibilidad de presentar de manera corta algunas
   ideas/propuestas “caídas” en el foro.
   -

   Balancear las semanas dedicadas a todo el proceso para asegurarse de no
   hacerlo muy largo. Si bien hay que recordar que ya se está ahorrando tiempo
   al dedicar la discusión sólo a propuestas consideradas relevantes.

Respecto a tu comentario de tocar varios puntos en la misma propuesta en
principio estamos de acuerdo. Lo importante es el equilibrio, es decir, no
incluir temas desconexos de diferentes partes del manual en la misma
política, pues eso complica mucho la discusión de las  políticas y su
posterior implementación, pero sí es importante que una política pueda
modificar todos los puntos relacionados y así asegurarse que el manual o el
proceso no quedan con inconsistencias.

Gracias de nuevo por tus aportes.

Alejandro y Esteban

El vie., 25 sept. 2020 a las 12:16, JORDI PALET MARTINEZ via Politicas (<
politicas at lacnic.net>) escribió:

> Hola Alejandro,
>
> Ayer no conteste a parte de este email (he cortado el texto al que me
> refiero para centrarnos), pues consideraba que ya lo había hecho en otro
> correo al indicar que soy partidario (aunque con sentimientos encontrados)
> de la participación del directorio y del staff, y sabes bien que tus
> aportaciones siempre han sido muy bienvenidas durante muchos años.
>
> Me centro. Esta claro que cualquier participación aporta valor, incluso la
> mera discusión de una idea aunque no sea buena, y esta propuesta puede
> mermar esto. Eso incluye el valor que aporta la participación del
> directorio y del staff, y por eso yo me he decantado en varias ocasiones
> por que participen, pero dentro de un orden (y resolviendo posibles
> conflictos de ratifiación y apelacion - no me voy a repetir respecto del
> otro día).
>
> Sin embargo, se produce una desigualdad cuando hay participación del
> directorio, que es muy explicita *en este caso concreto*, en el que os
> basais en un estudio que se ha hecho en la comunidad, y que vosotros
> conoceis integramente y la comunidad no. Y ello genera discrepancias, que
> sin conocer el estudio, son irresolubles. Hay una parte que tiene
> información y no la puede compartir con la otra parte. Y obviamente
> entiendo las cuestiones de confidencialidad, etc. pero ... ahí lo dejo.
>
> Independientemente de eso, acabo de volver a leer la propuesta, y sigo
> estando en contra, pero puedo ver cierta luz, si se resuelven algunos
> aspecto.
>
> (Alejandro, podéis enviar ese gráfico a la lista? - creo que eso esta
> mermando la comprensión)
>
> 1) El motivo fundamental por el que estoy en contra es que reducimos el
> consenso a la lista, y una propuesta podría no tener consenso en la lista y
> sin embargo si tenerlo en lista+foro. Creo que eso es muy tangible, por ese
> "circulo pequeño" (hemos dicho hasta ahora circulo cerrado pero creo que es
> incorrecto hablar de cerrado) de participantes. Ademas, debemos permitir
> que un problema no "aceptado hoy", no pueda regresar mañana. Ya hemos visto
> casos en los que eso ha sido necesario (ejemplo reciente Inter-RIR). Como
> podemos resolver esto?
>         a) Se me ocurre que podría habe un proceso de, si una propuesta se
> ha "caído", recuperala en el foro (solo la fase de discusión del
> problema/oportunidad), para que se determine allí el consenso. Eso
> implicaría que una propuesta cuyo problema no es adoptado inicialmente,
> tenga una demora de 5-6 meses (el tiempo entre foros) y por tanto otra
> oportunidad de adopción con el consenso foro. Si alcanza consenso de
> "adopción" en el foro, se le puede dar tiempo tambien al autor para
> presentar el problema e incluso medir el consenso (creo que hay casos en
> los que puede resolverse "de a una"), sino seguirá la discusión en la lista
> y siguiente foro.
>         b) La otra alternativa para resolverlo es que una propuesta que se
> ha "caido" pueda volver a ser planteada al cabo de 6 o 12 meses, por
> ejemplo. Al final en plazos ambas opciones son muy similares.
>
> 2) No me queda claro si en el plazo de 3+1 semanas (no lo entiendo bien
> sin el gráfico), se puede *revisar*, en la propia lista, el texto del
> problema (no el de la propuesta). Creo que sería deseable, porque un
> "problem statement" no lo leemos todos igual y a veces cambios en la
> redacción a ajustes del mismo cambian el "balance" entre que pueda alcanzar
> consenso o no. Podríamos decir que la versión 0.x de una propuesta es
> cuando se está discutiendo el problema (la "x" permite varias discusiones
> futuras si no alcanzara consenso como he indicado en el punto 1 arriba, sin
> necesidad de asignar un nuevo número de propuesta). Si el problema alcanza
> consenso, la primera version de discusión "completa" seria la v1.y y asi
> sucesivamente. La "y" es para revisiones menores, tipo editorial, etc. (que
> ahora es un lio, porque incluso en el last call, revisiones editoriales no
> quedan reflejadas).
>
> 3) Otro motivo es que se agregan 3+1 semanas y creo que es un plazo
> excesivamente largo. Bajo mi punto de vista, y me voy a aventurar, sin ver
> el gráfico, el proceso de publicación que ahora es de hasta 2 semanas,
> sinceremanete creo que no es necesario y podemos restringirlo a un máximo
> de 2-3 días hábiles y esas 3+1 semanas acortarlas o "comen" parte de esas 2
> semanas que tenníamos antes, y asi no incrementamos tanto ese tiempo. Otra
> alternativa es jugar con el tiempo de discusión, reducirlo a 6 semanas,
> dado que parte de esa discusión ya se ha producido. Ojo que el plazo de
> publicación de 2 semanas no se suele cumplir, aunque ultimamente cada vez
> tarda mas, y está en una media de unos 10 días (al menos para mis últimas
> propuestas), pero no le veo el sentido. Si una propuesta se envía en
> castellano, dado que es el idioma oficial, no hay que esperar a la
> traducción y por tanto la revisión del staff no debería suponer mas de
> pocas horas (simplemente no se puede automatizar al 100% para evitar que
> alguien utilice el formulario para cualquier insensatez, enviar insultos o
> publicidad a la lista, etc.).
>
> 4) El mayor perjucio que veo es que si un problema se produce 4 semanas
> antes del foro, ya no llegamos, y hay situaciones en las que se puede ver
> el problema perfectamente sin necesidad de agotar las 3+1 semanas, e
> incluso llegar al foro con una discusión en la lista y que alcance consenso
> a la primera. Tener que esperar 6 meses es una pérdida de tiempo, y se
> contradice con el objetivo de facilitar el proceso y fomentar la
> participación. Quizas hay que poner una excepción, no tengo pensado como,
> lo mas facil puede ser que lo moderadores tengan la atribución de decidir
> que es muy claro que merece pasar a discusión completa en solo 1 semana en
> lugar de 3+1. El proceso expeditivo, cada vez que lo hemos intentado ... no
> se ha logrado que los moderadores lo acepten, y creo que debe reservarse
> para situaciones mas "graves" y parece ser el punto de vista de los
> moderadores, vista la experiencia.
>
> 5) En el Resumen, el punto 3 es redudante. Si hay un problema Y la
> propuesta tiene potencial para resolverlo, esta claro que no solo merece el
> tiempo, sino que es nuestro *deber* invertirlo. Y ojo que hay otro pero. En
> esta fase es muy subjetivo si tiene potencial para resolverlo. Eso sabemos
> que solo lo veremos en la siguiente fase de discusión, quizas en la primera
> version, quizas necesite mas, porque el potencial para resolverlo es, al
> menos en parte, precisamente el mecanismo por el que alcanzamos consenso.
>
> 6) En la justificación, se habla de multiples temas en una misma
> propuesta. A veces esto es necesario, otras veces el staff ha recomendado
> partir una propuesta en otras mas pequeñas, etc. En cambio cuando envias
> varias propuestas para separar diversos problemas aunque estén en la misma
> parte del manual (ejemplo mejoras diversas del PDP), te dicen que envías
> muchas propuestas. A que nos atenemos?. Creo que es algo debatible y no
> creo que deba ser estricto. Si una propuesta ofrece mejoras, por ejemplo en
> la parte de IPv4 del manual, no tiene sentido separarlas, dado que son
> clarificaciones, resolución de falsas intepretaciones, no "controversias".
> Por lo tanto propuesto en la 3.1 debería hablar de "el(los) problema(s) que
> se pretende resolver o prevenir o la oportunidad de mejora(s relacionadas)
> que se quiere aprovechar". Si fomentamos romper "siempre" los problemas o
> mejoras en propuestas separadas, vamos en contra de los objetivos buscados.
>
> 7) Si esta propuesta no logra su objetivo, de incrementar la participación
> en un % importante, crea mas problema del que resuelve. Y por lo tanto creo
> que debe incorporar un mecanismo de "reversibilidad" de la misma. Quizas
> tras un año (o 2 ciclos de PDP, que puede ser un año y pico dependiendo de
> en que momento del año alcance consenso, sea ratificada e implementada)?
>
> 8) Hay algunos aspectos del proceso de envío de las propuestas que desde
> hace muchos tiempo no coinciden con el PDP, y sinceramente, no me di cuenta
> hasta ayer, al contestar a Hugo. En ese email creo que está muy claro, para
> no repetirme. Si esta propuesta, o cualquiera que toque ese texto sigue
> adelante, creo que coincidiremos que es una oportunidad para corregirlo y
> eso es un ejemplo de vuestro texto "aprovecha la oportunidad" si lo he
> entendido bien.
>
> Saludos,
> Jordi
> @jordipalet
>
>
>
> El 24/9/20 20:34, "Politicas en nombre de Alejandro Guzman" <
> politicas-bounces at lacnic.net en nombre de alejoguzg at gmail.com> escribió:
>
>     En resumen, y para despejar cualquier duda, solo nosotros dos estamos
>     proponiendo esta política y no el Directorio. Nosotros consideramos,
> por
>     las razones expuestas anteriormente, que la propuesta puede aportar
> valor,
>     mejorar el PDP  y ayudar a la comunidad a que la discusión de
> políticas sea
>     mucho más significativa, organizada y participativa.
>
>     Saludos
>
>     Alejandro y Esteban
>
>
>
>
>
> **********************************************
> IPv4 is over
> Are you ready for the new Internet ?
> http://www.theipv6company.com
> The IPv6 Company
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the exclusive use of
> the individual(s) named above and further non-explicilty authorized
> disclosure, copying, distribution or use of the contents of this
> information, even if partially, including attached files, is strictly
> prohibited and will be considered a criminal offense. If you are not the
> intended recipient be aware that any disclosure, copying, distribution or
> use of the contents of this information, even if partially, including
> attached files, is strictly prohibited, will be considered a criminal
> offense, so you must reply to the original sender to inform about this
> communication and delete it.
>
>
>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>