[LACNIC/Politicas] Nueva versión de la propuesta LAC-2018-5

Tue Mar 26 06:46:37 -03 2019

Hola Ricardo,

El 25/3/19 20:40, "Politicas en nombre de Ricardo Patara" <politicas-bounces at lacnic.net en nombre de patara at registro.br> escribió:

    Jordi,

    >   
    >
    > El 22/3/19 20:59, "Politicas en nombre de Ricardo Patara" <politicas-bounces at lacnic.net en nombre de patara at registro.br> escribió:
    >
    >      Hola,
    >      
    >      Me gusta ver que comentarios en la discusión fueran llevados en
    >      consideración y se presenta una nueva versión.
    >      
    >      Pero, aún estoy en contra el texto como escrito.
    >      
    >      Veo que se ajusto el texto en cuanto al plazo para las verificaciones:
    >      
    >      "LACNIC validará el cumplimiento de la política de forma periódica, al
    >      menos dos veces al año, y cuando se creen o modifiquen los atributos del
    >      “abuse-c”.
    >      
    >      La frecuencia de validación podrá ser modificada a criterio de LACNIC,
    >      informando a la comunidad de los motivos."
    >
    >
    > No es correcto, esto ya estaba en la versión anterior, no se ha cambiado en absoluto (salvo editorial).  Puedes verlo aquí:
    > https://politicas.lacnic.net/politicas/diff1?id=LAC-2018-5&v=4&v2=3
    >
    >
    >      Se da la libertad a LACNIC de ajustar la frecuencia.
    >      Pero no queda claro si eso en definitivo o a cada vez tendrá que
    >      justificarse
    >
    > Sólo debe justificarlo a la comunidad si se cambia. Creo que es lógico y que no es un problema. Por ejemplo, quizás el primer año interesa hacer una sola verificación anual, el segundo dos, y quizás en el futuro LACNIC decide que no hay fallos de validación (toda la comunidad ya conoce y respeta la política) y que se puede mejorar la frecuencia.

    y cual seria la razón para ya no dejar 1 año? me parece un buen plazo

Y cual sería la razón por la que dejarlo en 1 año?

Lo que quiero decir, es que mi objetivo inicial era 4 veces al año, creo que una vez al año no es suficiente, y de hecho se ha alcanzado consenso en APNIC con 2 al año, e igualmente espero que sea así en otras regiones. Así cedemos todos al 50% respecto de la idea original

De hecho, la idea de que el staff lo pueda modificar, nos permite la flexibilidad de si realmente conseguimos un "whois" con contactos limpios, se pueda reducir a 1 vez cada 18 o 24 meses, etc.

    >      
    >      Mi sugerencia es dejar ya en definitivo en texto que la verificación se
    >      hace una vez por año, como en RIPE y ARIN.
    >
    > Anteriormente me habías indicado que lo mismo que APNIC y así lo hice. De todos modos, RIPE y ARIN tienen ya oficialmente (por diversas razones no pude dedicarle tiempo antes), *la misma* propuesta que estas leyendo en LACNIC. Estoy esperando que se publiquen próximamente.

    vi que hay una propuesta en la cola de ARIN que seria verificada/validada por el 
    AC de ellos.

    Pero en RIPE no veo nada aún. (Incluso, cuando presentaste esa propuesta acá en 
    la región, dijiste que ya habia una propuesta en RIPE, pero desde entonces no la 
    veo alla).

En RIPE no existe la "cola" de ARIN, por eso no es visible, y efectivamente por muchas razones (entre otras, carga de trabajo), se ha ido demorando. En cuanto se publique lo informaré en la lista, aunque tu estas en el WG de anti-abuse que es donde será publicado, y lo verás directamente.

    >      
    >      En el 12.2. hay:
    >      
    >      "El buzón “abuse-mailbox” podrá devolver inicialmente, una respuesta
    >      automática, por ejemplo, asignando un número de ticket, aplicando
    >      procedimientos de clasificación, pidiendo más información, etc."
    >      
    >      no creo que la política deba indicar como ISP opera su red y sus sistemas.
    >      Sacaría eso de que hay que atribuir un numero de ticket y de clasificación.
    >      Si el ISP tiene como importante el tratamiento de estos problemas, por
    >      la políticas por ejemplo, que implemente los mecanismos que le parezca
    >      mejor y eficiente.
    >
    > Indica "por ejemplo", y este tipo de ejemplos lo tenemos en otras políticas, y creo que son informativos. Si no desean establecer un sistema de tickets, no lo obliga.
    >      

    comprendo.

    aún así yo lo sacaria.

    si es un ejemplo, agregaría poco. y dejemos al ISP tratar dichos abusos de la 
    forma que le cabe más apropiado.

