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

Fri Mar 22 18:26:45 -03 2019

Hola Ricardo,

De nuevo mil gracias por los comentarios.

Por aclarar los cambios realizados (si no mal recuerdo, porque los hice hace tiempo, pero decidí esperar por si había mas comentarios), son fundamentalmente para acceder a tus peticiones (aunque no estaba de acuerdo al 100%) de alinear mas el documento con lo que alcanzó consenso en APNIC.

También ha habido algún cambio meramente editorial, sugeridos por LACNIC, para que el texto sea mas fácil de leer, pero no se ha cambiado el objetivo de los diversos puntos de la propuesta (uno de ellos se ha separado en dos secciones para mayor claridad).

Por eso me extraña ahora que indiques dudas o cambios en aspectos que NO han cambiado respecto de la versión anterior, y que por tanto podríamos haber intentado consensuar en esta versión.

Voy a indicar las diversas cuestiones bajo cada uno de tus puntos y lo vamos revisando.

Saludos,
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.

    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.

    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.

    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.

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.

    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.

    "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.

    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.

    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.

    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.   

    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.