[LACNIC/Politicas] LAC-2019-10: Eliminación de obligación de devolver direcciones
Nicolas Antoniello
nantoniello at gmail.com
Tue Mar 17 22:04:06 GMT+3 2020
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%2Fpoli
> > ticas.lacnic.net%2Fpoliticas%2Fdetail%2Fid%2FLAC-2019-10%2Flanguage%2F
> > sp&data=02%7C01%7Cedmundo.cazarez%40nic.mx%7C09fac2be45b145afbfda0
> > 8d7cad5c0b7%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C1%7C6372008917192
> > 50203&sdata=seToFidc8qsaENQSo86oG48mpnUUAFRjajIEexTEcLo%3D&res
> > 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%2Fmail
> > .lacnic.net%2Fmailman%2Flistinfo%2Fpoliticas&data=02%7C01%7Cedmund
> > o.cazarez%40nic.mx%7C09fac2be45b145afbfda08d7cad5c0b7%7Cc65a3ea60f7c40
> > 0b89345a6dc1705645%7C0%7C1%7C637200891719250203&sdata=fGmAmfmodV8N
> > 02TlFFm9XXPdrA%2F6QRndinnxjEaC%2BzE%3D&reserved=0
> > > _______________________________________________
> > > 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%7C6c52489d525042e6910608d7cad4903b%7Cc65a3ea60f7c
> > > 40
> > > 0b89345a6dc1705645%7C0%7C0%7C637200886616653160&sdata=82ExniDJhf
> > > 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%2Fwww
> > > .t
> > > heipv6company.com&data=02%7C01%7Cedmundo.cazarez%40nic.mx%7C6c52
> > > 48
> > > 9d525042e6910608d7cad4903b%7Cc65a3ea60f7c400b89345a6dc1705645%7C0%7C
> > > 0%
> > > 7C637200886616653160&sdata=DAgS0%2FAAZhZN97qQogyAUpf%2BeUVB5BTG3
> > > 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.
>
>
More information about the Politicas
mailing list