[LACNIC/Politicas] propuesta de politica LAC-2016-5 - dudas para nueva version

Ricardo Patara patara at registro.br
Thu Aug 18 12:23:49 BRT 2016


Hola Jordi, te contesto a continuación.

>> Como recordatorio, el enlace de la misma es:
>> https://politicas.lacnic.net/politicas/detail/id/LAC-2016-5
>
>> 1) Hay organizaciones que son LIRs, pero no son ISPs (en el contexto
>> tradicional que todo entendemos). Por ejemplo un gobierno, o entidad
>> internacional. Tampoco son usuarios finales porque entregan recursos IPv4
>> y/o IPv6 a otras entidades.
>
> En el texto de políticas de LACNIC hay ya una defincion de LIR que creo
> atender ese caso que comentas:
>
> "Registro de Internet Local (LIR) es un IR que a su vez asigna recursos de
> Internet a usuarios de los servicios de red que éste provee. Los LIRs son
> generalmente ISPs, cuyos clientes son principalmente usuarios finales y
> posiblemente otros ISPs."
>
> Quizás seria necesario entonces ajustar solamente el titulo del punto 2.3.3.1
> para :
>
> "2.3.3.1. Distribución inicial a ISPs o LIRs"


| Entiendo lo que dices, pero el caso que intento describir, tiene un contexto
| mas amplio, porque no solo es el titulo sino los requisitos para asignar
| recursos, por eso no basta con cambiar el titulo.

comprendo.
mi intención era decir que si no hay necesidades "distintas" entre ISPs y LIRs, 
los cambios serian solamente ajustar el titulo del 2.3.3.1


>> Por ejemplo. No es lo mismo el Ministerio de Telecomunicaciones del pais
>> “x”, si recibe los recursos SOLO para su propio uso (caso a), que el
>> Ministerio de Administración Pública del mismo pais, si recibe los recursos
>> porque gestiona una red que conecta todos los Ministerio y otros organismos
>> públicos del país, y les entrega a cada uno de ellos recursos (caso b).
>>
>> En el caso a, esta claro que dicha entidad califica bajo la politica de
>> usuario final.
>>
>> En el caso b, esta entidad seria un LIR, pero no es un ISP en el sentido
>> estricto de la palabra, pues no ofrece servicios a cualquier otra entidad
>> fisica o jurídica, sino a entidades dentro de “un club” especial, en el
>> caso del ejemplo, organismos publicos.
>
> el texto de la politica no hace esa distincion del tipo de "cliente" del
> LIR/ISP.
>
> considera "clientes conectados a su red" y en ese caso especifico un
> ministerio, por ej, seria un cliente de la red del gobierno.

| Totalmente de acuerdo, pero el punto aquí es que si ponemos requisitos
| diferentes para un ISP que para otro tipo de LIR, y dejamos un único “tipo”,
| el texto de los requisitos se vuelve altamente complicado, además (sigo con
| el costo …)

okay, pero sigo con el punto de que no son diferentes los requisitos ni las 
necesidades.

>> Mi propuesta pretende aclarar esta situacion, con una categoria nueva
>> diferente de ISP, aunque es muy similar a un ISP. Sin embargo opino que
>> una nueva categoria permite que la membresia establezca, si es necesario,
>> una diferenciacion en el coste de los recursos, y que se establezcan otras
>> diferencias como pueden ser el criterio de adjudicación de dichos
>> recursos.
>
> hay que tener un cuidado aqui pues las políticas no establecen costos de
> asignación o categorias. eso cabe al directorio y asemblea de miembros
>

| Efectivamente, lo tengo perfectamente claro, pero si hay dos tipos de LIR
| (ISP y no-ISP), eso obliga a que tengan el mismo “costo”, porque no hay forma
| de diferenciarlos. Y yo creo que el costo no debe ser el mismo, me explico.

