[LAC-TF] [LACNIC/Politicas] Fwd:I-D
Ramos
ramos at enet.cu
Wed Jul 20 09:48:33 BRT 2005
Jordi:
Comparto tu opinión, pero creo que es un tema que debía salir para
enriquecer la discusión no se nos puede quedar ningún detalle fuera y ese
era el objetivo del mensaje ..
Una pregunta al grupo:
Cuando hablamos de privacidad en el whois nos referimos a que el whois de
Lacnic tenga una opción de no publicar algunos datos??
O se trata de no actualizar el Whois de Lacnic??
Saludos Ramos
----- Original Message -----
From: "JORDI PALET MARTINEZ" <jordi.palet at consulintel.es>
To: <lactf at lac.ipv6tf.org>
Sent: Wednesday, July 20, 2005 8:37 AM
Subject: Re: [LAC-TF] [LACNIC/Politicas] Fwd:I-D
> Hola,
>
> Yo creo que hay que seguir los conceptos generales de privacidad, igual
> que
> hace el derecho.
>
> Es decir, si se produce un ataque, en ese case tienes derecho a que se te
> indique quien es el atacante, pero en realidad, eso lo haria el propio
> juez
> (nadie debe tomarse la justicia por su mano, y mejor evitar tentaciones
> !).
>
> Es mas, que mas te da saber quien es el atacante, cuando lo que te
> interesa
> saber es desde que IP o prefijo se produce el ataque, para poder
> comunicarselo al ISP, LACNIC e incluso el juez si es el caso ?
>
> Yo lo compararia con el telefono. Cualquier usuario tiene derecho a tener
> un
> telefono anonimo y no por ello se priva a los posibles "atacados" desde
> dicho telefono de las penalizaciones y seguimientos o incluso hasta
> "escuchas" que sean precisas cuando se produce un delito o el juez
> considera
> que es probable.
>
> No veo ningun contra a no tener los datos publicos. Basta con que los
> datos
> esten en las manos del ISP, y esto siempre es el caso, y si no, se esta
> produciendo una falta que en su momento si se produce un delito el juez
> podra tomar medidas al respecto.
>
> Y como pro, veo que de esta manera se respeta la privacidad de quien lo
> desee. Si el usuario quiere publicar sus datos, hay miles de formas de
> hacerlo, con o sin la cooperacion del ISP, aunque seria bueno que el ISP,
> en
> el contrato, pregunte al usuario si quiere aparecer publicamente, al igual
> que ocurre con las paginas amarillas y servicios similares.
>
> Saludos,
> Jordi
>
>
>
>
>> De: Ramos <ramos at enet.cu>
>> Responder a: "lactf at lac.ipv6tf.org" <lactf at lac.ipv6tf.org>
>> Fecha: Wed, 20 Jul 2005 08:15:53 -0400
>> Para: <lactf at lac.ipv6tf.org>
>> Asunto: Re: [LAC-TF] [LACNIC/Politicas] Fwd:I-D
>>
>> German:
>>
>> Ante nada saludos al grupo.
>> Este es un tema interesante, por un lado tenemos la privacidad del
>> cliente y
>> por otro la búsqueda rápida de información de a que cliente o usuario
>> pertenece un bloque IP..la discusión estriba en que es mas importante.
>> Para
>> los administradores tener acceso al whois es fundamental sobre todo en
>> temas
>> de ataques, virus etc, pero esta el tema de la privacidad y debemos
>> analizar
>> hasta donde pesa.
>>
>> Estoy de acuerdo que hay que intercambiar todos los puntos de vistas para
>> llegar a un consenso, la idea de tener whois distribuidos en la región no
>> esta del todo mal pero hay que ver los pro y los contra.
>>
>>
>> Saludos
>>
>> Daniel Ramos
>>
>> ----- Original Message -----
>> From: "Erick Iriarte Ahon" <faia at amauta.rcp.net.pe>
>> To: <german at lacnic.net>; <lactf at lac.ipv6tf.org>; <rgaglian at adinet.com.uy>
>> Cc: <politicas at lacnic.net>
>> Sent: Wednesday, July 20, 2005 2:13 AM
>> Subject: Re: [LAC-TF] [LACNIC/Politicas] Fwd:I-D
>> ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
>>
>>
>>> 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-3177bis
>>>>>>>>>> -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
>>>
>>> _______________________________________________
>>> LACTF mailing list
>>> LACTF at lac.ipv6tf.org
>>> http://lacnic.net/mailman/listinfo/lactf
>>>
>>>
>>>
>>> --
>>> No virus found in this incoming message.
>>> Checked by AVG Anti-Virus.
>>> Version: 7.0.323 / Virus Database: 267.9.2/52 - Release Date: 7/19/2005
>>>
>>
>> _______________________________________________
>> LACTF mailing list
>> LACTF at lac.ipv6tf.org
>> http://lacnic.net/mailman/listinfo/lactf
>
>
>
>
> ************************************
> The IPv6 Portal: http://www.ipv6tf.org
>
> Barcelona 2005 Global IPv6 Summit
> Information available at:
> http://www.ipv6-es.com
>
> This electronic message contains information which may be privileged or
> confidential. The information is intended to be for the use of the
> individual(s) named above. If you are not the intended recipient be aware
> that any disclosure, copying, distribution or use of the contents of this
> information, including attached files, is prohibited.
>
>
>
> _______________________________________________
> LACTF mailing list
> LACTF at lac.ipv6tf.org
> http://lacnic.net/mailman/listinfo/lactf
>
>
>
> --
> No virus found in this incoming message.
> Checked by AVG Anti-Virus.
> Version: 7.0.323 / Virus Database: 267.9.2/52 - Release Date: 7/19/2005
>
More information about the LACTF
mailing list