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

Thu May 16 08:31:37 -03 2024

Hola Jordi:

Nuestra diferencias no son en lo que queremos que creo que en gran parte
podemos coincidir, sino en que algunas de las cosas las veo difícil de que
realmente sean implementables, no es que no sean deseables para mí. Y en mi
cabeza me setie que necesitamos lograr consenso.

Como mencionas yo tampoco creo en el Wild West pero tengo la sensación que
algunas de las cosas van a terminar siendo pedidos formales y cuando no se
cumplan vamos a necesitar mirar para otro lado como la mayor parte de la
comunidad lo viene haciendo hace años.

Por eso yo celebro esta propuesta y deseo que en Octubre logremos un
consenso.

También entiendo el pensamiento de Fernando y creo que sus interpretaciones
son correctas, pero ya tenemos el agua tapándonos la nariz y no nos queda
otra que tragarnos el sapo y replantear qué hacer hacia adelante (espero
los términos que use sean traducibles e interpretables....)

Respondo a los puntos de 1 a 4 entre líneas.

On Wed, May 15, 2024 at 6:36 AM jordi.palet--- via Politicas <
politicas at lacnic.net> wrote:

> Hola Hernan, todos,
>
> Mil gracias a ti y a todos por los comentarios.
>
> Voy a contestar en este email a todos para evitar un correo uno a uno.
>
> 1) Hernan, coincido con muchos de los comentarios y creo que podríamos
> resumir muchos de ellos como “seamos conservadores, igual que lo fuimos con
> la política de transferencias definitivas” si no resulta, la mejoramos.
> HA: 100% de acuerdo. Tener algo para mejorar es mejor que no tener nada.
>

> 2) Respecto de los requisitos adicionales, bajo mi punto de vista, todos
> son comprobables, con mayor o menor dificultad. Esto nos ocurre casi
> siempre en todas las políticas. Sin embargo, recordemos que la redacción
> implica que LACNIC no es responsable de comprobarlo directamente, sino que
> lo es el que alquila. Esta es la misma operativa que han indicado (algunos)
> de los que hoy están alquilando. LACNIC tiene una responsabilidad en ultimo
> extremo. Por ejemplo si hay abusos, y no se cumple la política, le
> llegarían escalados a LACNIC, o si hay denuncias por ejemplo en el caso de
> que una empresa que hiciera las transferencias temporales incumpliera su
> deber, etc.
>
HA: Coincido con la comprobabilidad, pero  veo difícil su exigencia desde
la política. Cuando hoy tenemos el Wild West en práctica, no veo como
re-encorsetarlo con solo escribirlo. Aca me expreso desde el pragmatismo
puro y no desde lo que quiero. Creo que exigir contacto de abuso
comprobable como se nos exige a todos los miembros con asignaciones es
razonable, pero a mi como miembro no se me exige RPKI o que tenga en
operacion Ipv6. No obstante hoy como miembro adhiero a todas las best
practices pero si no lo hago no tengo consecuencias respecto de riesgo de
mis asignaciones. Por eso me parece difícil trasladarlo aunque vaya contra
mi deseo.

>
> 3) Respecto de la lectura de la propuesta, si LACNIC nos permitiera con un
> pequeño cambio en la configuración de la lista enviar pequeños adjuntos en
> PDF, sería muy fácil mostrar a dos columnas lo actual y como queda con los
> cambios, así resolveríamos este aspecto ahora y no había que darle mas
> vueltas. Hace unos años, yo era el primero que no me gustaba recibir
> grandes adjuntos en listas de correo, pero la cosa ha cambiado, además,
> siempre se puede hacer que el adjunto no vaya en los correos, sino que se
> envíe el enlace de donde esta archivado. Igualmente, como he dicho en otras
> ocasiones, y espero que no se me diga que hace falta una propuesta de
> política, sería muy sencillo que el sistema de políticas permita a los
> autores subir esos PDFs además de los textos planos de la propuesta, etc.
>
HA:  Aca, olvidémonos de mi comentario. Si se logra consenso es lo que
importa.