Los ejemplos los tenemos en otros puntos de las políticas, porque a veces no es fácil entender el texto sin ellos, así que discrepo en quitarlo, y en cualquier caso no "molesta" porque no es normativo.

    >      
    >      En el 12.3, hay:
    >      "3) Confirmar que quien valida:
    >      • asegura conocer el procedimiento y las políticas de LACNIC
    >      • monitoriza regularmente el “abuse-mailbox”
    >      • toma medidas al respecto
    >      • responde al reporte de abuso."
    >      
    >      cómo asegurar que conoce uno las políticas?
    >
    > Lo que dice la política es que el proceso de validación pida la confirmación de que quién valida confirma (valga la redundancia) esos puntos. Se trata de una herramienta (típicamente será una página web), que tenga ese texto o un texto parecido, enlace al texto de la política, etc., para facilitar a la comunidad entender porque se pide esto (especialmente importante al principio), y confirmar que "cumple". En inglés diríamos un check-box.
    >
    > No sirve de nada una validación que haces click sin leer. Es como firmar un contrato sin leerlo.
    >      
    >      "4) Responder al primer contacto en un plazo no superior a 15 días."
    >      
    >      una respuesta automática es considerada como válida para atender ese
    >      requisito?
    >
    > No, la respuesta automática no sería suficiente, porque hay que ir al formulario para marcar el "check-box". Capaz que con la sugerencia de LACNIC lo hemos estropeado, porque creo que era mas claro "Plazo de validación inicial" en lugar de respuesta automática, y cuando yo he aceptado esa sugerencia he metido la pata.

    okay,

    pero ahí no me queda claro que en el párrafo

    "12.2. Características del “abuse-mailbox”

    Los emails enviados a “abuse-mailbox” deben requerir intervención manual en 
    algún momento,"

    como indicas que el tratamiento "manual" debe ocurrir en algún momento, al menos 
    a mí, pareció que se aceptaría un tratamiento automatizado.

Si el procedimiento es "solo" automatizado, no permitiría una validación por un humano, y además, el problema que hay con los "solo" automatizados es que no todos los casos de abuso se procesan adecuadamente, así que el ISP tiene que tener un criterio para ellos.

    > Voy a comentarlo con Gianina, ahora que todavía no están hechas las traducciones para que este punto en concreto lo devolvamos al estado anterior, sin tener que hacer "solo" por esto una nueva versión ... y todo el trabajo que ello conlleva.

Gianina me confirmó que ya se ha modificado.

    >      
    >      Aún en:
    >      "12.4. Validación del “abuse-c”/“abuse-mailbox”
    >      LACNIC validará el cumplimiento de la política de forma periódica, al
    >      menos dos veces al año, y cuando se creen o modifiquen los atributos del
    >      “abuse-c”."
    >      
    >      Lacnic asegura que la dirección de email informada cuando del cambio de
    >      datos de un contacto sea valida. Eso es suficiente como validación en
    >      caso de modificación indicada arriba?
    >
    > No estoy seguro de entender tu duda aquí. Si mañana se cambia un contacto (porque estaba mal o porque era invalido), es automáticamente validado, eso es lógico.

    ok, y incluso ese no tendría que se "re validar" caso un proceso de validación 
    programada estuviera para ocurrir justo en seguida.

