Plus de détails
|
Mise à jour de la politique Abuse Contact Policy Update |
|||
|
ID: |
AFPUB-2018-GEN-001-DRAFT05 |
Date de soumission: |
22nd Novembre 2019 |
|
Auteur : |
Jordi Palet Martínez jordi.palet sur theipv6company.com The IPv6 Company |
Version: |
5.0 |
|
Obsolètes: |
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 des abus et entraîne généralement des problèmes de sécurité et des coûts pour les victimes. Cela 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 existe une activité AFRINIC (https://afrinic.net/stats/contact-update) qui vise à vérifier les contacts, mais elle n'a fait rapport 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 d'abus AFRINIC sera en ligne avec d'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, ce qui devrait être confirmé par AfriNIC, un délai raisonnable pour permettre au personnel de développer l'outil et aux membres de mettre à jour leurs contacts 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'objet 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 'child' 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"
|
|
|
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). |
3.2 Informations supplémentaires:
Si cette proposition parvient à un consensus, pour s'y conformer, AFRINIC doit renommer mnt-IRT en abus-c. Il s'agit d'une décision opérationnelle d'AFRINIC 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 en whois des mêmes informations, indépendamment si vous cherchez abus-c ou mnt-IRT. C'est une décision opérationnelle d'AFRINIC de conserver et pendant combien de temps l'IRT ou de le supprimer, ainsi que le reste des informations réelles dans l'IRT. AFRINIC décidera également de la manière de mieux mettre à jour les lignes directrices réelles (https://www.afrinic.net/library/membership765-abuse-policy-bcp) ou s'ils ne sont plus nécessaires. Ceci est fait afin d'assimiler l'IRT à la majorité des RIRs où il est abusif-c.
A titre de clarification, les périodes de validation «initiale» et «escalade» peuvent être modifiées par AFRINIC, si cela est jugé opportun, à condition qu'il informe la communauté de sa motivation pour le faire. Par exemple, dans la phase de mise en œuvre, les périodes peuvent être prolongées et ajustées à mesure qu'un pourcentage plus élevé de contacts devient précis.
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.
4. Références
Une proposition équivalente a été acceptée dans l'APNIC (déjà mise en œuvre) et est en cours de discussion dans les régions ARIN, LACNIC et RIPE.
Historique des révisions
Historique des révisions
|
Date |
Plus de détails |
|
12 Août 2018 |
Version 1 : AFPUB-2018-GEN-001-DRAFT01 Initiales Draft Publié sur rpd |
|
20 Novembre 2018 |
Version 2 : AFPUB-2018-GEN-001-DRAFT02 Initiales Draft Publié sur rpd |
|
5 Juin 2019 |
|
|
2nd Novembre 2019 |
Version 4 : AFPUB-2018-GEN-001-DRAFT04 Simplification globale du texte |
|
22nd Novembre 2019 |
Version 5 : AFPUB-2018-GEN-001-DRAFT05 Précisions supplémentaires sur le texte |