>
> 4) Creo que como comunidad debemos facilitar la transición a IPv6 porque
> es el objetivo final de todos. Esta propuesta ahora mismo esta enfocada en
> eso y no veo la necesidad de solucionar el problema quien no quiera
> transicionar a IPv6. Quien quiera direcciones sin IPv6, siempre tiene la
> opción de hacer transferencias permanentes, donde no tiene ese requisito.
> No veo lógico ni bueno para la comunidad que se haga ningún despliegue ni
> siquiera temporal, sin IPv6 a estas alturas de la película.
>
HA: No poner IPv6 es de Neandertal con mis disculpas a los Neandertals,
pero.... puedo entender que se tenga asignación pero no se puede exigir
operación. Al fin y al cabo la curva S de adopción de tecnología los va a
obligar a hacerlo tarde o temprano :-)

>
> 5) Concurro con Arturo, y contesto con ello también a Fernando, que
> financiera, contable y fiscalmente, supongo que es algo universal, una
> transferencia temporal sería equiparable a un alquiler, y por lo tanto
> tiene diferencias importantes. Ejemplo, generalmente una empresa le es mas
> conveniente, aunque tenga cash, alquilar (renting, leasing, etc.), que
> comprar, porque una compra implica que tiene que dividir el valor de la
> compra en amortizaciones de x años mientras que las otras alternativas, es
> un gasto reflejado mensualmente.
>
> 6) No se si RIPE tiene estadísticas, desde luego no las he encontrado
> públicas, de usos maliciosos de las transferencias temporales. Igualmente
> me parece que evitarlo, independientemente de los datos que haya, es
> conveniente. Si queremos esos datos, creo que lo mejor es que los
> moderadores le pidan al staff el análisis de impacto incluyendo esos datos,
> de forma que no sean “de parte".
>
> 7) Hernan (M.). Poner como requisito MANRS es que haya buenas prácticas.
> Como se ha comentado, no es un requisito que tenga que hacer cumplir
> LACNIC, sino el oferente. Aunque cambien los requisitos de MANRS, eso no
> nos afectaría. Si MANRS se suaviza o se hace mas estricto, es porque la
> comunidad lo esta aceptando, y por tanto, implícitamente, lo haría esta
> propuesta. Si lo queremos suavizar podríamos indicar algo como “cumplir con
> buenas prácticas reconocidas por la comunidad como por ejemplo MANRS”.
>
> 8) Uesley, si eliminamos el límite /20, no veo que sea un problema que los
> que pidan transferencias temporales “agoten” los recursos que están
> disponibles para transferencias (definitivas o temporales), ya que es
> razonable suponer que por cuestión de economía de escala, grandes bloques
> necesitados serán mas económicos de un solo oferente que los tenga
> contiguos y no de múltiples oferentes/operaciones. Además, si existen las
> transferencias temporales, el abanico de oferentes se amplia, y de hecho,
> para muchos oferentes, puede ser mas conveniente económicamente ofrecer
> transferencias temporales en lugar de definitivas. Igualmente, cuanto mas
> avancemos en el despliegue de IPv6, los mas grandes necesitan muchisimas
> menos direcciones IPv4 (incluso se convierten en oferentes al menos de
> bloques pequeños - he vivido varios casos de esto). Creo que son cuestiones
> de oferta y demanda, que se ajustan por si solas muy bien en un mercado, y
> mas si hay ambas posibilidades (definitivas y temporales).
>
> Saludos,
> Jordi
>
> @jordipalet
>
>
> > El 14 may 2024, a las 17:03, Hernan Arcidiacono <
> harcidiacono at iplan.com.ar> escribió:
> >
> > 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 <mailto: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 <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 <mailto: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.
> >
>
>
>
> **********************************************
> 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.