[LACNIC/Politicas] LAC-2019-10: Eliminación de obligación de devolver direcciones
Nicolas Antoniello
nantoniello at gmail.com
Tue Mar 17 22:46:49 GMT+3 2020
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
>
More information about the Politicas
mailing list