[LACNIC/Politicas] Mi contribución a la discusión de la Propuesta LAC-2015-01

Juan Alejo Peirano juan.alejo.peirano at gmail.com
Sun Sep 27 19:34:27 BRT 2015


Estimad at s participantes de la lista,

Al igual que Nicolas, Arturo y Alejandro, estoy a favor de esta propuesta.
En este caso particular, siempre interpreté que las transferencias podían
llevarse a cabo luego de que se llegara a la primer reserva IPv4
establecida, por lo que si esta propuesta deja en claro eso, me parece
correcto incorporarlo al manual.

Saludos a todos!

Juan Alejo Peirano



El 23 de septiembre de 2015, 15:24, Alejandro Guzman <alejog at google.com>
escribió:

> De acuerdo con Nico
>
> No solo es función de LACNIC decir quien debe recibir un bloque IP y quien
> no según las políticas, además requiere que se registre quien realmente
> tiene los recursos para no crear inconsistencias. Igualmente Organizaciones
> grandes, medianas y pequeñas deben tener alternativas para poder obtener
> los recursos que requieren para su operación y con la interpretación que se
> ha hecho eso no se está cumpliendo.
>
> Por lo anterior apoyo la política y espero que el debate y la votación de
> la próxima semana refleje que entendemos las implicaciones de la política y
> se haga con argumentos.
>
> Saludos
>
> Alejandro Guzmán
>
> 2015-09-23 2:11 GMT-07:00 Arturo Servin <arturo.servin at gmail.com>:
>
> > De acuerdo con Nicolas, y en base a la respuesta de Gianina estoy de
> > acuerdo con esta nueva politica ya que mantiene el espiritu de la
> politica
> > original y resuelve las inconsitencias (que personalmente no creo que
> > existan, pero lo importante es resolverlas) que han aparecido.
> >
> > Slds
> > as
> >
> >
> > On Tue, 22 Sep 2015 at 18:10 Nicolas Antoniello <nantoniello at gmail.com>
> > wrote:
> >
> > > Estimados todos,
> > >
> > > Sobre la propuesta de política 2015-01:
> > >
> > > LAC-2015-1: Activar 2.3.2.18 cuando se reciba una solicitud justificada
> > de
> > > más de un /22 que no pueda ser satisfecha mediante una distribución de
> > > cualquiera de las reservas de direcciones de LACNIC.
> > > <
> https://politicas.lacnic.net/politicas/detail/id/LAC-2015-1?language=sp
> > >
> > >
> > > Quería comentar algo que tal vez puede parecer confuso para algunos, al
> > > menos en la forma como estaba planteada la versión discutida en el
> pasado
> > > Foro Público de Políticas.
> > >
> > > Esta política trata sobre una modificación (más que nada en términos de
> > > interpretación) de algo (2.3.2.18) que ya forma parte del Manual de
> > > Políticas <http://www.lacnic.net/web/lacnic/manual>. Básicamente
> plantea
> > > la
> > > eliminación de la NOTA, lo que activaría lo que ya está estipulado en
> el
> > > Manual cuando LACNIC no pueda satisface por cualquier motivo alguna
> > > solicitud de bloques IPv4.
> > >
> > > Que hace entonces esta política?
> > > En definitiva hace exactamente lo que está estipulado en el Manual de
> > > políticas vigente, con la diferencia que cuando LACNIC no pueda cubrir
> > por
> > > cualquier motivo una asignación IPv4 y en caso que se realice una
> > > transferencia INTERNA A REGION de direcciones IPv4, dicha transferencia
> > > quedaría correctamente registrada en los sistemas de LACNIC.
> > >
> > > Creo que es bueno que todos leamos las siguientes políticas que HOY
> están
> > > vigentes (extraído de la última versión del Manual):
> > >
> > > *2.3.2.17. Uniones, adquisiciones o venta entre ISPs o Usuarios
> Finales*
> > >
> > > Las políticas de LACNIC no reconocen la venta o transferencia no
> > autorizada
> > > de espacio de direcciones IPv4 y considerará tales transferencias
> > > inválidas, con excepción de las transferencias que se sujeten a la
> > sección
> > > 2.3.2.18.
> > >
> > > Si un ISP o usuario final cambia de dueño debido a una unión, venta o
> > > adquisición entonces la nueva entidad deberá registrar estos cambios
> ante
> > > LACNIC. Si la compañía cambia de nombre se debe proveer documentación
> > legal
> > > que respalde este cambio de nombre.
> > > Dentro de la información que puede ser solicitada se encuentra:
> > >
> > >    - Una copia del documento legal que respalda las transferencias de
> > >    activos.
> > >    - Un inventario detallado de todos los activos utilizados por el
> > >    solicitante con el cual mantendrá en uso el espacio de direcciones
> > IPv4.
> > >    - Una lista de los clientes de la parte solicitante que usa
> porciones
> > >    del espacio distribuido.
> > >
> > > *2.3.2.18.-Transferencias de bloques IPv4 dentro de la región LACNIC*
> > >
> > > NOTA: Esta sección entrará en vigor cuando LACNIC o alguno de sus NIRs
> > sea
> > > incapaz, por primera vez, de cubrir una distribución o asignación de un
> > > bloque IPv4 por falta de recursos.   <--- ESTA NOTA ES LO QUE SE
> PROPONE
> > > ELIMINAR
> > >
> > >
> > > Se permitirán las transferencias de bloques IPv4 entre LIRs y/o
> usuarios
> > > finales dentro de la región LACNIC, en adelante entidades, bajo las
> > > condiciones mencionadas en la presente sección.
> > >
> > >    - *2.3.2.18.1.- El tamaño mínimo de bloque que se permite transferir
> > es
> > >    un /24.*
> > >    - *2.3.2.18.2.- *Para que una entidad pueda ser el destinatario de
> una
> > >    transferencia, debe pasar primero por el proceso de justificación de
> > >    necesidades de recursos IPv4 ante LACNIC. Es decir, la entidad debe
> > >    justificar ante LACNIC la distribución/asignación inicial/adicional,
> > > según
> > >    sea el caso, de acuerdo a las políticas vigentes.
> > >    - *2.3.2.18.3.- *Ante una solicitud de transferencia de un bloque
> > IPv4,
> > >    LACNIC verificará que la entidad fuente es el titular de dicho
> bloque
> > > según
> > >    conste en los registros de LACNIC. El solicitante aprobado y la
> > entidad
> > > que
> > >    transferiría deberán presentar a LACNIC una copia del documento
> legal
> > > que
> > >    respalde la transferencia.
> > >    - *2.3.2.18.4.- *LACNIC mantendrá una bitácora de transferencias,
> > >    accesible públicamente, de todas las transferencias de bloques IPv4
> > que
> > > se
> > >    registren ante él. En dicha bitácora se registrará la fecha de la
> > >    operación, la entidad fuente de la transferencia, la entidad
> destino y
> > > el
> > >    bloque transferido.
> > >    - *2.3.2.18.5.- *La entidad fuente de la transferencia quedará
> > >    automáticamente inelegible para recibir distribuciones y/o
> > asignaciones
> > > de
> > >    recursos IPv4 por parte de LACNIC durante un año, a partir de la
> fecha
> > > de
> > >    operación registrada en la bitácora de transferencias.
> > >    - *2.3.2.18.6.- *Un bloque previamente transferido no podrá ser
> > >    subsecuentemente transferido durante un periodo de un año, a partir
> de
> > > la
> > >    fecha de operación registrada en la bitácora de transferencias. Lo
> > mismo
> > >    aplica para sus sub-bloques, es decir, bloques que agrupen un
> > > subconjunto
> > >    de las direcciones IPv4 que contiene el bloque.
> > >    - *2.3.2.18.7.- *Una vez concluida la transferencia, LACNIC
> modificará
> > >    la información sobre el recurso transferido para reflejar el cambio
> de
> > >    titular.
> > >    - *2.3.2.18.8.- *La entidad destino deberá cumplir con todas las
> > >    políticas vigentes de LACNIC.
> > >    - *2.3.2.18.9.- *Los bloques y sus sub-bloques, provenientes de
> > >    distribuciones o asignaciones de LACNIC, ya sean iniciales o
> > > adicionales,
> > >    no podrán ser sujetos a transferencias durante un periodo de un año
> a
> > >    partir de su fecha de distribución o asignación.
> > >
> > >
> > >    - *2.3.2.18.10.- *Los recursos legados transferidos dejarán de ser
> > >    considerados como tales.
> > >
> > >
> > > En lo personal creo que uno de los principales mecanismos y recursos
> que
> > > tenemos que defender es el hecho de que los registros de LACNIC
> continúen
> > > siendo vigentes y manteniéndose actualizados.
> > > En tanto existan transferencias dentro de la región (que ya se están
> > > realizando) que no sean registradas correctamente por LACNIC, tendremos
> > una
> > > base de datos de información que no está actualizada y no refleja la
> > > realidad.
> > >
> > > Por todo ello, en este caso yo estoy a favor de esta propuesta ya que
> de
> > > alguna manera colabora con garantizar una parte bastante importante de
> la
> > > correcta operación de LACNIC.
> > >
> > > Fraterno saludo a tod at s,
> > > Nico
> > >
> > > ---
> > > Nicolas Antoniello
> > > Uruguay
> > >
> > >
> > >
> > >
> > >
> > > On Thu, Sep 17, 2015 at 11:35 AM, Gianina Pensky <gianina at lacnic.net>
> > > wrote:
> > >
> > > > Hello Arturo,
> > > >
> > > > I apologize for the delay, but we wanted to give you a complete
> answer.
> > > >
> > > > Some important information:
> > > >
> > > > In 07/2010 it was implemented 2009-04 policy
> > > > (
> > > >
> > >
> >
> http://www2.lacnic.net/documentos/politicas/LAC-2009-04v3-propuesta-sp.pdf
> > > > )
> > > > On a certain moment there came up an inconsistency of interpretation
> > > > about when to activate this policy between LACNIC and each NIR.
> > > > Since then, we have been working to unify criteria.
> > > > We contacted the author´s proposal in order to clarify the original
> > > > intention of his proposal. After talking to the author, he has
> > clarified
> > > > that his intention, which was approved by the community, was to have
> it
> > > > active by now.
> > > > We haven´t succeded to unify criteria with the NIRs yet, that is why
> > the
> > > > policy hasn´t been activated, but we are working on that.
> > > >
> > > > It is important to unify criteria between NIRs, LACNIC and to the
> > > > author´s policy, and that is why we have an important need to clarify
> > > > this issues.
> > > >
> > > > Kind regards,
> > > >
> > > > --
> > > > Ing. Gianina Pensky
> > > > Policy Officer
> > > > LACNIC - http://www.lacnic.net
> > > > Latin American and Caribbean Internet Addresses Registry
> > > >
> > > >
> > > >
> > > > El 15/09/2015 a las 06:00 p.m., Arturo Servin escribió:
> > > > > On Tue, Sep 15, 2015 at 9:04 AM, Mike Burns <mike at iptrading.com>
> > > wrote:
> > > > >
> > > > >> Per my understanding, LACNIC will not allow any transfers between
> > > > members
> > > > >> until full exhaust is reached, which is projected to be in 2024
> > > > according
> > > > >> to
> > > > >> the graph provided by Sergio and posted to the list previously.
> > > > >>
> > > > > I think that is not what I think the policy says.
> > > > >
> > > > > According to my interpretation the transfers should start after we
> > > finish
> > > > > the current phase (per another email probably finishing in October
> > this
> > > > > year.)
> > > > >
> > > > > Could LACNIC staff clarify how they interpret the policy?
> > > > >
> > > > > Regards
> > > > > as
> > > > > _______________________________________________
> > > > > Politicas mailing list
> > > > > Politicas at lacnic.net
> > > > > https://mail.lacnic.net/mailman/listinfo/politicas
> > > >
> > > > _______________________________________________
> > > > Politicas mailing list
> > > > Politicas at lacnic.net
> > > > https://mail.lacnic.net/mailman/listinfo/politicas
> > > >
> > > _______________________________________________
> > > Politicas mailing list
> > > Politicas at lacnic.net
> > > https://mail.lacnic.net/mailman/listinfo/politicas
> > >
> > _______________________________________________
> > Politicas mailing list
> > Politicas at lacnic.net
> > https://mail.lacnic.net/mailman/listinfo/politicas
> >
>
>
>
> --
>
>
> Alejandro Guzman | Director - Content Distribution   | alejog at google.com
> | +1
> (650) 4268561
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>



More information about the Politicas mailing list