[LACNIC/Politicas] (no subject)

Ramos ramos at enet.cu
Thu Jul 21 14:47:18 BRT 2005 

Enrique:

Saludos.
Por la experiencia de ustedes tu propuesta seria poner solo publico el nombre de la entidad a la cual se delego el bloque y todo el resto de la información seria referido al ISP..

ejemplo:
 Copyright LACNIC lacnic.net
%  The data below is provided for information purposes
%  and to assist persons in obtaining information about or
%  related to AS and IP numbers registrations
%  By submitting a whois query, you agree to use this data
%  only for lawful purposes.
%  2005-07-21 14:34:02 (BRT -03:00)

inetnum:     200.55.129.0/25
status:      reallocated
owner:       Servicios Empresariales
ownerid:     CU-SEEM-LACNIC
responsible: ISP
address:    Direccion del ISP. 
address:     10600 - Ciudad de la Habana - 
country:     CU
phone:       +53 7 Phone del ISP []
owner-c:     DAR
tech-c:      DAR
created:     20040420
changed:     20040420
inetnum-up:  200.55.128/19

nic-hdl:     DAR
person:      Daniel Ramos
e-mail:      infocom at ENET.CU
address:     Ave Independencia y 19 de Mayo, 0, 
address:     10600 - La Habana - 
country:     CU
phone:       +53 7 337337 []
created:     20021011
changed:     20021209

% whois.lacnic.net accepts only direct match queries.
% Types of queries are: POCs, ownerid, CIDR blocks, IP
% and AS numbers.

Sustituyendo los datos del cliente por el del ISP.

Seria bueno ver otras criterios....

Daniel Ramos



----- Original Message ----- 
From: "Enrique Torres" <eta at millicomperu.com.pe>
To: <politicas at lacnic.net>
Sent: Thursday, July 21, 2005 12:26 PM
Subject: Re: [LACNIC/Politicas] [LAC-TF] Fwd:I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt


