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

[Nicolas Antoniello]

Estimados,

Ciertamente lo que comenta Jordi sobre entidades gubernamentales o
similares que delegan internamente a otras (separdas desde el punto de
vista administrativo) es una realidad.
En Uruguay por ejmplo, el servicio de Inforática de la Universidad Estatal
asigna subredes a las diferentes Universidades Estatales quienes a su vez
tienen cada una su propio grupo de TI que luego administra esas
direcciones. No son LIR en lo formal que respecta a Lacnic pero si lo son a
la interna. Y el modelo, por diversas razones, no admite que cada
Universidad pida las direcciones directo a Lacnic... Entre otros porque la
"conectividad" con Internet la brinda el Servicio Central, no hablan
necesariamente eBGP, no pueden hablar iBGP porque son dominios
administrativos diferentres, bla bla bla... Podemos buscar soluciones
alternativas para rodear el hecho, pero hoy es una realidad.

Tal vez debemos tener en cuenta esta situación y analizar el nivel
porcentual de exigencia de argumentación de uso de las direcciones
adaptándonos a estos casos que antes no habíamos considerado.
Sobre todo teniendo en cuenta que muy seguramente las re-asignaciones de
redes IPv6 por parte de los RIR a los miembros no sean ni cerca lo
frecuentes que son para los recursos IPv4 (lo cual reduce notablemete la
carga administrativa dinámica del RIR en este sentido, por decirlo de
alguna manera, pero no afecta el nivel de membresía de quienes tienen
delegadas las redes).

Saludos,
Nico



El Monday, August 29, 2016, JORDI PALET MARTINEZ <jordi.palet at consulintel.es>
escribió:

> Hola Ricardo,
>
> Contesto debajo entre líneas.
>
> Saludos,
> Jordi
>
>
>
> -----Mensaje original-----
> De: Politicas <politicas-bounces at lacnic.net <javascript:;>> en nombre de
> Ricardo Patara <patara at registro.br <javascript:;>>
> Responder a: Lista para discusion de politicas de la comunidad de LACNIC <
> politicas at lacnic.net <javascript:;>>
> Fecha: jueves, 18 de agosto de 2016, 17:23
> Para: <politicas at lacnic.net <javascript:;>>
> Asunto: Re: [LACNIC/Politicas] propuesta de politica LAC-2016-5 - dudas
> para nueva version
>
>     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
>
> Yo creo que si que hay necesidades distintas. Ya he comentado otras veces
> que el caso se ha dado en Europa. Alli se opto por una política con
> requisitos mucho mas “abiertos”, lo que, bajo mi punto de vista, se presta
> a que un ISP se pueda aprovechar de ello y por eso creo que es mas fácil de
> tener una política con dos categorías y requisitos ligeramente diferentes.
>
> En los casos Europeos ello ha demorado la asignación durante varios años,
> a gobiernos. Creo que hemos de ser inteligentes, aprender no solo de
> nuestros errores, sino también de los de los demás, y anticiparnos a que
> eso ocurra en la región.
>
>     >> 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.
>
> Aquí esta la diferencia:
>
> Caso del ISP:
> El plan de direccionamiento no debe superar los cuatro años. Y debe
> considerar el espacio necesario para atender a los clientes y a los
> servicios actuales considerando el prefijo mínimo para asignaciones
> recomendadas en la política vigente.
> Debido a la existencia de múltiples puntos de acceso (POP), el plan de
> direccionamiento puede indicar prefijos mínimos para cada POP. Los prefijos
> mínimos para cada POP deben estar dentro de las "fronteras" binarias de la
> dirección IPv6 (/X, donde X es múltiplo de 4). Sin embargo, el bloque
> previsto para cada POP debe satisfacer por lo menos un 30% de la necesidad
> actual del mismo.
>
> Caso del LIR no-ISP:
> El plan de direccionamiento ha de tener en cuenta la longevidad prevista
> de la organización.
> Debe considerar el espacio necesario para atender a los "clientes", número
> de usuarios, extensión de la infraestructura de la organización, estructura
> jerárquica y/o geográfica de la organización, segmentación de la
> infraestructura por razones de seguridad y a los servicios actuales
> considerando el prefijo mínimo para asignaciones recomendadas en la
> política vigente.
>
> Para ponerlo mas claro:
> - En un ISP el plan de direccionamiento no debe superar los cuatro años.
> Un gobierno planifica a mas tiempo.
> - Un ISP no considera la “jerarquía” de la organización para establecer el
> plan de direccionamiento. En un gobierno si que ha de ser considerado.
> Igualmente los otros puntos.
>
> Insisto, me baso en CASOS reales ocurridos en Europa. No en algo
> imaginario.
>
>     >> 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.
>
> Se que SI se establecen tarifas diferentes, eso lo tiene que hacer el
> directorio, pero si hay una categoría diferente, seria una labor mucho mas
> sencilla. Yo no estoy indicando que tenga que ser como parte de la
> política, simplemente, la política también facilita esa opción si se desea
> que asi sea. Ademas la tarifa actual del 50% solo aplica a usuarios finales
> y además NO-gubernamentales, y precisamente lo que estamos viendo es casos
> que NO son usuarios finales, y que por lo que consta, hasta ahora,
> erróneamente, han sido asi clasificados, pues no se ha entendido bien que
> un usuario final NO puede entregar recursos a otras organizaciones.
>
>     >> 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.
>
> Si, aquí no hay diferencia. Obviamente el objetivo es que se anuncie
> agregado siempre que sea posible.
>
>     > 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
>
> Es posible que en este caso, si el bloque que ha solicitado era un /32, o
> hasta /28, y el plan de direccionamiento fuera para 4 años, la política
> “funcionase” (desconozco los detalles y no se si se quieren hacer
> públicos), pero los casos en los que pienso son mucho mas grandes, mas
> completos, tienen planes de direccionamiento para muchos mas años, etc.
>
>     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.
>
> Estoy seguro que si revisamos esas asignaciones, descubriríamos que,
> erróneamente, se han podido entregar recursos como usuario final y que sin
> embargo están siengo asignados a otras organizaciones del propio gobierno.
> Insisto, son organizaciones diferentes administrativamente hablando.
>
>     | 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.
>
> Yo creo que no complicamos el manual, al revés, lo simplificamos, evitamos
> la confusión, creamos una categoría diferente para estos casos, se evita
> que surja la duda de si son usuarios finales, y se les permite planes de
> direccionamiento mas coherentes con el tipo de entidad y no limitados a una
> expansión comercial que lógicamente no les aplica porque no son entidades
> comerciales.
>
>     un abrazo
>     Ricardo Patara
>     _______________________________________________
>     Politicas mailing list
>     Politicas at lacnic.net <javascript:;>
>     https://mail.lacnic.net/mailman/listinfo/politicas
>
>
>
>
>
>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net <javascript:;>
> https://mail.lacnic.net/mailman/listinfo/politicas
>