[LACNIC/Politicas] evaluación del consenso

[Nicolas Antoniello]

Hola Jordi,

Lo que sigue es opinión estrictamente personal.

La verdad me acabas de sorprender... no se por donde comenzar a decirte que
en lo personal creo que estas equivocado de acá a Alfa Centauri, ida y
vuelta 56 veces...
Esto es un PDP, no un ámbito esencialmente técnico (gran diferencia con la
IETF que NO hace políticas sino estándares).

Nunca, en todos los años que llevo en la comunidad escuché tan solo una
referencia a la RFC7282 asociada al PDP y creo que está bien que así sea.
Creo además que la IETF no inventó el consenso ni creo tampoco que su
definición se adecue al PDP.

Para mi la definición que se maneja en el PDP actualmente para "consenso"
es muy adecuada y es una evolución de la que fuera antes... supongo que una
evolución razonable dada la madurez que ahora creo que tenemos como
comunidad y como PDP-

Tampoco creo que sea potestad de los Moderadores el definir lo que
solicitas al final del mail... pero bueno, sobre eso prefiero no opinar,
que lo haga el resto de la comunidad.

Abrazo,
Nico




El dom, 20 mar 2022 a la(s) 09:40, JORDI PALET MARTINEZ via Politicas (
politicas at lacnic.net) escribió:

> Hola Ariel, todos,
>
> Esto era un tema que tenía pendiente desde hace tiempo y he cambiado el
> asunto para que nos centremos porque no se refiere solo a una propuesta en
> concreto.
>
> Para determinar el consenso, nos regimos por el RFC7282 ("rough
> consensus"), porque el consenso se basa en medir objeciones
> razonadas/justificadas.
>
> Cuando en una determinada versión de una propuesta no hay discusión, pero
> al mismo tiempo se han resuelto, las objeciones de versiones anteriores, la
> única opción posible para cumplir con el RFC7282, y por tanto con nuestra
> definición de consenso es *declarar consenso*.
>
> Hay que recordar, que como bien dice el PDP, varios aspectos importantes:
> 1) “... se hayan resuelto, tras un período de discusión, las objeciones
> técnicas irrefutables.”
> 2) "no puede considerarse “no consenso” la baja participación ..."
> 3) "... el RFC7282, explica que “se logra la aproximación al consenso
> cuando se han abordan todas las cuestiones aun cuando no hayan sido
> resueltas a la satisfacción de todos ...“
> 4) "Como definición “breve” para el resto del documento, se entiende que
> una propuesta ha alcanzado consenso cuando es apoyada por opiniones
> significativas, luego de una discusión amplia y, que no subsistan
> objeciones técnicas irrefutables."
>
> Estos aspectos en absoluto son contradictorios, porque el PDP incluya una
> definición "breve", que se hace por simplificar, no por contradecir lo que
> indica el RFC7282.
>
> Si los moderadores interpretan que cuando en una determinada versión no
> hay comentarios, por una lectura exclusiva y literal del punto 4 antes
> mencionado, se estaría incumpliendo el resto de los puntos.
>
> Si se considera que hay que aclararlo, debemos modificar el texto para
> resaltar que ese punto 4 es sólo un "resumen" y no prima sobre el RFC7282,
> o incluso si hace falta incluir el texto completo de dicho RFC, lo cual me
> parece que no tendría mucho sentido.
>
> Voy a poner un ejemplo. Si hay dos propuestas, como así a ocurrido, y
> ambas han tenido objeciones, pero en sucesivas versiones han quedado
> resueltas, las dos alcanzan consensos y no se puede decir lo contrario.
> Quizás plantearían un problema de implementación o siguiendo estrictamente
> el PDP y sus plazos, al final quedaría la "ultima" en alcanzar consenso, y
> esto no puede ser de otro modo ya que muchas veces, en años tocamos las
> mismas partes del texto y no presenta problema, sino que es un proceso
> evolutivo natural. El que esto ocurra en meses de forma casi paralela en
> lugar de años, no implica que no puedan alcanzar consenso ambas.
>
> Bajo el RFC7282, y tal y como ha ocurrido otras veces en IETF (ejemplo
> aceptar MAP-T y MAP-E, cuando se buscaba "solo uno"), lo correcto era
> aceptar el consenso de una, luego de la otra, en el orden que vencieran, y
> por lo tanto quedaba el texto de la última.
>
> Para resumir, claramente se tiene que comprender que la definición de
> consenso en el PDP es un mero resumen del RFC7282 y que, si una propuesta
> ha tenido objeciones en la versión "n", y estas han quedado resueltas en la
> "n+1", el que ya no haya comentarios no puede ser una motivación para no
> declarar que tiene consenso.
>
> Si en IETF, siguiéremos al pie de la letra *solo* el texto de consenso del
> PDP, ignorando el RFC y su espíritu, nunca tendríamos nuevos RFCs, porque
> lo habitual es:
> 1) Se discute un documento (v0)
> 2) Se van aceptando cambios/mejoras en nuevas versiones, según se van
> resolviendo las objeciones (vn).
> 3) Cuando no hay objeciones, "nadie habla", porque ya se ha hablado antes,
> y nadie pierde el tiempo. Nadie (o casi nadie) dice "si muy bien esto es lo
> que quería".
> 4) Pasa al last call. El last call *precisamente* esta por si alguien no
> hablo o hay una objeción aún no resuelta.
>
> Aquí nos pasa lo mismo, pero como no permitimos pasar al last call ... las
> propuestas vuelven y vuelven *aún cuando las objeciones se han resuelto*.
> Obviamente me refiero a propuestas que realmente se han resuelto las
> objeciones (si no hay objeciones todavía estamos en el punto 2), como es el
> caso de las dos que devinieron en la formación de este grupo de trabajo.
>
> Espero que por favor los moderadores aclaren si en base a esto, el PDP
> presenta para ellos un problema al respecto, y si ha sido un fallo de
> interpretación que ahora queda resuelto o de lo contrario debemos modificar
> el PDP para aclararlo.
>
>
>
>
> Saludos,
> Jordi
> @jordipalet
>
>
>
> El 8/4/21, 16:57, "Ariel Weher" <mailto:ariel at weher.net> escribió:
>
> Buenos días
>
> Quiero aclarar algo en base a los constantes comentarios de Jordi en base
> a que "arbitrariamente se determinó que no había alcanzado consenso sin
> exponer con claridad objeciones válidas".
>
>
> https://www.lacnic.net/innovaportal/file/542/1/proceso-de-desarrollo-de-politicas-de-lacnic-v5.pdf
>
>
> Punto 2: Definición de "Consenso"
>
> "[...]
> Como definición “breve” para el resto del documento, se entiende que una
> propuesta ha alcanzado consenso cuando es apoyada por opiniones
> significativas, luego de una discusión amplia y, que no subsistan
> objeciones técnicas irrefutables.
> [...]"
>
> En el caso de que los moderadores consideremos que una propuesta no tuvo
> una *discusión amplia* tenemos la potestad de *NO* dar consenso. Para eso
> somos moderadores. Para eso nos eligieron.
>
> Si no estás de acuerdo con el texto que tú mismo escribiste, entonces
> deberás redactar un PDP nuevo en donde todos debamos ser tus marionetas.
>
> Por favor cerremos este tema.
>
> Saludos
>
>
>
>
> On Tue, Apr 6, 2021 at 3:48 PM JORDI PALET MARTINEZ via Politicas <mailto:
> politicas at lacnic.net> wrote:
> Hola a todos,
>
> Una vez mas, de acuerdo con esta propuesta.
>
> Creo que es una iniciativa muy buena e importante, y que espero que pronto
> llegue al resto de los RIRs.
>
> Cada vez está mas cerca el momento en que sea imprescindible proteger a
> los ciudadanos, y por tanto a la comunidad y sus recursos, y desde las
> políticas lo podemos hacer. No sería bueno, lo que sin duda llegará si no
> actuamos desde las políticas, que sea por intervención de gobiernos.
>
> Esta propuesta va en el camino adecuado. Ya lo estaba la versión anterior,
> y creo que arbitrariamente se determinó que no había alcanzado consenso sin
> exponer con claridad objeciones válidas.
>
> Mas pronto que tarde, tenemos que actuar y evitar que se usen los recursos
> IPv4, y concretamente las transferencias, para evitar el despliegue de IPv6
> y prolongar de forma innecesaria y dañina la vida de IPv4. Acaso
> preferimos, como digo, que sean los gobiernos los que lo impongan, sin
> conocimiento técnicos como a menudo hacen, sin plazos adecuados, etc.?
>
> Saludos,
> Jordi
> @jordipalet
>
>
>
> El 31/3/21 16:48, "Politicas en nombre de Fernando Frediani" <mailto:
> politicas-bounces at lacnic.net en nombre de mailto:fhfrediani at gmail.com>
> escribió:
>
>     Hola a todos
>
>     Tras la discusión de esta nueva versión de esta propuesta y con
>     el fin
>     de llegar a un consenso, a continuación aclaro algunos puntos sobre la
>     nueva versión y también el último mensaje de los Moderadores sobre las
>     razones por las que esta propuesta no llegó a un consenso.
>
>     - Repito que esta propuesta NO obliga automáticamente a ninguna
>     organización a desplegar IPv6 si no lo desean, solo y solo si
> necesitan
>     transferir bloques de IPv4
>
>     - Sin embargo, si existe interés en transferir bloques IPv4 en el
>     sistema de registro de LACNIC, este ya no es un tema que sea solo
>     interno de la organización, sino que afecta a todas las demás
>     organizaciones que forman parte del ecosistema de LACNIC donde se
> deben
>     desarrollar políticas con miras al interés y beneficio de la mayoría,
> no
>     solo de unos pocos.
>
>     - La mayoría de los interesados ​​no pueden seguir indiferentes a algo
>     que afecta y agrava aún más el problema de escasez de direcciones
> IPv4,
>     por lo que la *intención y espíritu* de esta propuesta sigue siendo
>     tener un requisito obligatorio para demostrar que IPv6 esta operativo
>     para realizar transferencias IPv4. Este es un requisito muy razonable
>     para 2021 y, si no se controla, continuará agravando el problema para
> la
>     mayoría de las organizaciones que se conectan o desean ser parte del
>
>     ecosistema de Internet.
>
>     - Respecto al análisis de impacto comentar que este requisito podría
> ser
>     un obstáculo para algunas organizaciones, la afirmación es correcta y
> no
>     hay nada de malo en querer agregar esta restricción dado el contexto
>
>     actual. Algunos "obstáculos" son totalmente razonables para que haya
>
>     equilibrio y equidad entre todas las organizaciones. ¿No es razonable
>     pedirle a cualquier organización que demuestre la necesidad de
> utilizar
>     bloques IPv4? ¿Por qué no le pediría también que demuestre su
> compromiso
>     con todos los demás con IPv6 operativo cuando es necesario transferir
>     más bloques de IPv4?
>
>     - El argumento de que las organizaciones pueden realizar
> transferencias
>     fuera del sistema de registro de LACNIC se utiliza con bastante
>     frecuencia como motivo para oponerse a una propuesta, pero se mencionó
>
>     varias veces durante la discusión que no se puede seguir siendo un
>     motivo tan general para oponerse a ella porque el registro ha sus
>     políticas vigentes, contratos previamente aceptados y reconocidos en
>     el
>     ordenamiento jurídico y sanciones para quienes incumplan. Ninguna
>     propuesta de política puede dejar de seguir adelante en función
>     de la
>     posibilidad de que se incumpla. Existen mecanismos de corrección para
>     esto. Lo más importante a tener en cuenta es su necesidad.
>
>     - Ninguna parte del PDP obliga a los autores a desarrollar políticas
>     con
>     la intención de educar al usuario (organización), por lo que no
>     creo que
>     este pueda ser un argumento para ser utilizado como objeción a una
>     propuesta. Propuesta cuando sea necesario, no depende de las acciones
>     contenidas o no en el sentido de educación del usuario. Si hay una
>     necesidad y hay un consenso, la parte de educación se deja a otros
>     actores involucrados.
>     Creo que LACNIC y sus RIR ya están realizando un trabajo educativo
> sobre
>     la necesidad de implementar IPv6, lo cual es muy elogiado.
>     Entonces, entiendo que esta justificación parece más un deseo personal
>     de los moderadores.
>
>     - No es cierto que "/según LACNIC sería contraproducente para el
>     registro de transferencia IPv4/". En ninguna parte del análisis de
>     impacto se dice nada al respecto. Simplemente dice que puede
> significar
>     un obstáculo para algunas organizaciones, como se explicó
> anteriormente,
>     que *no hay problema en crear restricciones razonables* a las
>     justificaciones para el uso de recursos.
>
>     Respecto a los cambios en esta versión de la propuesta:
>
>     - El staff menciona que entendió que existe una inconsistencia entre
>     el
>     resumen y la redacción de la propuesta. Aclaro que puede deberse a
> algún
>     error en la traducción porque nunca hubo la intención de limitar las
>     transferencias a /22.
>     Solo existe el buen sentido de eliminar este requisito solo para una
>     nueva organización que *aún no tiene bloques IPv4*  y quiere
> transferir
>     un bloque inicial hasta el límite de un /22para iniciar sus
> operaciones.
>     En el resumen de la propuesta se deja claro que la excepción de una
>     transferencia hasta a /22 es solo para el caso de *nuevos entrantes*
>     exactamente en línea con el agotamiento de la fase 3 de LACNIC.
> Además,
>     la mención del pool reservado en las condiciones 11.1 está
> directamente
>     relacionada solo con los nuevos participantes.
>     De todos modos, ajusté el texto para que quede aún más claro que solo
>     aplican aquellos que no tienen asignaciones de IPv4.
>
>     -En cuanto al término "significativas" mencionado, aclaro que como la
>     propuesta define que le corresponde al staff de LACNIC definir los
>     requisitos mínimos, no es la intención de este autor complicar
> demasiado
>     el texto de la propuesta, definiendo de forma detallada lo que es
>     significativo o no, sino al staff según el contexto que cambia con el
>     tiempo. Aclaro aquí que desde mi punto de vista en este contexto
>     "significativas" se relaciona con las partes principales de la red que
>     serán responsables de entregar conectividad IPv6 al usuario
>     final/downstream y no solo en equipos de red centrales que no tienen
> una
>     relación directa con la entrega de una conexión IPv6 a un usuario
>     final/downstream, de modo que el tráfico es de fin a fin hasta el
>     contenido disponible en IPv6.
>     Se agregó una aclaración en la parte de información adicional
>     relacionada con este asunto.
>
>     - Finalmente, se aclara que las modificaciones para esta versión no
>     alteran la reciprocidad mencionada en el punto 5 del análisis de
> impacto
>     anterior, refiriéndose a la reciprocidad ya confirmada con ARIN.
>
>     Saludos cordiales.
>     Fernando Frediani
>
>     On 31/03/2021 11:37, mailto:info-politicas at lacnic.net wrote:
>     > [Português abaixo]
>     > [English below]
>     >
>     > Estimados suscriptores de la lista de políticas de LACNIC,
>     >
>     > La propuesta LAC-2020-1 ha pasado de la versión 3 a la versión 4
>     >
>     > Título: Agregar IPv6 operativo como requisito para las
> transferencias de IPv4
>     >
>     > Resumen: On 15th February 2017 LACNIC started IPv4 Exhaustion Phase
> 3 meaning only new entrants can receive up to a single /22 of IPv4 space.
> Since then the amount of IPv4 Transfers between organizations has increased
>     reasonably as shown by the official LACNIC reports. With the
> implementation of LAC-2019-1 and possibility of Inter-RIR transfers these
> numbers have the potential to grow substantially.
>     >
>     > The objective of this proposal is to add as a requirement for
> organizations in process of receiving transferred IPv4 space under 2.3.2.18
> to show they have an IPv6 allocation/assignment by LACNIC or a provider and
> that is operational on their networks. Such organization must be able to
> prove this IPv6 space is being used by providing LACNIC the documented
> network deployment details to prove IPv6 is operational in significant
> parts of the network.
>     >
>     > On 28th November 2019 LACNIC Board issued a statement (
> https://www.lacnic.net/4283/2/lacnic/lacnic-board-calls-on-the-community-to-promote-ipv6-deployment)
> reinforcing the issue about IPv4 exhaustion, mentioning IPv4 address space
> will be exhausted by mid-2020 and calling the community to promote IPv6
> deployment.
>     > In its statement LACNIC Board “invite the community to work on
> promoting the development of policies that will accelerate the effective
> deployment of IPv6 above other policies that may be discussed at a later
> date.”
>     >
>     > In the case the receiver provides a written statement from its
> upstream
>     that IPv6 connectivity is unavailable, the IPv6 requirement may be
> waived. In the case LACNIC is not able to meet a new entrant request for
> IPv4
>     space, or the organization does not hold any IPv4 space the IPv6
> requirement may be waived for a transfer up to a /22.
>     >
>     > Para ver el detalle ingrese en:
>     >
> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1/language/sp
>     >
>     > Los cambios respecto a la versión anterior se pueden visualizar aquí:
>     >
> https://politicas.lacnic.net/politicas/diff2?id=LAC-2020-1&v=4&v2=3&language=SP
>     >
>     > Los comentarios y los puntos de vista aportados por la comunidad son
> vitales para el correcto desarrollo del proceso de la propuestas
>     > - ¿Apoya usted o se opone a esta nueva versión de la propuesta?
>     > - ¿Ve alguna desventaja en esta nueva versión de la propuesta?
>     > - ¿Qué cambios podrían hacerse a esta nueva versión
>     de la propuesta para que sea más eficaz?
>     >
>     >
>     > Por más información contacte a mailto:info-politicas at lacnic.net
>     > Saludos cordiales,
>     >
> ______________________________________________________________________________________________________
>     > Prezados assinantes da lista de políticas de LACNIC,
>     >
>     > A proposta LAC-2020-1 tem passado da versão 3 para a versão 4
>     >
>     > Título: Adicionar IPv6 operacional como requisito para as
> transferências do IPv4
>     >
>     > Resumo: On 15th February 2017 LACNIC started IPv4 Exhaustion Phase 3
> meaning only new entrants can receive up to a single /22 of IPv4 space.
> Since then the amount of IPv4 Transfers between organizations has increased
> reasonably as shown by the official LACNIC reports. With the implementation
> of LAC-2019-1 and possibility of Inter-RIR transfers these numbers have the
> potential to grow substantially.
>     >
>     > The objective of this proposal is to add as a requirement for
> organizations in process of receiving transferred IPv4 space under 2.3.2.18
> to show they have an IPv6 allocation/assignment by LACNIC or a provider and
> that is operational on their networks. Such organization must be able to
> prove this IPv6 space is being used by providing LACNIC the documented
> network deployment details to prove IPv6 is operational in significant
> parts of the network.
>     >
>     > On 28th November 2019 LACNIC Board issued a statement (
> https://www.lacnic.net/4283/2/lacnic/lacnic-board-calls-on-the-community-to-promote-ipv6-deployment)
> reinforcing the issue about IPv4 exhaustion, mentioning IPv4 address space
> will be exhausted by mid-2020 and calling the community to promote IPv6
> deployment.
>     > In its statement LACNIC Board “invite the community to work on
> promoting the development of policies that will accelerate the effective
> deployment of IPv6 above other policies that may be discussed at a later
> date.”
>     >
>     > In the case the receiver provides a written statement from its
> upstream
>     that IPv6 connectivity is unavailable, the IPv6 requirement may be
> waived. In the case LACNIC is not able to meet a new entrant request for
> IPv4
>     space, or the organization does not hold any IPv4 space the IPv6
> requirement may be waived for a transfer up to a /22.
>     >
>     > Para ver o detalhe acesse:
>     >
> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1/language/pt
>     >
>     > As alterações da versão anterior podem ser vistas aqui:
>     >
> https://politicas.lacnic.net/politicas/diff2?id=LAC-2020-1&v=4&v2=3&language=PT
>     >
>     >   Os comentários e os pontos de vista aportados pela comunidade são
>     > vitais para o bom desenvolvimento do processo das propostas
>     > - Você está a favor ou em contra desta nova versão
>     >   da proposta?- Vê alguma desvantagem nesta nova versão
>     >   da proposta?
>     >
>     > - Que mudanças poderiam ser feitas à esta nova versão
>     >   da proposta para que seja mais eficaz?
>     >
>     > Por mais informações entre em contato conosco através do
>     e-mail:
>     > mailto:info-politicas at lacnic.net.
>     >
>     > Atenciosamente,
>     >
> ______________________________________________________________________________________________________
>     >
>     > Dear LACNIC Policy List subscribers,
>     >
>     > Proposal LAC-2020-1 has been updated from version 3 to version 4
>     >
>     > Title: Add IPv6 operational as a requirement for IPv4 transfers
>     >
>     > Summary: On 15th February 2017 LACNIC started IPv4 Exhaustion Phase
> 3 meaning only new entrants can receive up to a single /22 of IPv4 space.
> Since then the amount of IPv4 Transfers between organizations has increased
>     reasonably as shown by the official LACNIC reports. With the
> implementation of LAC-2019-1 and possibility of Inter-RIR transfers these
> numbers have the potential to grow substantially.
>     >
>     > The objective of this proposal is to add as a requirement for
> organizations in process of receiving transferred IPv4 space under 2.3.2.18
> to show they have an IPv6 allocation/assignment by LACNIC or a provider and
> that is operational on their networks. Such organization must be able to
> prove this IPv6 space is being used by providing LACNIC the documented
> network deployment details to prove IPv6 is operational in significant
> parts of the network.
>     >
>     > On 28th November 2019 LACNIC Board issued a statement (
> https://www.lacnic.net/4283/2/lacnic/lacnic-board-calls-on-the-community-to-promote-ipv6-deployment)
> reinforcing the issue about IPv4 exhaustion, mentioning IPv4 address space
> will be exhausted by mid-2020 and calling the community to promote IPv6
> deployment.
>     > In its statement LACNIC Board “invite the community to work on
> promoting the development of policies that will accelerate the effective
> deployment of IPv6 above other policies that may be discussed at a later
> date.”
>     >
>     > In the case the receiver provides a written statement from its
> upstream
>     that IPv6 connectivity is unavailable, the IPv6 requirement may be
> waived. In the case LACNIC is not able to meet a new entrant request for
> IPv4
>     space, or the organization does not hold any IPv4 space the IPv6
> requirement may be waived for a transfer up to a /22.
>     >
>     > To see the details, please click on:
>     >
> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-1/language/en
>     >
>     > The changes from the previous version can be seen here:
>     >
> https://politicas.lacnic.net/politicas/diff2?id=LAC-2020-1&v=4&v2=3&language=EN
>     >
>     > The community's comments and opinions are essential to the proper
> functioning of the policy development process.
>     > - Do you support this new version of the proposal or are you against
> it?
>     > - Do you think this new version of the proposal has any drawbacks?
>     > - What changes could be made to this new version of the proposal to
> make it more effective?
>     >
>     > For further information, please contact mailto:
> info-politicas at lacnic.net
>     > Kind regards,
>     > --
>     > LACNIC - Registro de Direcciones de Internet para América Latina y
>     Caribe
>     > Rambla Rep. de México 6125, CP 11400
>     >
>     > Montevideo-Uruguay
>     >
>     > Teléfono: +598 2604 22 22
>     > http://www.lacnic.net
>     > _______________________________________________
>     > Politicas mailing list
>     > mailto:Politicas at lacnic.net
>     > https://mail.lacnic.net/mailman/listinfo/politicas
>     _______________________________________________
>     Politicas mailing list
>     mailto:Politicas at lacnic.net
>     https://mail.lacnic.net/mailman/listinfo/politicas
>
>
>
> **********************************************
> 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
> mailto:Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>
>
>
> **********************************************
> 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
> Desuscribirse/Descadastre-se/Unsubscribe
> <https://mail.lacnic.net/mailman/listinfo/politicasDesuscribirse/Descadastre-se/Unsubscribe>:
> https://mail.lacnic.net/mailman/options/politicas
>
>