> El Jue 21 Jul 2005 10:29, Enrique Torres Angeles escribió:
>> Hola Todos
>>
>> Les cuento un poco la experiencia que tuvimos aqui en Peru al respecto de
>> la confidencialidad de los datos cuando hace unos años comenzamos a
>> implementar el WHOIS y zonas WHOIS delegadas para alimentar los registros
>> de ARIN.
>>
>> Con respecto a la declaracion de los datos completos en el WHOIS la
>> problematica que se dio fue la siguiente:
>>
>> 1- Utilizacion de la base de datos whois por otros operadores de
>> telecomunicaciones para atacar la base de clientes internet de la
>> competencia
>>
>> 2- Utilizacion de las bases de datos whois para crear bases de datos de
>> publicidad o telemercadeo
>>
>> 3- Utilizacion en contadas oportunidades para fraudes basandose en la
>> informacion de la base WHOIS.
>>
>>
>> Contra esta problematica se opto en dos alternativas y creo que son las que
>> se deben analizar
>>
>> 1- Declarar el bloque IP con el nombre de la Organizacion que lo tenia
>> delegado pero en la seccion de contactos administrativos y tecnicos que son
>> los datos visibles se publico la informacion del contacto tecnico y
>> administrativo del ISP que delega el numero.
>>
>> Internamente existian datos que no eran mostrados donde estaba la data real
>> del usuario.
>>
>> 2- Tuvimos solo un caso en donde el cliente no quiso que apareciera ninguna
>> informacion sobre el y se declaro como si el bloque estuviera utilizado por
>> el ISP y con sus contactos administrativos y tecnicos.
>>
>> Cabe mencionar que en este caso fue el que mas complicacion nos creo porque
>> nos llevo a analizar la opcion de añadir un campo que indique el
>> Representante y el Beneficiario del bloque a fin de que solo se publique en
>> el WHOIS los datos del Representante.
>>
>>
>> En conclusion lo que les quiero decir es que este no es un problema
>> complicado de solucionar es un problema mas que todo del tipo
>> administrativo que implica adicionar datos al WHOIS algunos de los cuales
>> no son publicados y definir una opcion al momento de que registra el
>> usuario los datos en que le permite decidir si quiere mantener los datos
>> confidenciales o no.
>>
>> Es claro que ante los RIR esta opcion no era aplicable era solo aplicable
>> para declarar la sub delegaciones hechas por el ISP.
>>
>>
>> Saludos,
>>             Enrique
>>
>> > !
>> > Pues como diria un abogado amigo mio: "desconozco mayormente"!
>> >
>> > No que sepa.
>> >
>> > Erick
>> >
>> > At 09:09 a.m. 20/07/2005, rgaglian at adinet.com.uy wrote:
>> > >Erik,
>> > >
>> > >Sabes si LacTLD esta trabajando en este tema tambien?
>> > >
>> > >Roque
>> > >
>> > > >-- Mensaje original --
>> > > >Date: Wed, 20 Jul 2005 01:13:40 -0500
>> > > >To: german at lacnic.net,<lactf at lac.ipv6tf.org>,<rgaglian at adinet.com.uy>
>> > > >From: Erick Iriarte Ahon <faia at amauta.rcp.net.pe>
>> > > >Subject: Re: [LACNIC/Politicas] [LAC-TF]
>> > > >  Fwd:I-D      ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
>> > > >Cc: politicas at lacnic.net
>> > > >
>> > > >
>> > > >Hola German.
>> > > >
>> > > >>Creo que Roque ha hecho una observacion muy interesante.
>> > > >> Efectivamente,
>> > > >
>> > > >las
>> > > >
>> > > >>reasignaciones de un /48 deberan registrarse en el WHOIS asi sea a
>> > > >> usuarios residenciales por lo que la politica de privacidad que se
>> > > >> planteo dias
>> > >
>> > >atras
>> > >
>> > > >>vuelve a resultar interesante analizar.
>> > > >
>> > > >Concuerdo con lo que indicas, el punto claro es establecer el dato del
>> > > >whois hasta que nivel lo queremos llevar?.
>> > > >
>> > > >>La decision de implementar o no esquemas de privacidad de datos en la
>> > > >> base de datos WHOIS de LACNIC es un tema que recae directamente en
>> > > >> los miembrosde la lista de politicas y asistentes al foro publico.
>> > > >> Si bien
>> > > >>
>> > > >>tiene aristas
>> > > >>legales la decision de si LACNIC debe implementar una politica
>> > > >> similar
>> > >
>> > >es
>> > >
>> > > >de
>> > > >
>> > > >>ustedes.
>> > > >
>> > > >En general, las aristas legales (y en todos los casos existen las
>> > > > mismas),
>> > > >
>> > > >no deben ser entendidas como "bloqueos" sino como "encaminadores"
>> > > > dentro de
>> > > >procesos sociales en los cuales vivimos.
>> > > >
>> > > >>  En otras regiones tal como lo menciona Marcelo  el tema de
>> > > >>privacidad de datos fue resuelto dejando a decision del ISP cuales
>> > > >>asignaciones de sus clientes serian publicos a traves del WHOIS pero
>> > > >> en definitiva todas las reasignaciones se registran la diferencia es
>> > >
>> > > determinar
>> > >
>> > > >>si son publicas o no.
>> > > >
>> > > >Pero tengamos en cuenta, que en otras regiones (como es el caso
>> > > > europeo
>> > >
>> > >en
>> > >
>> > > >particular), esta claramente definido normativas sobre datos
>> > > >personales/privacidad,  mientras que en nuestra region asi de
>> > > > explicito
>> > > >
>> > > >solo Argentina.
>> > > >
>> > > >>La cuestion es determinar si hay una necesidad de un cambio asi y si
>> > > >> hay quienes lo apoyen
>> > > >
>> > > >SIn embargo creo que sera una interesante experiencia el poder
>> > > > trabajar
>> > >
>> > >en
>> > >
>> > > >politicas de privacidad en relacion al whois.
>> > > >
>> > > >Erick
>> > > >
>> > > >>Saludos
>> > > >>
>> > > >>  German Valdez
>> > > >>LACNIC
>> > > >>Potosi 1517
>> > > >>Montevideo Uruguay 11500
>> > > >>http://www.lacnic.net
>> > > >>Participe en el desarrolo de politicas publicas en LACNIC
>> > > >>Suscribase en http://lacnic.net/sp/lists.html
>> > > >>
>> > > >> > -----Mensaje original-----
>> > > >> > De: lactf-bounces at lac.ipv6tf.org
>> > > >> > [mailto:lactf-bounces at lac.ipv6tf.org] En nombre de marcelo
>> > > >> > bagnulo braun
>> > > >> > Enviado el: Martes, 19 de Julio de 2005 06:00 a.m.
>> > > >> > Para: rgaglian at adinet.com.uy
>> > > >> > CC: lactf at lac.ipv6tf.org; politicas at lacnic.net
>> > > >> > Asunto: Re: [LAC-TF] [LACNIC/Politicas] Fwd:I-D
>> > > >> > ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
>> > > >> >
>> > > >> > Hola Roque,
>> > > >> >
>> > > >> > no he seguido muy de cerca este ultimo tema que mencionas,
>> > > >> > pero creo recordar que en otras regiones solucionaron esto
>> > > >> > dejando a discrecion del ISP si poner o no en el WHOIS los
>> > > >> > datos de los clientes finales, por lo que no me queda claro
>> > > >> > que esto sea un problema grave, pero como dije no estoy muy
>> > > >> > puesto en esto, asi que si me podes corregir...?
>> > > >> >
>> > > >> > saludos, marcelo
>> > > >> >
>> > > >> > El 19/07/2005, a las 2:10, rgaglian at adinet.com.uy escribió:
>> > > >> > > Creo que un punto que no podemos perder desde el punto de
>> > > >> >
>> > > >> > vista de los
>> > > >> >
>> > > >> > > operadores es que si se mantiene el /48 como unidad de
>> > > >> >
>> > > >> > asignación, se
>> > > >> >
>> > > >> > > deberá registrar a cada usuario residencial (ADSL, etc) en
>> > > >> >
>> > > >> > la base de
>> > > >> >
>> > > >> > > datos Whois, con el correspondiente costo administrativo y con
>> > > >> > > un agravamiento de los problemas de confidencialidad ya
>> > > >> > > planteados en esta lista.
>> > > >> > >
>> > > >> > > Roque
>> > > >> > >
>> > > >> > >> -- Mensaje original --
>> > > >> > >> Cc: lactf at lac.ipv6tf.org, politicas at lacnic.net
>> > > >> > >> From: marcelo bagnulo braun <marcelo at it.uc3m.es>
>> > > >> > >> Subject: Re: [LACNIC/Politicas] Fwd:
>> > > >> > >> I-D        ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
>> > > >> > >> Date: Sun, 17 Jul 2005 12:52:02 +0200
>> > > >> > >> To: rgaglian at adinet.com.uy
>> > > >> > >>
>> > > >> > >>
>> > > >> > >> Hola Roque,
>> > > >> > >>
>> > > >> > >> si, a mi me parece un disparate tambien
>> > > >> > >>
>> > > >> > >> tener en cuenta que la eficiencia requerida resultante del
>> > > >> >
>> > > >> > uso del HD
>> > > >> >
>> > > >> > >> ratio para un /19 es de 1,8%!!!!
>> > > >> > >>
>> > > >> > >> ademas, en
>> > > >> >
>> > > >> > draft-narten-iana-rir-ipv6-considerations-00.txt se lantea
>> > > >> >
>> > > >> > >> un ejemplo que me parece ilustrar muy bien tu preocupacion, lo
>> > > >> > >> transcribo para uds.
>> > > >> > >>
>> > > >> > >>
>> > > >> > >> 4.1.  An example: Cable Modem/DSL Service in US
>> > > >> > >>
>> > > >> > >>    In the hallway at a recent ARIN meeting, I was cornered
>> > > >> >
>> > > >> > by someone
>> > > >> >
>> > > >> > >>    who had done a back-of-the envelope calculation that led him
>> > > >> > >> to believe the current policies needed adjustment. The
>> > > >> >
>> > > >> > argument went
>> > > >> >
>> > > >> > >>    like:
>> > > >> > >>
>> > > >> > >>       If I assign 4M /48Ç«÷s of IPv6 (one to each cable modem
>> > > >> > >> on
>> > >
>> > >my
>> > >
>> > > >> > >>       network), according to the HD-ratio I am justified to
>> > > >> > >> obtain something around a /20 of IPv6 addresses.  In other
>> > > >> >
>> > > >> > words, I am
>> > > >> >
>> > > >> > >>       justified in getting 268M /48Ç«÷s even though I am
>> > > >> >
>> > > >> > only using
>> > > >> >
>> > > >> > >> 4M
>> > > >> > >>
>> > > >> > >> of
>> > > >> > >>       them.  That would be enough for me to assign at least two
>> > > >> > >> for every household in the US (not just the 19M on my network).
>> > > >> > >>
>> > > >> > >>       Now if all the cable providers (e.g., Comcast, Cox,
>> > > >> > >> Adelphia, Cablevision, Time-Warner, etc.) did the same for
>> > > >> >
>> > > >> > their networks;
>> > > >> >
>> > > >> > >>       and each of the DSL companies made a similar move
>> > > >> >
>> > > >> > (SBC, Verizon,
>> > > >> >
>> > > >> > >>       Quest, etc.); perhaps we could easily see the
>> > > >> >
>> > > >> > broadband market
>> > > >> >
>> > > >> > >> in
>> > > >> > >>       the US alone obtaining some 16 /20Ç«÷s of IPv6 or a total
>> > > >> > >> of /16.
>> > > >> > >>       There are only 8192 of those available in the current
>> > > >> > >> global unicast space of 2001::/3.
>> > > >> > >>
>> > > >> > >>       Anyhow, you can see where this might lead...
>> > > >> > >>
>> > > >> > >>
>> > > >> > >> Saludos, marcelo
>> > > >> > >>
>> > > >> > >> PD: este tema se esta discutiendo en la lista global-v6
>> > > >> > >> global-v6 mailing list
>> > > >> > >> global-v6 at lists.apnic.net
>> > > >> > >> http://mailman.apnic.net/mailman/listinfo/global-v6
>> > > >> > >> seria bueno que enviaramos nuestros comentarios ahi, de
>> > > >> >
>> > > >> > forma que las
>> > > >> >
>> > > >> > >> opiniones del lacnic tambien se tomen en cuenta
>> > > >> > >>
>> > > >> > >> El 17/07/2005, a las 6:56, rgaglian at adinet.com.uy escribió:
>> > > >> > >>> Marcelo,
>> > > >> > >>>
>> > > >> > >>> Hace tiempo que queria contestarte este correo con un
>> > > >> >
>> > > >> > comentario que
>> > > >> >
>> > > >> > >>> he escuchado más de una vez.
>> > > >> > >>>
>> > > >> > >>> ¿¿¿Cómo hizo D-Telecom para justificar un /19???
>> > > >> > >>>
>> > > >> > >>> No he estudiado mucho las políticas actuales de RIPE pero
>> > > >> >
>> > > >> > claramente
>> > > >> >
>> > > >> > >>> se desprende del resto de los RIR por estos bloques gigantes
>> > > >> > >>> de direcciones asignados a algunos proveedores.
>> > > >> > >>>
>> > > >> > >>> Un /19 se podría dividir en 539 millones de /48. Es mi
>> > > >> >
>> > > >> > impresión que
>> > > >> >
>> > > >> > >>> el plan de numeración que utilizaron (y amparados en el
>> > > >> >
>> > > >> > RFC vigente)
>> > > >> >
>> > > >> > >>> da un
>> > > >> > >>> /48
>> > > >> > >>>
>> > > >> > >>> a
>> > > >> > >>> cada usuario DSL y A CADA CELULAR.
>> > > >> > >>>
>> > > >> > >>> Lo que es interesante es que el draft, a primera vista,
>> > > >> >
>> > > >> > no estudia
>> > > >> >
>> > > >> > >>> la
>> > > >> > >>>
>> > > >> > >>> asignación
>> > > >> > >>> de direcciones para empresas celulares/moviles.
>> > > >> > >>>
>> > > >> > >>> Un abrazo
>> > > >> > >>>
>> > > >> > >>> Roque
>> > > >> > >>>
>> > > >> > >>>> -- Mensaje original --
>> > > >> > >>>> To: lactf at lac.ipv6tf.org, politicas at lacnic.net
>> > > >> > >>>> From: marcelo bagnulo braun <marcelo at it.uc3m.es>
>> > > >> > >>>> Date: Wed, 13 Jul 2005 11:39:33 +0200
>> > > >> > >>>> Subject: [LACNIC/Politicas] Fwd: I-D
>> > > >> > >>>>  ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
>> > > >> > >>>>
>> > > >> > >>>>
>> > > >> > >>>> fyi
>> > > >> > >>>>
>> > > >> > >>>> Inicio mensaje reenviado:
>> > > >> > >>>>> De: Internet-Drafts at ietf.org
>> > > >> > >>>>> Fecha: 12 de julio de 2005 21:50:03 GMT+02:00
>> > > >> > >>>>> Para: i-d-announce at ietf.org
>> > > >> > >>>>> Asunto: I-D
>> > > >> > >>>>> ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt Responder
>> > > >> > >>>>> a: internet-drafts at ietf.org
>> > > >> > >>>>>
>> > > >> > >>>>> A New Internet-Draft is available from the on-line
>> > > >> >
>> > > >> > Internet-Drafts
>> > > >> >
>> > > >> > >>>>> directories.
>> > > >> > >>>>>
>> > > >> > >>>>>
>> > > >> > >>>>>         Title           : IPv6 Address Allocation to End
>> > > >> > >>>>> Sites Author(s)       : T. Narten, et al.
>> > > >> > >>>>>         Filename        :
>> > > >> >
>> > > >> > draft-narten-ipv6-3177bis-48boundary-00.txt
>> > > >> >
>> > > >> > >>>>>         Pages           : 8
>> > > >> > >>>>>         Date            : 2005-7-12
>> > > >> > >>>>>
>> > > >> > >>>>>    This document revisits the IAB/IESG recommendations on
>> > > >> > >>>>> the assignment
>> > > >> > >>>>>    of IPv6 address space to end sites. Specifically, it
>> > > >> >
>> > > >> > indicates
>> > > >> >
>> > > >> > >>>>> that
>> > > >> > >>>>>    changing the default end-site assignment for typical
>> > > >> >
>> > > >> > home and
>> > > >> >
>> > > >> > >>>>> SOHO
>> > > >> > >>>>>    sites from /48 to /56 is consistent with the goals
>> > > >> >
>> > > >> > of IPv6 and
>> > > >> >
>> > > >> > >>>>> RFC
>> > > >> > >>>>>    3177. Although it is for the RIR community to make
>> > > >> >
>> > > >> > adjustments
>> > > >> >
>> > > >> > >>>>> to
>> > > >> > >>>>>
>> > > >> > >>>>> the
>> > > >> > >>>>>    IPv6 address space allocation and end site
>> > > >> >
>> > > >> > assignment policies,
>> > > >> >
>> > > >> > >>>>> the
>> > > >> > >>>>>    IETF community would be comfortable with RIRs changing
>> > > >> > >>>>> the default
>> > > >> > >>>>>    assignment size to /56 for smaller end sites. This
>> > > >> > >>>>> document obsoletes
>> > > >> > >>>>>    RFC 3177 and reclassifies it as historic.
>> > > >> > >>>>>
>> > > >> > >>>>> A URL for this Internet-Draft is:
>> > > >> > >>>>> http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bi
>> > > >> > >>>>>s -48boundary-00.txt
>> > > >> > >>>>>
>> > > >> > >>>>> To remove yourself from the I-D Announcement list, send
>> > > >> >
>> > > >> > a message
>> > > >> >
>> > > >> > >>>>> to i-d-announce-request at ietf.org with the word
>> > > >> >
>> > > >> > unsubscribe in the
>> > > >> >
>> > > >> > >>>>> body
>> > > >> > >>>>>
>> > > >> > >>>>> of
>> > > >> > >>>>>
>> > > >> > >>>>> the message.
>> > > >> > >>>>> You can also visit
>> > > >> > >>>>> https://www1.ietf.org/mailman/listinfo/I-D-announce
>> > > >> > >>>>> to change your subscription settings.
>> > > >> > >>>>>
>> > > >> > >>>>>
>> > > >> > >>>>> Internet-Drafts are also available by anonymous FTP. Login
>> > > >> > >>>>> with the username "anonymous" and a password of your e-mail
>> > > >> > >>>>> address. After logging in, type "cd internet-drafts" and
>> > > >> > >>>>> then "get draft-narten-ipv6-3177bis-48boundary-00.txt".
>> > > >> > >>>>>
>> > > >> > >>>>> A list of Internet-Drafts directories can be found in
>> > > >> > >>>>> http://www.ietf.org/shadow.html or
>> > > >> > >>>>> ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>> > > >> > >>>>>
>> > > >> > >>>>>
>> > > >> > >>>>> Internet-Drafts can also be obtained by e-mail.
>> > > >> > >>>>>
>> > > >> > >>>>> Send a message to:
>> > > >> > >>>>>         mailserv at ietf.org.
>> > > >> > >>>>> In the body type:
>> > > >> > >>>>>         "FILE
>> > > >> > >>>>> /internet-drafts/draft-narten-ipv6-3177bis-48boundary-00.txt
>> > > >> > >>>>>".
>> > > >> > >>>>>
>> > > >> > >>>>> NOTE:   The mail server at ietf.org can return the document
>> > > >> > >>>>> in MIME-encoded form by using the "mpack" utility.
>> > > >> >
>> > > >> >  To use this
>> > > >> >
>> > > >> > >>>>>         feature, insert the command "ENCODING mime"
>> > > >> >
>> > > >> > before the "FILE"
>> > > >> >
>> > > >> > >>>>>         command.  To decode the response(s), you will
>> > > >> >
>> > > >> > need "munpack" or
>> > > >> >
>> > > >> > >>>>>         a MIME-compliant mail reader.  Different
>> > > >> >
>> > > >> > MIME-compliant mail
>> > > >> >
>> > > >> > >>>>> readers
>> > > >> > >>>>>         exhibit different behavior, especially when dealing
>> > > >> > >>>>> with "multipart" MIME messages (i.e. documents which
>> > > >> >
>> > > >> > have been split
>> > > >> >
>> > > >> > >>>>>         up into multiple messages), so check your local
>> > > >> >
>> > > >> > documentation on
>> > > >> >
>> > > >> > >>>>>         how to manipulate these messages.
>> > > >> > >>>>>
>> > > >> > >>>>>
>> > > >> > >>>>> Below is the data which will enable a MIME compliant
>> > > >> >
>> > > >> > mail reader
>> > > >> >
>> > > >> > >>>>> implementation to automatically retrieve the ASCII
>> > > >> >
>> > > >> > version of the
>> > > >> >
>> > > >> > >>>>> Internet-Draft.
>> > > >> > >>>>> Content-Type: text/plain
>> > > >> > >>>>> Content-ID: <2005-7-12130012.I-D at ietf.org>
>> > > >> > >>>>>
>> > > >> > >>>>> _______________________________________________
>> > > >> > >>>>> I-D-Announce mailing list
>> > > >> > >>>>> I-D-Announce at ietf.org
>> > > >> > >>>>> https://www1.ietf.org/mailman/listinfo/i-d-announce
>> > > >> > >>>>
>> > > >> > >>>> _______________________________________________
>> > > >> > >>>> Politicas mailing list
>> > > >> > >>>> Politicas at lacnic.net
>> > > >> > >>>> http://www.lacnic.net/mailman/listinfo/politicas
>> > > >> > >>>
>> > > >> > >>> Ing.Roque Gagliano
>> > > >> > >>> rgaglian at adinet.com.uy
>> > > >> > >>>
>> > > >> > >>>
>> > > >> > >>> _______________________________________________
>> > > >> > >>> Politicas mailing list
>> > > >> > >>> Politicas at lacnic.net
>> > > >> > >>> http://www.lacnic.net/mailman/listinfo/politicas
>> > > >> > >
>> > > >> > > Ing.Roque Gagliano
>> > > >> > > rgaglian at adinet.com.uy
>> > > >> > >
>> > > >> > >
>> > > >> > > _______________________________________________
>> > > >> > > Politicas mailing list
>> > > >> > > Politicas at lacnic.net
>> > > >> > > http://www.lacnic.net/mailman/listinfo/politicas
>> > > >> >
>> > > >> > _______________________________________________
>> > > >> > LACTF mailing list
>> > > >> > LACTF at lac.ipv6tf.org
>> > > >> > http://lacnic.net/mailman/listinfo/lactf
>> > > >>
>> > > >>_______________________________________________
>> > > >>Politicas mailing list
>> > > >>Politicas at lacnic.net
>> > > >>http://www.lacnic.net/mailman/listinfo/politicas
>> > >
>> > >Ing.Roque Gagliano
>> > >rgaglian at adinet.com.uy
>> >
>> > _______________________________________________
>> > Politicas mailing list
>> > Politicas at lacnic.net
>> > http://www.lacnic.net/mailman/listinfo/politicas
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> http://www.lacnic.net/mailman/listinfo/politicas
> 
> 
> 
> -- 
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.323 / Virus Database: 267.9.2/53 - Release Date: 7/20/2005
> 
>

More information about the Politicas mailing list