Eso es.

    >      
    >      "Cualquier acceso a MiLACNIC, durante dicho bloqueo, mostrará un mensaje
    >      de advertencia, incluyendo el texto de esta política, y para permitir
    >      continuar será necesario que dicho mensaje sea “leído” hasta el final, y
    >      se confirme mediante un check-box o similar."
    >      
    >      No estoy de acuerdo que una política indique como debe ser el
    >      procedimiento operacional. Una vez que eso limita al RIR y impide
    >      mejoras en los procesos.
    >
    > Yo tampoco creo que haya que tener ciertos aspectos operacionales, pero otros si cuando son un aspecto importante de la política como es este caso.

    no veo de esa forma.

    si lacnic decidir indicar el problema de una otra forma no lo podría hacerlo 
    pues tendría que hacer tal cual está en la política.

    dejaria algo más generalizado sin indicar como debe ser el mensaje y tampoco 
    como obtener una confirmación de que lo haya leído.

Si te parece, puedo intentar usar la expresión "por ejemplo" en los casos en los que bajo mi punto de vista puede haber cierta flexibilidad u opciones de mejorar o cambiar el procedimiento (nuevas tecnologías, etc)

    >      Sacaría esa parte.
    >      
    >      Aun en 12.4:
    >      "A criterio de LACNIC, de forma generalizada o en casos puntuales (por
    >      ejemplo para la confirmación en casos de escalado según el 12.6), LACNIC
    >      podrá utilizar dominios diferentes a lacnic.*, e incluso modificar el
    >      asunto y cuerpo del mensaje, para realizar dichas validaciones."
    >      
    >      sacaría esa parte. no veo la necesidad de tal.
    >
    > Es otro aspecto fundamental. Si no se especifica, es fácil que se pueda "engañar" el cumplimiento de la política.

    no veo como fundamental.

    si lacnic tiene la responsabilidad de validar y tratar los casos, que se confíe 
    en lacnic que tratará de utilizar los mejores mecanismos para hacerlo.

    procedimientos operacionales, a mi ver, no debería estar en las políticas

Si te fijas dice "A criterio de LACNIC", así que se les esta dando la discreción de decidir. Creo que es perfectamente válido.

    >      
    >      En 12.5.:
    >      "De los incumplimientos"
    >      
    >      En general, que será considerado como "incumplimiento"?
    >      No contestar en los 15+15 días?
    >
    > Incumplimiento es no cumplir la política. No se trata de contestar en 15+15 días, porque habrá quien conteste en 1, o en 29 con una respuesta automática. Se trata, dentro del plazo máximo, de haber validado el procedimiento. Creo que el primer párrafo del 12.4 es suficientemente claro.

    okay, entendido.

    >      O por ejemplo, no confirmar que conoce las políticas? O que no toma
    >      medidas as respeto?
    >      
    >      Aún en el 12.5:
    >      
    >      "El incumplimiento por parte de cualquier organización, implicará el
    >      bloqueo de MiLACNIC y medidas equivalentes en los sistemas de los NIRs,
    >      para todos los recursos asociados con dicha organización. "
    >      
    >      tengo una preocupación.
    >      en algunos sistemas el registro de la organización en el sistema no es
    >      solamente para IP/ASN sino que para dominios también, por ejemplo.
    >      No estoy seguro si seria correcto bloquearle el acceso a otros servicios
    >      por un problema con registros de IP.
    >      
    > Aquí solo es nueva la referencia a los NIR. Creo que entiendo lo que dices. NIC.MX y NIC.BR también hacen gestiones como .mx y .br, y podría ser la misma cuenta. Sin embargo, mi texto indica "equivalentes". Es decir, que los NIR no podrían bloquear algo que ellos ofrecen y LACNIC no. O dicho de otro modo, los NIR bloquearan las mismas funcionalidades que bloquee LANIC y no las adicionales.

    okay, entendí

    pero puede ser que el sistema sea el mismo, pero es algo a se verificar cuando 
    lacnic haga sus análisis de impacto.

