Registro e validação do contato de abuso

Idioma Original Español Data Publicação 05/03/2018 Última Modificação 25/04/2019
Período de últimos comentários Não aplicável Data de ratificação Não aplicável Data de implementação Não aplicável
Estado Em discussão Baixar TXT PDF XML DOCX
Ver outras versões 1.0 2.0 3.0 4.0 5.0 (comparar)

Autores

Nome: Jordi Palet Martinez
E-mail: jordi.palet@theipv6company.com
Organização: The IPv6 Company

Dados da Proposta

Tipo Política: LACNIC
Id: LAC-2018-5
Última versão: 5
Apresentada em: LACNIC 31 Apresentações:

Resumo

A proposta permite garantir e validar os contatos de abuso do WHOIS (abuse-c e abuse-mailbox) das organizações e poder assim informar os casos de abuso e resolvê-los.

Esta proposta visa resolver o problema e garantir a existência de um contato abuse-c correto e o processo para seu uso.

Justificativa

A política atual (ASN) não é clara em relação à obrigação de registrar um contato de abuse (abuse-c) nem ao formato específico, e se pode ser aplicada a outros casos de registros no WHOIS.

Como resultado, pode haver receptores de recursos de LACNIC que não têm esse contato registrado para seus recursos, ou ainda há casos de LIRs/ISPs, usuários finais ou outros, que usam uma caixa de correio inexistente ou que não está ativamente monitorada.

A falta de validação dos contatos tornou o relato de casos de abuso ineficaz, gerando problemas de segurança e custos para as vítimas.

Para tentar resolver este problema, é feita uma simples verificação periódica do contato de abuso, evitando assim custos desnecessários para terceiros.

A proposta garante que o custo de processar os abusos recaia sobre o receptor do recurso quem, direta ou indiretamente (seu cliente e de quem ele possivelmente recebe compensação pelo serviço), é responsável pelo abuso, em vez de recair sobre a vítima. Leve em conta que isso evita o possível agravamento, tempo e despesas legais para ambas as partes se forem para essa instância.

Para isso, o atributo abuse-c, que até agora era apenas referenciado para o objeto "aut-num", torna-se obrigatório nos objetos "inetnum" (tanto para o IPv4 quanto para o IPv6), e qualquer um que venha surgir no futuro. Este atributo é um contato de abuso, que irá conter no mínimo o atributo "abuse-mailbox".

Texto

Texto atual: Não existe

Texto novo:

12. Registro e validação de "abuse-c" e "abuse-mailbox"

12.1. Descrição do "abuse-c" e "abuse-mailbox"
Todos os recursos que usem os sistemas de registro de LACNIC devem incluir obrigatoriamente, nas entradas do WHOIS correspondentes, o atributo de contato abuse-c (contato de abuso) como mínimo com um e-mail abuse-mailbox válido, monitorado e devidamente atendido, que permita o envio de relatórios manuais ou automáticos de comportamentos abusivos, segurança e semelhantes.

O atributo abuse-mailbox deve estar disponível sem restrições via WHOIS, APIs e futuras tecnologias.

Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo, subdesignações), estar cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo.

Seguindo práticas usuais, outros atributos "e-mail" podem ser incluídos para outros fins.

12.2. Características do "abuse-mailbox"

Os e-mails enviados para "abuse-mailbox" devem exigir intervenção manual em algum momento, por parte do destinatário, e não podem ser filtrados, pois isso poderia impedir, em alguns casos, a recepção de um relatório de abuso. Por exemplo, um relatório de spam, ao incluir a própria mensagem de spam ou URLs ou conteúdos geralmente classificados como spam.

