Detalhes
|
Atualização da política de contato de abuso |
|||
|
IDENTIDADE: |
AFPUB-2018-GEN-001-DRAFT08 |
Data de envio: |
15 de maio de 2022 |
|
Autor: |
Jordi Palet Martinez jordi.palet noipv6company.com O Plano de Ação Global para Saúde Mental XNUMX-XNUMX da IPv6 Empresa |
Versão: |
8.0 |
|
Estado: |
Expirado |
Altera: |
CPM arte 8.0
|
Proposta
1. Resumo do problema tratado nesta proposta
A política atual não implica a obrigação de registrar um contato de abuso e especifica um formato para comunicação pessoal e para “denúncia automática”, que em comparação com outros RIRs torna-se confuso, pois um único e-mail será mais eficiente, pois, no final, os relatórios são copiados para os dois e-mails.
Como resultado, alguns detentores de recursos podem não ter essas informações de contato registradas e atualizadas para seus recursos. De fato, existem até casos de caixas de correio inexistentes ou que não são monitoradas ativamente.
Na prática, esse contato torna-se ineficaz para denunciar abusos e geralmente gera problemas de segurança e custos para as vítimas. Isso também é contraditório com a RSA, que afirma que as informações nos bancos de dados devem ser precisas. Esta política garante que isso possa ser verificado automaticamente e periodicamente pela AFRINIC, sem entrar nos detalhes operacionais de como fazê-lo. Na verdade, há uma atividade AFRINIC (https://afrinic.net/stats/contact-update) que visa a verificação dos contactos, contudo apenas reportou para 2017.
Novamente, esta proposta, garante que esta atividade seja feita de forma automatizada (o máximo possível), economizando custos para o associado e para a comunidade.
Esta proposta visa solucionar este problema e garantir a existência de um contato abuse-c adequado e o processo para sua utilização, mais uniforme em todas as RIRs, a fim de facilitar a denúncia de abuso entre regiões.
As referências políticas existentes a um “Documento de Boas Práticas”, que não é considerado obrigatório e, de fato, não estão sendo usadas pela comunidade. Essa proposta não altera o escopo desse documento e, de fato, um vínculo entre os poucos objetos IRT existentes e o novo deve ser estabelecido automaticamente.
Desta forma, o contato de abuso AFRINIC estará alinhado com outros RIRs. APNIC, por exemplo, agora está usando o IRT, mas como uma proposta equivalente foi aceita, um “link” automatizado (alias ou ponteiro) para o IRT pré-existente será criado, então abuse-c e abuse-mailbox prevalecem.
Não há necessidade de excluir os outros dados opcionais hoje incluídos no IRT; é uma decisão operacional do AFRINIC como lidar com a transição. Essa política apenas garante que abuso-ce caixa de correio-abuso estejam disponíveis e verificados periodicamente.
2. Resumo de como esta proposta aborda o problema
A comunidade da Internet é baseada na colaboração. No entanto, em muitos casos, isso não é suficiente e todos precisamos entrar em contato com os LIRs que podem estar enfrentando problemas em suas redes e desconhecem a situação.
Esta proposta cria uma nova seção no Manual de Política para resolver esse problema por meio de uma verificação simples e periódica, e estabelece as regras básicas para a realização dessa verificação e, assim, evita custos desnecessários a terceiros que precisam entrar em contato com as pessoas responsáveis pela solução do problema. abusos de uma rede específica.
A proposta garante que o custo do processamento do abuso recaia sobre o detentor do recurso cujo cliente está causando o abuso (e de quem ele recebe compensação financeira pelo serviço), em vez de recair sobre a vítima, como seria o caso se eles tivessem recorrer aos tribunais, evitando custos (advogados, solicitadores etc.) e economizando tempo para ambas as partes.
Para isso, o atributo abuse-c se torna obrigatório nos objetos "aut-num", "inetnum" e "inet6num", assim como em qualquer outro que possa ser usado no futuro. Este atributo é um contato de abuso, que deve conter pelo menos o atributo "abuse-mailbox".
Espera-se que a proposta seja implementada em 90 dias, a ser confirmada pela AFRINIC, um período de tempo razoável para permitir que os funcionários desenvolvam a ferramenta e os membros atualizem seus contatos abuse-c.
3. Proposta
3.1 Alterando 8.0 do CPM, como segue:
|
Atual |
Proposto |
|
8.1 Introdução Esta política especifica um objeto dedicado que deve ser usado como o local preferido para publicar informações de contato público de abuso na região de serviço do AFRINIC. O objeto mencionado pode ser referenciado nos objetos inetnum, inet6num e aut-num no AFRINIC whois base de dados. Ele fornece uma maneira mais precisa e eficiente para denúncias de abuso chegarem ao contato de rede correto
|
8.1 Introdução Esta política especifica um atributo obrigatório (abuse-c) que deve ser usado para publicar informações de contato público sobre abuso na região de serviço do AFRINIC. O atributo mencionado deve ser referenciado nos objetos inetnum, inet6num e aut-num no AFRINIC whois Base de dados. Ele fornece uma maneira mais precisa e eficiente para denúncias de abuso chegarem ao contato correto.
|
|
8.2 Detalhes da política: Para disponibilizar um novo ou usar um já existente whois objeto de banco de dados que implementa as seguintes propriedades:
O objeto deve ser acessível através do whois protocolo. AFRINIC para publicar um Documento de boas práticas que incentiva todos os membros a usar ativamente o objeto para publicar informações de contato de abuso. |
8.2 Descrição de “abuse-c” e “abuse-mailbox” Os recursos alocados / atribuídos pelo AFRINIC devem incluir um atributo de contato "abuse-c" obrigatório (contato de abuso), apontando para uma pessoa ou função, com pelo menos uma caixa de entrada de email válida, monitorada e gerenciada ativamente (caixa de correio de abuso) destinada a receber relatórios sobre comportamento abusivo, questões de segurança e similares. O atributo "abuse-mailbox" deve estar disponível de forma irrestrita via whois, APIs e técnicas futuras. Considerando a natureza hierárquica dos objetos de endereço IP, os objetos filhos daqueles distribuídos diretamente pelo AFRINIC podem ser cobertos por objetos pais ou podem ter seu próprio atributo "abuse-c". Seguindo práticas usuais, outros atributos de "email" podem ser incluídos para outros fins.
|
|
8.3 Vantagens e desvantagens da política 8.3.1 Vantagens
8.3.2 Desvantagens Este objeto, como todos os outros objetos existentes, enfrentará o problema de precisão de dados. Esta política visa resolver o problema da falta de lugar para informações de contato abusivas e não vai melhorar a precisão dos dados no whois base de dados. No entanto, sugere-se à AFRINIC que ofereça uma forma de receber relatos sobre objetos que não funcionam ou não são precisos. |
8.3 Sobre a "caixa de correio de abuso" Emails enviados para "abuse-mailbox":
|
|
8.4 Objetivos da validação "abuse-c" / "abuse-mailbox" O procedimento, que será desenvolvido pela AFRINIC, deve atender aos seguintes objetivos:
|
|
|
8.5 Validação de "abuse-c" / "abuse-mailbox" O AFRINIC validará a conformidade com os itens acima, quando os atributos "abuse-c" e / ou "abuse-mailbox" forem criados ou atualizados, bem como periodicamente, pelo menos uma vez a cada 6 meses, e sempre que o AFRINIC considerar adequado.
|
|
|
8.6 Encaminhamento para AFRINIC Comportamento fraudulento (por exemplo, uma "caixa de correio de abuso" que apenas responde aos e-mails da AFRINIC ou a mensagens com um assunto ou conteúdo específico) ou falha no cumprimento dos aspectos restantes desta política (incorreta ou falta de resposta a casos de abuso) podem ser relatados ao AFRINIC para uma revalidação (conforme a seção 8.5 acima).
|
|
|
8.7 Arranque lento e acompanhamento do progresso Os períodos iniciais / escalonados e a periodicidade de validação definidos por esta política podem ser alterados anualmente pela AFRINIC, considerando os procedimentos internos, as necessidades de pessoal e os dados reais, considerando tanto o início lento quanto o acompanhamento da precisão dos dados. As razões para as emendas serão devidamente comunicadas à comunidade.
|
3.2 Informações adicionais:
Se esta proposta chegar a um consenso, para cumpri-la, a AFRINIC deve renomear mnt-IRT para abuse-c. É uma decisão operacional do AFRINIC se um alias (ponteiro, atributo duplicado ou qualquer outra alternativa) para mnt-IRT é mantido e por quanto tempo (período de transição) para facilitar a busca em whois para a mesma informação, independentemente de procurar abuse-c ou mnt-IRT. É uma decisão operacional do AFRINIC manter e por quanto tempo o IRT ou excluí-lo e o restante da informação real no IRT. A AFRINIC também decidirá como atualizar as diretrizes atuais (https://www.afrinic.net/library/membership765-abuse-policy-bcp) melhor ou se elas não são mais necessárias. Isso é feito para assimilar o IRT à maioria dos RIRs onde há abuso-c.
A título de esclarecimento, os períodos de validação “inicial” e “escalada” podem ser modificados pela AFRINIC, se julgar conveniente, desde que informe a comunidade sobre sua motivação para fazê-lo. Por exemplo, os períodos podem ser estendidos na fase de implementação e ajustados à medida que uma porcentagem maior de contatos se tornar precisa.
Da mesma forma, a frequência da validação periódica pode ser modificada se o AFRINIC considerar apropriado e informar a comunidade de suas razões para fazê-lo.
Por exemplo, uma única validação pode ser feita no primeiro ano para facilitar a adesão à política. O número de validações anuais pode aumentar ao longo do tempo, talvez se tornando trimestral, com o objetivo de melhorar a qualidade dos contatos.
Isso facilitará o AFRINIC para um “início lento” para implementar a política e garantir que nenhuma equipe adicional seja necessária nas fases iniciais de implementação, pois dependendo da taxa de contatos com falha, eles podem precisar de mais tempo para as primeiras passagens por todos os Filiação. Por exemplo, pode-se esperar que o primeiro passe leve de 12 a 24 meses e seja feito por diferentes tipos de membros (LIRs/usuários finais/outros), com um lote por mês ou mesmo mantendo o próximo lote em caso de muito alta taxa de falhas, etc.
Como em todas as outras apólices, esta não estabelece condições diferenciadas específicas para os titulares de legados. Esta é uma questão genérica do AFRINIC que deve ser abordada de forma uniforme em todos os manuais de políticas.
Da mesma forma, a política não prevê as consequências do descumprimento, já que é genericamente declarado no RSA.
A política não define o que é abuso porque essa definição não se enquadra de forma alguma nas ações da perspectiva AFRINIC. Cada participante da Internet deve definir o que é abuso para eles, e caso outros não respeitem, podem usar o abuse-c para contatá-los e em caso de inação para resolver o caso, devem escalar o assunto de acordo com suas próprias procedimentos, que em alguns casos, também podem depender de seus regulamentos locais. Tudo isso está fora do escopo da AFRINIC.
Esta política não tem impacto adicional no GDPR, pois isso já está coberto por todos os regulamentos AFRINIC existentes sobre esse assunto.
Esta proposta não impõe nenhum cronograma de implementação, que é deixado para as práticas operacionais, prioridades e necessidades de pessoal da AFRINIC.
4. Referências
Uma proposta equivalente foi aceita em APNIC (já implementada) e LACNIC (em implementação). Uma nova versão está sendo elaborada para RIPE e ARIN.
Histórico de Revisão
Histórico de Revisão
|
Data |
Detalhes |
|
12 agosto 2018 |
Versão 1: AFPUB-2018-GEN-001-DRAFT01
|
|
20 Novembro de 2018 |
Versão 2: AFPUB-2018-GEN-001-DRAFT02
|
|
5 de Junho de 2019 |
|
|
2nd novembro 2019 |
Versão 4: AFPUB-2018-GEN-001-DRAFT04
|
|
21 Novembro de 2019 |
Versão 5: AFPUB-2018-GEN-001-DRAFT05
|
| 5 agosto 2020 |
Versão 6: AFPUB-2018-GEN-001-DRAFT06
|
| 17 de maio de 2021 |
Versão 7: AFPUB-2018-GEN-001-DRAFT07
|
| 15 de maio de 2022 |
Versão 8: AFPUB-2018-GEN-001-DRAFT08
|
