[LACNIC/Politicas] LAC-2019-10: Eliminación de obligación de devolver direcciones
Nicolas Antoniello
nantoniello at gmail.com
Tue Mar 17 21:45:32 GMT+3 2020
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%2Fpoliticas.lacnic.net%2Fpoliticas%2Fdetail%2Fid%2FLAC-2019-10%2Flanguage%2Fsp&data=02%7C01%7Cedmundo.cazarez%40nic.mx%7C6c52489d525042e6910608d7cad4903b%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C0%7C637200886616653160&sdata=IixBO6VnFfuUVG8Mk30KYf%2FiJyVca5RonRfMO%2BAxnDs%3D&reserved=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%2Fmail.lacnic.net%2Fmailman%2Flistinfo%2Fpoliticas&data=02%7C01%7Cedmundo.cazarez%40nic.mx%7C6c52489d525042e6910608d7cad4903b%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C0%7C637200886616653160&sdata=82ExniDJhfvz8FA%2BQw6rI9hYXsZdnWlHRpKnRMtVoeM%3D&reserved=0
> > _______________________________________________
> > 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%7Cedmund
> > o.cazarez%40nic.mx%7C6c52489d525042e6910608d7cad4903b%7Cc65a3ea60f7c40
> > 0b89345a6dc1705645%7C0%7C0%7C637200886616653160&sdata=82ExniDJhfvz
> > 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%2Fwww.t
> > heipv6company.com&data=02%7C01%7Cedmundo.cazarez%40nic.mx%7C6c5248
> > 9d525042e6910608d7cad4903b%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C0%
> > 7C637200886616653160&sdata=DAgS0%2FAAZhZN97qQogyAUpf%2BeUVB5BTG3Q3
> > 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%7Cedmund
> > o.cazarez%40nic.mx%7C6c52489d525042e6910608d7cad4903b%7Cc65a3ea60f7c40
> > 0b89345a6dc1705645%7C0%7C0%7C637200886616653160&sdata=82ExniDJhfvz
> > 8FA%2BQw6rI9hYXsZdnWlHRpKnRMtVoeM%3D&reserved=0
> >
> _______________________________________________
> 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%7C6c52489d525042e6910608d7cad4903b%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C0%7C637200886616653160&sdata=82ExniDJhfvz8FA%2BQw6rI9hYXsZdnWlHRpKnRMtVoeM%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