A caixa de correio "abuse-mailbox" poderá enviar inicialmente uma resposta automática, por exemplo, designando um número de bilhete, aplicando procedimentos de classificação, solicitando mais informações, etc. No entanto, não poderá requerer o uso de um formulário, pois isso implicaria que cada entidade que precisar denunciar abusos, geralmente de forma automatizada, seja forçada a desenvolver uma interface específica para cada receptor de recursos a quem tem que informar um abuso. Isso seria inviável, uma vez que faria recair o custo do processado dos abusos em quem envia a reclamação, vítima do abuso, em vez de ser pago por aquele que, direta ou indiretamente, provoca o abuso.

O razoável é que quem denuncia o abuso, faça isso no primeiro relatório, enviando informações suficientes (log, cópia de spam ou cabeçalhos completos, o equivalente em cada tipo de abuso). Da mesma forma, é razoável que o e-mail inicial de auto-resposta indique que, se essas informações não tiverem sido enviadas, não será atendido, dando assim a oportunidade de repetir o envio com a evidência pertinente. Isso permite relatórios automatizados, por exemplo, mediante fail2ban, SpamCop ou outros, com um custo mínimo para ambas as partes. Normalmente, espera-se que, se um número de bilhete tiver sido designado, ele será mantido em todas as comunicações (tipicamente como parte do assunto).

12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"

O procedimento, que deverá ser desenvolvido por LACNIC, deve atender aos seguintes objetivos:

1) Garantir sua funcionalidade e permitir os "helpdesk" que lidam com os relatórios de abuso, a verificação de que a validação realmente provem de LACNIC e não de terceiras fontes (envolvendo riscos de segurança, evitando, por exemplo, uma única URL "direta" para a validação).
2) Impedir um processo exclusivamente automatizado.
3) Confirmar que quem valida:
• garante conhecer o procedimento e as políticas de LACNIC
• monitora regularmente o “abuse-mailbox”
• toma medidas a esse respeito
• responde ao relatório de abuso.
4) Prazo de validação “inicial” de 15 dias.
5) Se não for validado corretamente, “escalado” com o restante dos contatos disponíveis, em um prazo “adicional” de 15 dias.

Os prazos de validação poderão ser modificados a critério de LACNIC, informando a comunidade dos motivos.

(na forma de recomendação, propõe-se um procedimento detalhado em "informações adicionais" desta proposta de política).

12.4. Validação do "abuse-c"/"abuse-mailbox"
LACNIC validará o cumprimento da política periodicamente, pelo menos duas vezes por ano, e quando os atributos "abuse-c" forem criados ou modificados.

A frequência de validação poderá ser modificada a critério de LACNIC, informando a comunidade dos motivos.

12.5. Dos incumprimentos

O incumprimento por parte de qualquer organização ocorre se não foi validado no prazo "inicial" ou "adicional". Isso implicará o bloqueio de MiLACNIC e medidas equivalentes nos sistemas dos NIRs, para todos os recursos associados a essa organização. Excluem-se as questões exclusivamente contratuais e relacionadas a pagamentos, bem como a atualização dos contatos abuse-c/abuse-mailbox, de modo que possam ser revalidados automaticamente para permitir o desbloqueio de MiLACNIC.

Qualquer acesso a MiLACNIC (ou sistemas equivalentes dos NIRs) durante o referido bloqueio, mostrará uma mensagem de aviso, incluindo o texto desta política, e para permitir continuar será necessário que essa mensagem seja "lida" até o final, e confirmada por meio de um check-box ou semelhante. Mecanismos equivalentes adaptados ao progresso da tecnologia poderão ser usados.

Se o incumprimento for mantido, LACNIC atuará de acordo com suas políticas e procedimentos pertinentes.

12.6. Mecanismo de escalado para LACNIC

