[LAC-TF] [LACNIC/Politicas] Fwd:I-D ACTION:draft-narten-ipv6-3177bis-48boundary-00.txt
Erick Iriarte Ahon
faia at amauta.rcp.net.pe
Thu Jul 21 03:46:41 BRT 2005
!
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-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
> >
>
>Ing.Roque Gagliano
>rgaglian at adinet.com.uy
More information about the LACTF
mailing list