Aunque el sistema sea el mismo, obviamente puede requerir cambios de software para diferencias si se quiere acceder a un cambio de recursos de IP o de dominio, pero creo que son leves, y eso puede pasar con esta y con otras propuestas de políticas.

    Ricardo

    >      
    >      
    >      Em 22/03/2019 00:21, info-politicas at lacnic.net escreveu:
    >      > [Português abaixo]
    >      > [English below]
    >      >
    >      > Estimados suscriptores de la lista de políticas de LACNIC,
    >      >
    >      > La propuesta LAC-2018-5 ha pasado de la versión 3 a la versión 4
    >      >
    >      > Título: Registro y validación del contacto de abuso
    >      >
    >      > Resumen: La propuesta permite garantizar y validar los contactos de abuso del WHOIS (abuse-c y abuse-mailbox) de las organizaciones y poder así reportar los casos de abuso y resolverlos.
    >      >
    >      > Esta propuesta pretende resolver el problema y garantizar la existencia de un contacto abuse-c correcto y el proceso para su uso.
    >      >
    >      > Para ver el detalle ingrese en:
    >      > https://politicas.lacnic.net/politicas/detail/id/LAC-2018-5
    >      >
    >      > 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 nueva versión de la propuesta?
    >      > - ¿Ve alguna desventaja en esta nueva versión de la propuesta?
    >      > - ¿Qué cambios podrían hacerse a esta nueva versión de la 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,
    >      >
    >      > A proposta LAC-2018-5 tem passado da versão
    >      > 3 para a versão
    >      > 4
    >      >
    >      > Título: Registro e validação do contato de abuso
    >      >
    >      > Resumo: La política actual (ASN) no es clara en cuanto a la obligación de registrar un contacto de abuse (abuse-c) ni al formato específico y si aplica a otros casos de registros en el whois.
    >      >
    >      > Como consecuencia, puede haber receptores de recursos de LACNIC que no tienen dicho contacto registrado para sus recursos, o incluso hay casos de LIRs/ISPs, usuarios finales, u otros, que utilizan un buzón de correo inexistente o que no está activamente monitorizado.
    >      >
    >      > Ello origina en la práctica, que dicho contacto sea ineficaz para poder reportar abusos y en general problemas de seguridad y costes para las víctimas.
    >      >
    >      > Esta propuesta pretende resolver el problema y garantizar la existencia de un contacto abuse-c correcto y el proceso para su uso.
    >      >
    >      > Para ver o detalhe acesse:
    >      > https://politicas.lacnic.net/politicas/detail/id/LAC-2018-5
    >      >
    >      >  Os comentários e os pontos de vista aportados pela comunidade são
    >      > vitais para o bom desenvolvimento do processo das propostas
    >      > - Você está a favor ou em contra desta nova versão
    >      >  da proposta?- Vê alguma desvantagem nesta nova versão
    >      >  da proposta?
    >      >
    >      > - Que mudanças poderiam ser feitas à esta nova versão
    >      >  da proposta para que seja mais eficaz?
    >      >
    >      > Por mais informações entre em contato conosco através do e-mail:
    >      > info-politicas at lacnic.net.
    >      >
    >      > Atenciosamente,
    >      > ______________________________________________________________________________________________________
    >      >
    >      > Dear LACNIC Policy List subscribers,
    >      >
    >      > Proposal LAC-2018-5 has been updated from version 3 to version 4
    >      >
    >      > Title: Registration and validation of abuse contact
    >      >
    >      > Summary: La política actual (ASN) no es clara en cuanto a la obligación de registrar un contacto de abuse (abuse-c) ni al formato específico y si aplica a otros casos de registros en el whois.
    >      >
    >      > Como consecuencia, puede haber receptores de recursos de LACNIC que no tienen dicho contacto registrado para sus recursos, o incluso hay casos de LIRs/ISPs, usuarios finales, u otros, que utilizan un buzón de correo inexistente o que no está activamente monitorizado.
    >      >
    >      > Ello origina en la práctica, que dicho contacto sea ineficaz para poder reportar abusos y en general problemas de seguridad y costes para las víctimas.
    >      >
    >      > Esta propuesta pretende resolver el problema y garantizar la existencia de un contacto abuse-c correcto y el proceso para su uso.
    >      >
    >      > To see the details, please click on:
    >      > https://politicas.lacnic.net/politicas/detail/id/LAC-2018-5
    >      >
    >      > The community's comments and opinions are essential to the proper functioning of the policy development process.
    >      > - Do you support this new version of the proposal or are you against it?
    >      > - Do you think this new version of the proposal has any drawbacks?
    >      > - What changes could be made to this new version of the 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
    >      >
    >      
    >      --
    >      Ricardo Patara
    >      _______________________________________________
    >      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.