Comportamentos fraudulentos (por exemplo, "abuse-mailbox” que respondem apenas a e-mails de LACNIC, a um assunto específico ou corpo da mensagem) ou o incumprimento dos demais aspectos desta política (incorreta ou não atenção aos casos de abuso), poderão ser denunciados a LACNIC, para sua revalidação segundo 12.4.

Informações Adicionais

Nota (não deve ser incluído no manual de políticas):
A seção atual “12. Apêndices "passa a ser" A. Apêndices ", no final do manual de políticas, e todas as referências a ela são renumeradas em todo o manual de políticas. Dessa forma, as novas seções do manual não requererão renumerações futuras, segundo o manual for "crescendo". O texto desta proposta torna-se, portanto, a seção 12, ou a considerada apropriada pelo pessoal no momento de sua implementação, uma vez que o consenso tenha sido alcançado.

O texto a seguir é um exemplo de procedimento de validação, considerando as práticas usuais nos "helpdesk" (mesas de ajuda), que, por exemplo, impedem clicar em um link html de um e-mail, para evitar casos de phishing ou outros. Mesmo quando este texto não faz parte do texto da política, recomenda-se sua consideração estrita, uma vez que é o resultado de discussões relacionadas a políticas de abuse-c na comunidade global.

1) A validação começa de forma automatizada, por parte de LACNIC, com o envio de DOIS e-mails consecutivos para o "abuse-mailbox”.
2) Esses e-mails terão exclusivamente formato texto (e, portanto, ocultar URLs que correspondam a ataques como "phishing" etc.).
3) A critério de LACNIC, de forma generalizada ou em casos específicos (por exemplo, para a confirmação em casos de escalado de acordo com o ponto 12.6), LACNIC, poderá usar outros domínios além do lacnic.*, e inclusive modificar o assunto e corpo da mensagem, para realizar ditas validações de forma mais eficaz.
4) O primeiro dos e-mails vai conter a URL onde a validação deve ser realizada, que será "validacion.lacnic.net", e poderá conter informações sobre o procedimento, extrato desta política, etc.
5) O segundo dos e-mails vai conter um código alfanumérico único de validação.
6) O receptor que atende o "abuse-mailbox", deverá acessar à URL e inserir no formulário o código recebido no segundo e-mail.
7) Esta URL deverá estar projetada de forma de impedir um processo automatizado (por exemplo, "captcha") e conterá um texto que confirme que o receptor da validação conhece o procedimento, a política e que monitora regularmente o "abuse-mailbox" e que são tomadas medidas adequadas para resolver os abusos relatados e responder a eles, com um "checkbox" que deverá ser necessariamente aceito.
8) O código alfanumérico apenas será válido por um máximo de 15 dias.
9) Se o código não for inserido nesse prazo, o sistema marcará o "abuse-c" como "provisoriamente inválido" e alertará a equipe de LACNIC para que possa ser iniciado o acompanhamento personalizado com o receptor do recurso.
10) No caso de não obter uma resposta com a confirmação da correção da situação, em um prazo adicional de 15 dias, o "abuse-c" será marcado de forma permanente como "inválido".
11) O processo de validação será repetido automaticamente (pontos 1 a 7 acima) e, neste caso, o "abuse-c" será marcado como "válido" se for satisfatório, caso contrário, seria um caso de descumprimento da política.
12) LACNIC terá mecanismos (formulário, e-mail e outros no futuro) para facilitar o escalamento nos casos em que se queira denunciar uma violação desta política. Isso permitirá a revalidação (12.4) e a intervenção de LACNIC na aplicação das políticas, procedimentos e requisitos contratuais em vigor.

Tempo de Implementação

-

Referências

-

Notas Públicas da equipe de LACNIC

ANALISE DE IMPACTO PELA EQUIPE DE LACNIC - Proposta LAC-2018-5 - versión 5

Interpretación de la propuesta por el staff de LACNIC
-----------------------------------------------------

Aplicación de la propuesta
--------------------------
Esta propuesta se aplicaría a los receptores de recursos de LACNIC para que registren un contacto de abuso válido para ASNs, IPv4 e IPv6.

