Détails
|
Mise à jour de la politique Abuse Contact Policy Update |
|||
|
ID: |
AFPUB-2018-GEN-001-DRAFT08 |
Date de soumission: |
15 mai 2022 |
|
Auteur : |
Jordi Palet Martínez jordi.palet auipv6company.com The IPv6 Company |
Version: |
8.0 |
|
Statut: |
Expiré |
Modifie: |
Art CPM 8.0
|
Proposition
1. Résumé du problème traité par cette proposition
La politique actuelle n'implique pas l'obligation d'enregistrer un contact abusif et spécifie un format de communication personnelle et de «signalement automatique», qui, par rapport aux autres RIRs devient déroutant, car un seul e-mail sera plus efficace, car à la fin, les rapports sont copiés dans les deux e-mails.
En conséquence, certains détenteurs de ressources peuvent ne pas avoir ces informations de contact enregistrées et à jour pour leurs ressources. En fait, il existe même des cas de boîte aux lettres inexistante ou qui n'est pas activement surveillée.
En pratique, ce contact devient inefficace pour signaler les abus et engendre généralement des problèmes de sécurité et des coûts pour les victimes. Ceci est également contradictoire avec RSA, qui stipule que les informations contenues dans les bases de données doivent être exactes. Cette politique garantit que cela peut être vérifié automatiquement et périodiquement par AFRINIC, sans entrer dans les détails opérationnels de la façon de le faire. En fait il y a une activité AFRINIC (https://afrinic.net/stats/contact-update) qui vise à la vérification des contacts, mais il n'a signalé que pour 2017.
Encore une fois, cette proposition garantit que cette activité est effectuée de manière automatisée (autant que possible), ce qui réduit les coûts pour les membres et la communauté.
Cette proposition vise à résoudre ce problème et à garantir l’existence d’un contact approprié contre les abus et le processus de son utilisation, qui est plus uniforme dans tous les pays. RIRs, afin de faciliter le signalement des abus entre régions.
Les références politiques existantes à un «document sur les meilleures pratiques», qui n'est pas considéré comme obligatoire et en fait, n'est pas utilisé par la communauté. Cette proposition ne modifie pas la portée de ce document et, en fait, un lien entre les quelques objets IRT existants et le nouveau devrait être automatiquement établi.
De cette façon, le contact avec AFRINIC en cas d'abus sera conforme aux autres RIRs. L'APNIC, par exemple, utilise désormais l'IRT, mais comme une proposition équivalente a été acceptée, un «lien» automatisé (alias ou pointeur) vers l'IRT préexistant sera créé, de sorte que abuse-c et abuse-mailbox prévalent.
Il n'est pas nécessaire de supprimer les autres données optionnelles aujourd'hui incluses dans l'IRT, c'est une décision AFRINIC opérationnelle de gérer la transition. Cette politique garantit simplement que abuse-c et abuse-mailbox sont disponibles et vérifiés périodiquement.
2. Résumé de la manière dont cette proposition résout le problème
La communauté Internet est basée sur la collaboration. Cependant, dans de nombreux cas, cela ne suffit pas et nous devons tous être en mesure de contacter les LIR qui peuvent rencontrer des problèmes dans leurs réseaux et ne sont pas conscients de la situation.
Cette proposition crée une nouvelle section dans le manuel des politiques pour résoudre ce problème au moyen d'une vérification simple et périodique, et établit les règles de base pour effectuer une telle vérification et évite ainsi des coûts inutiles aux tiers qui doivent contacter les personnes chargées de résoudre le problème. abus d'un réseau spécifique.
La proposition garantit que le coût du traitement de l'abus incombe au détenteur de la ressource dont le client est à l'origine de l'abus (et de qui il reçoit une compensation financière pour le service), au lieu de tomber sur la victime, comme ce serait le cas s'il avait recourir aux tribunaux, évitant ainsi des frais (avocats, solicitors, etc.) et un gain de temps pour les deux parties.
Pour cela, l'attribut abuse-c devient obligatoire dans les objets "aut-num", "inetnum" et "inet6num", ainsi que dans tous les autres qui pourraient être utilisés à l'avenir. Cet attribut est un contact abusif, qui doit contenir au moins l'attribut "boîte aux lettres abusive".
La proposition devrait être mise en œuvre dans 90 jours, à confirmer par l'AFRINIC, un délai raisonnable pour permettre à la fois au personnel de développer l'outil et aux membres de mettre à jour leurs contacts en matière d'abus-c.
3. Proposition
3.1 Modifier le 8.0 de la RPC, comme suit:
|
Actuel |
Proposition |
|
8.1 Introduction Cette politique spécifie un objet dédié qui doit être utilisé comme lieu préféré pour publier des informations de contact public abusives dans la région de service AFRINIC. L'objet mentionné peut être référencé dans les objets inetnum, inet6num et aut-num dans l'AFRINIC whois base de données. Il fournit un moyen plus précis et efficace pour les rapports d'abus d'atteindre le bon contact réseau
|
8.1 Introduction Cette politique spécifie un attribut obligatoire (abus-c) qui doit être utilisé pour publier les informations de contact public concernant les abus dans la région de service AFRINIC. L'attribut mentionné doit être référencé dans les objets inetnum, inet6num et aut-num dans l'AFRINIC whois Base de données. Il fournit un moyen plus précis et efficace pour les rapports d'abus d'atteindre le bon contact.
|
|
8.2 Détails de la politique: Pour rendre disponible un nouveau ou utiliser un déjà existant whois objet de base de données qui implémente les propriétés suivantes:
L'objet doit être accessible via le whois protocole. AFRINIC pour publier un Document sur les meilleures pratiques qui encourage tous les membres à utiliser activement l'objet pour publier des informations de contact d'abus. |
8.2 Description de «abuse-c» et «abuse-mailbox» Les ressources allouées / attribuées par AFRINIC doivent inclure un attribut de contact "abus-c" obligatoire (contact abusif), pointant vers une personne ou un rôle, avec au moins une boîte de réception (boîte aux lettres abusive) valide, surveillée et activement gérée destinée à recevoir des rapports concernant les comportements abusifs, les problèmes de sécurité, etc. L'attribut "abuse-mailbox" doit être disponible sans restriction via whois, API et techniques futures. Compte tenu de la nature hiérarchique des objets d'adresse IP, les objets enfants de ceux directement distribués par AFRINIC peuvent être couverts par des objets parents ou ils peuvent avoir leur propre attribut "abuse-c". Suivant les pratiques habituelles, d'autres attributs "e-mail" peuvent être inclus à d'autres fins.
|
|
8.3 Avantages et inconvénients de la politique 8.3.1 Avantages
8.3.2 Inconvénients Cet objet, comme tous les autres objets existants, sera confronté au problème de précision des données. Cette politique vise à résoudre le problème d'une place manquante pour les coordonnées d'abus et n'améliorera pas l'exactitude des données dans le whois base de données. Néanmoins, il est suggéré à AFRINIC de proposer un moyen de recevoir des rapports sur des objets non fonctionnels ou non précis. |
8.3 À propos de la "boîte aux lettres d'abus" Emails envoyés à "abuse-mailbox":
|
|
8.4 Objectifs de la validation "abuse-c" / "abuse-mailbox" La procédure, qui sera développée par AFRINIC, doit répondre aux objectifs suivants:
|
|
|
8.5 Validation de "abuse-c" / "abuse-mailbox" AFRINIC validera la conformité avec les éléments ci-dessus, à la fois lorsque les attributs "abuse-c" et / ou "abuse-mailbox" sont créés ou mis à jour, ainsi que périodiquement, au moins une fois tous les 6 mois, et chaque fois qu'AFRINIC le juge opportun.
|
|
|
8.6 Escalade vers AFRINIC Comportement frauduleux (par exemple, une "boîte aux lettres d'abus" qui ne répond qu'aux e-mails d'AFRINIC, ou à des messages avec un sujet ou un contenu spécifique), ou le non-respect des autres aspects de cette politique (incorrect ou absence de réponse aux cas de peuvent être signalés à AFRINIC pour une revalidation (conformément à la section 8.5 ci-dessus).
|
|
|
8.7 Démarrage lent et suivi des progrès Les périodes initiales / d'escalade et la périodicité de validation fixées par cette politique peuvent être modifiées chaque année par AFRINIC, en tenant compte des procédures internes, des besoins en personnel et des données réelles, en tenant compte à la fois d'un démarrage lent et d'un suivi de l'exactitude des données. Les raisons des modifications doivent être dûment communiquées à la communauté.
|
3.2 Informations supplémentaires:
Si cette proposition parvient à un consensus, pour s'y conformer, AFRINIC doit renommer mnt-IRT en abuse-c. C'est une décision AFRINIC opérationnelle si un alias (pointeur, attribut dupliqué ou toute autre alternative) à mnt-IRT est conservé et pendant combien de temps (période de transition) afin de faciliter la recherche dans whois pour les mêmes informations, indépendamment de la recherche d'abus-c ou de mnt-IRT. C'est une décision opérationnelle d'AFRINIC de conserver et pendant combien de temps l'IRT ou de le supprimer et le reste des informations réelles dans l'IRT. AFRINIC décidera également comment mettre à jour les directives actuelles (https://www.afrinic.net/library/membership765-abuse-policy-bcp) mieux ou si elles ne sont plus nécessaires. Ceci est fait dans le but d'assimiler l'IRT à la majorité des RIRs où il est abusif-c.
À titre de clarification, les périodes de validation «initiale» et «d'escalade» peuvent être modifiées par AFRINIC, si cela est jugé approprié, à condition qu'il informe la communauté de sa motivation à le faire. Par exemple, les périodes pourraient être prolongées dans la phase de mise en œuvre et ajustées à mesure qu'un pourcentage plus élevé de contacts deviennent exacts.
De même, la fréquence de la validation périodique peut être modifiée si AFRINIC le juge approprié et informe la communauté des raisons pour lesquelles elle le fait.
Par exemple, une seule validation peut être effectuée au cours de la première année pour faciliter le respect de la politique. Le nombre de validations annuelles pourrait augmenter dans le temps, devenant peut-être trimestriel, dans le but d'améliorer la qualité des contacts.
Cela facilitera AFRINIC pour un "démarrage lent" pour mettre en œuvre la politique et garantira qu'aucun personnel supplémentaire n'est nécessaire dans les phases initiales de mise en œuvre, car en fonction du taux d'échec des contacts, ils peuvent avoir besoin de plus de temps pour les premiers passages à travers tous les adhésion. Par exemple, on pourrait s'attendre à ce que le premier passage prenne 12 à 24 mois et soit effectué par différents types de membres (LIR/utilisateurs finaux/autres), avec un lot chaque mois ou même en retenant le lot suivant en cas de très taux d'échec élevé, etc.
Comme dans toutes les autres politiques, celle-ci ne fixe pas de conditions spécifiques différentes pour les détenteurs d'héritage. Il s'agit d'un problème AFRINIC générique qui devrait être abordé de manière uniforme pour tous les manuels de politiques.
De même, la politique n'indique pas les conséquences du non-respect, comme cela est indiqué de manière générique dans le RSA.
La politique ne définit pas ce qu'est un abus, car cette définition ne correspond en aucun cas aux actions du point de vue d'AFRINIC. Chaque participant Internet doit définir ce qu'est un abus pour lui, et si d'autres ne respectent pas cela, ils peuvent utiliser l'abus-c pour les contacter et en cas d'inaction pour résoudre le cas, ils doivent escalader le problème en fonction de leurs propres procédures qui, dans certains cas, peuvent également dépendre de leurs réglementations locales. Tout cela est en dehors du champ d'application d'AFRINIC.
Cette politique n'a pas d'impact supplémentaire sur le GDPR, car cela est déjà couvert par toutes les réglementations AFRINIC existantes en la matière.
Cette proposition n'impose aucun calendrier de mise en œuvre, qui est laissé aux pratiques opérationnelles, aux priorités et aux besoins en personnel d'AFRINIC.
4. Références
Une proposition équivalente a été acceptée dans APNIC (déjà mis en œuvre) et LACNIC (en cours de mise en œuvre). Une nouvelle version est en cours d'élaboration pour RIPE et ARIN.
Historique des révisions
Historique des révisions
|
Date |
Détails |
|
12 Août 2018 |
Version 1 : AFPUB-2018-GEN-001-DRAFT01
|
|
20 Novembre 2018 |
Version 2 : AFPUB-2018-GEN-001-DRAFT02
|
|
5 Juin 2019 |
|
|
2nd Novembre 2019 |
Version 4 : AFPUB-2018-GEN-001-DRAFT04
|
|
21 Novembre 2019 |
Version 5 : AFPUB-2018-GEN-001-DRAFT05
|
| 5 Août 2020 |
Version 6 : AFPUB-2018-GEN-001-DRAFT06
|
| 17 mai 2021 |
Version 7 : AFPUB-2018-GEN-001-DRAFT07
|
| 15 mai 2022 |
Version 8 : AFPUB-2018-GEN-001-DRAFT08
|
