[LACNIC/Politicas] Algunas respuestas a los comentarios en el foro de LACNIC 38 sobre la propuesta "LAC-2022-3 - Manejo de Recursos Recuperados con origen en la Reserva para Infraestructura Crítica.

Wed Oct 19 09:30:56 -03 2022

Hola a todos!

Con las aclaraciones arriba, estoy de acuerdo con la propuesta.

Saludos,

Uesley Corrêa - Analista de Telecomunicações
CEO Telecom Consultoria, Entrenamiento y Servicios
CEO Telecom Fiber Solutions

On Tue, Oct 18, 2022 at 7:42 PM Fernando Frediani <fhfrediani at gmail.com>
wrote:

> Hola Sergio
> Gracias por la aclaración. No leo 7.5 tan claro así, pero como dije en
> el mensaje anterior, no veo problema en aclarar esto en el manual de
> políticas, ni que traiga ningún problema con el cambio propuesto. De
> acuerdo.
> Fernando
>
> On 18/10/2022 16:21, Sergio Rojas. . . wrote:
> > Hola Fernando,
> >
> > Solo para corregir tu interpretación respecto a esta punto y aclarar
> > al resto de los suscriptores.
> >
> > No es una cuestión lógica, el manual de políticas es bastante claro
> > sobre qué hacer con los recursos recuperados y devueltos. El punto 7.5
> > dice claramente que los bloques IPv4 devueltos y recuperados irán al
> > pool en vigor. Recuerden que el pool en vigor en la que nos
> > encontramos en este momento corresponde a la fase 3 del periodo de
> > agotamiento, y los lineamientos aplicables a la fase 3 se encuentran
> > descriptor en el punto 11.1, donde dice claramente como está
> > constituido este pool:
> >
> > */11.1.Reserva especial de distribuciones/asignaciones IPv4 para
> > nuevos miembros./**/
> > /**/1. LACNIC creará una reserva de direccionamiento IPv4 utilizando
> > el espacio distribuido por la IANA a LACNIC post agotamiento,
> > considerando además del espacio recuperado y devuelto mencionado en la
> > sección 7 del manual de políticas./*/
> > /
> >
> > En conclusión y de acuerdo a lo que establece el Manual de Políticas,
> > todo el espacio devuelto o recuperado sin importar como y a quien haya
> > sido asignado deberá volver a pool normal.
> >
> > Saludos,
> >
> > Sergio. . .
> >
> >
> > El 18/10/22 a las 14:52, Fernando Frediani escribió:
> >> Colegas, es una cuestión de lógica: si tenemos pools para diferentes
> >> propósitos, cualquier dirección que se origine en ellos cuando ya no
> >> se necesite debe volver a los mismos pools de los que se originaron.
> >>
> >> Véase como ejemplo el ítem 7.5 del manual de políticas, que no es
> >> explícito pero habilita lo que hoy se hace con la waiting list y, en
> >> consecuencia, se puede aplicar de la misma forma al pool de
> >> infraestructura crítica.
> >>
> >> Saludos
> >> Fernando
> >>
> >> On 18/10/2022 14:37, Ricardo Patara via Politicas wrote:
> >>> +1
> >>>
> >>> On 18/10/22 14:36, Hernan Moguilevsky wrote:
> >>>>   Hola Todos,
> >>>>
> >>>> Yo no interpreto 2.3.5.6 como que se devuelva al pool original. Me
> >>>> parece
> >>>> muy válida la propuesta para dejarlo claramente especificado.
> >>>>
> >>>> Coincido con que la definición de infraestructura crítica no está
> >>>> en el
> >>>> alcance de esta propuesta.
> >>>>
> >>>> Ratifico mi apoyo a la propuesta.
> >>>>
> >>>> Saludos
> >>>> HM
> >>>>
> >>>> On 17/10/2022 23:42, Fernando Frediani wrote:
> >>>>
> >>>> Hola Edmundo
> >>>> Mis comentarios sobre esta propuesta y sus aclaraciones.
> >>>>
> >>>> En primer lugar quiero decir que siempre he apoyado plenamente la
> >>>> existencia de una reserva de infraestructura crítica para los fines
> >>>> establecidos y también que siempre debemos tener cuidado de
> >>>> preservarla tal
> >>>> como está.
> >>>>
> >>>> A mi entender, cualquier bloque proveniente del pool reservado para
> >>>> infraestructuras críticas ya se entiende como un uso exclusivo y en
> >>>> caso de
> >>>> que ya no sea necesario para ese fin para el que inicialmente se
> >>>> justificó,
> >>>> automáticamente regresaría al pool de donde se originó, sin
> >>>> necesidad de
> >>>> ningún cambio en las políticas para regular esto. Así lo entiendo
> >>>> leyendo
> >>>> el punto 2.3.5.6 del manual de políticas.
> >>>> En cuanto al punto 2.3.5.8 propuesto, no menciona el tiempo de la
> >>>> cuarentena y tal vez sea bueno especificar eso.
> >>>>
> >>>> Cuando lo leí por primera vez lo consideré innecesario porque
> >>>> 2.3.5.6 ya
> >>>> estipula la exclusividad en el uso de estos recursos. Sin embargo,
> >>>> no creo
> >>>> que el texto propuesto plantee ningún problema o riesgo para el
> >>>> grupo de
> >>>> infraestructura crítica.
> >>>>
> >>>> Finalmente, estoy de acuerdo con todos los puntos que mencionaste
> >>>> que están
> >>>> fuera del alcance propuesto por esta propuesta. A menudo hay
> >>>> cuestiones y
> >>>> objeciones que no tienen nada que ver con la intención de la
> >>>> propuesta y
> >>>> termina pasando mucho.
> >>>>
> >>>> Saludos
> >>>> Fernando Frediani
> >>>>
> >>>> On 11/10/2022 02:49, Edmundo Cazarez Lopez wrote:
> >>>>
> >>>> Hola,
> >>>>
> >>>> Espero que se encuentren bien.
> >>>>
> >>>> Muchas gracias a todos por sus opiniones durante la presentación de la
> >>>> propuesta LAC-2022-3 en el foro de políticas de LACNIC 38.
> >>>>
> >>>> Quiero tratar de aclarar algunos puntos que me parece dejé sin
> >>>> contestar:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>     *   ¿Qué es la "Infraestructura Crítica"? ¿Por qué la propuesta
> >>>> no hace
> >>>> referencia a cuál infraestructura crítica ayuda?
> >>>>
> >>>>
> >>>> La definición de "Infraestructura Crítica" que se usa en la
> >>>> definición del
> >>>> uso de la reserva, y en otras partes del manual de políticas, se
> >>>> encuentra
> >>>> en el punto 2.3.3.2. El segundo párrafo dice:
> >>>>
> >>>> "
> >>>> LACNIC podrá realizar este tipo de asignación en casos de proyectos e
> >>>> infraestructuras de redes claves o críticas para la región como son
> >>>> IXP
> >>>> (Internet Exchange Point), NAP (Network Access Point), RIR, ccTLD
> >>>> entre
> >>>> otros.
> >>>> "
> >>>> (énfasis agregado por mi)
> >>>>
> >>>> Quiero resaltar que la reserva no es solo para IXPs.
> >>>>
> >>>> La definición incluye a otros elementos de la red además de los
> >>>> puntos de
> >>>> intercambio de tráfico, como son los que puedan ayudar a los ccTLDs
> >>>> de la
> >>>> región (servidores de DNS), mismos que tienen funciones distintas a
> >>>> las de
> >>>> un IXP, y que por tanto no se ven beneficiados de las técnicas
> >>>> mencionadas
> >>>> durante la presentación en el foro, en que indicaron pueden servir
> >>>> a los
> >>>> IXP para no utilizar IPv4.
> >>>>
> >>>> No es parte del alcance de esta propuesta modificar la definición
> >>>> actual de
> >>>> "Infraestructura Crítica".
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>     *   ¿Qué ocurre con las direcciones de la infraestructura que
> >>>> se creo
> >>>> antes que la reserva o que no usó direcciones de la reserva?
> >>>>
> >>>> El objetivo de esta propuesta es manejar los recursos que hayan
> >>>> salido de
> >>>> la reserva y que sean recuperados o devueltos, por lo que las
> >>>> direcciones
> >>>> que no salieron de la reserva y fueron usadas en infraestructura
> >>>> crítica, y
> >>>> sean recuperadas o devueltas, deben ir al pool de recursos
> >>>> recuperados o
> >>>> devueltos, con el manejo común de tales recursos.
> >>>>
> >>>> Esta propuesta busca que la "vida" de la reserva se extienda lo más
> >>>> posible, no busca que la reserva "crezca" con otros recursos.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>     *   "Permitir el uso de las direcciones asignadas a un IXP para
> >>>> dar
> >>>> acceso a sus miembros"
> >>>>
> >>>> Ese es un tema que queda fuera del alcance de esta propuesta, y que me
> >>>> parece que requeriría de una propuesta por si mismo para ser
> >>>> analizado y
> >>>> estudiado.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>     *   "Esta propuesta hace que sea más lenta la adopción de IPv6"
> >>>>
> >>>> Me parece que el tema de la adopción de IPv6 ya se ha visto no es
> >>>> en blanco
> >>>> y negro, en muchos casos no es que podamos apagar IPv4 y prender
> >>>> IPv6. IPv4
> >>>> e IPv6 coexistirán por algún tiempo, y durante ese tiempo será
> >>>> necesario
> >>>> contar con la infraestructura crítica con soporte en ambos
> >>>> protocolos, por
> >>>> lo que considero que la reserva es importante y útil y puede serlo
> >>>> aún más
> >>>> en el futuro.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>     *   "Utilizar ROAs para evitar a quienes finjan ser un IXP para
> >>>> tener
> >>>> acceso a los recursos"
> >>>>
> >>>> Me parece que es una idea interesante, pero queda fuera del alcance
> >>>> de esta
> >>>> propuesta el modificar los criterios y condiciones de asignación del
> >>>> espacio de direcciones de la reserva.
> >>>>
> >>>>
> >>>> Espero estar dando claridad a las dudas que se presentaron sobre la
> >>>> propuesta.
> >>>>
> >>>>
> >>>> Saludos.
> >>>> --Edmundo.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> 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.
> >>>> Instituto Tecnológico y de Estudios Superiores De Monterrey,
> >>>> ubicado en
> >>>> Ave. Eugenio Garza Sada 2501 Sur Col. Tecnológico, Monterrey,
> >>>> México, C.P.
> >>>> 64849 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
> >>>> <https://tec.mx/es/avisos-de-privacidad>
> >>>> <https://tec.mx/es/avisos-de-privacidad>.
> >>>>
> >>>>
> >>>> 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. Instituto
> >>>> Tecnológico y de
> >>>> Estudios Superiores De Monterrey, located on Av. Eugenio Garza Sada
> >>>> 2501
> >>>> Sur, Col. Tecnológico, Monterrey, Mexico, CP 64849 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
> >>>> <https://tec.mx/es/avisos-de-privacidad>
> >>>> <https://tec.mx/es/avisos-de-privacidad>.
> >>>> _______________________________________________
> >>>> 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
> >>>>
> >>>>
> >>> _______________________________________________
> >>> 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
> >>
> > _______________________________________________
> > 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
>
>