Modificación del texto actual
-----------------------------
La sección actual “12. Apéndices” pasa ser “A. Apéndices”, al final del Manual de Políticas, y se actualizan todas sus referencias.

Se agregan las secciones:
o 12. “Registro y Validación de "abuse-c" y "abuse-mailbox”
o 12.1 “Descripción del "abuse-c" y "abuse-mailbox”
o 12.2. “Características del "abuse-mailbox"
o 12.3. Objetivos de la validación del "abuse-c"/"abuse-mailbox
o 12.4. Validación del "abuse-c"/"abuse-mailbox"
o 12.5. Mecanismo de escalado a LACNIC

La nueva versión incorpora
---------------------------
1. La sugerencia del staff para incluir todo tipo de recursos que utilicen los sistemas de LACNIC.
2. En la sub sección 12.5 Incumplimientos, que el bloqueo de MiLACNIC se realizará si no se han validado los contactos en el plazo inicial ni adicional.
3. Agrega las correspondencias con los sistemas de los otros NIRs.
4. Modifica la sub sección 12.4 de incumplimentos

Comentarios del staff
---------------------
1. Si bien el Manual de Políticas no indica que el bloque IPv4 debe contener un contacto de abuso, el sistema de LACNIC ya soporta esta modalidad y los bloques IPv4, IPv6 y ASN ya poseen este atributo. Lo mismo sucede en el caso de las sub asignaciones, el abuse-c utilizado es el punto de contacto administrativo de la organización que recibe la asignación o la sub asignación.
Se realizó una consulta a la Base de Datos de LACNIC sobre el registro de los contactos de abuso de cada tipo de recursos y se obtuvieron los siguientes resultados:
- Cantidad de recursos IPv4, IPv6, ASN con contacto de abuso null o vacío: 0
- Cantidad de recursos legados IPv4 con contactos de abuso null o vacío: 241
- Cantidad de recursos legados IPv6 con contactos de abuso null o vacío: 0
- Cantidad de recursos legados ASN con contactos de abuso null o vacío: 146

Por lo tanto, actualmente no existe ningún recurso que no sea legado con el contacto de abuso vacío/null. Todos los que aparecen el la BD con null/vacío son legados. Sin embargo, LACNIC no hace ningún tipo de validación sobre los contactos.

2. LACNIC entiende que esto no aplica para las organizaciones con recursos legados. Si bien estas organizaciones están en la misma base de datos de LACNIC, muchos no tienen un contacto válido (e-mail, teléfono) ni obligación contractual de actualizarlo debido a la antigüedad de la asignación (antes de 1997). Las organizaciones con recursos legados tampoco están obligadas a regirse por las políticas de LACNIC por lo que esta política tampoco sería aplicable a ellos.

3. Con relación al siguiente texto: “ Teniendo en cuenta la naturaleza jerárquica de los objetos, los heredados de aquellos distribuidos directamente por LACNIC (por ejemplo, sub-asignaciones), están cubiertos por los objetos de nivel superior y su propio atributo “abuse-c” es opcional.”
LACNIC entiende que esto significa que en caso de sub asignaciones de direcciones, el contacto de “abuse-c” puede estar cubierto por el de la organización de nivel superior o por el de su propia organización.

4. Se observa que para la implementación de esta propuesta LACNIC necesitará invertir nuevos recursos para atender el seguimiento de todos los casos que lo necesiten.

5. Tal como está redactada la propuesta, el bloqueo de Mi LACNIC permitiría acceso acceso a las cuestiones exclusivamente contractuales y relacionadas con pagos, así como la actualización de los contactos abuse-c/abuse-mailbox Por lo cual, inhabilitaría a nuevos servicios que surjan podría ofrecer Mi LACNIC.

