[LACNIC/Politicas] LAC-2019-10: Eliminación de obligación de devolver direcciones

JORDI PALET MARTINEZ jordi.palet at consulintel.es
Wed Mar 18 06:03:12 GMT+3 2020


Efectivamente.

El problema que existía era que *antes* si no mal recuerdo, el plazo de devolución *al proveedor* era sólo de 3 meses y si que entendió la comunidad que era muy poco y por eso lo ampliamos y además hicimos explícita la opción de una transferencia ligeramente mas simplificada (que se podía hacer igualmente, pero a veces un texto mas explicito ayuda a que eso pueda ocurrir, o incluso a que se conozca la opción). 
 
Saludos,
Jordi
@jordipalet
 
 

El 18/3/20 2:47, "Politicas en nombre de Nicolas Antoniello" <politicas-bounces at lacnic.net en nombre de nantoniello at gmail.com> escribió:

    Claro, pero lo que allí se indica es una de dos opciones:
    
    Opción 1: el proveedor está de acuerdo con que conserves el bloque y Lacnic
    te asigna un complemento adicional para completar tu solicitud.
    Opción 2: eliges renumerar y por lo tanto creo que está bien que dejes de
    utilizar el bloque del proveedor. Por no es que son devueltas a Lacnic (al
    menos yo entiendo eso) sino que son devueltas al proveedor que te las
    asignó como cliente... estoy en lo correcto?
    
    Y de ser así, tal vez no haya ningún problema con la redacción actual
    (nuevamente, más allá de querer simplifaicar).
    
    Saludos,
    Nico
    
    
    
    
    El mar., 17 de mar. de 2020 a la(s) 22:10, Edmundo Cázarez López (
    edmundo.cazarez at nic.mx) escribió:
    
    > Hola Nico,
    >
    > "En caso de renumeración, el bloque previamente asignado deberá ser
    > retornado en un plazo máximo de 12 meses. Excepcionalmente, este plazo
    > podrá ser extendido en 6 meses adicionales si se justifica que no ha habido
    > tiempo para la consecución de los recursos que precisa y la renumeración
    > correspondiente."
    >
    > En el texto actual solo veo dos opciones: que el ISP titular de la
    > asignación "ceda" las direcciones en uso o que sean devueltas.
    >
    > Saludos.
    >
    > - - Edmundo.
    > -
    > -----Original Message-----
    > From: Politicas <politicas-bounces at lacnic.net> On Behalf Of Nicolas
    > Antoniello
    > Sent: Tuesday, March 17, 2020 7:04 PM
    > To: Lista para discusion de politicas de la comunidad de LACNIC <
    > politicas at lacnic.net>
    > Subject: Re: [LACNIC/Politicas] LAC-2019-10: Eliminación de obligación de
    > devolver direcciones
    >
    > Edmundo,
    >
    > Justamente eso es lo que no entiendo: ¿dónde establece la versión actual
    > del manual que hay que devolver direcciones?
    >
    > Ojo que puede que la estadía prolongada en casa por el COVID-19 me esté
    > afectando.   :)
    >
    > Saludos,
    > Nico
    >
    >
    >
    > El mar., 17 de mar. de 2020 a la(s) 21:51, Edmundo Cázarez López (
    > edmundo.cazarez at nic.mx) escribió:
    >
    > > Hola Nico,
    > >
    > > No se obliga a devolver espacio de direcciones. Las partes pueden o no
    > > hacerlo.
    > >
    > >
    > > - - Edmundo.
    > > -
    > > -----Original Message-----
    > > From: Politicas <politicas-bounces at lacnic.net> On Behalf Of Nicolas
    > > Antoniello
    > > Sent: Tuesday, March 17, 2020 6:46 PM
    > > To: Lista para discusion de politicas de la comunidad de LACNIC <
    > > politicas at lacnic.net>
    > > Subject: Re: [LACNIC/Politicas] LAC-2019-10: Eliminación de obligación
    > > de devolver direcciones
    > >
    > > Edmundo,
    > >
    > > Gracias por la explicación.
    > > Entonces, que cambia respecto de lo que se puede y no se puede hacer
    > > actualmente (más allá de simplificar el texto)?
    > >
    > > Saludos,
    > > Nico
    > >
    > >
    > >
    > > El mar., 17 de mar. de 2020 a la(s) 21:43, Edmundo Cázarez López (
    > > edmundo.cazarez at nic.mx) escribió:
    > >
    > > > Hola Nicolas,
    > > >
    > > > El objetivo de la propuesta es simplificar el texto de la misma.
    > > >
    > > > El texto propuesto en ningún lugar menciona que "puedan" o "deban"
    > > > quedarse con las direcciones, así como tampoco hace forzoso que un
    > > > operador ceda las direcciones que ha asignado.
    > > >
    > > > Me parece que el texto actual va demasiado a tratar de cubrir todos
    > > > los casos, de modo exhaustivo.
    > > >
    > > > En la práctica, hay muchos casos en que las direcciones que se van a
    > > > asignar a un operador son insuficientes para que renumere su red, y
    > > > en todo caso la idea es que si es "conveniente" para las partes, los
    > > > nuevos entrantes puedan seguir utilizando las direcciones que le
    > > > asignaron
    > > >
    > > >
    > > > - - Edmundo.
    > > > -
    > > > -----Original Message-----
    > > > From: Politicas <politicas-bounces at lacnic.net> On Behalf Of Nicolas
    > > > Antoniello
    > > > Sent: Tuesday, March 17, 2020 6:37 PM
    > > > To: Lista para discusion de politicas de la comunidad de LACNIC <
    > > > politicas at lacnic.net>
    > > > Subject: Re: [LACNIC/Politicas] LAC-2019-10: Eliminación de
    > > > obligación de devolver direcciones
    > > >
    > > > Hola todos,
    > > >
    > > > Una consulta porque pensando en esta propuesta no entiendo algo:
    > > > Que sucede si "devuelvo" los bloques al proveedor y luego arreglo
    > > > con el proveedor para hacer una transferencia intra RIR con costo
    > > > cero y
    > > listo...
    > > > es decir, si me quiero quedar con el bloque y el proveedor está de
    > > > acuerdo siempre podría encontrar la forma de hacerlo no? Sin
    > > > importar lo que diga esta propuesta.
    > > >
    > > > Por otro lado, con el texto actual, si el proveedor está de acuerdo,
    > > > entiendo que puedo quedarme con el bloque, al menos eso dice el
    > > > texto del manual en los puntos 2.3.3.1.1 y 2.3.3.4.3, correcto?
    > > >
    > > > Entonces, por un lado no me queda claro que se logra con la
    > > > propuesta y por otro lado no entiendo las argumentaciones en contra
    > > > alegando que hay que devolver el bloque, cuando el manual actual
    > > > indica que si hay arreglo no es necesario devolver.
    > > >
    > > > Por último, pensar en que me puedo "adueñar" de un bloque de un
    > > > operador (siendo yo cliente de el) no me parece que sea algo que
    > > > deba o no ir en una propuesta... pues esa acción sería no permitida
    > > > en cualquier escenario (y si lo hago y publico algo que no es mío ya
    > > > todos sabemos que sucede y que medidas se pueden tomar para evitarlo).
    > > >
    > > > Les dejo esas dudas de letra :)
    > > >
    > > > Abrazo,
    > > > Nico
    > > >
    > > >
    > > >
    > > > El mar., 17 de mar. de 2020 a la(s) 12:23, JORDI PALET MARTINEZ via
    > > > Politicas (politicas at lacnic.net) escribió:
    > > >
    > > > > Coincido con Fernando, y para que no haya dudas, contrario a la
    > > > propuesta.
    > > > >
    > > > > Esta parte del manual de políticas se modificó recientemente con
    > > > > mi propuesta LAC-2018-9, que era consecuencia de una de las
    > > > > mejoras de políticas manifestadas por la comunidad y publicadas por
    > el staff.
    > > > >
    > > > > Como referencia, la problemática que se reflejaba era el escaso
    > > > > tiempo para la devolución, y por ello presenté dicha propuesta y
    > > > > con la previsión de además que se pudiera evitar la remuneración
    > > > > con una transferencia "simplificada" (cesión) si el ISP le
    > > > > interesaba y había acuerdo entre ambas partes, y obviamente me
    > > > > planteé la posibilidad de no realizar la devolución, pero no me
    > > > > pareció que
    > > estuviera justificada.
    > > > >
    > > > > Mis argumentos en contra de la propuesta son:
    > > > >
    > > > > 1) La justificación de la propuesta LAC-2019-10, indica que hay
    > > > > casos en los que no se quiere realizar la renumeración, y aún
    > > > > estando de acuerdo con ello, no tiene sentido, porque si hay
    > > > > multihoming, no serviría, o es algo que si se quiere cambiar de
    > > > > proveedor tampoco sirve, o si se utiliza NAT, el problema no
    > > > > existe, o es sumamente reducido (ejemplo, renumerar las reglas del
    > > > > firewall que hace el proxy
    > > > inverso o equivalente).
    > > > >
    > > > > 2) Igualmente dicha justificación habla de que a veces se requiere
    > > > > más de un /22, y aunque eso es cierto, en esos casos la solución
    > > > > mas adecuada es una transferencia de un bloque mayor, y así evitar
    > > > > múltiples anuncios de rutas fragmentadas (que precisamente era una
    > > > > de las oposiciones a mi propuesta), en lugar de utilizar esta
    > > > > parte del
    > > > manual.
    > > > >
    > > > >
    > > > >
    > > > > Saludos,
    > > > > Jordi
    > > > > @jordipalet
    > > > >
    > > > >
    > > > >
    > > > > El 17/3/20 14:33, "Politicas en nombre de Fernando Frediani" <
    > > > > politicas-bounces at lacnic.net en nombre de fhfrediani at gmail.com>
    > > > escribió:
    > > > >
    > > > >     Sigo siendo contrario a esta propuesta.
    > > > >
    > > > >     Si el destinatario de los recursos recibe sus propios
    > > > > recursos, es
    > > > muy
    > > > >     razonable pensar, especialmente a largo plazo, que esos recursos
    > > > >     previamente asignados al proveedor deben ser devueltos para
    > > > > que
    > > > puedan
    > > > >     asignarse a otros clientes en el futuro y que estos recursos
    > puedan
    > > > >     reutilizarse mejor con el tiempo, especialmente en tiempos de
    > > > > escasez de
    > > > >     IPv4.
    > > > >     En algún momento no muy lejano, cuando el pool de IPv4 para
    > nuevos
    > > > >     participantes esté completamente agotado, este será uno de los
    > > > >     mecanismos para que existan nuevas organizaciones, utilizando
    > estas
    > > > >     asignaciones de IPv4 de sus proveedores para mecanismos de
    > > > transición,
    > > > >     incluso de una manera menos óptima.
    > > > >
    > > > >     Además, una organización que obtiene sus propias asignaciones
    > > > > de
    > > > estos
    > > > >     montos generalmente siempre será mayor de lo que tiene con su
    > > > > proveedor
    > > > >     y, por lo tanto, la remuneración en este caso es parte del
    > negocio.
    > > > Si
    > > > >     alguien no está preparado para llevar a cabo un plan de
    > > > > remuneración en
    > > > >     un caso como este, entonces no está preparado para convertirse
    > > > > en
    > > un
    > > > >     Sistema Autónomo.
    > > > >
    > > > >     Si las organizaciones que se han convertido en sistemas
    > autónomos y
    > > > >     tienen sus propias asignaciones también se les permite
    > > > > mantener las
    > > > de
    > > > >     sus proveedores con el tiempo, habrá un uso menos eficiente de
    > > estos
    > > > >     recursos.
    > > > >
    > > > >     La única excepción que creo que es justa es para aquellos que,
    > > > después
    > > > >     de que el pool de IPv4 está completamente agotado, no tienen
    > > ninguna
    > > > >     asignación de IPv4 y están esperando en una lista de espera o una
    > > > >     transferencia.
    > > > >
    > > > >     Fernando Frediani
    > > > >
    > > > >     On 17/03/2020 09:27, Tomas Lynch via Politicas wrote:
    > > > >     > Estimados miembros de la lista,
    > > > >     >
    > > > >     > Recordamos que la propuesta de política "LAC-2019-10:
    > > > > Eliminación de
    > > > >     > obligación de devolver direcciones" sigue en discusión.
    > > > > Durante
    > > > esta
    > > > >     > semana, del 16 al 22 de Marzo nos dedicaremos a la discusión
    > > > > de
    > > la
    > > > >     > misma [1].
    > > > >     >
    > > > >     > Les pedimos que respondan a este correo, sin cambiar el
    > > > > subject,
    > > si
    > > > >     > están de acuerdo o no con la propuesta adjuntando una breve
    > > > >     > descripción que sustente su posición [2].
    > > > >     >
    > > > >     > Encontrarán la propuesta completa en
    > > > >     >
    > > > >
    > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpo
    > > > li
    > > > ticas.lacnic.net%2Fpoliticas%2Fdetail%2Fid%2FLAC-2019-10%2Flanguage%
    > > > 2F
    > > > sp&data=02%7C01%7Cedmundo.cazarez%40nic.mx%7C09fac2be45b145afbfd
    > > > a0
    > > > 8d7cad5c0b7%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C1%7C63720089171
    > > > 92
    > > > 50203&sdata=seToFidc8qsaENQSo86oG48mpnUUAFRjajIEexTEcLo%3D&r
    > > > es
    > > > erved=0
    > > > >     >
    > > > >     > A continuación se muestra el texto original y el de la
    > propuesta:
    > > > >     >
    > > > >     > *Texto Actual*
    > > > >     > 2.3.3.1.1. - Requisitos para un prefijo /24 a un /22
    > > > >     >
    > > > >     > Para calificar para la distribución de un prefijo /24 a un
    > > > > /22 el ISP
    > > > >     > solicitante deberá cumplir los siguientes requisitos
    > > > >     >
    > > > >     > 1. Demostrar el uso o la necesidad inmediata de al menos el
    > > > > 25%
    > > del
    > > > >     > prefijo solicitado.
    > > > >     >
    > > > >     > 2. Entregar un plan detallado de uso de 50% de uso del prefijo
    > > > >     > solicitado para un año.
    > > > >     >
    > > > >     > - Si previamente había un bloque asignado por un proveedor,
    > > > > y se desea
    > > > >     > mantener el mismo para evitar la renumeración, y hay acuerdo
    > > entre
    > > > >     > ambas partes, se podrá ceder[1] dicho bloque (con el cambio de
    > > > >     > titularidad en el whois, a través de LACNIC).
    > > > >     >
    > > > >     > - Si se ha justificado espacio adicional y es posible su
    > > > > distribución,
    > > > >     > el receptor podrá decidir si la cesión le es conveniente y
    > > > > recibe
    > > > un
    > > > >     > bloque por el espacio adicional o prefiere un único bloque por
    > el
    > > > >     > total y, por lo tanto, renumera. En caso de renumeración, el
    > > bloque
    > > > >     > previamente asignado deberá ser retornado en un plazo máximo
    > > > > de
    > > 12
    > > > >     > meses. Excepcionalmente, este plazo podrá ser extendido en 6
    > > meses
    > > > >     > adicionales si se justifica que no ha habido tiempo para la
    > > > >     > consecución de los recursos que precisa y la renumeración
    > > > >     > correspondiente.
    > > > >     >
    > > > >     > - En caso de que el solicitante aun no cuente con un bloque
    > IPv6
    > > > >     > asignado por LACNIC, solicitar al mismo tiempo un bloque IPv6
    > > > >     > cumpliendo con la política aplicable.
    > > > >     >
    > > > >     > 2.3.3.1.2. - Requisitos para un prefijo /21 o menor (bloque
    > > > > de
    > > > > 8
    > > > > /24 o
    > > > >     > más)
    > > > >     >
    > > > >     > En caso de que el ISP solicitante requiera una distribución
    > > > > inicial de
    > > > >     > direcciones IPv4 a partir de un prefijo /21 deberá cumplir los
    > > > >     > siguientes requerimientos
    > > > >     >
    > > > >     > - Proveer información de las asignaciones realizadas por
    > > > > prefijos
    > > > de
    > > > >     > longitudes /29 o menores (más de 8 direcciones IPv4) en el
    > > > > WHOIS
    > > de
    > > > >     > LACNIC
    > > > >     >
    > > > >     > - Proveer documentación justificando la distribución de
    > > > > espacio
    > > de
    > > > >     > direcciones inicial. (Llenado de la plantilla de solicitud de
    > > > >     > direcciones IPv4 para ISP). Se deberá incluir información
    > > detallada
    > > > >     > mostrando cómo será utilizado ese recurso dentro de los
    > > > > periodos
    > > de
    > > > >     > tres, seis y doce meses
    > > > >     >
    > > > >     > - Si previamente había un bloque asignado por un proveedor,
    > > > > y se desea
    > > > >     > mantener el mismo para evitar la renumeración, y hay acuerdo
    > > entre
    > > > >     > ambas partes, se podrá ceder[2] dicho bloque (con el cambio de
    > > > >     > titularidad en el whois, a través de LACNIC).
    > > > >     >
    > > > >     > - Si se ha justificado espacio adicional y es posible su
    > > > > distribución,
    > > > >     > el receptor podrá decidir si la cesión le es conveniente y
    > > > > recibe
    > > > un
    > > > >     > bloque por el espacio adicional o prefiere un único bloque por
    > el
    > > > >     > total y, por lo tanto, renumera. En caso de renumeración, el
    > > bloque
    > > > >     > previamente asignado deberá ser retornado en un plazo máximo
    > > > > de
    > > 12
    > > > >     > meses. Excepcionalmente, este plazo podrá ser extendido en 6
    > > meses
    > > > >     > adicionales si se justifica que no ha habido tiempo para la
    > > > >     > consecución de los recursos que precisa y la renumeración
    > > > >     > correspondiente.
    > > > >     >
    > > > >     > - En caso de que el solicitante aun no cuente con un bloque
    > IPv6
    > > > >     > asignado por LACNIC, solicitar al mismo tiempo un bloque IPv6
    > > > >     > cumpliendo con la política aplicable.
    > > > >     >
    > > > >     > ...
    > > > >     >
    > > > >     > 2.3.3.4.3 - Tamaño de la asignación y procedimiento
    > > > >     >
    > > > >     > El solicitante debe justificar que anunciará el espacio
    > > > > asignado, con
    > > > >     > su propio sistema autónomo, al menos a otro sistema autónomo.
    > > > >     >
    > > > >     > El tamaño de asignación mínima de direcciones IPv4 para un
    > > usuario
    > > > >     > final es de un bloque con prefijo /24 y el tamaño máximo
    > > > > será un /20,
    > > > >     > el cual deberá ser justificado, de acuerdo con la tasa de
    > > > > utilización
    > > > >     > (sección 2.3.3.4.2).
    > > > >     >
    > > > >     > Si previamente había un bloque asignado por un proveedor, y
    > > > > se
    > > > desea
    > > > >     > mantener el mismo para evitar la renumeración, y hay acuerdo
    > > entre
    > > > >     > ambas partes, se podrá ceder dicho bloque (con los cambios
    > > > >     > correspondientes en el whois). Si se ha justificado espacio
    > > > > adicional
    > > > >     > y es posible su asignación, el receptor podrá decidir si la
    > > > > cesión le
    > > > >     > es conveniente y recibe un bloque por el espacio adicional o
    > > > > prefiere
    > > > >     > un único bloque por el total y, por lo tanto, renumera. En
    > > > > caso
    > > de
    > > > >     > renumeración, el bloque previamente asignado deberá ser
    > > > > retornado
    > > > en
    > > > >     > un plazo máximo de 6 meses. Excepcionalmente, este plazo
    > > > > podrá
    > > ser
    > > > >     > extendido en 6 meses adicionales si se justifica que no ha
    > habido
    > > > >     > tiempo para la consecución de los recursos que precisa y la
    > > > >     > renumeración correspondiente.
    > > > >     >
    > > > >     > Para asignaciones adicionales se seguirán las políticas
    > > > > incluidas
    > > > en
    > > > >     > la sección 2.3.4 aplicables a los usuarios finales.
    > > > >     >
    > > > >     > *Texto Nuevo*
    > > > >     > 2.3.3.1.1. - Requisitos para un prefijo /24 a un /22
    > > > >     >
    > > > >     > Para calificar para la distribución de un prefijo /24 a un
    > > > > /22 el ISP
    > > > >     > solicitante deberá cumplir los siguientes requisitos
    > > > >     >
    > > > >     > 1. Demostrar el uso o la necesidad inmediata de al menos el
    > > > > 25%
    > > del
    > > > >     > prefijo solicitado.
    > > > >     >
    > > > >     > 2. Entregar un plan detallado de uso de 50% de uso del prefijo
    > > > >     > solicitado para un año.
    > > > >     >
    > > > >     > - En caso de que el solicitante aun no cuente con un bloque
    > IPv6
    > > > >     > asignado por LACNIC, solicitar al mismo tiempo un bloque IPv6
    > > > >     > cumpliendo con la política aplicable.
    > > > >     >
    > > > >     > 2.3.3.1.2. - Requisitos para un prefijo /21 o menor (bloque
    > > > > de
    > > > > 8
    > > > > /24 o
    > > > >     > más)
    > > > >     >
    > > > >     > En caso de que el ISP solicitante requiera una distribución
    > > > > inicial de
    > > > >     > direcciones IPv4 a partir de un prefijo /21 deberá cumplir los
    > > > >     > siguientes requerimientos
    > > > >     >
    > > > >     > - Proveer información de las asignaciones realizadas por
    > > > > prefijos
    > > > de
    > > > >     > longitudes /29 o menores (más de 8 direcciones IPv4) en el
    > > > > WHOIS
    > > de
    > > > >     > LACNIC.
    > > > >     >
    > > > >     > - Proveer documentación justificando la distribución de
    > > > > espacio
    > > de
    > > > >     > direcciones inicial. (Llenado de la plantilla de solicitud de
    > > > >     > direcciones IPv4 para ISP). Se deberá incluir información
    > > detallada
    > > > >     > mostrando cómo será utilizado ese recurso dentro de los
    > > > > periodos
    > > de
    > > > >     > tres, seis y doce meses.
    > > > >     >
    > > > >     > - En caso de que el solicitante aun no cuente con un bloque
    > IPv6
    > > > >     > asignado por LACNIC, solicitar al mismo tiempo un bloque IPv6
    > > > >     > cumpliendo con la política aplicable.
    > > > >     >
    > > > >     > ...
    > > > >     >
    > > > >     > 2.3.3.4.3 - Tamaño de la asignación.
    > > > >     >
    > > > >     > El solicitante debe justificar que anunciará el espacio
    > > > > asignado, con
    > > > >     > su propio sistema autónomo, al menos a otro sistema autónomo.
    > > > >     >
    > > > >     > El tamaño de asignación mínima de direcciones IPv4 para un
    > > usuario
    > > > >     > final es de un bloque con prefijo /24 y el tamaño máximo
    > > > > será un /20,
    > > > >     > el cual deberá ser justificado, de acuerdo con la tasa de
    > > > > utilización
    > > > >     > (sección 2.3.3.4.2).
    > > > >     >
    > > > >     > Para asignaciones adicionales se seguirán las políticas
    > > > > incluidas
    > > > en
    > > > >     > la sección 2.3.4 aplicables a los usuarios finales.
    > > > >     >
    > > > >     > <fin del texto>
    > > > >     >
    > > > >     > Notas:
    > > > >     >
    > > > >     > [1] La discusión no estará restringida solo esta propuesta,
    > > > > si alguien
    > > > >     > quiere opinar sobre otra propuesta es libre de hacerlo. Sin
    > > > > embargo es
    > > > >     > una manera fácil de ordenar la discusión.
    > > > >     >
    > > > >     > [2] Los comentarios durante esta semana se suman a los
    > > > > comentarios ya
    > > > >     > expresados con anterioridad para la decisión del consenso.
    > > > >     >
    > > > >     > Ariel Weher / Tomas Lynch
    > > > >     > Moderadores del Foro de Políticas Públicas de LACNIC
    > > > >     > _______________________________________________
    > > > >     > Politicas mailing list
    > > > >     > Politicas at lacnic.net
    > > > >     >
    > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma
    > > > il
    > > > .lacnic.net%2Fmailman%2Flistinfo%2Fpoliticas&data=02%7C01%7Cedmu
    > > > nd
    > > > o.cazarez%40nic.mx%7C09fac2be45b145afbfda08d7cad5c0b7%7Cc65a3ea60f7c
    > > > 40
    > > > 0b89345a6dc1705645%7C0%7C1%7C637200891719250203&sdata=fGmAmfmodV
    > > > 8N
    > > > 02TlFFm9XXPdrA%2F6QRndinnxjEaC%2BzE%3D&reserved=0
    > > > >     _______________________________________________
    > > > >     Politicas mailing list
    > > > >     Politicas at lacnic.net
    > > > >
    > > > > https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2F
    > > > > ma
    > > > > il
    > > > > .lacnic.net%2Fmailman%2Flistinfo%2Fpoliticas&data=02%7C01%7Ced
    > > > > mu
    > > > > nd
    > > > > o.cazarez%40nic.mx%7C6c52489d525042e6910608d7cad4903b%7Cc65a3ea60f
    > > > > 7c
    > > > > 40
    > > > > 0b89345a6dc1705645%7C0%7C0%7C637200886616653160&sdata=82ExniDJ
    > > > > hf
    > > > > vz
    > > > > 8FA%2BQw6rI9hYXsZdnWlHRpKnRMtVoeM%3D&reserved=0
    > > > >
    > > > >
    > > > >
    > > > >
    > > > > **********************************************
    > > > > IPv4 is over
    > > > > Are you ready for the new Internet ?
    > > > > https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
    > > > > ww
    > > > > .t
    > > > > heipv6company.com&data=02%7C01%7Cedmundo.cazarez%40nic.mx%7C6c
    > > > > 52
    > > > > 48
    > > > > 9d525042e6910608d7cad4903b%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%
    > > > > 7C
    > > > > 0%
    > > > > 7C637200886616653160&sdata=DAgS0%2FAAZhZN97qQogyAUpf%2BeUVB5BT
    > > > > G3
    > > > > Q3
    > > > > hXnrqbtE%3D&reserved=0
    > > > > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.lacnic.net%2Fmailman%2Flistinfo%2Fpoliticas&data=02%7C01%7Cedmundo.cazarez%40nic.mx%7Ce27d14cbdf724d32e19d08d7cad85560%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C1%7C637200902801768109&sdata=FRPd6UR4YCbrLKVxSB9wVtbunohwLGOjbFEFliEVRXI%3D&reserved=0
    > Este mensaje contiene información confidencial y se entiende dirigido y
    > para uso exclusivo del destinatario. Si recibes este mensaje y no eres el
    > destinatario por favor elimínalo, ya que difundir, revelar, copiar o tomar
    > cualquier acción basada en el contenido está estrictamente prohibido.
    > Network Information Center, S.A. de C.V., ubicado en Ave. Eugenio Garza
    > Sada 427 L4-6 Col. Altavista, Monterrey, México, C.P. 64840 recaba tus
    > datos personales necesarios para: la prestación, estudio, análisis y mejora
    > del servicio, la realización de comunicaciones y notificaciones; la
    > transferencia y publicación en los casos aplicables; el cumplimiento de la
    > relación existente; así como para la prevención o denuncia en la comisión
    > de ilícitos. Si eres colaborador o candidato a colaborador de NIC México,
    > tus datos serán utilizados para: la creación y administración de tu perfil
    > como profesionista; el otorgamiento de herramientas de trabajo; la
    > realización de estudios; el otorgamiento de programas y beneficios para
    > mejorar tu desarrollo profesional; la gestión y administración de servicios
    > de pago y/o nómina; así como para contacto y/o notificaciones. Si
    > participas en promociones o en estudios podrás dejar de participar. Para
    > mayor información revisa el Aviso de Privacidad<
    > http://www.nic.mx/es/NicMx.AvisosDePrivacidad>.
    >
    >
    > This message contains confidential information and is intended only for
    > the individual named. If you are not the named addressee please delete it,
    > since the dissemination, distribuition, copy or taking any action in
    > reliance on the contents is strictly prohibited. Network Information
    > Center, S.A. de C.V., located on Av. Eugenio Garza Sada 427 L4-6, Col.
    > Altavista, Monterrey, Mexico, CP 64840 collects your personal data which is
    > necessary to: provide, research, analyze and improve the service; send
    > communications and notices; transfer and publish your personal data when
    > applicable; fulfill the existing relationship; prevent or inform in the
    > commission of unlawful acts or events. If the data is processed in your
    > quality of candidate or collaborator of NIC Mexico, the purpose of
    > treatment is to: create and manage your profile as a professional; provide
    > you with working tools; conduct studies; grant benefits and programs to
    > enhance your professional development; manage and administrate payment
    > services and/or payroll; as well as to contact you. If you participate in
    > promotions or surveys you may stop or quit your participation at any time.
    > For more information read the Privacy Note<
    > http://www.nic.mx/es/NicMx.AvisosDePrivacidad>.
    > _______________________________________________
    > Politicas mailing list
    > Politicas at lacnic.net
    > https://mail.lacnic.net/mailman/listinfo/politicas
    >
    _______________________________________________
    Politicas mailing list
    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.





More information about the Politicas mailing list