| a) Un usuario final tiene un costo menor, asumo porque NO hace “lucro”
| directo con los recursos asignados. Aún asi, el costo actual parece
| excesivamente bajo, pero eso es otro tema para debatir precisamente en el
| directorio y asamblea, simplemente lo comento. b) Un ISP, obviamente, su
| negocio es “dar servicios” con esos recursos, y es lógico que tenga un costo
| mucho mas alto. c) Un LIR que NO sea ISP, al igual que un usuario final NO
| hace “lucro” directo con los recursos asignados. Creo que debería tener un
| costo inferior al de un ISP y para ello, creo que el directorio y la asamblea
| “necesitan” una categoría diferente de LIR, distinta de ISP, para poder
| hacerlo. Sino, es incluso administrativamente difícil tener dos precios según
| seas LIR o ISP.

comprendo.
pero como dije, el tema de costos, tarifas, etc no cabe en el foro.

agrego que lacnic tiene tarifas especiales para organizaciones sin fines de 
lucro que sean usuarios finales.
quizas el directorio podria estudiar algo similar para LIRs. Pero eso no nos 
cabe discutir aqui.

>> 2) Este tipo de organizaciones (caso b), tiene unos requisitos que no son
>> los mismos que los de un ISP. Por ejemplo, la consideración de “clientes”
>> no es tal, y la extension de la infraestructura, su estructura jerárquica,
>> la necesidad de entregar bloques mas pequeños a cada “sub-organización”
>> (cad ministerio, cada entidad del gobierno, etc.).
>
> no queda claro que requisitos son distintos para los clientes del LIR
> comparados con clientes de un ISP.
>
> clientes del NIR son clientes de una red que esperase sea jerárquica. y por
> las politicas vigentes, el LIR podría entregar bloques a dichos clientes
> (sean bloques pequenos o grandes) de acuerdo a la necesidad de cada cliente.
>

| Si comparas el texto de la política actual con el que propongo para la nueva
| sección, veras esas diferencias. Para no complicarlo en este email creo que
| lo podemos debatir aparte, una vez tengamos claro si hace falta una nueva
| categoría o no para que el directorio pueda establecer otro “rango” de
| precios.

ok

>> El gobierno de nuestro ejemplo, podria optar por hacer multiples peticiones
>> a LACNIC para cada una de las entidades, y luego anunciarlas de forma
>> agregada, etc., pero es un trámite administrativo y tecnico innecesario y
>> no siempre posible, porque puede que haya ministerios sin personal
>> especifico para eso, o muchas otras razones que lo hacen poco practico, o
>> incluso que los prefijos asignados por LACNIC no fueran contiguos, etc.
>> Todo ello sin contar la carga de trabajo de realizar “n” peticiones y
>> justificaciones a LACNIC en lugar de una sola.
>>
>> Se trataria de una peticion de “n” recursos, sumamente “artificial” si lo
>> quereis entender de este modo.
>
> a ver si comprendi ese punto lo que propones es seria una politica que le
> permita asignar un rango de prefijo X para un gobierno (LIR), para que en
> seguida sea divido en rangos menores de prefijos X+Y a entidades del goberno
> que por su vez van a anunciar dichos prefijos X+Y a sus provedores de
> transito particulares.

| NO, al contrario. Quiero evitar eso. Ahora mismo un gobierno podría pedir (un
| ejemplo) un /32 para cada ministerio. Y obtendría n x /32, que si te fijas
| serian a un costo ridículo comparado con si pide lo mismo, pero agregado,
| como LIR (con el texto actual). Por eso creo que hay que 1) evitar esta
| petición “artificial”, 2) Permitiendo asi que tenga una clasificación de
| costes que pudiera ser diferente a la de ISP y diferente a la de usuario
| final (quizás algo intermedio).

ok
entonces es parecido con el esceneario de un ISP.

Ese recibe un /28 por ejemplo y internamente lo divide en prefijos más largos 
(bloques menores) para sus clientes.
Pero en anuncio a la DFZ es un /32 agregado.