Recomendaciones
-------------------
1. En la sección 12.5, cuando se indica “De mantenerse el incumplimiento, LACNIC actuará de conformidad con sus políticas y procedimientos pertinentes”:
a. no se especifica cómo deberá proceder LACNIC. LACNIC interpreta que el incumplimiento de esta política no determina la revocación de los recursos dado que se eliminó en la versión anterior. Si se pretende que el incumplimiento de esta política sea causal de revocación el autor deberá dejarlo explícito en el texto propuesto.
b. se recomienda aclarar al indicar “de mantenerse el incumplimiento (...) LACNIC entiende que se refiere a mantenerse el incumpliemiento durante el período de verificación inicial y adicional.

2. Es importante recordar que la revocación de recursos es de carácter permanente, tiene alto impacto sobre la operativa de las organizaciones y es un proceso complejo. Por este motivo recomendamos que esta instancia únicamente se aplique agotados todos los recursos y pasado un plazo significativo luego de que la irregularidad es detectada.

3. En el punto 5) de la sección 12.3, LACNIC asume que el “escalado” sería con el contacto administrativo de la organización. Se recomienda aclarar la redacción.

4. Se recomienda que la propuesta no defina plazos, sino que determine acciones y que los plazos necesarios se definan en base a razones operativas.

Impacto en el sistema de registro
---------------------------------
Esta propuesta implicará la creación de un proceso para el control automático del abuse-c y abuse-mailbox.
Además implicará un desarrollo para el sistema el portal de los NIRs y de LACNIC para el bloqueo inicial.
Fuentes oficiales de referencias

Políticas sobre el contacto de abuso en otros RIRs
.-------------------------------------------------
RIPE
Hay una propuesta en fase de implementación: https://www.ripe.net/publications/docs/ripe-705
Sin embargo, es más flexible: la frecuencia es cada un año y es más simple, RIPE revisará que exista un dominio y que haya un servidor de correo configurado únicamente.

APNIC
Una política similar a la de LACNIC llegó a consenso en el último evento de APNIC y está en fase de implementación.
https://www.apnic.net/wp-content/uploads/2018/08/prop-125-v001.txt

ARIN: De acuerdo a la sección 3.6: https://www.arin.net/participate/policy/nrpm/#3-6-annual-validation-of-arin-s-public-whois-point-of-contact-data
Actualmente ARIN utiliza el siguiente procedimiento de validación: envía un correo una vez al año a cada contacto registrado. Cada contacto tiene un máximo de 60 días para responder que el contacto es correcto y está actualizado. De no responder luego de los 60 días, el contacto será marcado como inválido en la base de datos. Estos usuarios tendrán acceso limitado a las funcionalidades de ARIN online hasta que actualicen el contacto.
Además, hay una propuesta similar a la de LACNIC que se presentará en el evento de abril de ARIN: https://www.arin.net/participate/policy/drafts/2019_5/

AFRINIC
Hay una propuesta similar a la de LACNIC que está en discusión desde noviembre del 2018. Se presentó en el último evento y volvió a discusión.
https://afrinic.net/policy/2018-gen-001-d2#proposal

ANALISE DE IMPACTO PELA EQUIPE DE LACNIC - Proposta LAC-2018-5 - versión 4

Interpretação da proposta pela equipe de LACNIC
-----------------------------------------------------

Aplicação da proposta
---------------------------
Esta proposta seria aplicada nos receptores de recursos de LACNIC para que registrem um contato de abuso válido para ASNs, IPv4 e IPv6.

Modificação do texto atual
----------------------------
A seção atual “12. Apêndices "passa a ser" A. Apêndices", no final do Manual de Políticas, e todas suas referências são atualizadas.

Serão acrescentadas as seções:
o 12. “Registro e Validação de "abuse-c" e "abuse-mailbox”
o 12.1 “Descrição do "abuse-c" e "abuse-mailbox”
o 12.2. “Características do "abuse-mailbox"
o 12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"
o 12.4. Validação do "abuse-c"/"abuse-mailbox"
o 12.5. Mecanismo de escalado para LACNIC

