[LACNIC/Politicas] [LAC-TF] Fwd:I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
Erick Iriarte Ahon
faia at amauta.rcp.net.pe
Wed Jul 20 03:13:40 BRT 2005
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
More information about the Politicas
mailing list