[LACNIC/Politicas] Nuevo análisis de impacto - LAC-2020-10 v2: Facultar a receptores de bloques delegados para firmar ROA.

Wed May 11 11:10:18 -03 2022

Hola!

Hago público en la lista mi apoyo a la propuesta, así como hice en el
micrófono. Realmente el problema existe y a depender del tamaño de la
empresa que ofrece el bloque al cliente y con solamente una persona
responsable por firmar los bloques, eso puede tardar demasiado y generar
los problemas que ya conocemos. Entonces, estoy de acuerdo con la propuesta
(con las correcciones presentadas en la diapositiva respecto a la palabra
"cliente").
Respecto a lo que dice Jordi sobre el IPv6, yo creo que estaría bien la
unificación de textos.

Saludos,

Uesley Corrêa - Analista de Telecomunicaciones
CEO Telecom Consultoria, Entrenamiento y Servicios

On Wed, May 11, 2022 at 10:01 AM Hernan Moguilevsky <noc.hernan at gmail.com>
wrote:

> Hola Jordi,
>
> Entendí tu pregunta al micro. Y la respuesta sigue siendo la misma:
> No veo que sea un impedimento para que se apruebe la propuesta la
> omisión del cambio en la sección de IPv6.
> Bien puede presentarse un nuevo texto para modificar ese párrafo, o
> pueden unificarse los textos, como has propuesto.
> Yo me inclino por la unificación de textos (bien hecha).
>
> Saludos
> HM
>
> On 04/05/2022 14:39, JORDI PALET MARTINEZ via Politicas wrote:
> > Aprovecho para explicar lo que dije al respecto de IPv6.
> >
> > Es el penúltimo párrafo de
> > https://mail.lacnic.net/pipermail/politicas/2021-May/006236.html
> >
> > No tiene sentido que en el año 2022, tengamos una propuesta que puede
> repercutir sobre ambos, IPv4 e IPv6 y no resolvamos cono el mismo texto (ni
> siquiera hace falta un texto diferente, salvo la longitud de los prefijos,
> que incluso creo que se podría omitir en ambos casos, pues es un detalle
> operativo). Hay incluso varios RFCs que dicen que no se puede hacer trabajo
> de estandares que solo sea de IPv4 (contexto de IETF). Como ingenieros,
> como comundiad, deberíamos aplicarnos la misma norma a estas alturas.
> >
> > Que sentido tiene presentar/discutir 2 propuestas iguales, una para IPv4
> y otra para IPv6? Que sentido tiene que el staff tenga que hacer una
> implementacion primero para IPv4 y mas adelante para IPv6? Hay tan poca
> diferencia, que creo que el trabajo sería conjunto el mismo y hacerlo por
> separado una carga innecesaria.
> >
> > Ahora, lo que creo que no se entendió de mi pregunta/respuesta en el
> micro. Es cierto que en IPv4 estas asignaciones de clientes conectados son
> mas frecuentes, porque no hay direcciones, porque hay NAT, porque incluso
> hay ISPs que no tienen direcciones de LACNIC y reciben sus direccioenes de
> otros ISPs mas grandes, etc., etc.. Tambien es cierto que en IPv6, NO
> deberíamos repetir estos errores y un cliente que tenga necesidad de IPv6 y
> quiera evitar renumeracion, lo *razonable* dado que no hay NAT (y por tanto
> no puede hacer multihoming), y no hay escasez, es que tenga su propio
> prefijo asignado directamente por LACNIC (como usuario final de LACNIC) y
> no dependa de su proveedor. Pero si alguno lo quiere hacer "mal" de algun
> modo sería "su problema", y nosotros como comunidad tenemos que garantizar
> que tendrá el mismo "trato" para los ROAs de IPv4 y de IPv6.
> >
> > Saludos,
> > Jordi
> > @jordipalet
> >
> >
> >
> > El 4/5/22, 19:54, "Politicas en nombre de Fernando Frediani" <
> politicas-bounces at lacnic.net en nombre de fhfrediani at gmail.com> escribió:
> >
> >      Hola Hernán y todos.
> >
> >      Siguiendo con esta discusión posterior al FPP, pensé un poco más en
> la
> >      parte práctica y de hecho, debido a la limitación operativa de no
> poder
> >      anunciar un bloques menores a /24, si un receptor firma un ROA
> para, por
> >      ejemplo, un bloque /26 este anuncio no llegaría a Internet y por lo
> >      tanto seguiría como mínimo como Unknown.
> >      Por lo tanto, para los usuarios más pequeños que son la mayoría de
> los
> >      receptores debido al tamaño de los bloques menores, no tendrá ningún
> >      efecto práctico.
> >
> >      Por otro lado, las asignaciones de bloques mayores de /24 requieren
> una
> >      atención especial. En teoría, un bloque no debería asignarse de un
> >      titular a otro para que pueda anunciarlo desde su propio ASN *y
> >      utilizarlo exclusivamente para sí mismo como si lo hubiera recibido
> del
> >      RIR*.
> >      El único uso válido que es en cantidad mucho menor es cuando un
> titular
> >      de recursos necesita que otra organización (y otro ASN) anuncie sus
> >      recursos, pero *el uso sigue siendo para el uso exclusivo del
> titular de
> >      los recursos* según lo justificado (por ejemplo, cómo funcionan
> algunos
> >      CDNs, o organizaciones que han optado por no recibir la numeración
> ASN y
> >      necesitan que su proveedor lo haga).
> >
> >      Saludos
> >      Fernando Frediani
> >
> >      On 09/02/2022 15:54, Franco cabrera wrote:
> >      > Estimados miembros de la lista,
> >      >
> >      > Queremos informarles que ya se encuentra disponible el análisis
> de impacto de la siguiente propuesta de política:
> >      >
> >      > LAC-2020-10 v2: Facultar a receptores de bloques delegados para
> firmar ROA.
> >      >
> https://politicas.lacnic.net/politicas/detail/id/LAC-2020-10/language/sp
> >      >
> >      > Saludos cordiales,
> >      >
> >      > Franco Cabrera
> >      >
> >      > Asistente de Políticas
> >      > Policy Assistant
> >      >
> >      > www.lacnic.net
> >      > Latin American and Caribbean Internet Addresses Registry
> >      >
> >      > _______________________________________________
> >      > 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
> >      >
> >      _______________________________________________
> >      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
> >
> >
> >
> >
> > **********************************************
> > 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/options/politicas
> >
>
> _______________________________________________
> 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
>
>