[LAC-TF] Fwd: [NCUC-DISCUSS] Numbering issues
Roque Gagliano
rgaglian at adinet.com.uy
Tue Aug 31 15:43:52 BRT 2004
Hola amigos,
Estoy de acuerdo con lo expresado con Marcelo, creo que hay que bajar
estos planteamientos un poquito mas a tierra.
un abrazo
r.
On Tue, 2004-08-31 at 10:08, Oscar A. Robles-Garay wrote:
> Al menos yo estoy interesado, si deciden seguir esta plática en privado les
> pido que me incluyan, me gustaría conocer las respuestas a los
> planteamientos que hizo Marcelo.
> Saludos a todos,
>
> Oscar
>
> At 08:50 a.m. 31/08/2004, Carlos Afonso wrote:
> >Caro, creo que podemos ya estar llegando al punto en que necesitamos una
> >"review" de la situación de comercialización de números IP, para que se
> >intente elaborar una propuesta concreta para discusión. Mi intento hasta
> >ahora es apenas sensibilizar para el problema, que sí existe y es
> >importante. Podemos seguir este diálogo en privado? Es que podemos estar
> >dialogando en la lista sin que haya interés efectivo de los demás, y esto
> >no es buena práctica.
> >
> >[] fraterno
> >
> >--c.a.
> >
> >At 05:43 31/08/2004, you wrote:
> >
> >>Hola Carlos,
> >>
> >>la verdad que estoy un poco perdido...
> >>
> >>El 30/08/2004, a las 17:33, Carlos Afonso escribió:
> >>
> >>>Caro Marcelo, gracias muchas por tus comentarios muy relevantes.
> >>>
> >>>Una de las preocupaciones es que, en el "último km", bienes públicos
> >>>dejen de serlo porque pasan a ser comercializados, en general por un
> >>>monopolio o cartel privado con fines de lucro (regulado o no).
> >>>
> >>>Nota bene: cobrar por un servicio de distribución no significa
> >>>necesariamente que el bien siendo distribuido deje de ser público -- hay
> >>>un obvio costo de mantenimiento y operación que tiene que ser cubierto
> >>>por la misma comunidad que se beneficia de este bien.
> >>
> >>Yo creo que no hay ninguna duda que las direcciones IP (tanto en IPv4
> >>como en IPv6) son un bien de la comunidad y que los RIRs lo administran
> >>siguiendo las politicas definidas por la comunidad (te animo a que si
> >>alguna de las politicas vigentes no te convencen o si se te ocurre otra
> >>nueva que necesitemos, envies tus comentarios a la lista de politicas del
> >>lacnic , siempre estamos necesitados de discusiones apasionantes :-)
> >>
> >>> Pero cuando un rango de bloques IP pasa a ser cobrado al usuario final
> >>> a valores astronómicos para generar lucros, este bien público pasa a
> >>> ser apropiado por intereses comerciales.
> >>
> >>Tu inquietud es que los precios que cobran los RIRs son muy altos y no
> >>corresponden con los costos de operacion? O que los precios de los ISPs
> >>son muy altos?
> >>
> >>Con respecto al tema de los RIRs, creo que el tema costes es bastante
> >>transparente, pero yo no soy un miembro, asi que tampoco sigo el tema muy
> >>de cerca.
> >>
> >>>
> >>>Entiendo que, por los errores de criterio de alocación de bloques en el
> >>>"principio de los tiempos" (más o menos motivados por algo parecido a
> >>>Gates cuando dijo "quién va un día necesitar de más de 640 KB?"), se
> >>>creó una situación (o más bien una noción) de bien escaso mucho antes de
> >>>lo que debería ocurrir.
> >>>
> >>>Sin embargo, esto es relativo -- solo los 91 bloques /8 aún reservados
> >>>por IANA corresponden a 1.4 mil millones de números, y el consumo anual
> >>>aproximado es del orden de 4 a 6 bloques /8 (algo como 80-100 millones
> >>>al año), sin que eso signifique que entren en uso efectivo, claro. Menos
> >>>de 25 /8s han sido alocados por el conjunto de los RIRs en cinco años -
> >>>y ya pasamos por la burbuja y su explosión hace tiempo. (datos de RIPE,
> >>>basados en info aportada por todos los RIRs e IANA.)
> >>>
> >>>Pero se ha, digamos, creado la noción de escasez desde hace años, y eso
> >>>dió obviamente margen a la prevalencia de comercialización en el "último km".
> >>
> >>No entiendo mucho la relacion que tienen estos tres parrafos con lo
> >>anterior...
> >>
> >>>Mi punto es: no es necesario pensar en una política que busque minimizar
> >>>o eliminar eso cuando tengamos "velocidad de crucero" en IPv6? No
> >>>queremos cometer la misma "naivete" del "principio de los tiempos", creo yo.
> >>
> >>Podes definir "eso" de forma mas concisa? estoy un poco perdido...
> >>
> >>>
> >>>Bueno, esta discusión no es nueva - veo mensajes en las listas de IANA
> >>>desde el 1998 tratando de discutir el asunto.
> >>>
> >>>Entiendo que el énfasis en la lista LAC-TF es mucho más de "casa de
> >>>máquinas" - que es fundamental, claro - que de políticas de ese tipo -
> >>>que también lo son.
> >>
> >>Politicas es lo que se discute en el LACNIC
> >>
> >>>Quizás si pudiera tener en el próximo encuentro LACNIC un panel o
> >>>"track" de discusión sobre eso?
> >>
> >>Me gustaria entender un poco mas el problema en cuestion.
> >>Cual es exactamente el problema y si es que existe, la solucion propuesta
> >>
> >>gracias, marcelo
> >>
> >>>Por favor, tiren mis orejas si estoy diciendo tonterías o
> >>>trivialidades... :)
> >>>
> >>>[]s frats
> >>>
> >>>--c.a.
> >>>
> >>>At 05:28 30/08/2004, you wrote:
> >>>
> >>>>Hola Carlos,
> >>>>
> >>>>Hasta lo que yo se, las direcciones IP ya son un patrimonio de la
> >>>>comunidad (tanto en IPv4 como en IPv6) y la comunidad los administra a
> >>>>traves de los RIRs, quienes ejecutan las politicas definidas por la comunidad.
> >>>>En IPv4, el problema es que es un patrimonio de la comunidad, pero es
> >>>>escaso, por lo que hay que recurrir a NATs. Pero eso lo decide asi la
> >>>>propia comunidad basada en criterios tecnicos.
> >>>>En IPv6, no hay tal limitacion, por lo que se pueden evitar esos
> >>>>dispositivos.
> >>>>Sin embargo, tanto en IPv6 como en IPv4, la unica forma de preservar la
> >>>>escalabilidad del sistema de rutas es la agregacion por proveedor. Eso
> >>>>significa, que un sitio final debe ontener direcciones de su proveedor.
> >>>>ahora bien, esto no es un tema comercial, pero es un tema tecnico.
> >>>>simplemente no sabemos como preservar la escalabilidad del sistema de
> >>>>rutas de otra manera (las nuevas ideas son bienvenidas :-)
> >>>>
> >>>>Esto implica que los sitios finales pueden llegar a tener una
> >>>>dependencia de sus proveedores ya que cambiar de proveedor signiffica
> >>>>renumerar y esto puede ser costoso (sobre todo para un sitio grande).
> >>>>En IPv6, se ha tratado que la renumeracion sea mas simple, pero todavia
> >>>>tiene un costo no nulo.
> >>>>
> >>>>Espero que esto sirva para inicar el tema que planteas para discusion,
> >>>>saludos, marcelo
> >>>>
> >>>>El 27/08/2004, a las 20:41, Carlos Afonso escribió:
> >>>>
> >>>>>Caríssimas y carísssimos,
> >>>>>
> >>>>>El mensaje abajo del compa Harold menciona asunto de gran importancia
> >>>>>sobre
> >>>>>los criterios de distribución de números (y bloques de números) IPv6.
> >>>>>
> >>>>>En mi visión, tal como los ccTLDs, números IP deberían ser considerados
> >>>>>patrimonio de la comunidad ("assets of the commons" o bienes públicos), no
> >>>>>"commodities". No es así con muchos de los ccTLDs, y sabemos que la
> >>>>>distribución de IPs por proveedores es un comercio como cualquier otro.
> >>>>>
> >>>>>Ahora estamos en un nuevo paradigma, el de IPv6, en que hay abundancia
> >>>>>y no
> >>>>>escasez de este recurso (argumento usado por algunos para que se
> >>>>>comercialize
> >>>>>la cosa) -- más razón todavía para que sea considerado y tratado como
> >>>>>un bien
> >>>>>público.
> >>>>>
> >>>>>Me gustaría debatir un poco el asunto en el ámbito de LACNIC como en
> >>>>>el ámbito
> >>>>>de la gestión de esos recursos en Brasil.
> >>>>>
> >>>>>[]s fraternos
> >>>>>
> >>>>>--c.a.
> >>>>>
> >>>>>---------- Mensagem encaminhada ----------
> >>>>>
> >>>>>Subject: [NCUC-DISCUSS] Numbering issues
> >>>>>Date: Thursday 26 August 2004 14:15
> >>>>>From: Harold Feld <hfeld at MEDIAACCESS.ORG>
> >>>>>To: NCUC-DISCUSS at LISTSERV.SYR.EDU
> >>>>>
> >>>>>Hi everyone!
> >>>>>
> >>>>>I am back from a fantastic conference on community wireless
> >>>>>networking. In
> >>>>>the United States, there is increasing interest by non-commercial
> >>>>>organizations to use unlicensed spectrum access to provide free or
> >>>>>low-cost
> >>>>>Internet connectivity to poor urban neighborhoods and rural communities.
> >>>>>
> >>>>>At the conference, I discovered that there is an urgent need for more
> >>>>>address space. Nearly all community wireless networks are deployed behind
> >>>>>NAT boxes, which creates difficulties for those trying to foster
> >>>>>independent community media projects or voice over IP for community
> >>>>>networks.
> >>>>>
> >>>>>The issue is purely financial. Community networks cannot afford v6 blocks
> >>>>>of address space. While address blocks are modestly priced by
> >>>>>commercial
> >>>>>standards, they are beyond the reach of community wireless projects.
> >>>>>I had
> >>>>>one administrator tell me that the cost of a v6 block would be higher than
> >>>>>the cost of his entire network combined. What is worse, because it is an
> >>>>>annual registration fee, v6 space would constitute a continuing
> >>>>>expense. Even if a network can raise the money for an initial
> >>>>>registration
> >>>>>via a grant, there is a problem of sustainability.
> >>>>>
> >>>>>In any event, what is needed is not a one shot cure for a single network,
> >>>>>but a systemic way of addressing the issue. I would very much like to
> >>>>>talk
> >>>>>to people in the RIR community about this issue in the hopes of
> >>>>>working out
> >>>>>a solution (I have some ideas). But I do not know who in the RIR
> >>>>>community
> >>>>>or the broader ICANN community would be interested and sympathetic to the
> >>>>>issue.
> >>>>>
> >>>>>I suspect this issue goes beyond the scope of the NCUC, since this is the
> >>>>>naming side of the street. However, I expect that access to address space
> >>>>>has been a long standing issue outside of the U.S., and would be very
> >>>>>eager
> >>>>>to hear from anyone outside the U.S. what problems getting affordable
> >>>>>address space you have and what solutions (other than NAT) are available.
> >>>>>
> >>>>>Finally, if there is a sense within the Consticuency that numbering issues
> >>>>>are appropriately addressed here (since there is no other place within the
> >>>>>ICANN structure to raise issues of unique concern to the noncommercial
> >>>>>community), please let me know.
> >>>>>
> >>>>>Harold Feld
> >>>>>
> >>>>>-------------------------------------------------------
> >>>>>
> >>>>>--
> >>>>>Carlos A. Afonso
> >>>>>diretor de planejamento e estratégia
> >>>>>Rits - Rede de Informações para o Terceiro Setor
> >>>>>Rua Guilhermina Guinle 272 - sexto andar
> >>>>>22270-060 Rio de Janeiro BRASIL
> >>>>>telefone +55-21-2527-5494
> >>>>>telefax +55-21-2527-5460
> >>>>>http://www.rits.org.br
> >>>>>
> >>>>>
> >>>>>_______________________________________________
> >>>>>LACTF mailing list
> >>>>>LACTF at lac.ipv6tf.org
> >>>>>http://lacnic.net/mailman/listinfo/lactf
> >>>>
> >>>>_______________________________________________
> >>>>LACTF mailing list
> >>>>LACTF at lac.ipv6tf.org
> >>>>http://lacnic.net/mailman/listinfo/lactf
> >>>
> >>>
> >>>===
> >>>Carlos A. Afonso
> >>>diretor de planejamento e estratégia
> >>>Rede de Informações para o Terceiro Setor - Rits
> >>>Rua Guilhermina Guinle 272 - sexto andar
> >>>22270-060 Rio de Janeiro Brasil
> >>>telefone +55-21-2527-5494
> >>>telefax +55-21-2527-5460
> >>>rits at rits.org.br
> >>>http://www.rits.org.br
> >>>
> >>>---
> >>>Outgoing mail is certified Virus Free.
> >>>Checked by AVG anti-virus system (http://www.grisoft.com).
> >>>Version: 6.0.744 / Virus Database: 496 - Release Date: 24/08/2004
> >>>_______________________________________________
> >>>LACTF mailing list
> >>>LACTF at lac.ipv6tf.org
> >>>http://lacnic.net/mailman/listinfo/lactf
> >>
> >>_______________________________________________
> >>LACTF mailing list
> >>LACTF at lac.ipv6tf.org
> >>http://lacnic.net/mailman/listinfo/lactf
> >>
> >
> >
> >===
> >Carlos A. Afonso
> >diretor de planejamento e estratégia
> >Rede de Informações para o Terceiro Setor - Rits
> >Rua Guilhermina Guinle 272 - sexto andar
> >22270-060 Rio de Janeiro Brasil
> >telefone +55-21-2527-5494
> >telefax +55-21-2527-5460
> >rits at rits.org.br
> >http://www.rits.org.br
> >
> >
> >
> >---
> >Outgoing mail is certified Virus Free.
> >Checked by AVG anti-virus system (http://www.grisoft.com).
> >Version: 6.0.745 / Virus Database: 497 - Release Date: 27/08/2004
> >_______________________________________________
> >LACTF mailing list
> >LACTF at lac.ipv6tf.org
> >http://lacnic.net/mailman/listinfo/lactf
>
> _______________________________________________
> LACTF mailing list
> LACTF at lac.ipv6tf.org
> http://lacnic.net/mailman/listinfo/lactf
More information about the LACTF
mailing list