[LACNIC/Politicas] Nueva propuesta LAC-2019-9 / Nova proposta LAC-2019-9 / New proposal LAC-2019-9
Gianina Pensky
gianina at lacnic.net
Wed Aug 7 11:17:06 -03 2019
Estimados,
Con respecto a la consulta realizada en los correos anteriores:
El staff analiza cada caso con sus particularidades, por lo cual
prefiere no opinar sobre casos genéricos, pues usualmente se omiten
detalles que pueden ser determinantes. Si hubiera un caso real que
debamos atender, agradecemos que nos lo compartan y podremos analizarlo
con mayor detalle.
De cualquier forma, acercamos las referencias del Manual de Políticas y
del Acuerdo de Servicios al respecto:
* En el Manual de Políticas, los puntos:
o 1.9. Asignar
/Asignar significa delegar espacio de direcciones a un usuario
final, para su uso exclusivamente dentro de la infraestructura
que opera, así como para fines de interconexión. La asignación
de espacio de direcciones es sólo para el uso por el receptor
original de dicha asignación, así como para dispositivos de
terceros, siempre y cuando estén operando dentro de dicha
infraestructura/.
o 2.3.3.4.Asignaciones a Usuarios Finales/
//LACNIC asignará bloques de direcciones IPv4 a usuarios finales
que requieren espacio//
//de direcciones IPv4 para su uso interno, para el
funcionamiento de sus redes. /
* En el Acuerdo de Servicios, cláusula 2: /En caso de que el
Solicitante sea un Proveedor de Servicios de Internet, el
Solicitante acuerda que las direcciones IP serán usadas únicamente
para su infraestructura interna o para asignar a los clientes a los
que el Proveedor de Servicios de Internet está proveyendo servicios
de acceso a Internet./
Quedamos atentos a cualquier consulta.
Saludos cordiales,
--
Ing. Gianina Pensky
Coordinadora de Políticas y Capacitación
Coordinator of Policies and Training
LACNIC -http://www.lacnic.net
Latin American and Caribbean Internet Addresses Registry
El 2/8/19 a las 18:31, Fernando Frediani escribió:
> Hola Jordi
>
> On 02/08/2019 17:28, JORDI PALET MARTINEZ via Politicas wrote:
>> Hola Fernando,
>>
>> Antes de nada, te recuerdo que lo que estamos discutiendo NO esta
>> siendo modificado por esta propuesta. Lo digo porque son aspectos que
>> pueden confundir y optar a "no apoyar" la propuesta e incluso
>> "oponerse" y que no estarían justificados, porque habría que ir a la
>> raíz del problema, que está en otras partes del texto del manual de
>> políticas.
> Como la propuesta trata sobre la recuperación de recursos, estoy
> tratando de discutir temas pertinentes relacionados con el sujetopara
> que, si corresponde, se incorporen al texto.
>>
>> Eso no quiere decir, que si encontramos una forma de resolverlo en la
>> propuesta, me parezca bien adaptar el texto, o incluir nuevos cambios
>> en otras partes del manual, pero estaríamos complicando mucho mas una
>> propuesta, que ya de por si es larga y compleja.
>>
>> El 2/8/19 19:26, "Politicas en nombre de Fernando Frediani"
>> <politicas-bounces at lacnic.net en nombre de fhfrediani at gmail.com>
>> escribió:
>>
>> Hola Jordi
>> Respondo todos los puntos pronto abajo:
>> - Alquiler de direcciones IP: Esperemos un posicionamiento
>> del staff con
>> respecto a la interpretación. Desde mi punto de vista, el
>> arrendamiento
>> de direcciones IP de un ASN a otro es injustificable en cualquier
>> situación y demuestra que el ASN que posee los recursos no tiene
>> uso
>> para esas direcciones. Es decir, sería razonable que si LACNIC
>> le pide a
>> un ASN que justifique el uso de sus direcciones, él responde:
>> "De /22
>> que poseo, alquilaré 1 x /24 para ASN A, otro /24 para ASN B,
>> otro para
>> ASN C, etc. ?
>>
>> Concuerdo contigo, pero también entiendo que hay casos en los que un
>> ISP pide direcciones, su negocio "decrece" y aunque lo razonable
>> sería devolverlas, pensando en que vuelva a crecer en el futuro,
>> puede optar a "alquilarlas" mientras, porque sabe que LACNIC no le
>> podrá entregar en el futuro. No lo justifico, lo ideal sería la
>> devolución, pero esto no se ha hecho en ningún RIR, y sin embargo, me
>> consta que hay "leasing" de direcciones en todo el mundo (no he
>> investigado si las políticas de los 5 RIRs lo permiten o no, de ahí
>> mi pregunta al staff).
> Creo que el alquiler de bloques de IP no es aceptable en ninguna
> situación. Si un ASN no puede justificar sus asignaciones basadas en
> el alquiler para un ASN tercero, esto no puede hacerse bajo ninguna
> circunstancia, ni siquiera temporalmente. La ASN que quiere alquilar
> estas instrucciones tiene condiciones de ir directamente al mercado a
> comprarlas, es su única opción.
>
> Y si no es aceptable, entonces debe quedar claro en la propuesta que
> en esta situación también se pueden recuperar las direcciones. Este es
> mi punto.
>
>>
>> <clip>
>> - Transferencia de direcciones: Cuando un ASN solicita la
>> transferencia
>> permanente de parte de sus direcciones, está asumiendo ante
>> LACNIC que
>> ya no tiene uso para esas direcciones y está dispuesto a renunciar,
>>
>> Esta dispuesto a renunciar porque existe la posibilidad de una
>> transferencia, pero obviamente es muy raro que alguien haga una
>> transferencia sin haber comprobado la necesidad (por parte de LACNIC)
>> de su "receptor", y si no hubiera política de transferencias, seguro
>> que nadie estaría dispuesto a renunciar.
> Desde el momento en que un ASN le dice a LACNIC: "Solicito la
> transferencia de parte de mis bloques a ASN B" es lo mismo que decir
> "Ya no necesito usar este bloque" y, por lo tanto, si ASN B no puede
> probar lo uso, el es necesario tener claro en esta política de
> recuperación que este bloque se devolverá a LACNIC.
> En mi opinión, esto está en línea con la causa de la revocación en el
> ítem 7 donde dice "**Recursos no utilizados** o anunciado".
> Dependiendo del posicionamiento del staff, es posible que se deba
> realizar cambios en la política para garantizar que se realicen estas
> devoluciones.
>>
>> independientemente de si el ASN de destino puede justificarlo o
>> no. Si
>> el ASN de destino justifica que se les transfieran estas
>> direcciones
>> bien. Si el ASN de destino no justifica entonces estas direcciones
>> deberían recuperarse e ir al pool de direcciones para ser
>> redistribuidas
>> de acuerdo con 11.1.
>>
>> Entiendo que te refieres al punto 11 completo (no al 11.1). Aunque
>> entiendo tu razonamiento, si no me equivoco en ningún párrafo del 11
>> se indica que haya obligación de devolver los excedentes de
>> direcciones. Lo que tu estas comentando tendría que ir en la sección
>> de IPv4 del manual, no en la 11, ni en la 7.
> Esto no es lo que dije sobre 11.1. Dije que direcciones recuperadas
> deben ir al pool de LACNIC para luego ser distribuida a nuevos
> entrantes o infraestructura crítica como se hace normalmente.
>>
>> No creo que sea necesario modificar la política de
>> transferencia. Solo
>> aplicar la política de recuperación basada en el hecho de que el
>> ASN
>> "donante" ha asumido para LACNIC que no tiene uso para esas
>> direcciones
>> y ya no las justifica mas.
>>
>> Fíjate en el texto de las transferencias:
>> 2.3.2.18.2. Para que una entidad dentro de LACNIC, pueda ser el
>> destinatario de una transferencia, debe pasar ****primero**** por el
>> proceso de justificación de recursos IPv4 ante LACNIC. Es decir, la
>> entidad debe justificar ante LACNIC la distribución/asignación
>> inicial/adicional, según sea el caso, de acuerdo a las políticas
>> vigentes.
>> Por lo tanto, no se da el caso de que alguien quiera transferir
>> *antes* de saber que el receptor ya puede *recibir*.
>>
>> Es decir, el proceso lógico es que primero el "receptor" comprueba si
>> cumple la necesidad. Luego busca un "proveedor". Puede que ya sepa
>> quien o quienes son sus propios proveedores (porque los brokers lo
>> han buscado, o él mismo).
> No Jordi, creo que te equivocas.
> Cualquier transferencia quien solicita y aprobar es el titular de la
> asignación, por lo que primero debe decir para LACNIC que tiene un
> bloque disponible para transferir a otro ASN, y por lo tanto está
> asumiendo que ya no tiene uso para ese bloque.
> Lo que dice el texto de la política de transferencia es que **para que
> se realice la transferencia**, el ASN receptor debe primero justificar
> el uso. Apenas eso y es bastante obvio.
> O de lo contrario, ¿cómo justificará un ASN receptor el uso de un
> bloque sin saber cual bloque y el tamaño ya que el ASN "donante" no ha
> dicho oficialmente qué bloque está "donando"?
>>
>> En este caso creo que la propuesta se ajuste a la causa:
>> "Recursos *no
>> utilizados* o anunciados". Es posible que tal vez esto deba
>> hacerse aún
>> más claro en la propuesta si aún no se hace de esta manera.
>>
>> El "proveedor" de los recursos puede estar usándolos ahora para hacer
>> dual-stack, y pasar a 464XLAT y por lo tanto necesita menos
>> direcciones. Con lo que recibe por la transferencia, cubre parte de
>> su coste de pasar a IPv6-only, sino no lo haría.
> Incluso si realiza esta migración y requiere menos direcciones , aún
> puede haber justificación para mantener esas direcciones para uso
> futuro o uso en otros servicios o expansión inminente. Esto es
> bastante diferente de un ISP que dice "No tengo uso para este bloque y
> estoy dispuesto a transferirlo para siempre a ASN B". Si ASN B no
> puede justificar, entonces es lógico que este bloque no utilizado
> regrese a LACNIC
>>
>> - Incumplimiento causado por terceros: Sí, el primer
>> ejemplo y el
>> ejemplo del whois que diste tienen sentido de que el ASN no sea
>> castigado.
>> Sin embargo, no puedo estar de acuerdo con el ejemplo de que una
>> transferencia realizada por un empleado no autorizado no se
>> puede revertir.
>> Si no hubo autorización del ISP A para la transferencia, el
>> mayor daño
>> es del ISP A y no del ISP B. Además, no es el ISP B el que debe
>> saber si
>> el empleado está autorizado o no, sino solo LACNIC.
>>
>> Este ejemplo tiene que ver con casos de engaño, estafa, el empleado
>> falsifica documentos o credenciales. Obviamente LACNIC, el ISP A y el
>> ISP B, son todos engañados. Todos tienen "un daño", pero nadie es
>> culpable (salvo que haya connivencia con ese empleado).
> Si, de acuerdo. En este caso, todo debe revertirse como estaba antes
> del fraude o error.
>>
>> También creo que si dicha transferencia no se puede revertir a
>> petición
>> del propio ISP A, esto será en detrimento no solo para él sino
>> para toda
>> la comunidad de la misma que pueda sucederle a cualquier otro ASN.
>>
>> Es posible que el ISP A estuviera en medio de una transición de
>> dual-stack a IPv6-only. Y por eso esas direcciones estaban
>> disponibles. Quizás estaban reservadas para clientes corporativos,
>> porque el ISP A quería crecer en ese sector, y en este caso era más
>> lógico el incentivo de ofrecerles direcciones IPv4 persistentes.
> No entiendo la relación de uso con la posibilidad de error causado por
> un empleado. El punto aquí es solo que si una transacción se lleva a
> cabo por error causado por un empleado no autorizado, debe revertirse,
> independientemente del posible daño a ASN B. En este caso, el mayor
> perdedor siempre será ASN A.
>>
>> Como tal, no estoy de acuerdo con la política como escrito
>> y creo que
>> necesita algunos ajustes como se indica en las razones descritas.
>>
>>
>> No había leído todo tu correo cuando escribí arriba ... pero si te
>> fijas, aunque esta propuesta no alcance consenso, lo que estás
>> comentado *es exactamente igual*, y por lo tanto la objeción no sería
>> válida. No quiero decir que no quiera mejorar el texto (si es
>> posible), pero estás "atacando" a la parte del manual incorrecta!
>>
>> De todos modos creo que serán importantes las apreciaciones del staff.
> La intención es mejorar el texto y contener los casos posibles más
> importantes que permitan al RIR / NIR recuperar direcciones y no dejar
> abierto o para casos de doble interpretación que no puedan aclararse
> lo suficiente
> Algunos de estos puntos aún no han sido aclarados por el staff. Pero
> el último punto que me causó más dudas y quería aclarar mejor.
>
> Gracias por las respuestas hasta ahora. Vamos a continuar.
>>
>> Saludos
>> Fernando
>> On 02/08/2019 12:25, JORDI PALET MARTINEZ via Politicas wrote:
>> > Hola Fernando,
>> >
>> > Como siempre mil gracias por tus comentarios. Contesto abajo.
>> >
>> >
>> > El 2/8/19 5:19, "Politicas en nombre de Fernando Frediani"
>> <politicas-bounces at lacnic.net en nombre de fhfrediani at gmail.com>
>> escribió:
>> >
>> > Hola
>> >
>> > Los siguientes son mis comentarios iniciales sobre esta
>> propuesta.
>> >
>> > - En la parte que menciona "Transferencias no
>> autorizadas", ¿podemos
>> > entender también los alquileres (o leases) de bloques de
>> direcciones IP
>> > de un ASN a otro? Creo que cuando un ASN alquila parte de
>> su bloque a
>> > otro, queda claro que no tiene uso para este bloque y
>> incumple con la
>> > política. ¿Se consideraría una Transferencia temporal no
>> autorizada?
>> >
>> > * Para mi que transferencia y "lease" no es lo mismo. Yo he
>> "cambiado de sitio" para evitar repeticiones y ubicar todo el texto
>> en una sección mas apropiada del manual lo que ya estaba en el
>> apartado 7.1 y ahora esta en la "introducción" del apartado 7.0.
>> >
>> > Por lo tanto, creo que, si debemos permitir o no los "leases"
>> es algo diferente, y creo que convendría saber cual es la
>> interpretación actual del staff al respecto. Se permiten actualmente
>> los alquileres de direcciones o no se permiten? Y en base a que
>> apartado del manual.
>> >
>> > Una vez el staff nos confirme, podemos decidir si la comunidad
>> considera que eso es apropiado o eso es algo que "también" hay que
>> cambiar o aclarar.
>> >
>> > - Hay otra situación que justifica la recuperación de
>> recursos y me
>> > gustaría aclarar si ya está implícito en la política y /
>> o propuesta
>> > actual: cuando un ASN solicita una transferencia de parte
>> de sus
>> > recursos y el ASN receptor no puede justificar la
>> necesidad de estos los
>> > recursos deben recuperarse ya que está claro que si el
>> ASN solicitante
>> > ya no usa ese bloque, está dispuesto a renunciar a él.
>> >
>> > * Si no me equivoco eso ya esta previsto, porque el apartado
>> 2.3.2.18.2. (transferencias) dice: Para que una entidad dentro de
>> LACNIC, pueda ser el destinatario de una transferencia, debe pasar
>> primero por el proceso de justificación de recursos IPv4 ante LACNIC.
>> Es decir, la entidad debe justificar ante LACNIC la
>> distribución/asignación inicial/adicional, según sea el caso, de
>> acuerdo a las políticas vigentes.
>> >
>> > Por lo tanto, si una entidad no justifica la necesidad, no
>> podría ser receptora de la transferencia, por lo tanto, esa
>> "operación" ni siquiera comenzará.
>> >
>> > Si lo que quieres decir es que, si el "donante" de las
>> direcciones NO necesita las direcciones y por eso quiere
>> transferirlas, eso supondría *modificar* la política de
>> transferencias y especificar si en lugar de una transferencia, deben
>> retornarse los recursos. Pero eso implicaría, básicamente "cancelar"
>> todas las políticas de transferencias, y por lo tanto, aunque
>> nosotros lo hiciéramos en LACNIC, automáticamente yo no podríamos
>> recibir recursos de otras regiones. No se si entiendes lo que quiero
>> decir?
>> >
>> > - Quisiera tanobia una aclaración sobre la siguiente
>> parte de la
>> > propuesta: "Cuando el incumplimiento ha sido causado por
>> un tercero, sin
>> > conocimiento de la organización que recibe los recursos,
>> y sea evidente
>> > que no hay connivencia ni negligencia por parte de dicha
>> organización,
>> > no se completará el proceso de revocación."
>> > En el correo electrónico de Jordi el 18/07/2019 se
>> menciona: "Entiendo
>> > que no es lo mismo un incumplimiento accidental y que se
>> puede corregir,
>> > o un incumplimiento manifiesto como podría ser una
>> transferencia no
>> > autorizada, que si se revierte causa daños a terceros que no
>> > necesariamente eran conscientes de la situación."
>> > Me gustaría entender qué tipo de situaciones serían
>> involuntarias. Por
>> > ejemplo, ¿algo causado por un cliente de ASN o un
>> empleado no autorizado
>> > para realizar un determinado procedimiento o otras
>> situaciones? Podría
>> > ejemplificar?
>> >
>> > * Te pongo un ejemplo para ver si se entiende. Un ISP recibe
>> un bloque y entrega parte de el a uno de sus clientes. El cliente
>> tiene su propio ASN y BGP y se compromete a anunciarlo. La política
>> dice que es obligatorio anuncia el bloque. Su cliente no lo anuncia.
>> >
>> > Crees que se deben retirar los recursos al ISP? Yo creo que no
>> (y así lo he intentado reflejar en el texto), sino que LACNIC deberá
>> advertirle al ISP (y me consta que así lo hacen), que esta
>> incumpliendo la política y que *si no* rectifica (bien advirtiendo a
>> su cliente, o bien anunciando el mismo ese bloque, etc.), entonces,
>> LACNIC ante la permanencia del incumplimiento, podría revocar dichos
>> recursos. Hay una excepción, pero sería muy extraña en el caso de
>> IPv4 (si es factible en IPv6), y es que el cliente necesite
>> direcciones públicas para una red privada y por lo tanto no las
>> anuncie. Creo que eso necesitaría una justificación muy muy muy
>> rigurosa hacia LACNIC, ya que el apartado 2.3.3.4 "recomienda" usar
>> direcciones privadas y el 2.3.3.4.3 indica que "se debe justificar
>> que se anunciará el espacio al menos a otro sistema autónomo" (y
>> podría darse el caso de dos redes privadas que no publiquen en
>> Internet, pero mediante VPN o enlaces dedicados se anuncien el
>> espacio entre ambos).
>> >
>> > Otro ejemplo: Un ISP hace una sub-asignación y delega la
>> actualización del whois al cliente (que bajo mi punto de vista es lo
>> correcto), y el cliente no lo actualiza. Obviamente es lo mismo que
>> el ejemplo, anterior. No se deben revocar "de primeras" todos los
>> recursos al ISP (ni una parte de ellos), salvo que una vez advertido
>> por LACNIC, persista de forma deliberada en el incumplimiento.
>> >
>> > Sobre el tema de la transferencia no autorizada que se ha
>> mencionado
>> > "que si se revierte causa daños a terceros que no
>> necesariamente eran
>> > conscientes de la situación". Me hace comprender que una
>> transferencia
>> > no autorizada no se puede revertir después de que se
>> realizó cuando el
>> > destinatario no estaba al tanto de toda la situación.
>> Pido que se aclare
>> > este punto para que podamos continuar con la discusión.
>> >
>> > * Imagina que un empleado (ISP A) hace una transferencia, sin
>> estar autorizado a ello. El receptor (ISP B) de la transferencia
>> empieza a usar esas direcciones con clientes. Al cabo de muchos meses
>> se descubre el fraude. El empleado es despedido del ISP A. LACNIC
>> comprueba que en cualquier caso cumple la política de transferencias
>> (existía la necesidad en el destinatario, ISP B). Deben las partes y
>> LACNIC solo regularizar los registros, etc., o debe perjudicarse a
>> los clientes del ISP B receptor (que desconocía que el empleado no
>> era autorizado), y cancelar la transferencia, e incluso recuperar los
>> recursos del ISP A?
>> >
>> > Me gustaría también aquí saber si el staff puede hacer alguna
>> observación concreta al respecto de este párrafo, o si por ejemplo
>> creen que solo debería aplicarse a los otros incumplimientos y no a
>> las transferencias (es un ejemplo, no estoy diciendo que deba ser asi!).
>> >
>> > Tanto esta aclaración del staff, como la que mencioné antes
>> (tema de leases), son de forma independiente al análisis de impacto,
>> ya que creo que si estos dos temas puntuales deben ser modificados en
>> el texto, podemos ahorrarnos un paso y avanzar con una nueva versión.
>> >
>> > Como siempre me gustaría recibir más comentarios!
>> >
>> > Saludos
>> > Fernando Frediani
>> >
>> > On 12/07/2019 11:42, info-politicas at lacnic.net wrote:
>> > > [Português abaixo]
>> > > [English below]
>> > >
>> > > Estimados suscriptores de la Lista de Políticas de LACNIC,
>> > >
>> > > Se recibió una nueva propuesta de Política, se le
>> asignó el id LAC-2019-9.
>> > >
>> > > Título: Actualización de “Recuperación y devolución de
>> recursos” y coherencia con el resto del manual
>> > >
>> > > Resumen: Esta propuesta actualiza el título de la
>> sección 7 del manual de políticas como “Revocación y devolución de
>> recursos”. Se resuelven discrepancias en la redacción actual y se
>> hace consistente con la terminología del Contrato de Servicios,
>> dejando claro que aplica a cualquier incumplimiento reiterado y/o
>> continuado de políticas, así como a fraudes e impagos.
>> > >
>> > > Se corrigen otros apartados del manual, para evitar
>> duplicidades y mantener la coherencia, evitando la innecesaria
>> revocación de recursos en casos ya indicados como “problemáticos” en
>> la lista de mejoras de políticas.
>> > >
>> > > Para ver el detalle ingrese en:
>> > >
>> https://politicas.lacnic.net/politicas/detail/id/LAC-2019-9
>> > >
>> > > Los comentarios y los puntos de vista aportados por la
>> comunidad son vitales para el correcto desarrollo del proceso de la
>> propuestas
>> > > - ¿Apoya usted o se opone a esta propuesta?
>> > > - ¿Esta propuesta resolvería un problema que usted está
>> experimentando?- ¿Ve alguna desventaja en esta propuesta?
>> > > - ¿Qué cambios podrían hacerse a esta propuesta para
>> que sea más eficaz?
>> > >
>> > > Por más información contacte a info-politicas at lacnic.net
>> > > Saludos cordiales,
>> > >
>> > >
>> ______________________________________________________________________________________________________
>> > >
>> > > Prezados assinantes da lista de políticas de LACNIC,
>> > >
>> > > Foi recebida uma nova proposta de Política, foi
>> atribuído o id LAC-2019-9.
>> > >
>> > > Título: Actualización de “Recuperación y devolución de
>> recursos” y coherencia con el resto del manual
>> > >
>> > > Resumo: Esta propuesta actualiza el título de la
>> sección 7 del manual de políticas como “Revocación y devolución de
>> recursos”. Se resuelven discrepancias en la redacción actual y se
>> hace consistente con la terminología del Contrato de Servicios,
>> dejando claro que aplica a cualquier incumplimiento reiterado y/o
>> continuado de políticas, así como a fraudes e impagos.
>> > >
>> > > Se corrigen otros apartados del manual, para evitar
>> duplicidades y mantener la coherencia, evitando la innecesaria
>> revocación de recursos en casos ya indicados como “problemáticos” en
>> la lista de mejoras de políticas.
>> > >
>> > > Para ver o detalhe acesse:
>> > >
>> https://politicas.lacnic.net/politicas/detail/id/LAC-2019-9
>> > >
>> > > Os comentários e os pontos de vista aportados pela
>> comunidade são vitais para o bom desenvolvimento do processo das
>> propostas
>> > > - ¿Você é a favor ou contra desta proposta?
>> > > - ¿Esta proposta iria resolver um problema que você
>> está experimentando?- ¿Vê alguma alguma desvantagem nesta proposta?
>> > > - ¿Que mudanças poderiam ser feitas à proposta para que
>> seja mais eficaz?
>> > >
>> > > Por mais informações entre em contato conosco através
>> do seguinte e-mail: info-politicas at lacnic.net
>> > > Atenciosamente,
>> > >
>> ______________________________________________________________________________________________________
>> > >
>> > > Dear LACNIC Policy List subscribers,
>> > >
>> > > A new Policy Proposal has been received and assigned
>> the following ID: LAC-2019-9.
>> > >
>> > > Title: Actualización de “Recuperación y devolución de
>> recursos” y coherencia con el resto del manual
>> > >
>> > > Summary: Esta propuesta actualiza el título de la
>> sección 7 del manual de políticas como “Revocación y devolución de
>> recursos”. Se resuelven discrepancias en la redacción actual y se
>> hace consistente con la terminología del Contrato de Servicios,
>> dejando claro que aplica a cualquier incumplimiento reiterado y/o
>> continuado de políticas, así como a fraudes e impagos.
>> > >
>> > > Se corrigen otros apartados del manual, para evitar
>> duplicidades y mantener la coherencia, evitando la innecesaria
>> revocación de recursos en casos ya indicados como “problemáticos” en
>> la lista de mejoras de políticas.
>> > >
>> > > To read the proposal, please go to
>> > >
>> https://politicas.lacnic.net/politicas/detail/id/LAC-2019-9
>> > >
>> > > The community's comments and opinions are essential to
>> the proper functioning of the policy development process.
>> > > - Do you support this policy or are you against it?
>> > > - Would this proposal solve a problem you are
>> experiencing?- Do you think this proposal has any drawbacks?
>> > > - What changes could be made to this proposal to make
>> it more effective?
>> > >
>> > > For further information, please contact
>> info-politicas at lacnic.net
>> > > Kind regards,
>> > >
>> > >
>> > > --
>> > > LACNIC - Registro de Direcciones de Internet para
>> América Latina y Caribe
>> > > Rambla Rep. de México 6125, CP 11400
>> > > Montevideo-Uruguay
>> > > Teléfono: +598 2604 22 22
>> > > www.lacnic.net
>> > > _______________________________________________
>> > > 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
>> >
>> >
>> >
>> >
>> > **********************************************
>> > IPv4 is over
>> > Are you ready for the new Internet ?
>> > http://www.theipv6company.com
>> > The IPv6 Company
>> >
>> > This electronic message contains information which may be
>> privileged or confidential. The information is intended to be for the
>> exclusive use of the individual(s) named above and further
>> non-explicilty authorized disclosure, copying, distribution or use of
>> the contents of this information, even if partially, including
>> attached files, is strictly prohibited and will be considered a
>> criminal offense. If you are not the intended recipient be aware that
>> any disclosure, copying, distribution or use of the contents of this
>> information, even if partially, including attached files, is strictly
>> prohibited, will be considered a criminal offense, so you must reply
>> to the original sender to inform about this communication and delete it.
>> >
>> >
>> >
>> > _______________________________________________
>> > 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
>>
>>
>>
>> **********************************************
>> IPv4 is over
>> Are you ready for the new Internet ?
>> http://www.theipv6company.com
>> The IPv6 Company
>>
>> This electronic message contains information which may be privileged
>> or confidential. The information is intended to be for the exclusive
>> use of the individual(s) named above and further non-explicilty
>> authorized disclosure, copying, distribution or use of the contents
>> of this information, even if partially, including attached files, is
>> strictly prohibited and will be considered a criminal offense. If you
>> are not the intended recipient be aware that any disclosure, copying,
>> distribution or use of the contents of this information, even if
>> partially, including attached files, is strictly prohibited, will be
>> considered a criminal offense, so you must reply to the original
>> sender to inform about this communication and delete it.
>>
>>
>>
>> _______________________________________________
>> 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
--
Ing. Gianina Pensky
Coordinadora de Políticas y Capacitación
Coordinator of Policies and Training
LACNIC -http://www.lacnic.net
Latin American and Caribbean Internet Addresses Registry
More information about the Politicas
mailing list