A nova versão acrescenta:
---------------------------
1. A sugestão da equipe que durante o bloqueio de Mi LACNIC também seja permitido acessar ao contato e à parte do pagamento em Mi LACNIC a pesar do incumprimento.

2. Melhorar a redação em algumas frases.

Comentários da equipe
----------------------
1. Mesmo que o Manual de Políticas não indique que o bloco IPv4 deva conter um contato de abuso, o sistema de LACNIC já suporta esta modalidade e os blocos IPv4, IPv6 e ASN já possuem este atributo. O mesmo acontece no caso das subdesignações, o abuse-c usado é o ponto de contato administrativo da organização que recebe a designação ou a subdesignação.

Foi feita uma consulta ao Banco de Dados de LACNIC sobre o registro dos contatos de abuso de cada tipo de recursos e os seguintes resultados foram obtidos:
- Número de recursos IPv4, IPv6, ASN com contato de abuso null ou vazio: 0
- Número de recursos legados IPv4 com contatos de abuso null ou vazio: 241
- Número de recursos legados IPv6 com contatos de abuso null ou vazio: 0
- Número de recursos legados ASN com contatos de abuso null ou vazio: 146

Portanto, atualmente não existe nenhum recurso que não seja legado com o contato de abuso vazio/null. Todos os que aparecem na BD com null/vazio sai legados.
2. LACNIC entende que isso não aplica para as organizações com recursos legados, já que nada é mencionado sobre esse tipo de organização.

3. Em relação ao seguinte texto: “Levando em conta a natureza hierárquica dos objetos, os herdados de aqueles alocados diretamente por LACNIC (por exemplo, subdesignações), são cobertos pelos objetos de nível superior e seu próprio atributo "abuse-c” é optativo”
LACNIC entende que isso significa que, no caso de subdesignações de endereços, o contato de "abuse-c" pode estar coberto pelo da organização de nível superior ou pelo de sua própria organização.

4. Observa-se que, para a implementação desta proposta, LACNIC precisará investir novos recursos para atender o acompanhamento de todos os casos que precisarem.
Recomendações
-------------------
5. Na seção 12.5 quando é apontado que “Se o incumprimento for mantido, LACNIC atuará de acordo com suas políticas e procedimentos pertinentes”:

5.1. Não é especificado como deverá proceder LACNIC. LACNIC interpreta que a violação desta política não determina a revogação dos recursos desde que foi eliminada na versão anterior. Se se pretende que o incumprimento desta política seja motivo de revogação, o autor deverá deixá-lo explícito no texto proposto.

5.2. Ao indicar “se o incumprimento for mantido (...) LACNIC entende que a seguinte verificação d incumprimento seria na segunda validação do ano.

6. É importante lembrar que a revogação de recursos é permanente, tem alto impacto nas operações das organizações e é um processo complexo. Por esse motivo, recomendamos que essa instância seja aplicada apenas quando todos os recursos sejam esgotados e tenha passado um prazo significativo após a irregularidade ser detectada.

7. Na seção 12.1 é indicado: “Todos os recursos alocados (…)”.
Recomenda-se trocar por: “Todos os recursos alocados e designados (…)”. Desta forma, procuramos manter a linguagem do Manual de Políticas, para indicar que "alocados" faz referência aos ISPs e "designados" aos Usuários Finais.

8. No ponto 5) da seção 12.3, LACNIC assume que o “escalado” seria com o contato administrativo da organização. Recomenda-se esclarecer a redação.

9. Recomenda-se que a proposta não defina prazos, mas determine ações e que os prazos necessários sejam definidos com base em razões operacionais.
Impacto no sistema de registro
---------------------------------

Esta proposta implicará a criação de um processo para o controle automático do abuse-c e abuse-mailbox.
Implicará também um desenvolvimento para o sistema o portal dos NIRs e de LACNIC para o bloqueio inicial.

