[LACNIC/Politicas] [LAC-TF] Fwd:I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
Enrique Torres
eta at millicomperu.com.pe
Thu Jul 21 13:26:49 BRT 2005
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
More information about the Politicas
mailing list