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

Mon Aug 29 14:00:28 BRT 2016

Hola Ricardo,

Contesto debajo entre líneas.

Saludos,
Jordi

-----Mensaje original-----
De: Politicas <politicas-bounces at lacnic.net> en nombre de Ricardo Patara <patara at registro.br>
Responder a: Lista para discusion de politicas de la comunidad de LACNIC <politicas at lacnic.net>
Fecha: jueves, 18 de agosto de 2016, 17:23
Para: <politicas at lacnic.net>
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
    https://mail.lacnic.net/mailman/listinfo/politicas