> o sea, el gobierno no actuaria como provedor de conectividad en su ejemplo?
>

| Precisamente, el gobierno en estos casos que propongo, ES el proveedor de
| conectividad (típicamente con multihoming, etc.).

ok

> eso implicaria en asignar un prefijo que se verá desagregado al final en la
> tabla. Es eso mismo?

| Intento evitar esa desagregación. Creo que lo has “leído” justamente al
| revés. Intento evitar también que se pidan “n” /32 y luego se anuncien
| agregados (si son contiguos). No hay necesidad que obligar al gobierno a
| hacer “cosas raras”.

ok, comprendido.

>> Mi propuesta pretende, partiendo de los requisitos de la politica para
>> ISP, establecer otros mas apropiados para este caso, que ademas se basan
>> en modificaciones recientes a los requisitos habilitados para gobiernos
>> Europeos en RIPE NCC, atendiendo precisamente a casos concretos y que ya
>> hemos visto en la region y sin embargo se han asignado recursos como
>> usuarios finales EN CONTRA de la politica actual, porque no son usuarios
>> finales sino que entregan recursos a otras organizaciones.
>
> para que la discusion sea más productiva, podrias indicar estos casos
> concretos en nuestra región que mencionas que se asigno en contra la
> política?

| En el ultimo LACNIC, precisamente en el foro de políticas e incluso en una
| presentación previa, se hablo de un par de casos de gobiernos, no recuerdo
| todos ahora mismo, pero uno de ellos era Panama. Les pregunte en el foro
| publico un par de veces para asegurarme y confirmaron que habían recibido un
| prefijo /32 como usuario final, pero que ellos entregaban “trozos” de ese
| prefijo a las diversas entidades, y les proporcionaban conectividad. Eso
| claramente va en contra de la política de usuario final, porque NO se permite
| entregar a OTRAS entidades, y confirmaron que LEGALMENTE cada entidad a la
| que asignan direcciones son entidades DIFERENTES. Queda claro que mi
| intención es que se corrija la situación, de hecho, quizás, con la política
| actual, en este caso concreto, se debería recalificar ese /32 como ISP y que
| abonen la diferencia de precio.

okay.
en ese caso hay que ver con lacnic qué fue solicitado y que justificativa 
presentaron.
puede haber pasado que ellos mismos lo solicitaron como END USER.

lo que solicitaba era un ejemplo de govierno que haya solicitado como ISP y se 
les recuso.

te comento, que en brasil tenemos una empresa del govierno que actua como 
provedor de servicios y conectividad para organos del govierno y que ha recibido 
un bloque grande como uns ISP governamental.

o sea, la política se le permite

no veo que puntos en el texto le impediria un govierno (atraves de su 
empresa/organo/departamento tecnico) solicitar a lacnic un bloque como ISP se le 
fuera denegado.

| Estoy casi seguro que en otros países se ha dado el mismo caso, pero no
| quiero hablar de esos casos sin tener una constancia tan explicita como en
| este caso.

como te comente arriba, hay casos concretos donde se paso el contrario.

| Yo creo que o bien porque el precio es mucho menor, o bien porque no se
| conocen bien las políticas, los que piden recursos pueden a veces
| aprovecharse de la diferencia de precio o bien como digo sin conocimiento,
| para no explicar que “se van a entregar recursos a otras entidades” o bien
| que no se dan cuenta que “otras” entidades del gobierno, son PRECISAMENTE
| otras entidades. No se si me explico …

ok
pero en ambos los casos la solucion puede ser otra que no la de crear nuevo 
texto (y desde mi humilde opinion, complicar el manual de políticas)

si el problema es el costo, los miembros deben solicitar al directorio una 
revisión de las tarifas.

si el problema es comprender las políticas, se pueden hacer tutoriales, 
workshops, conferencias o incluso incluir estos temas en las reuniones que 
lacnic ya hace con gobiernos.

un abrazo
Ricardo Patara



More information about the Politicas mailing list