[LACNIC/Politicas] Politicas para el foro publico
Francisco Obispo
fobispo at nic.ve
Tue May 2 17:38:47 BRT 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hola Christian
CHRISTIAN O'FLAHERTY wrote:
> Hola Francisco, para simplificar la discusión sobre el cambio de valor
> de HD ratio tal vez sea suficiente con mencionar la mejor eficiencia
> conseguida. En la presentación se pueden mostrar ambos porcentajes
> segun el tamaño de asignación mínimo utilizado.
>
> No es conveniente atar una politica a otra. Por otro lado, subir aun
> mas el valor de HD ratio seria realizar otra propuesta diferente que
> requerirá mas debate. Tal vez esta propuesta no haya sido analizada en
> profundidad por la comunidad para ser votada en el Foro Público. Qué
> opinas?
>
Bueno, lo que si podríamos mencionar en la política es que el valor de
HD-Ratio que utilicemos para medir el uso de un prefijo en especifico
debe garantizar que se utilice al menos el 50% de los recursos asignados.
> Es posible hacer solo la presentación (sin votarla) en el Foro si
> consideran que el tema no fue suficientemente discutido en la lista.
>
>
Estoy deacuerdo, sin embargo, sería poco conveniente adoptar el HD-Ratio
de 0.94 y cambiar el tamaño de usuario final al > /56 porque estaríamos
hablando de una eficiencia de 36,86%
Saludos
Christian
>
> On 5/2/06, Francisco Obispo <fobispo at nic.ve> wrote:
>
> Hola Chrisian,
>
> Tenemos que tener cuidado como se "aprueban" las políticas.
>
> Porque si aprobamos el cambio de asignación de IPv6 para usuarios
> finales, de /48 fijo a tamaño variable mayores a /56, ( utilizando este
> ultimo para el cálculo del HD-Ratio), y luego aprobamos que se cambiará
> el HD-Ratio de IPv6 de 0.8 a 0.94, entonces la justificación para
> aprobar el cambio no sería válido.
>
> Tendríamos en este caso de cambiar de 0.94 a 0.96 para poder justificar
> el 51.41% de utilización de recursos.
>
> Crees que sería conveniente discutir las políticas en ese orden, y
> modificar la propuesta de cambio de HD-Ratio en IPv6 para que se ajuste
> según el tamaño de usuario final aprobado en asamblea?
>
>
> Saludos
>
>
> CHRISTIAN O'FLAHERTY wrote:
>> Estimados, durante los próximos días podremos hacer comentarios a las
>> políticas que han sido discutidas en esta lista durante los meses
>> anteriores.
>
>> Para no tener que buscar entre los mails el texto de cada una, les
>> envío todas las propuestas recibidas en este mail.
>
>> Saludos,
>
>> Christian
>
>> Indice:
>
>> LAC-2006-01 Privacidad WHOIS
>> LAC-2006-02 Recuperacion de Recursos
>> LAC-2006-03 Periodo de Analisis Tamanho Asignaciones Adicionales
>> LAC-2006-04 ASN 32 bits
>> LAC-2006-05 HD Ratio IPv6
>> LAC-2006-06 HD Ratio IPv4
>> LAC-2006-07 Tamano de asignaciones IPv6
>> LAC-2006-08 Asignacion IPv6 a Usuarios Finales
>
>> Propuestas:
>
>> LAC-2006-01 Privacidad WHOIS
>
>> Política propuesta "Filtrado de la Información del WHOIS de LACNIC "
>
>> Los ISP suministran a LACNIC información clasificada de las
>> delegaciones de los bloques hechas a los clientes, cuyo rango sea
>> mayor a 8 direcciones (prefijo /29). Esta información será publicada a
>> través de la nueva base de datos WHOIS, en donde se han modificar y
>> eliminar aquellos campos de los contactos y usuarios que podrían
>> constituir información de carácter privado.
>
>> LACNIC tendrá la potestad de solicitar más información (de carácter
>> publico o información autorizado por el cliente) a los ISPs, sobre las
>> delegaciones realizadas. A su vez, ISPs puede solicitar que la
>> información suministrada no sea de carácter público .
>
>> 1. Los datos pedidos actualmente para una asignación son:
>
>> " Nombre
>> " Responsable
>> " Dirección Postal
>> " Código Postal
>> " Ciudad
>> " Estado
>> " País
>> " Teléfono
>> " Id del contacto
>
>> 2. Para un contacto del ISP la información pedida es:
>
>> " Nombre
>> " E-mail
>> " Direcc. Postal
>> " Código Postal
>> " Ciudad
>> " Estado
>> " País
>> " Lengua
>> " Teléfono
>
>> LACNIC hará público en el WHOIS los siguientes datos para cada
> bloque siempre:
>
>> " Nombre cliente
>> " Bloques de direcciones
>> " A pedido del RI, LACNIC eliminará del WHOIS los siguientes datos
>> del cliente:
>> " Id del contacto
>> " Dirección Postal
>> " Código Postal
>> " Ciudad
>> " Estado
>> " País
>> " Teléfono
>
>> Los datos del contacto podrán ser datos de una persona real o los de
>> un grupo de personas responsables de la administración de red. Esos
>> datos deben existir siempre y es responsabilidad de la entidad que lo
>> registra mantenerlos actualizados.
>> --------------------------------
>
>> LAC-2006-02 RECUPERACIÓN DE RECURSOS
>
>> POLÍTICA DE RECUPERACIÓN DE RECURSOS DE INTERNET NO UTILIZADOS
>
>> Propuesta
>
>> Se considera que el término "recursos de Internet no utilizado"
>> refiere a aquellos recursos administrados por LACNIC, no visibles en
>> la tabla de enrutamiento global de Internet por más de un año y de los
>> cuales no hay constancia de su utilización.
>
>> Cuando los recursos no están utilizados y:
>
>> 1. Se localiza el contacto de la organización pero este no esta de
>> acuerdo en regresar los recursos:
>> en este caso la organización se queda con los bloques.
>
>> 2. El contacto no responde o ya no tiene ninguna relación con la
>> organización que los pidió y:
>
>> a. Se comprueba que la organización existe y
>
>> b. No se puede conseguir información sobre el estado de la
> organización:
>> enlistar en una página los nombres de las organizaciones de las que se
>> tiene duda. De la misma manera crear un boletín de distribución, tal
>> vez mensual, de forma que toda la comunidad se convierta en un
>> "aliado" potencial.
>
>> 3. Se comprueba que la organización ya no existe más (sea que el
>> contacto responda o no) y
>
>> a. La organización deja de existir porque fue comprada por otra y los
>> recursos no son más utilizados:
>> Se recuperan los recursos (LACNIC los puede reasignar)
>
>> b. La organización deja de existir porque fue comprada por otra y se
>> puede justificar que servicios o usuarios que utilizan dichos recursos
>> fueron también transferidos:
>> En este caso LACNIC acepta la transferencia de los recursos en un
>> plazo no mayor de 90 días
>
>> c. La organización desapareció, no tiene más operación. Los recursos
>> ya no se utilizan:
>> Si no hay mas servicios ofrecidos los recursos son recuperados por
> LACNIC.
>
>> d. La organización desapareció, no tiene más operación. Los recursos
>> todavía son utilizados:
>> La nueva organización debe hacer su solicitud formal de asignación de
>> recursos ante LACNIC en un plazo no mayor de 90 días a partir de la
>> fecha de notificación. En caso de no solicitar la asignación de
>> recursos en 90 días o si no cumple con todos los requisitos
>> establecidos en las políticas para la asignación de recursos de
>> Internet: LACNIC procederá la recuperación de dichos recursos.
>
>> La recuperación de recursos implicará la eliminación del registro de
>> los recursos en la base de datos WHOIS.
>
>> LACNIC recomienda que los ISP de la región verifiquen la existencia
>> del registro de los recursos de numeración de Internet en la base de
>> datos WHOIS antes de implementar su anuncio en sus tablas de Internet.
>
>> --------------------
>
>> LAC-2006-04 ASN 32 bits
>
>> 1. Policy Proposal Name:
>
>> 4-Byte AS Number Policy Proposal
>
>> 2. Author:
>
>> Geoff Huston
>> gih at apnic.net
>> APNIC
>
>> 3. Proposal Version:
>
>> 1.0
>
>> 4. Submission Date:
>
>> 9 December 2005 (resubmitted on the 30th December)
>
>> 5. Proposal Type:
>
>> New
>
>> 6. Policy Term:
>
>> Temporary (1 January 2007 ¬ 1 January 2010)
>
>> 7. Policy Statement:
>
>> This policy proposal nominates 3 dates for changes to the current AS
>> Number allocation policy for the registry:
>
>> 1. On 1 January 2007 the registry will process applications that
>> specifically request 32-bit only AS Numbers and allocate such AS
>> Numbers as requested by the applicant. In the absence of any specific
>> request for a 32-bit only AS Number, a 16-bit only AS Number will be
>> allocated by the registry.
>
>> 2. On 1 January 2009 the registry will process applications that
>> specifically request 16-bit only AS Numbers and allocate such AS
>> Numbers as requested by the applicant. In the absence of any specific
>> request for a 16-bit only AS Number, a 32-bit only AS Number will be
>> allocated by the registry.
>
>> 3. On 1 January 2010 the registry will cease to make any distinction
>> between 16-bit only AS Numbers and 32-bit only AS Numbers, and will
>> operate AS number allocations from an undifferentiated 32-bit AS
>> Number allocation pool.
>
>> No other changes in AS number allocation policy are implied by this
> proposal.
>
>
>> 8. Rationale:
>
>> Recent studies of AS number consumption rates indicate that the
>> existing pool of unallocated 16-bit AS Numbers will be exhausted
>> sometime in the period between 2010 and 2016, absent of any concerted
>> efforts of recovery of already-allocated AS Numbers [1] [2].
>> Standardization work in the IETF has produced a document that is
>> currently being submitted as a Proposed Standard that will expand the
>> AS Number space to a 32-bit field [3].
>
>> It is noted that some advance period may be required by network
>> operators to undertake the appropriate procedures relating to support
>> of 32-bit AS numbers, and while no flag day is required in the
>> transition to the longer AS Number field, it is recognised that a
>> prudent course of action is to allow for allocation of these extended
>> AS numbers well in advance of an anticipated 16-bit AS Number
>> exhaustion date.
>
>> This policy proposal details a set of actions and associated dates for
>> RIR AS Number allocation policies to assist in an orderly transition
>> to use of the 32-bit AS Number space.
>
>> The essential attributes of this policy proposal are to facilitate the
>> ease of transitional arrangements by equipment vendors, network
>> managers and network operations staff, to provide the industry with
>> some predictability in terms of dates and associated actions with
>> respect to registry operational procedures for AS Number allocations.
>
>> Nomenclature
>
>> It is proposed to identify 32-bit AS Numbers using a syntax of <high
>> order 16 bit value in decimal>.<low order 16 bit value in decimal>.
>> Accordingly, a 32-bit AS number of value 65546 (decimal) would be
>> identified as "1.10".
>
>> Terminology
>
>> "16-bit only AS Numbers" refers to AS numbers in the range 0 65535
>
>> "32-bit only AS Numbers" refers to AS Numbers in the range 1.0
>> 65535:65535 (decimal range 65,536 - 4,294,967,295)
>
>> "32-bit AS Numbers" refers to AS Numbers in the range 0.0
>> 65535.65535 (decimal range 0 4,294,967,295)
>
>> References
>
>> [1] Daily AS Number Report, http://www.potaroo.net/tools/asns
>> [2] ASNs MIA: A Comparision of RIR Statistics and RIS Reality,
>> http://www.nanog.org/mtg-0510/wilhelm.html
>> [3] BGP Support for Four-octet AS Number Space,
> draft-ietf-idr-as4bytes-12.txt
>
>> 9. Timetable for implementation:
>
>> Procedures to support this proposal need to be implemented by 1
> January 2007
>
>> --------------------------
>
>> LAC-2006-07 Tamaño de asignaciones IPv6
>
>> Se propone que se modifique la política de asignación de IPv6 de
>> manera tal que permita a los LIRs la asignación de /56s para el caso
>> de usuarios finales que sean pequeñas y medianas empresas,
>> residenciales o redes personales, donde el número de subredes
>> potenciales exceda 1 pero no exceda 256.
>
>> Se propone que se cambie el párrafo referente a las asignaciones /48,
>> de manera que refiera específicamente a asignaciones a grandes
>> empresas y entornos corporativos finales cuyo requerimiento es
>> superior a 256 subredes.
>
>> Se propone que se tome como por defecto la asignación /56, tanto para
>> la definición de Utilización (Punto 2.7 de la política) como para el
>> cálculo del HD Ratio.
>
>> ----------------------------
>
>> LAC-2006-05 HD Ratio IPv6
>
>> Se propone que se cambie el valor del HD Ratio de 0.8 a 0.94, de
>> manera de aumentar los niveles de eficiencia.
>
>> A modo de ejemplo, con un HD Ratio de 0.94 el nivel de utilización
>> requerido para una asignación adicional de un /32 pasa del ya
>> mencionado 10,9% a un 51,4%
>
>> ------------------------
>
>> LAC-2006-08 Asignaciones IPv6 Independientes del Proveedor (PI)
>> para Organizaciones-Usuario-Final
>
>> Resumen:
>
>> Esta politica se presenta como posible solucion para organizaciones
>> que necesitan asignaciones IPv6 independientes del proveedor (en
>> adelante PI).
>
>> Por lo general dichas organizaciones requeriran la asignacion del PI
>> para cumplir con requisitos de multihoming en la forma tradicional
>> utilizada con IPv4, pero puede haber otras razones detrás de dicha
>> peticion. Por ejemplo, algunas organizations no requieren multihoming,
>> pero aun así necesitan que sus asignaciones sean globalmente
>> encaminables con direccionamiento estable.
>> Podria haber el deseo de evitar la renumeracion si cambian de
> proveedor.
>> Esto podria deberse a razones administrativas, politicas o de
>> seguridad. En estos casos, parece que actualmente no hay otra solucion
>> mas que las asignaciones de PI.
>
>> Considerando las consecuencias del medio/largo plazo que esta politica
>> podria ocasionar en las tablas de encaminado, esta propuesta sugiere
>> una fecha de expiracion de tres años para esta politica. Este periodo
>> de tres años comenzaria a contar una vez que exista una solucion
>> tecnicamente viable y operacionalmente desplegable, que sea aceptada
>> por la comunidad de Internet. Tras el periodo de gracia, las
>> asignaciones hechas con propositos de multihoming deberian de ser
>> reclamadas y esta politica deberia de ser modificara para continuar
>> permitiendo las asignaciones que sean requeridas para propositos
>> diferentes al multihoming.
>
>> En dicho momento, cualquier organización que requiera evitar la
>> renumeracion podria optar a convertirse en LIR, si asi cualifica para
>> ello, y se le adjudicaria el mismo prefijo.
>
>> Texto de la Politica:
>
>> Cualificacion para una asignacion IPv6 PI:
>> Para cualificar para una asignacion directa, la organización no debe
>> de ser un LIR IPv6, y debe cualificar para una asignacion o
>> adjudicacion IPv4 por parte de LACNIC. Esto aplica tanto si la
>> organización tiene como si no, asignado o adjudicado dicho espacio
>> IPv4.
>
>> Tamaño de la asignacion IPv6 PI:
>> El tamaño minimo para la asignacion es un /32, aunque un bloque mayor
>> podria ser asignado si se documenta y justifica convenientemente.
>
>> Asignaciones subsecuentes:
>> Siempre que sea posible, sucesivas asignaciones se realizarian de un
>> bloque de direcciones adyacente, pero solo si se documenta y justifica
>> convenientemente.
>
>> "Super-Bloque" de asignacion:
>> Las asignaciones seran asignadas desde un "super-bloque" separado para
>> facilitar a los RIR el filtrado de las mismas, si fuera requerido.
>
>> Expiracion de las asignaciones:
>> Los bloques asignados mediante esta propuesta como solucion para
>> multihoming, deben ser devueltos a LACNIC en un plazo maximo de tres
>> años.
>> El periodo de tres años comienza una vez que haya una solucion
>> tecnicamente valida y desplegable que sea aceptada por la comunidad
>> Internet. Cualquier organización que desee evitar renumerar podria
>> optar a convertirse en LIR, si cualifica para ello, y le seria
>> adjudicado el mismo prefijo.
>
>> Argumentos soportanto la propuesta
>
>> En IPv4, hay organizaciones que cualifican para una asignacion PI, o
>> que podrian optar a ser un LIR. Esto podria ser bien porque necesiten
>> multihoming, o tengan otras razones administrativas o tecnicas para un
>> bloque de direccionamiento portable.
>
>> Este no es el caso, en la actualidad, para IPv6, y se percibe como una
>> clara barrera para su despligue por parte de algunas organizaciones.
>> Esta propuesa de politica pretende evitar dicha barrera por medio de
>> la asignacion directa desde LACNIC.
>
>> Cualquier organización recibiendo dicha asignacion, no podria realizar
>> sucesivas asignaciones a otras organizaciones externas, y por tanto
>> solo podria asignar subredes internamente dentro de sus propias
>> entidades.
>
>> Asignar un /32 permite a estos bloques comportarse como cualquier otra
>> asignacion adjudicada a un LIR, y por tanto seguir las practicas
>> habituales de filtrado de rutas. Al mismo tiempo, los bloques podrian
>> ser facilmente identificables como pertenecientes a un "super-bloque"
>> especial. Esto podria tambien permitir a estas organizaciones
>> convertirse en LIR y evitar la renumeracion.
>
>> Por medio de esta politica, evitamos la creacion de una situacion
>> injusta entre diferentes regiones, y satisfacemos los requisitos de
>> cualquier organización que requiera espacio PI. Todas las
>> organizaciones que opten por este PI, estaran en igualdad de situacion
>> una vez que la comunidad haya aceptado una solucion tecnica a mas
>> largo plazo, y tendran que bien moverse a dicha nueva situacion o bien
>> convertirse en LIR, si cualifican para ello.
>> Las nuevas organizaciones estaran por tanto en la misma situacion.
>> Algunas organizaciones no optaran por PI bajo esta politica, porque
>> realmente no lo necesitan, y la politica impide que esten en una
>> situacion desventajosa.
>
>> Aquellos que no creen en posibles soluciones alternativas, pero en su
>> lugar prefieren una solucion de politica permanente de PI, no tienen
>> razones validas para oponerse a esta propuesta, dado que el plazo de
>> expiracion solo entra en efecto una vez que una solucion valida ha
>> sido aceptada. Esta propuesta, por tanto, no interfiere con sus
>> planes.
>
>> Algunas organizaciones podrian cualificar en este momento para ser LIR
>> y evitar usar esta politica de asignacion temporal. Sin embargo, si la
>> unica razon para convertirse en LIR es obtener un bloque PI, en este
>> caso es mejor facilitar el control de las tablas de encaminado en el
>> largo plazo, mediante el uso de la opcion ofrecida por esta propuesta.
>> Esto seria mas justo con toda la comunidad Internet.
>
>> La naturaleza "temporal" de esta asignacion debe de ser entendida como
>> un largo plazo, dado que esperamos soluciones alternativas que puedan
>> estar disponibles en tres o cuatro años. Este plazo no incluye el
>> periodo de transicion. Por lo tanto, pidiendo un cambio tras un
>> periodo de seis o siete años, deberia de ser totalmente aceptable para
>> todos.
>
>> Argumentos oponiendose a la propuesta
>
>> El posible efecto de esta propuesta es el crecimiento de las tablas de
>> encaminado hasta niveles que, junto a los existentes y previstos en
>> IPv4, podria crear problemas muy importantes para operadores, salvo
>> que los fabricantes pudieran proporcionar productos que solventen los
>> mismos. Aun cuando dichas soluciones tecnicas fueran halladas, la
>> propuesta aun tendria un impacto importante en el coste y/o periodod
>> de amortizacion de las inversiones en infraestructura.
>
>> Por esta razon, esta propuesta tiene un plazo de caducidad, pero
>> respecto de una fecha en la que una solucion alternativa tecnica
>> valida sea aceptada por la comunidad de Internet.
>
>> Una asignacion temporal /32 no deberia de ser vista como un
>> desperdicio de direcciones. Traeria consigo la ventaja de evitar la
>> necesidad de filtros especiales, asi como la de renumeracion de
>> aquellos que lleguen a ser LIR.
>
>> Reconocimientos: Deseo reconocer los comentarios recibidos a la
>> primera version de esta propuesta por parte de Marcelo Bagnulo y Lea
>> Roberts.
>> _______________________________________________
>> Politicas mailing list
>> Politicas at lacnic.net
>> http://www.lacnic.net/mailman/listinfo/politicas
>
>
>
>
> --
> ~~
> Francisco Jose Obispo Semidey
> Jefe de Oficina de NIC-VE - NIC-VE Manager
> Centro Nacional de Tecnologias de Informacion - http://www.nic.ve
> Caracas - Venezuela
>>
- --
~~
Francisco Jose Obispo Semidey
Jefe de Oficina de NIC-VE - NIC-VE Manager
Centro Nacional de Tecnologias de Informacion - http://www.nic.ve
Caracas - Venezuela
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFEV8NXGs0zZ5KMmSMRAlJ5AJwLJWgkBqVkq95E4T94oubo4TsHQwCeJyE5
dA/rgfldjay48ITxkJ4H8P0=
=itkR
-----END PGP SIGNATURE-----
More information about the Politicas
mailing list