[LACNIC/Politicas] Consulta a la lista
Fernando Frediani
fhfrediani at gmail.com
Thu Aug 14 01:49:21 -03 2025
Tentando entender o que significaria "organizar isso" nesse contexto.
Seria criar novas políticas para tornar legal uma prática que é sabida
irregular, contra as políticas vigentes e que alguns que concordaram em
cumpri-las, assinando previamente um contrato para isso, resolvem
simplesmente descumprir em função de seus próprios interesses ?
A muito tempo sigo acreditando que apesar de ser importante conhecer os
eventuais problemas decorrentes da utilização irregular das alocações de
endereços IPs, não é por essa razão que deveríamos simplesmente jogar a
toalha e passar a criar novas políticas para ter a sensação de que elas
estão sendo cumpridas. Quem tem o dever de se adequar à regras criadas
neste Fórum de Políticas são os detentores de recursos, não ao contrário.
Existem mecanismos de sanção para os que insistem em descumpri-las e é
não só papel mas dever tanto de LACNIC quanto de seus NIRs de aplicá-las
quando houver suficiente evidência do ilícito.
Sabemos quanto isso pode ser complexo e custoso, porém também não é
razoável renunciarmos à essa prerrogativa de sancionar os que optaram
por seguir descumprindo o que foi previamente acordado. E isso nada de
tem a ver com ser "polícia da Internet".
O cumprimento das regras vigentes precisa ser acima de tudo exemplo para
que não exista incentivo ao descumprimento e a certeza da impunidade.
Fernando
On 8/13/2025 12:21 PM, Ricardo Patara via Politicas wrote:
> sem entrar no mérito quanto à prática, penso que o tema necessita
> discussão e por isso felicito o grupo (Hernan, Uesley, Edumundo e
> Douglas)
>
> de forma frequente se comenta que a cessão de bloco ipv4 para
> terceiros ocorre e é difícil controlar
>
> e que portanto melhor organizar isso
>
> em um mundo ideal, os endereços ipv4 excedentes seriam devolvidos e
> reciclados... em um mundo ideal a adoção de ipv6 já estaria próxima
> aos 100%
>
> entendo perfeitamente as opiniões sobre fomentar ainda mais a
> implementação de ipv6
>
> não sei se a escassez de ipv4 é o motivador ideal.
> talvez a solução esteja em outro lugar.
>
> sobre o que foi apresentado nesse email, eu fiquei curioso com essa
> parte:
>
> "Portanto considero muito importante haver um limite no tamanho máximo
> do bloco à ser recebido por um ASN em no máximo um /21 como forma de
> evitar abusos, má utilização desta proposta e que *genuinamente seja
> útil para os pequenos* poderem sair da inércia e se posicionarem no
> mercado."
>
> quais seriam esses "abusos" ou "má utilização"?
>
>
>
> On 12/08/25 16:52, Fernando Frediani wrote:
>> Olá Hernan
>>
>> Antes de tudo agradeço o cuidado de trazer o assunto de maneira bem
>> organizada com o intúito de uma discussão séria na lista.
>>
>> Por outro lado preciso dizer que me sinto um pouco incomodado e
>> frustrado desse assunto seguir retornando da maneira que tem sido e
>> ainda sem ainda um foco em um objeito mais bem definido.
>> As vezes sinto uma frustração de muitos com a situação da escassez de
>> IPv4 que já é algo de anos e não tanto com situações mais específicas
>> como por exemplo os pequenos ISPs - essas última sim que na minha
>> visão que merece uma análise mais *prática e restrita*.
>>
>> Sigo acreditando que para lidar com o problema da escassez - e para
>> não chover no molhado e falar sobre IPv6 mais uma vez - é necessário
>> haver uma melhor aceitação de uma vez que não existe solução sequer
>> razoável ou sequer escalável, (mesmo esta proposta que está sendo
>> discutida aqui) e o melhor a se fazer é aceitar, aprender a lidar e
>> fazer mais com um menor número de endereços IPv4 disponíveis para
>> atender aquela mesma base de clientes, realizar um CGNAT mais bem
>> organizado e outras técnicas existentes.
>>
>> Hoje em dia mesmo com um número reduzido de endereços IPv4 é possível
>> atender uma quantidade bastante razoável de clientes na base. Porém
>> vejo que em certos casos muitos operações desejam seguir utilizando
>> as mesmas técnicas e receitas de sempre e acreditando que ainda
>> precisam de um número bem maior de IPv4 do que realmente precisam e
>> que "não tem outra solução senão alugar".
>>
>> Agora falando da proposta para poder discuti-la é necessário partir
>> de algumas premissas. Cito abaixo as principais que levo em conta:
>>
>> - Qualquer proposta nesse sentido não pode dar margem para o conceito
>> de aluguel. Se houver dúvida então é melhor não fazer.
>> - Se a proposta é *realmente para ajudar os pequenos operadores de
>> rede* então as condições *necessitam ser restritas* para que sejam
>> úteis apenas para esses operadores e não possam ser utilizadas de
>> outras maneiras por quem não necessite delas.
>> - A maneira certa de fazer é transferir blocos IPv4 de maneira
>> definitiva que é o que as políticas já preveem à algum tempo.
>> - É irrelevante se quem necessita o bloco possui ou não recursos
>> financeiros para adquirir no mercado. Não vejo como razoável que se
>> ajuste ou crie extras para acomodar problemas de fluxo de caixa das
>> empresas em detrimento ao conceito principal sobre uso e alocação dos
>> endereços IPs.
>> - Quaisquer recursos sendo utilizados por qualquer ASN/organização
>> que seja precisam ter justificativa de uso. É e segue sendo a base
>> para qualquer atribuição de endereços IP, independente de quem para
>> quem, então segue fazendo sentido que qualquer um recebendo endereços
>> IP, mesmo que temporariamente, tem o dever de comprovar que necessita
>> deles para atender clientes ou infraestrutura própria.
>>
>> Com relação aos 9 pontos colocados seguem alguns comentários abaixo:
>>
>> 2 - Se os recursos de numeração estão registrados em um ASN do LACNIC
>> é razoável que ele siga sendo utilizado também por outro ASN do
>> LACNIC e não de fora da região. Assim garanta-se que os recursos
>> sigam sendo utilizados dentro da região que é um requisito atual da
>> políticas. Não vejo muito dúvida com relação à esse ponto.
>>
>> 3 - Este para mim é talvez o *ponto mais importante de todos*. Embora
>> alguns tenham se manifestado no sentido de não ter limite, esse é o
>> maior equívoco nessa tentativa de encontrar uma solução para atender
>> os pequenos.
>> Acredito que é importante ser coerente nesse ponto e não vejo como
>> esta proposta pode seguir adiante sem esse limite.
>> Se é tão somente para atender a necessidade inicial dos pequenos - e
>> nisso considero novos ASN sem nenhum IPv4 ou aqueles que possuem
>> apenas até 1 x /22.
>> Qualquer outro além disso considero que já possui uma base de
>> clientes ativos e faturamento suficiente para se organizar
>> financeiramente a transferir em definitivo blocos adicionais
>> necessários para expansão de sua operação.
>> Portanto considero muito importante haver um limite no tamanho máximo
>> do bloco à ser recebido por um ASN em no máximo um /21 como forma de
>> evitar abusos, má utilização desta proposta e que *genuinamente seja
>> útil para os pequenos* poderem sair da inércia e se posicionarem no
>> mercado.
>>
>> 4 - Sem dúvida a justificativa é a base para qualquer uso de IPs por
>> qualquer organização que seja. Não se pode pensar na possibilidade de
>> alocar IPs, mesmo que temporariamente e não exigir uma justificativa
>> mínima da necessidade de uso. Se quem recebe tem necessidade não terá
>> muita dificuldade em justificá-la. Não se deveria sequer chamar isso
>> de "burocracia ou dificuldade", mas algo bastante razoável para
>> seguir o que sempre foi o óbvio. Remover isso é abrir outra porta
>> para abusos.
>>
>> 6 - De acordo, faz todo o sentido. Aquela organização cedente deverá
>> arcar com a responsabilidade daquela relação perante LACNIC
>> independente dos acordos que possua com o cliente final.
>> Os recursos foram entregues à esta organização e justificados por ela
>> portanto ela segue sendo a principal responsável.
>>
>> 7 - De acordo. Blocos recebidos diretamente de LACNIC provenientes de
>> recursos recuperados e portanto por ASNs que estejam na lista de
>> espera não faz nem sentido que possam ser realocados para outro ASN
>> em um tempo curto.
>>
>> 8 - Creio que não se deveria envolver recursos legados nesta
>> discussão. É sempre um tema mais complexo e que por ora deve seguir
>> sendo como é até aqui. Se alguém deseja transferi-los esses recursos
>> deixam de ter o status de legado.
>> Permitir que sejam "sub-alocados" é abrir uma porta para especulação
>> granular desses recursos que em geral são em maior quantidade e
>> agregados.
>>
>> Fernando Frediani
>>
>>
>> On 8/11/2025 1:34 PM, Hernan Arcidiacono wrote:
>>> Gracias a todos por ir aportando. Me gustaría listar sobre qué
>>> puntos sería
>>> bueno escuchar posiciones de más gente de la comunidad fuera de la
>>> que ya
>>> ha opinado y a quienes nuevamente les agradecemos.
>>>
>>> No detallaré nuestro argumento a cada punto ya que los mismos están
>>> en la
>>> cadena.
>>>
>>> 1- Exigencia ASN LACNIC
>>> 2- Autorregulación del tamaño máximo del bloque.
>>> 3- Periodo de 3 o 5 años para mecanismo anti especulación.
>>> 4- Justificación liviana.
>>>
>>> Desde ya muchas gracias.
>>>
>>> Hernan Arcidiacono
>>>
>>> CTIO
>>>
>>> +549 11 5025 5106
>>>
>>>
>>>
>>>
>>> On Sun, Aug 10, 2025 at 12:39 PM Lic. Cesar E. Labrador C. <
>>> cesarlabradorcastro01 at gmail.com> wrote:
>>>
>>>> Buen día a todos;
>>>>
>>>> Por mi parte estoy muy de acuerdo con los puntos iniciales que
>>>> indicaste
>>>> Hernán al iniciar la discusión de la posible propuesta de este tema
>>>> tan
>>>> importante, ya que para mi el punto mas critico es resolver como
>>>> los ISP
>>>> Pequeños y Medianos en la region puedan atender sus requerimientos de
>>>> servicios, interconexión y crecimiento..
>>>>
>>>> Entrando en detalles mis comentarios sobre los siguientes puntos
>>>> propuestos:
>>>>
>>>> 3. Tamaño del Bloque: De acuerdo con el punto de no sea necesario
>>>> establecer un tamaño máximo de Bloques.
>>>>
>>>> 7. Mecanismos Anti-especulación: Mi comentario sobre este punto es que
>>>> me parece mas apropiado un tiempo de 03 Años.
>>>>
>>>> Sobre los otros puntos expuestos me parecen que están muy bien
>>>> planteados y de acuerdo con lo indicado en los argumentos.
>>>>
>>>> Un Abrazo para todos y saludos cordiales..
>>>>
>>>> El 8/8/2025 a las 1:46 p. m., Hernan Arcidiacono escribió:
>>>>> Buenas tardes a todos. En primer lugar gracias por sus
>>>>> comentarios. Voy a
>>>>> tratar de responder a los salientes a título personal, a riesgo de
>>>> exponer
>>>>> algo distinto de alguno de mis compañeros con que consensuamos las
>>>>> ideas
>>>>> originales.
>>>>>
>>>>> Sólo como información de contexto de cómo hemos pensado lo expuesto,
>>>>> resalto:
>>>>>
>>>>> - Entendemos que tenemos una realidad que no permite los esquemas de
>>>>> alquileres pero que en la realidad ocurre.
>>>>> - Vimos la dificultad de abarcar todas las alternativas.
>>>>> - Nos concentramos en pensar en los pequeños ISPs de nuestra región.
>>>>> - Adoptamos ser conservadores para no descubrir, post implementación
>>>>> (asumiendo tener en algún momento un proceso exitoso), situaciones no
>>>>> previstas.
>>>>> - En los casos contemplados decidimos que la barrera de entrada
>>>>> sea baja
>>>>> para que genere adopción, dado que si no ocurre habremos invertido
>>>>> tiempo
>>>>> en escribir algo que no se use.
>>>>>
>>>>> Detallo ahora:
>>>>>
>>>>> 1- *ASN LACNIC.* Responde al mecanismo conservador explicado, al
>>>> propósito
>>>>> de atender la necesidad de los ISPs pequeños de la región y no
>>>>> contempla
>>>>> que se malentienda que pudiéramos buscar alentar que desde nuestra
>>>>> región
>>>>> se alquilen direcciones a ASNs de otros RIRs. Fue nuestra mejor
>>>>> elección
>>>>> para cubrir lo expuesto.
>>>>>
>>>>> 2- *Tema CGNAT e IPv6*. Entendemos el espíritu del comentario. No lo
>>>> hemos
>>>>> contemplado porque buscamos barreras bajas de entrada para
>>>>> aquellos que
>>>>> quieran estar en regla. También vemos difícil de controlar en la
>>>> práctica.
>>>>> 3- *Plazo 3 o 5 años.* Es válido el comentario. No lo discutimos,
>>>>> pero
>>>> los
>>>>> 5 años podrían ser 3. Lo importante es que coincidimos con el
>>>>> espíritu de
>>>>> evitar transferencias que lleven a un mecanismo especulativo.
>>>>>
>>>>> 4- *Tamaño máximo*. Soy testigo de que el tema se ha conversado en el
>>>> foro.
>>>>> Sin embargo decidimos proponer sacarlo ya que el riesgo que vemos que
>>>>> genere perjuicio es bajo. Claramente es discutible (lo discutimos
>>>> bastante
>>>>> de hecho), y la postura fue la de simplificar. Sabemos que puede
>>>>> ser un
>>>>> tema a reconsiderar si hiciera falta, aunque por el momento
>>>>> creemos que
>>>> no
>>>>> es necesario.
>>>>>
>>>>> 5- *Justificación:* Creemos que se necesita una justificación,
>>>>> pero no
>>>> las
>>>>> justificación full. La solución de compromiso fue proponer la de
>>>>> usuario
>>>>> final. Creo que el tema puede revisarse siempre que no genere
>>>>> barreras de
>>>>> adopción mas altas, entendiedo que lo que llamamos adopción en
>>>>> realidad
>>>>> debería tener una etapa inical mejor llamada de "blanqueo" a lo
>>>>> que hoy
>>>>> existe en "negro".
>>>>>
>>>>> Gracias de nuevo.
>>>>>
>>>>> Slds.
>>>>>
>>>>>
>>>>>
>>>>> Hernan Arcidiacono
>>>>>
>>>>> CTIO
>>>>>
>>>>> +549 11 5025 5106
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Fri, Aug 8, 2025 at 1:55 PM Henri Alves de Godoy <
>>>>> henri.godoy at fca.unicamp.br> wrote:
>>>>>
>>>>>> Entendo o sufocamento que os pequenos provedores enfrentam pela
>>>>>> falta de
>>>>>> endereços IPv4 e todos nós sabemos qual seria a melhor solução.
>>>>>> Porém,
>>>> sou
>>>>>> *contrário* a qualquer tentativa de legalizar o aluguel na nossa
>>>>>> região,
>>>>>> seja sob o argumento de rastreio da operação ou para evitar
>>>> especulações,
>>>>>> sem que haja, no* mínimo*, um compromisso claro de fomento à
>>>>>> transição
>>>> para
>>>>>> IPv6 por parte de quem recebe a alocação.
>>>>>>
>>>>>> A minha sugestão para discussão é evitar a normalização do CGNAT
>>>>>> como
>>>>>> solução permanente e, ao mesmo tempo, manter a coerência com os
>>>> princípios
>>>>>> defendidos pelo LACNIC em relação à transição para o IPv6,
>>>>>> estimulando a
>>>>>> sua adoção.
>>>>>>
>>>>>> Assim, temos o direcionamento do IPv4 remanescente para sua
>>>>>> função mais
>>>>>> estratégica neste momento, demonstrando o recebimento para uso nos
>>>>>> mecanismos de transição e serviços e aplicações legadas mais
>>>>>> urgentes.
>>>> Tudo
>>>>>> isso pode ser facilmente demonstrado e justificado.
>>>>>>
>>>>>> Obrigado
>>>>>>
>>>>>> Henri.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Em sex., 8 de ago. de 2025 às 12:21, Basilio Perez <
>>>> brperez at carrier.com.br
>>>>>> escreveu:
>>>>>>
>>>>>>> Discordo, não vejo necessidade desse tipo de restrição na
>>>>>>> justificativa
>>>>>>> de uso.
>>>>>>>
>>>>>>> O motivo de aceitarmos que exista essa política é para não
>>>>>>> tentar mais
>>>>>>> tapar o sol com a peneira.
>>>>>>>
>>>>>>> Criar restrições desse tipo, vai manter a situação atual.
>>>>>>>
>>>>>>> Basilio R Perez
>>>>>>>
>>>>>>> Em 07/08/2025 20:40, Henri Alves de Godoy escreveu:
>>>>>>>> Hola Hernan e a todos
>>>>>>>>
>>>>>>>> Eu adicionaria no item 4 - Justificativa de Uso
>>>>>>>>
>>>>>>>> 4.1 - A justificação de uso apresentada pela organização que
>>>>>>>> recebe a
>>>>>>>> sublocação *deverá comprovar* que os recursos IPv4 serão
>>>>>>>> utilizados
>>>>>>>> exclusivamente como parte de mecanismos de transição para IPv6
>>>>>>> reconhecidos.
>>>>>>>> 4.2 - A organização deverá apresentar documentação mínima do
>>>>>>>> projeto
>>>>>> ou
>>>>>>>> plano de implementação do mecanismo de transição. Não será
>>>>>>>> permitido o
>>>>>>> uso
>>>>>>>> da sublocação para expansão de infraestruturas baseadas
>>>>>>>> exclusivamente
>>>>>> em
>>>>>>>> CGNAT de longa duração, sem estratégia de transição.
>>>>>>>>
>>>>>>>> Abraços !
>>>>>>>> Henri.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Em qua., 6 de ago. de 2025 às 19:38, Hernan Arcidiacono <
>>>>>>>> harcidiacono at iplan.com.ar> escreveu:
>>>>>>>>
>>>>>>>>> Hola a todos,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sobre el final del LACNIC 43, un grupo de miembros de la
>>>>>>>>> comunidad
>>>>>> hemos
>>>>>>>>> estado conversando sobre cómo abordar el tema del "alquiler" de
>>>>>>> direcciones
>>>>>>>>> IPv4.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Si bien *no estamos a favor del concepto de alquiler*, creemos
>>>>>>>>> que la
>>>>>>>>> situación actual es como querer tapar el sol con la mano. No
>>>>>>>>> podemos
>>>>>>>>> ignorar los inconvenientes que el modelo presente nos acarrea, y
>>>>>> estamos
>>>>>>>>> convencidos de que abordar este tema ayudará a que los
>>>>>>>>> operadores más
>>>>>>>>> pequeños tengan un mecanismo adecuado ante el agotamiento de
>>>>>>>>> IPv4.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Sabemos que esto no cubrirá la totalidad de los casos, pero
>>>>>>>>> permitirá
>>>>>> a
>>>>>>>>> aquellos que quieren actuar responsablemente, subirse a un
>>>>>>>>> esquema
>>>>>>> aceptado
>>>>>>>>> en el marco de nuestras políticas. También creemos que el camino
>>>>>>> iniciado
>>>>>>>>> con las transferencias temporales ha sido de gran utilidad, pero
>>>>>>> requiere
>>>>>>>>> darle un giro.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> La idea es encontrar una forma que sea transparente, que se pueda
>>>>>>> rastrear
>>>>>>>>> y que mantenga la responsabilidad de todos, cumpliendo las
>>>>>>>>> reglas.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> *Por eso, queremos compartir estos lineamientos iniciales para
>>>>>>>>> que
>>>> los
>>>>>>>>> discutamos abiertamente en la lista. Si hay consenso, podemos
>>>>>>> convertirlo
>>>>>>>>> en una propuesta formal.*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Lineamientos para la Discusión
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1. Ámbito de Aplicación: La política aplicará exclusivamente a la
>>>>>>>>> sub-asignación de recursos IPv4.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 2. Requisito del Receptor: La organización que reciba los
>>>>>>>>> recursos en
>>>>>>>>> sub-asignación deberá contar con un Número de Sistema Autónomo
>>>>>>>>> (ASN)
>>>>>>>>> asignado por LACNIC.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 3. Tamaño del Bloque: El tamaño mínimo para una sub-asignación
>>>>>>>>> será
>>>> de
>>>>>>> un
>>>>>>>>> /24. No vemos necesario establecer un tamaño máximo, ya que el
>>>>>>>>> propio
>>>>>>>>> receptor buscará mecanismos más eficientes y seguros cuando su
>>>>>>> necesidad de
>>>>>>>>> recursos crezca (los riesgos de mal uso se cubren de otra
>>>>>>>>> manera, ver
>>>>>>> punto
>>>>>>>>> 6)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 4. Justificación de Uso: LACNIC requerirá a la organización
>>>>>> solicitante
>>>>>>> una
>>>>>>>>> justificación del uso de los recursos, análoga a la que se
>>>>>>>>> solicita a
>>>>>>> los
>>>>>>>>> usuarios finales.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 5. Transparencia y Trazabilidad:
>>>>>>>>>
>>>>>>>>> - Identificación en WHOIS: Cada sub-asignación deberá ser
>>>>>> claramente
>>>>>>>>> identificada en la base de datos WHOIS de LACNIC,
>>>>>>>>> asociando el
>>>>>>> bloque de
>>>>>>>>> direcciones con el ASN del receptor.
>>>>>>>>> - Bitácora Pública de Movimientos: Se creará y mantendrá
>>>>>>>>> una
>>>>>>> bitácora
>>>>>>>>> pública para dar trazabilidad a los eventos de inicio y
>>>>>>>>> fin de
>>>>>> cada
>>>>>>>>> sub-asignación. Deberá incluir, como mínimo: el bloque de
>>>>>>> direcciones,
>>>>>>>>> el
>>>>>>>>> ASN del receptor y la fecha del evento.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 6. Responsabilidad sobre los Recursos: La responsabilidad
>>>>>>>>> final sobre
>>>>>> el
>>>>>>>>> uso y el enrutamiento de las direcciones IP recaerá siempre en la
>>>>>>>>> organización miembro de LACNIC que realiza la sub-asignación.
>>>>>>>>> El mal
>>>>>>> uso de
>>>>>>>>> los recursos es responsabilidad de quien tiene la relación con
>>>>>> LACNIC, y
>>>>>>>>> deberá ser esta organización quien termine la sub-asignación
>>>>>>>>> si se
>>>>>>> produce
>>>>>>>>> un mal uso. De no hacerlo, será susceptible de la revocación
>>>>>>>>> de sus
>>>>>>>>> recursos. *(Pregunta a la comunidad: ¿Consideran necesario
>>>>>>>>> hacer este
>>>>>>> punto
>>>>>>>>> explícito en la política, aunque ya esté implícito en el
>>>>>>>>> acuerdo de
>>>>>>>>> servicios?)*
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 7. Mecanismos Anti-especulación: Para proteger el espíritu de la
>>>>>>> política y
>>>>>>>>> evitar la creación de organizaciones cuyo único fin sea la
>>>>>>> intermediación,
>>>>>>>>> proponemos que los bloques IPv4 que una organización reciba
>>>>>>>>> por una
>>>>>>> nueva
>>>>>>>>> transferencia o por asignación desde el pool de recuperados no
>>>>>>>>> podrán
>>>>>>>>> entrar en este tipo de subdelegación por un periodo de cinco (5)
>>>>>> años.
>>>>>>>>>
>>>>>>>>> 8. Recursos Legados: Las organizaciones con recursos IPv4
>>>>>>>>> legados que
>>>>>>>>> deseen usar este esquema deberán firmar previamente el acuerdo de
>>>>>>> servicios
>>>>>>>>> vigente con LACNIC. Aquí no estamos seguros de incluirlo en esta
>>>>>>> propuesta
>>>>>>>>> o no. Nos gustaría también recibir comentarios al respecto.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 9. Modificación del Manual de Políticas: El Manual de Políticas
>>>> deberá
>>>>>>> ser
>>>>>>>>> modificado para permitir explícitamente la sub-delegación de
>>>>>>>>> recursos
>>>>>> a
>>>>>>> un
>>>>>>>>> tercero sin que la organización cedente deba proveerle una
>>>>>>> infraestructura
>>>>>>>>> de servicio asociada.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Desde ya, vamos a estar agradecidos en recibir feedback.
>>>>>>>>> Sabemos que
>>>>>> es
>>>>>>> un
>>>>>>>>> tema complejo, que puede tener posiciones disímiles, pero que sin
>>>> duda
>>>>>>>>> tenemos que tener el coraje de resolverlo.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Gracias de antemano
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Uesley, Edmundo y Hernan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Hernan Arcidiacono
>>>>>>>>>
>>>>>>>>> CTIO
>>>>>>>>>
>>>>>>>>> +549 11 5025 5106
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> *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/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.
>>>>>>
>>>>>>
>>>> --
>>>> Lic. Cesar E. Labrador C.
>>>> _______________________________________________
>>>> 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/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.
>
More information about the Politicas
mailing list