[LACNIC/Politicas] LAC-2023-7 v2 - comentarios adicionales

Tue May 14 14:39:35 -03 2024

Esta propuesta requiere que LACNIC revise si el recipiente necesita X
número de IPs. (LAC-2024-3 no, pero esa no la estamos discutiendo ahora.)

Si el recipiente necesita, justifica y LACNIC acepta que necesita X número,
no veo porque se requiera restringir a un tamaño específico.

>Hay 2 caminos que siguen siendo posibles de manera correcta a través de
lo RIR: lista de espera o transferencia definitiva

Yo diría que hay 3.

lista de espera, transferencia definitiva o transferencia temporal.

Saludos
as

On Tue, 14 May 2024 at 19:27, Fernando Frediani <fhfrediani at gmail.com>
wrote:

> On 14/05/2024 14:17, Arturo Servin wrote:
> >
> > Si, pueden tener el dinero pero la compra puede ser subóptima
> > financieramente. Como comente:
> >
> > 'las transferencias temporales pueden verse también como un caso
> financiero
> > donde se arrenda el IP a múltiples años. En este caso, es posible que la
> > entidad receptora requiera mucho más de un /22 (e.g. proveedor de Cloud,
> > ISP grande, etc.)'
> Este no es un tema que deba preocupar mucho este foro de políticas. Aquí
> debemos preocuparnos principalmente de los principios que guían la
> asignación de direcciones IP a aquellas que realmente tienen
> justificación y logran un buen equilibrio entre los aspectos económicos,
> técnicos y prácticos.
> Si la justificación para esta propuesta es facilitarle a alguien que no
> tiene direcciones IP poder iniciar su negocio, establecerse y poder
> comprometerse a hacer lo correcto de manera definitiva, entonces un
> límite facilita esto, pero permitirlo sin límites. es simplemente
> desregular y desequilibrar las relaciones antes mencionadas además de
> utilizar esta propuesta para un fin diferente al que se declara
> oficialmente.
> >> se confirmará que al final esta propuesta es sólo una
> >> forma encubierta de permitir el alquiler o préstamo de direcciones IP de
> >> una entidad a otra que pueda recibirlas directamente del RIR
> > Los RIRs ya no tienen direcciones, así que la única forma de recibir IPs
> es
> > vía una transferencia. Esta puede ser permanente (como venta) o temporal
> > (renta.) El racional al final es similar si arrendar o comprar un auto,
> > depende de tus finanzas, taxes, etc. si te vas por una u otra.
> Hay 2 caminos que siguen siendo posibles de manera correcta a través de
> lo RIR: lista de espera o transferencia definitiva y debe haber
> preocupación en mantener esto y no solo crear una nueva regla para
> evitar un problema que afecta a todos por igual y no se va a resolver
> con más permisividad y sin muchos controles.
>
> De nuevo, las preocupaciones financieras no deben anular los principios
> que siempre han guiado la asignación de direcciones durante décadas,
> incluso en el escenario actual, por lo que este equilibrio y la
> existencia de un límite son importantes para seguir teniendo un 'check
> and balance' necesarios.
>
> Fernando
>
> >
> > Saludos
> > as
> >
> >
> >
> >
> >
> >
> >
> > On Tue, 14 May 2024 at 18:55, Fernando Frediani<fhfrediani at gmail.com>
> > wrote:
> >
> >> No tiene sentido ni lógica no tener un límite de tamaño si se trata de
> >> una "transferencia" temporal. Quienes necesitan bloques más grandes
> >> tienen las condiciones económicas para realizar estas transferencias sin
> >> contratiempos.
> >> Si alguien necesita un tamaño mayor, entonces debe transferir
> >> permanentemente los bloques necesarios y no quedarse en un escenario
> >> temporal-definitivo.
> >>
> >> De lo contrario, se confirmará que al final esta propuesta es sólo una
> >> forma encubierta de permitir el alquiler o préstamo de direcciones IP de
> >> una entidad a otra que pueda recibirlas directamente del RIR.
> >>
> >> Fernando
> >>
> >> On 14/05/2024 13:33, Arturo Servin wrote:
> >>> Hola
> >>>
> >>> Como le comente a Jordi, creo que la propuesta se está tomando como una
> >>> solución para mecanismos de transición a IPv6 pero en mi opinión, ese
> es
> >>> solo un caso de uso. Como comente, las transferencias temporales pueden
> >>> verse también como un caso financiero donde se arrenda el IP a
> >>> múltiples años. En este caso, es posible que la entidad receptora
> >> requiera
> >>> mucho más de un /22 (e.g. proveedor de Cloud, ISP grande, etc.) De esta
> >>> forma, la transferencia temporal es igual que una permanente solo con
> la
> >>> diferencia de cómo los 'assets' se manejan.
> >>>
> >>> Por lo anterior creo que estas transferencias deberían tener los mismos
> >>> requisitos que las permanentes, es decir:
> >>>
> >>> - No requerimiento de IPv6
> >>> - No requerimiento de poner IPv6, hacer RPKI, IRR etc. (estas son
> >>> decisiones del recipiente)
> >>> - No MARNS (soy proponente de MANRS pero en este caso no es indicado
> >>> requerirlo)
> >>> - No límite de tamaño
> >>>
> >>> También me gustaría si entre Jordi y Gonzalo (LAC-2024-3) pudieran
> sacar
> >>> algunos números de lo que ha pasado en RIPE NCC donde estas
> >> transferencias
> >>> son permitidas. Por ejemplo, tenemos la hipótesis de que si no tenemos
> >>> cuidado las transferencias temporales se van a usar para malos usos.
> Sin
> >>> embargo no se si tenemos evidencia para probar o rechazar esta
> >>> hipótesis. Creo que esto es importante para tomar una decisión
> informada
> >>> como comunidad.
> >>>
> >>> Saludos
> >>> as
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> On Tue, 14 May 2024 at 17:03, Hernan Arcidiacono<
> >> harcidiacono at iplan.com.ar>
> >>> wrote:
> >>>
> >>>> Gracias Jordi por volver rápido con el tema. Van mis comentarios entre
> >>>> líneas:
> >>>>
> >>>> On Tue, May 14, 2024 at 11:07 AM jordi.palet--- via Politicas <
> >>>> politicas at lacnic.net> wrote:
> >>>>
> >>>>> Hola a todos,
> >>>>>
> >>>>> Con este correo quiero debatir a algunos de los comentarios, tras
> >> revisar
> >>>>> el video, que hubo durante la presentación de la propuesta en el
> pasado
> >>>>> foro, dado que íbamos muy justos de tiempo.
> >>>>>
> >>>>> Sería muy importante recibir feedback al respecto de los siguientes
> >>>> puntos
> >>>>> que creo que son los mas debatidos, obviamente no exclusivamente:
> >>>>>
> >>>>> 1) Restringir las transferencias temporales a /20, otro prefijo o sin
> >>>>> restricción?
> >>>>> Bajo mi punto de vista, y con la experiencia de casos reales de
> >>>> despliegue
> >>>>> de IPv6, puede haber muchos casos de operadores que tengan varios
> PoPs
> >>>>> donde conectan a sus upstreams y por lo tanto necesitan un /24 por
> cada
> >>>> uno
> >>>>> de ellos, dado que no pueden anunciar eficazmente, por ejemplo, un
> /25
> >> o
> >>>>> /26. Por lo tanto un /22 sería excesivamente pequeño en algunos
> casos.
> >> La
> >>>>> alternativa es no poner limite alguno. Personalmente no tendría
> >> problema
> >>>> en
> >>>>> ello si mantenemos la justificación de la necesidad.
> >>>>>
> >>>> HA: A mi me gusta la opción de /22 pero estoy dispuesto a aceptar
> otras
> >>>> alternativas inclusive al de sin límite si es el consenso de la
> >> comunidad.
> >>>>> 2) Mantener la justificación de la necesidad o eliminarla?
> >> Personalmente
> >>>>> creo que es importante mantenerla. No le veo el sentido a que se
> puedan
> >>>>> realizar transferencias de ningún tipo si no hay una necesidad
> >>>> demostrada,
> >>>>> pues entonces impera el poderío económico frente a los que realmente
> >>>>> necesitan direcciones.
> >>>>>
> >>>> HA: Coincido en la conveniencia de mantener la justificación. Si bien
> >>>> entiendo que puede atentar contra un esquema más rápido de
> utilización,
> >>>> daría la chance de tener una política más conservadora y ver como
> >> resulta.
> >>>>> 3) Requisitos adicionales. Mi lectura de la discusión de esta
> >> propuesta y
> >>>>> de la que se presentó con objetivos similares, es que una parte
> >>>>> (importante) de la comunidad desea que haya un grado de control.
> >> Además,
> >>>>> las propias empresas de leasing nos han dicho que ellos imponen ese
> >>>> control
> >>>>> en sus contratos. Por lo tanto, dado que puede haber empresas de
> >> leasing
> >>>>> “buenas y malas” (entendiendo aquí por malas aquellas que alquilan
> las
> >>>>> direcciones sin comprobar nada, e incluso a sabiendas de que pueden
> ser
> >>>>> usadas de forma maliciosa, generando casos de abuso, etc.), porque no
> >>>>> uniformizar los requisitos para que todas estén no solo buscando su
> >>>>> negocio, sino también siendo buenos “cyber-ciudadanos” y
> contribuyendo
> >> al
> >>>>> bien de la comunidad?
> >>>>>
> >>>>> De forma resumida, veamos esas restricciones, para entender si el
> >>>> problema
> >>>>> es que debe haber ciertas restricciones, pero no todas (por ejemplo):
> >>>>> a) Que las direcciones no puedan ser utilizadas para abusos. Alguna
> >> razón
> >>>>> por la que debamos permitir abusos desde esas direcciones?
> >>>>>
> >>>> HA: OK. Entiendo además que es quien reciba la transferencia temporal
> >> quien
> >>>> además proveerá el contacto.
> >>>>
> >>>>> b) Disponer de IPv6. Quizás que sea al menos un compromiso el
> >> despliegue
> >>>>> de IPv6?
> >>>>>
> >>>> HA: Disponer de asignación es comprobable. No estaría de acuerdo que
> se
> >>>> exija que esté operativo y el compromiso no es comprobable.
> >>>>
> >>>>> c) Disponer de RPKI. Porque no va a desplegar RKPI alguien que reciba
> >>>>> recursos?
> >>>>>
> >>>> HA: Me parece deseable, pero lo veo difícil como exigible.
> >>>>
> >>>>> d) Geolocalización e IRR. Porque no va a geolocalizar y tener
> >>>>> correctamente el IRR alguien que reciba recursos?
> >>>>>
> >>>> HA: Me parece deseable, pero lo veo difícil como exigible.
> >>>>
> >>>>> e) Cumplir con MANRS. Porque no va a desear cumplir con MANRS quien
> >>>> recibe
> >>>>> direcciones?
> >>>>>
> >>>> HA: Me parece deseable, pero lo veo difícil como exigible.
> >>>>
> >>>> HA: Me gustaría establecer los requisitos, en especial los c,d,e, pero
> >> no
> >>>> veo como exigirlos y no quiero atentar contra que tengamos una
> >> política. Si
> >>>> alguien está más creativo acá, estoy abierto a escuchar
> >>>>
> >>>> Si lo pensamos detenidamente, se me hace difícil comprender que
> alguien
> >> que
> >>>>> recibe recursos para usos “buenos” no quiera protegerse también y
> >> cumplir
> >>>>> con estos requisitos. Entiendo que pueda haber otros puntos de vista,
> >>>> pero
> >>>>> creo que es necesario explicarlos y debatirlos.
> >>>>>
> >>>>> 4) Misma sección de transferencias definitivas o diferente. Creo que
> el
> >>>>> problema es meramente editorial y que en realidad “en este momento”
> >> puede
> >>>>> parecer que se lee confuso, porque en una propuesta tal y como se lee
> >> en
> >>>> el
> >>>>> sistema de políticas, no se lee tan fácilmente. Si ponemos en un PDF
> a
> >>>> dos
> >>>>> columnas el texto actual con el texto propuesto, bajo mi punto de
> >> vista,
> >>>> le
> >>>>> lee perfectamente.
> >>>>>
> >>>> HA: Como dije en el micrófono, creo que la lectura es confusa, pero si
> >>>> estamos de acuerdo en que salga, no veo un problema con esto.
> >>>>
> >>>>> Saludos,
> >>>>> Jordi
> >>>>>
> >>>>> @jordipalet
> >>>>>
> >>>>>
> >>>>>
> >>>>> **********************************************
> >>>>> IPv4 is over
> >>>>> Are you ready for the new Internet ?
> >>>>> http://www.theipv6company.com
> >>>>> The IPv6 Company
> >>>>>
> >>>>> This electronic message contains information which may be privileged
> or
> >>>>> confidential. The information is intended to be for the exclusive use
> >> of
> >>>>> the individual(s) named above and further non-explicilty authorized
> >>>>> disclosure, copying, distribution or use of the contents of this
> >>>>> information, even if partially, including attached files, is strictly
> >>>>> prohibited and will be considered a criminal offense. If you are not
> >> the
> >>>>> intended recipient be aware that any disclosure, copying,
> distribution
> >> or
> >>>>> use of the contents of this information, even if partially, including
> >>>>> attached files, is strictly prohibited, will be considered a criminal
> >>>>> offense, so you must reply to the original sender to inform about
> this
> >>>>> communication and delete it.
> >>>>>
> >>>>>
> >>>>>
> >>>>> _______________________________________________
> >>>>> Politicas mailing list
> >>>>> Politicas at lacnic.net
> >>>>> https://mail.lacnic.net/mailman/listinfo/politicas
> >>>>> Desuscribirse/Descadastre-se/Unsubscribe
> >>>>> <
> >>
> https://mail.lacnic.net/mailman/listinfo/politicasDesuscribirse/Descadastre-se/Unsubscribe
> >>>>> :
> >>>>> https://mail.lacnic.net/mailman/options/politicas
> >>>>>
> >>>>> El Codigo de Conducta de la Comunidad de LACNIC (
> >>>>> https://rir.la/codigoconducta-SP) aplica a las listas de discusion
> de
> >>>>> LACNIC.
> >>>>> O Codigo de Conduta da Comunidade do LACNIC (
> >>>>> https://rir.la/codigoconducta-PT) se aplica as listas de discussao
> do
> >>>>> LACNIC.
> >>>>> LACNIC's Community Code of Conduct (https://rir.la/codigoconducta-EN
> )
> >>>>> applies to LACNIC's discussion lists.
> >>>>>
> >>>>>
> >>>> --
> >>>> *No Imprimas Digitalizá*ESTE MENSAJE ES CONFIDENCIAL. Puede contener
> >>>> información amparada por el secreto profesional. Si usted ha recibido
> >> este
> >>>> e-mail por error, por favor comuníquenoslo inmediatamente vía e-mail y
> >>>> tenga la amabilidad de eliminarlo de su sistema; no deberá copiar el
> >>>> mensaje ni divulgar su contenido a ninguna persona. Muchas gracias.
> >>>>
> >>>> THIS
> >>>> MESSAGE IS CONFIDENTIAL. It may also contain information that is
> >>>> privileged
> >>>> or otherwise legally exempt from disclosure. If you have received it
> by
> >>>> mistake please let us know by e-mail immediately and delete it from
> your
> >>>> system; should also not copy the message nor disclose its contents to
> >>>> anyone. Many thanks.
> >>>>
> >>>>
> >>>> NSS S.A. – IPLAN | CUIT: 30-70265297-5 | IVA
> >>>> Responsable Inscripto | Ingr. Brutos: 901-033512-0 Inscripción I.G.J.:
> >>>> 24/02/1999, N° 2588, libro 4, tomo - Sociedades por Acciones | Sede
> >>>> Social:
> >>>> Reconquista 865 2° Piso, CABA
> >>>> <
> >>>>
> >>
> https://maps.google.com/?q=Reconquista+865+2%C2%B0+Piso,+CABA&entry=gmail&source=g
> >>>> C1003ABQ
> >>>>
> >>>>
> >>>>
> >>>> Ley 25326 - art.27. - inc. 3. El titular podrá en cualquier
> >>>> momento solicitar el retiro o bloqueo de su nombre de los bancos de
> >> datos
> >>>> a
> >>>> los que se refiere el presente artículo.
> >>>>
> >>>>
> >>>> Decreto 1558/01 - art. 27. -
> >>>> 3er. párrafo. En toda comunicación con fines de publicidad que se
> >> realice
> >>>> por correo, teléfono, correo electrónico, Internet u otro medio a
> >>>> distancia
> >>>> a conocer, se deberá indicar, en forma expresa y destacada, la
> >> posibilidad
> >>>> del titular del dato de solicitar el retiro o bloqueo, total o
> parcial,
> >> de
> >>>> su nombre de la base de datos. A pedido del interesado, se deberá
> >> informar
> >>>> el nombre del responsable o usuario del banco de datos que proveyó la
> >>>> información.
> >>>>
> >>>>
> >>>>
> >>>> El titular de los datos personales tiene la facultad de
> >>>> ejercer el derecho de acceso a los mismos en forma gratuita y a
> >> intervalos
> >>>> no inferiores a 6 meses, salvo que se acredite un interés legítimo al
> >>>> efecto conforme lo establecido por el artículo 14, inciso 3 de la ley
> >>>> 25326.-
> >>>>
> >>>>
> >>>>
> >>>> La Agencia de Acceso a la Información Pública , órgano de
> >>>> control de la ley Nº 25.326, tiene la atribución de atender las
> >> denuncias
> >>>> y
> >>>> reclamos que se interpongan con relación al incumplimiento de las
> normas
> >>>> sobre protección de datos personales.
> >>>>
> >>>> _______________________________________________
> >>>> Politicas mailing list
> >>>> Politicas at lacnic.net
> >>>> https://mail.lacnic.net/mailman/listinfo/politicas
> >>>> Desuscribirse/Descadastre-se/Unsubscribe
> >>>> <
> >>
> https://mail.lacnic.net/mailman/listinfo/politicasDesuscribirse/Descadastre-se/Unsubscribe
> >>> :
> >>>> https://mail.lacnic.net/mailman/options/politicas
> >>>>
> >>>> El Codigo de Conducta de la Comunidad de LACNIC (
> >>>> https://rir.la/codigoconducta-SP) aplica a las listas de discusion de
> >>>> LACNIC.
> >>>> O Codigo de Conduta da Comunidade do LACNIC (
> >>>> https://rir.la/codigoconducta-PT) se aplica as listas de discussao do
> >>>> LACNIC.
> >>>> LACNIC's Community Code of Conduct (https://rir.la/codigoconducta-EN)
> >>>> applies to LACNIC's discussion lists.
> >>>>
> >>>>
> >>> _______________________________________________
> >>> Politicas mailing list
> >>> Politicas at lacnic.net
> >>> https://mail.lacnic.net/mailman/listinfo/politicas
> >>> Desuscribirse/Descadastre-se/Unsubscribe:
> >> https://mail.lacnic.net/mailman/options/politicas
> >>> El Codigo de Conducta de la Comunidad de LACNIC (
> >> https://rir.la/codigoconducta-SP) aplica a las listas de discusion de
> >> LACNIC.
> >>> O Codigo de Conduta da Comunidade do LACNIC (
> >> https://rir.la/codigoconducta-PT) se aplica as listas de discussao do
> >> LACNIC.
> >>> LACNIC's Community Code of Conduct (https://rir.la/codigoconducta-EN)
> >> applies to LACNIC's discussion lists.
> >> _______________________________________________
> >> Politicas mailing list
> >> Politicas at lacnic.net
> >> https://mail.lacnic.net/mailman/listinfo/politicas
> >> Desuscribirse/Descadastre-se/Unsubscribe
> >> <
> https://mail.lacnic.net/mailman/listinfo/politicasDesuscribirse/Descadastre-se/Unsubscribe
> >:
> >> https://mail.lacnic.net/mailman/options/politicas
> >>
> >> El Codigo de Conducta de la Comunidad de LACNIC (
> >> https://rir.la/codigoconducta-SP) aplica a las listas de discusion de
> >> LACNIC.
> >> O Codigo de Conduta da Comunidade do LACNIC (
> >> https://rir.la/codigoconducta-PT) se aplica as listas de discussao do
> >> LACNIC.
> >> LACNIC's Community Code of Conduct (https://rir.la/codigoconducta-EN)
> >> applies to LACNIC's discussion lists.
> >>
> >>
> > _______________________________________________
> > Politicas mailing list
> > Politicas at lacnic.net
> > https://mail.lacnic.net/mailman/listinfo/politicas
> > Desuscribirse/Descadastre-se/Unsubscribe:
> https://mail.lacnic.net/mailman/options/politicas
> >
> > El Codigo de Conducta de la Comunidad de LACNIC (
> https://rir.la/codigoconducta-SP) aplica a las listas de discusion de
> LACNIC.
> > O Codigo de Conduta da Comunidade do LACNIC (
> https://rir.la/codigoconducta-PT) se aplica as listas de discussao do
> LACNIC.
> > LACNIC's Community Code of Conduct (https://rir.la/codigoconducta-EN)
> applies to LACNIC's discussion lists.
> >
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
> Desuscribirse/Descadastre-se/Unsubscribe
> <https://mail.lacnic.net/mailman/listinfo/politicasDesuscribirse/Descadastre-se/Unsubscribe>:
> https://mail.lacnic.net/mailman/options/politicas
>
> El Codigo de Conducta de la Comunidad de LACNIC (
> https://rir.la/codigoconducta-SP) aplica a las listas de discusion de
> LACNIC.
> O Codigo de Conduta da Comunidade do LACNIC (
> https://rir.la/codigoconducta-PT) se aplica as listas de discussao do
> LACNIC.
> LACNIC's Community Code of Conduct (https://rir.la/codigoconducta-EN)
> applies to LACNIC's discussion lists.
>
>