[LACNIC/Politicas] Consulta a la lista
Basilio Perez
brperez at carrier.com.br
Tue Aug 12 17:08:17 -03 2025
Apesar de eu ter opinado por não existir limite no tamanho do bloco, não
é um ponto que considero "escrito em pedra", se para que essa proposta
possa caminhar for necessário estabelecer um tamanho máximo, creio que
esse é o menor dos problemas e um /21 pode ser um bom parâmetro a ser
utilizado, tal como sugerido pelo Fernando.
Basilio R Perez
Em 12/08/2025 16:52, Fernando Frediani escreveu:
> 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.
>
More information about the Politicas
mailing list