Fontes oficiais de referências
--------------------------------
Políticas sobre o contato de abuso nos outros RIRs
--------------------------------------------------
- RIPE
Existe uma na fase de implementação: https://www.ripe.net/publications/docs/ripe-705
No entanto, é mais flexível: a frequência é anual e é mais simples, RIPE irá verificar que exista um domínio e que haja apenas um servidor de correio configurado.

- APNIC
Uma política semelhante à de LACNIC alcançou consenso no último evento de APNIC e está em fase de implementação.
https://www.apnic.net/wp-content/uploads/2018/08/prop-125-v001.txt

- ARIN
De acordo à seção 3.6: https://www.arin.net/participate/policy/nrpm/#3-6-annual-validation-of-arin-s-public-whois-point-of-contact-data

ARIN atualmente usa o seguinte procedimento de validação: envia um e-mail uma vez por ano para cada contato registrado. Cada contato tem um máximo de 60 dias para responder que o contato é correto e está atualizado. Se o contato não responder após 60 dias, será marcado como inválido no banco de dados. Estes usuários terão acesso limitado às funcionalidades de ARIN on-line até o contato seja atualizado.

Também há uma proposta semelhante à de LACNIC que será apresentada no evento de abril de ARIN:
https://www.arin.net/participate/policy/drafts/2019_5/

- AFRINIC
Também há uma proposta semelhante à de LACNIC que está em discussão desde novembro de 2018. Foi apresentada no último evento e voltou a discussão.
https://afrinic.net/policy/2018-gen-001-d2#proposal

ANALISE DE IMPACTO PELA EQUIPE DE LACNIC - Proposta LAC-2018-5 - versão 3

Interpretação da proposta pela equipe de LACNIC
----------------------------------------------------

Aplicação da seção 12. Registro e validação de "abuse-c" e "abuse-mailbox"
---------------------------------------------------------------------------
Esta proposta se aplicaria aos receptores dos recursos de LACNIC para que registrem um contato de abuso válido, tanto para ASNs quanto para IPv4 e IPv6.

Modificação do texto atual
---------------------------
De acordo com as modificações apresentadas na proposta 2018-5, o manual de políticas ficaria como mostrado abaixo nas seguintes seções:

• Adicionam-se as seções:
o 12. Registro e validação de "abuse-c" e "abuse-mailbox”
o 12.1 Descrição do "abuse-c" e "abuse-mailbox”
o 12.2. Características do "abuse-mailbox
o 12.4. Validação do "abuse-c"/"abuse-mailbox"
o 12.5. Mecanismo de escalado para LACNIC

• Seção 12. Os apêndices deixam de ter numeração para poder incorporar novas seções sem a necessidade de renumerar os apêndices constantemente.

Comentários da equipe
----------------------
• Mudanças em relação à versão anterior da proposta:
o Incorpora as recomendações da equipe de LACNIC das versões anteriores sobre:
- usar o termo inetnum tanto para IPv4 quanto para IPv6
- colocar a seção de apêndices sem numeração
o Acrescenta que o procedimento estabelecido por LACNIC deve impedir que o processo de validação seja exclusivamente automatizado.
o Modifica que o prazo de validação inicial não deve ser superior a 15 dias úteis em vez de 2.
o Indica que, se o contato de abuso não for validado corretamente na etapa inicial, será escalado com o receptor do recurso em um prazo não superior a 15 dias, em vez de 3.
o Acrescenta que os prazos de validação “inicial” e “escalado” podem ser modificados por LACNIC.
o Muda a validação periódica que LACNIC deveria fazer de uma vez cada 3 meses para duas vezes por ano. Além disso, permite que LACNIC modifique a frequência de validação se considerar oportuno.
o Propõe uma alternativa no caso de descumprimento:
- Bloqueio inicial de milacnic para todos os recursos da organização, exceto para a atualização de contatos abuse-c/abuse-mailbox
- Se os contatos de abuso forem atualizados corretamente, serão revalidados para permitir o desbloqueio de milacnic.
- No caso de descumprimento continuado, será aplicada a seção 7.1. Recuperação de recursos.

