[LACNIC/Politicas] propuesta de politica LAC-2016-5 - dudas para nueva version
JORDI PALET MARTINEZ
jordi.palet at consulintel.es
Tue Aug 30 12:30:30 BRT 2016
Si, como comente en otros de los emails, a mi me parecio mejor crear una nueva categoría, porque en caso contrario, el defecto que le veo a la política de RIPE es que un ISP podría aprovecharse de algunos puntos que no están pensados para su caso, por ejemplo “planned longevity of the allocation”.
Como lo planteo yo parece mas complicado, pero en realidad “protege” mejor los recursos de LACNIC frente a peticiones a mas largo plazo de ISP, que en LACNIC están fijadas cada 4 años para ese caso.
O prefieres eliminar del caso de los ISPs, los 4 años y otras cosas?
O la otra alternativa, dejar solo una categoría de ISP/LIR (cambiando el titulo como tu proponías) y poner “dos” subsecciones diferentes, una para el caso de ISP y otra para el caso de LIR (no-ISP).
Esta claro que los requisitos son diferentes no crees?
Obviamente, dado que el resto de la política es diferente entre LACNIC y RIPE NCC no tiene mucho sentido “copiar” literalmente lo que aquí se ha hecho.
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: martes, 30 de agosto de 2016, 17:22
Para: <politicas at lacnic.net>
Asunto: Re: [LACNIC/Politicas] propuesta de politica LAC-2016-5 - dudas para nueva version
Oka, comprendi.
Pero el unico cambio implementado fue ese:
antes:
[...]
"the allocation size will be based on the number of existing users and the
extent of the organisation's infrastructure.
ahora:
[...]
"the allocation size will be based on the number of users, the extent of the
organisation's infrastructure, the hierarchical and geographical structuring of
the organisation, the segmentation of infrastructure for security and the
planned longevity of the allocation."
o sea, no se cambia el concepto de LIR
no veo como ese ejemplo de lo que habrá pasado en Europa sirve de base como para
el cambio que estás a proponer en LACNIC.
Creo hasta que el texto de la propuesta en RIPE es buena e podria se aplicada a
LACNIC. Pero eso no es lo que figura en tu propuesta. Tu propuesta usa esa idea
para crea un otro parrafo. Lo que especificamente, para mi, no es necessario
un abrazo
Ricardo Patara
On 30/08/2016 12:01, JORDI PALET MARTINEZ wrote:
> No, no. Es una propuesta que se presento y aprobó hace año y medio, y esta implementada.
>
> Los enlaces que te he pasado son antiguos para que puedas seguir la discusión desde el primer momento.
>
> 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: martes, 30 de agosto de 2016, 16:57
> Para: <politicas at lacnic.net>
> Asunto: Re: [LACNIC/Politicas] propuesta de politica LAC-2016-5 - dudas para nueva version
>
> Gracias Jordi,
> Voy a leerlo.
>
> Entonces para aclarar, tratase todavía de una propuesta y no un texto ya
> implementado.
>
> Habia compreendido que era algo ya en operacion.
>
> gracias y abrazos
>
> Ricardo Patara
>
> On 30/08/2016 11:48, JORDI PALET MARTINEZ wrote:
> > Hola Ricardo,
> >
> > Esta fue la propuesta de RIPE:
> >
> > https://www.ripe.net/participate/policies/proposals/2015-03
> >
> > Y aquí esta la discusión en la lista, cuya lectura puede aclarar mas lo que estoy diciendo:
> >
> > https://www.ripe.net/ripe/mail/archives/address-policy-wg/2015-April/009852.html
> >
> >
> > El resto contesto debajo.
> >
> > 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: martes, 30 de agosto de 2016, 15:19
> > Para: <politicas at lacnic.net>
> > Asunto: Re: [LACNIC/Politicas] propuesta de politica LAC-2016-5 - dudas para nueva version
> >
> > Hola Jordi,
> >
> > > >> 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.
> >
> > podrías indicar cual es la parte de las políticas de ripe que atienden esa
> > necesidad?
> >
> > la busque y no la encontre.
> >
> > | 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.
> >
> > no estoy muy de acuerdo.
> > la forma de operación de un rir no debe ser tomada de regla para todos los demás.
> >
> > como te comento, ya hubieron asignaciones así en nuestra región y ellas no tardarón.
> >
> > Se que un RIR no necesariamente tiene que tener las mismas políticas que los demás, pero cuando sucede un problema en una región y se ve que puede ocurrir en otra, hay que aprovechar la ocasión, bajo mi punto de vista. Por eso además, mi propuesta no es exactamente igual. Por ejemplo en RIPE se emplea /29 como punto de partida, porque se pensó que habría mucho despligue de 6rd, y no fue asi en la mayoría de los casos.
> >
> >
> > > >> 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.
> >
> > ese es el plazo maximo en la justificatiba para una asignación.
> > eso es para impedir asignaciones que lleven en cuenta planes de utilización
> > fuera de la realidad (por ejemplo, indicar la necesidad de IPs para 15 años,
> > algo no muy real)
> >
> > y eso no impedi el ISP de regresar y solicitar más cuando haya utilizado lo que
> > se les asigno considerando el plan incial de 4 anos, por ejemplo
> >
> > Un gobierno NO es un ISP. Lo que quiere es hacer el plan de direcciones COMPLETO para todo el país, con una estructura jerarquica, geográfica, etc., adecuada aunque el despliegue se haga en 8 años en lugar de 4. Precisamente lo que se pretende evitar es que cuando el gobierno hace la mitad del despliegue en 4 años, no tenga que volver para hacer el resto y afecte a su plan de direccionamiento.
> >
> > | 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.
> >
> > ok
> >
> > | Caso del LIR no-ISP: El plan de direccionamiento ha de tener en cuenta la
> > | longevidad prevista de la organización.
> >
> > ok, pero te parece que un plan de la necesidad de una organización así
> > (gobierno, por ejemplo), y que considere cuanto va a necesitar hasta 4 años sea
> > falla?
> >
> > o sea, que no logren planear su necesidad para hasta 4 años?
> >
> > y dudo que un gobierno cresca mucho más que un ISP comercial, por ejemlo.
> >
> > un ISP comercial van a intentar crecer en clientes y servicios
> >
> > un gobierno no! Quizas tener algunos nuevos departamentos, pero nada que no se
> > pueda presentar en un plan para 4 años
> >
> > Eso es!, posiblemente no crezca, esa es la idea, pero para ello necesita poder tener el plan de numeración coherente a mucho mas largo plazo. O de hecho, que si ha pedido un /32 para cada uno de los ministerios (por ejemplo), aunque inicialmente solo se usara el 30% de ese plan, ya tiene disponible ese crecimiento para muchos años.
> >
> > | 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.
> >
> > un ISP también debe considerar estos puntos.
> >
> > un ISP de grande cobertura, quizas nacional, tiene que llevar todo eso en
> > consdieración. No es exclusivo de ese ejemplo de LIR gobernamental.
> >
> > | Para ponerlo mas claro: - En un ISP el plan de direccionamiento no debe
> > | superar los cuatro años.
> >
> > eso para indicar su necesidad a cada solicitud
> >
> > | Un gobierno planifica a mas tiempo.
> >
> > nuevamente, no veo un govierno creciendo mucho. no veo como un plan considerando
> > la necesidad hasta 4 años sea tan complicado.
> >
> > imaginemos un gobierno que inicie su solicitud hoy y considere lo que tiene
> > "hoy" de departamentos, empresas de TI, oficinas, universidades que serán sus
> > clientes de conectividad, y todo más. Para ellos todos haga un buen plan
> > considerando la red existente, numero de "usuarios", etc y en ese plan ponga una
> > medida de crecimiento.
> >
> > no veo eso cambiando mucho después de 4 anos.
> >
> > esa red, diferentemente de un ISP comercial, no tiene planes de crecimento.
> >
> >
> > | - 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.
> >
> > no estoy de acuerdo. un isp comercial *SÍ* tiene que considerar todo eso.
> > si no lo hace, está muy mal en su topologia de ruteo interno.
> >
> > No me refiero a jerarquía de red, sino de organización. Cada ministerio, por su cuenta puede pedir /32 como usuario final. Entonces, si hay 40 ministerior y organismos públicos, podrían pedir 40 veces /32, es decir /26. Se trata de que puedan pedir /26 de una sola vez.
> >
> > | Insisto, me baso en CASOS reales ocurridos en Europa. No en algo imaginario.
> >
> > y yo insisto también :-)
> > presentenos un caso donde una solicitud haya sido rechazada en LACNIC que
> > justifique dicho cambio
> >
> > Entonces, queremos esperar a que ocurra y le explicamos a ese gobierno que NO se le puede asignar, porque no existe una política y en ese caso tiene que esperar 6 meses o un año para hacerlo? Asi queremos ayudar al despliegue cuando sabemos que esto puede ocurrir, como ha ocurrido en otras regiones?
> >
> > Las políticas tienen que ANTICIPARSE a las situaciones, no al revés. Sino, casi nunca haríamos muchas de las políticas que hemos hecho, entre otras cosas, porque a quien le ocurre un caso no siempre lo reporta en publico, y menos aun presenta una propuesta de política. Mentira e intentara obtener esos recursos de otra forma, si es el caso.
> >
> > > >> 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.
> >
> > no veo eso como un argumento valido para sugerir cambios en las políticas
> > pienso que debemos nos atentar a los puntos técnicos.
> >
> > > >> 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.
> >
> > ok, pueden ser más grandes en necesidad de IPs, pero si indican su estrutura, su
> > necesidad, usuarios, etc al dia de HOY un ponen ahí un incremento de lo que
> > piensan en "crecer" hasta 4 años no veo como eso pueda fallar.
> >
> >
> > > 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.
> >
> > ok, puede ser.
> > pero pienso que las propuestas deben estar basadas en casos concretos, en
> > necesidades concretas y no suposiciones :-(
> >
> > No estoy de acuerdo, las políticas tienen que anticiparse a problemas que pueden ocurrir. Eso no quiere decir, abrir la mano a todo lo que se nos ocurra, pero cuando hay casos reales en otras regiones, es bueno anticiparse y evitar que haya demoras o que se pidan recursos de formas alternativas.
> >
> > > | 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.
> >
> > comprendo lo que decis,
> > pero nuevamente, no veo como eso se hace diferente de lo que ya tenemos
> >
> > abrazos
> > _______________________________________________
> > Politicas mailing list
> > Politicas at lacnic.net
> > https://mail.lacnic.net/mailman/listinfo/politicas
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > Politicas mailing list
> > Politicas at lacnic.net
> > https://mail.lacnic.net/mailman/listinfo/politicas
> >
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>
>
>
>
>
>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> https://mail.lacnic.net/mailman/listinfo/politicas
>
_______________________________________________
Politicas mailing list
Politicas at lacnic.net
https://mail.lacnic.net/mailman/listinfo/politicas
More information about the Politicas
mailing list