Recomendações
• Na seção 12.4 e 12.5, quando disse “O descumprimento, implicará um seguimento mais exaustivo, de conformidade com as políticas/procedimentos pertinentes de LACNIC e principalmente "7.1. Recuperação de recursos", não especifica como deve proceder LACNIC, si terá que aplicar a política 7.1 em todos os casos ou não.
• Observa-se que para a implementação desta proposta LACNIC precisará investir novos recursos para atender ao acompanhamento de todos os casos que o necessitarem.
• Recomenda-se que a proposta não defina prazos, mas que determine ações, e que os prazos necessários sejam definidos com base em motivos operacionais.
• Se sugere que durante o bloqueio de Mi LACNIC também se deveria permitir o acesso ao contrato de afiliação e à sessão de pagamento em Mi LACNIC apesar do incumplimento.
• Em relação às informações adicionais mencionadas na proposta, aponta que "uma proposta semelhante sobre o contato de abuso alcançou consenso no RIPE NCC em junho de 2018".
(https://www.ripe.net/participate/policies/proposals/2017-02).
A proposta 2017-2 do RIPE NCC é mais flexível: não indica prazos e a validação que o RIPE implementará é mais simples, verificará que exista um domínio e que haja um servidor de correio configurado unicamente.

Impacto da política no sistema de registro e endereços
-------------------------------------------------------
Esta proposta implicará a criação de um processo para a fiscalização automática do abuse-c e abuse-mailbox.

ANALISE DE IMPACTO PELA EQUIPE DE LACNIC - Proposta LAC-2018-5 - versão 2

Interpretação da proposta pela equipe de LACNIC
----------------------------------------------------

Aplicação
-----------
Esta proposta seria aplicada aos LIR para que deixem um registro de um contato de abuso válido.

Alteração do texto atual
-----------------------------
O manual de políticas aparecerá na seção seguinte como mostrado abaixo:

• Serão acrescentadas as secções:
o 12. “Registro e validação de "abuse-c" e "abuse-mailbox”
o 12.1 "Descrição do "abuse-c" e "abuse-mailbox"
o 12.2. "Características do "abuse-mailbox"
o 12.3. Objetivos da validação do "abuse-c"/"abuse-mailbox"
o 12.4. Validação do "abuse-c" /"abuse-mailbox"
o 12.5. Mecanismo de escalado para LACNIC

• O ponto 12: “Apêndices” passa a ser a secção 13. Apêndices.


Comentários da equipe:
-----------------------
• Nas secções 12.4 e 12.5 quando indicado "O descumprimento implicará um acompanhamento mais exaustivo, de acordo com as políticas/procedimentos pertinentes de LACNIC e, principalmente, "7.1. Recuperação de recursos", não fica claro como deverá proceder LACNIC, se deverá aplicar a política 7.1 em todos os casos ou não.


• Observa-se que, para a implementação desta proposta, LACNIC precisará investir novos recursos para atender o acompanhamento de todos os casos que precisarem. 


• Na proposta se faz referência ao objeto “inetnum6”. No whois de LACNIC, só se faz referência ao objeto "inetnum", tanto para IPv4 quanto para IPv6.


• Recomenda-se colocar a secção do apêndice sem numeração, mas como "A" (apêndice). Esta recomendação é para não ter que atualizar a numeração do apêndice tantas vezes como secções adicionadas ao manual, o que poderia gerar erros devido a todas as referências para o apêndice (seção 12), que aparecem ao longo do texto do manual de políticas.

Impacto da política no sistema de registro e endereços
-------------------------------------------------------
Esta proposta implicará a criação de um processo para o controle automático do abuse-c e do abuse-mailbox.

Política de privacidade