AFRINIC-29 | Réunion de politique publique

Réunion de politique publique AFRINIC-29

Procès-verbal de la réunion du PDWG du 29 novembre 2018

Hammamet, Tunisie

 

Version PDF 

 

Coprésidents de la session: Sami Salih, Dewole Ajao

 

Agenda:

1. introduction et aperçu de l'agenda
2. Le PDR AFRINIC
3. Rapport d'expérience sur l'impleméntation des politiques
4. Mise à jour sur l'élaboration des politiques à partir d'autres RIRs
5. Proposition: Processus d'élaboration des politiques AFRINIC Bis v4
6. Proposition: mise à jour simple du PDP
7. Proposition: mise à jour de la politique sur les contacts abusifs
8. Proposition: Examen des ressources des numéros Internet par AFRINIC
9. Proposition: clarification sur IPv6 Sous-affectations
10. Proposition: Inter-RIR Transfert de ressources
11. Proposition: IPv4 Atterrissage en douceur BIS
12. Proposition: SL-Update
13. Microphone de politique ouverte

 

1. Bienvenue, introduction et aperçu de l'ordre du jour

La session a été introduite par Ernest Byaruhanga qui a souhaité la bienvenue aux délégués à la réunion, a présenté les coprésidents (Dewole et Sami), les a remerciés pour leurs efforts et a exhorté les délégués à leur accorder leur entière coopération. 

Sami a présenté le draft ordre du jour qui a été adopté sans modifications.

Il a également déclaré que le Code de conduite d'AFRINIC guidera les discussions de la journée, et qu'il met l'accent sur la politesse, le respect mutuel, aucune discrimination, aucune attaque personnelle, le respect de l'ordre du jour et du temps, la tolérance des différences linguistiques et la nécessité de toujours agir en l'intérêt supérieur de la communauté AFRINIC.

 

2. Le PDR AFRINIC

Sami a présenté le processus d'élaboration des politiques d'AFRINIC et a déclaré qu'il était basé sur les principes d'une approche ascendante et d'ouverture. Une proposition peut être publiée par n'importe qui sur la liste des politiques de rpd qui est ouverte, discutée pendant au moins 4 semaines, puis présentée lors d'une réunion de politique publique. Une proposition est ensuite envoyée au dernier appel si elle parvient à un consensus lors de la réunion de politique publique (sinon elle revient à la liste pour une autre discussion de 4 semaines). S'il n'y a eu aucun problème lors du dernier appel, les coprésidents envoient un rapport au conseil recommandant la ratification, et le conseil ratifie et demande au personnel de le mettre en œuvre, à condition que le processus soit correctement suivi.

 

Réactions et questions reçues:

• Comment les coprésidents appliquent-ils le Code de conduite? Les coprésidents ont précisé qu'il s'agit d'une question interne à la discrétion des coprésidents pour le moment. 

• Le conseil d'administration ratifie-t-il toujours une proposition lorsqu'il est conseillé par les coprésidents? Quand le conseil d'administration peut-il s'opposer / rejeter une politique ou demander à la communauté d'apporter des contributions supplémentaires? Les coprésidents ont déclaré que le Conseil ne ratifie que si la proposition suit ou non le processus. Ils ont ajouté que la proposition revient à la liste si le Conseil ne la ratifie pas.

• Certaines propositions à l'ordre du jour semblent enfreindre le PDP, en raison du délai de soumission d'une semaine avant le PDP. Les coprésidents ont précisé que la proposition en question avait été soumise à temps, mais n'avait pas été publiée (ni publiée sur la liste) à temps. Ils ont proposé qu'à l'avenir, les coprésidents n'attendent pas la publication sur le site Web d'une proposition reçue et l'afficheront sur la liste juste après sa réception.

 

3. Rapport d'expérience sur la mise en œuvre des politiques

Ceci a été présenté par James Chirwa, AFRINIC Senior IP Analyst. Le rapport met en évidence les principaux aspects politiques (et lacunes) dont la mise en œuvre (se traduisant par une distribution réelle des ressources numériques aux membres lors du traitement des demandes) pourrait être mieux clarifiée afin que le personnel puisse mieux comprendre et interpréter ces aspects et combler ces lacunes.

 

Points saillants du rapport:

• Les politiques récemment ratifiées sont les suivantes:
  • IPv6 Mise à jour de la politique et des références - qui a été mise en œuvre le 23 novembre 2018 et est active.
  • IPv6 Mise à jour de l'allocation initiale - également mise en œuvre le 23 novembre 2018 et est active.
  • IPv6 PI Update - en cours de mise en œuvre, en attente d'automatisation de certaines exigences de stratégie (outils pour vérifier que IPv6 L'espace PI attribué aux membres est acheminé et non désagrégé).
  • Les délégations Lame dans le DNS inversé AFRINIC - ont été mises en œuvre (partiellement) le 28 septembre 2018. Les enregistrements Lame pour les domaines et les serveurs de noms ne sont pas encore supprimés et la page de statistiques est en cours d'élaboration. AFRINIC soutient les membres concernés pour corriger ces délégations boiteuses.
• Conflits et ambiguïtés dans le manuel des politiques:
  • Le CPM 5.4.6.1 stipule une utilisation de 90% de tout l'espace émis avant qu'un membre puisse recevoir l'espace suivant, ce qui est en conflit avec 5.5.1.4.1 (80% d'utilisation) et 5.6.3 (Taux d'utilisation de 50% en 1 an)
  • CPM 5.7.1 permet des inter-RIR transferts de IPv4 l'espace, mais il y a certains membres qui souhaitent transférer ASN et IPv6 ressources dues, par exemple, à des fusions.
  • CPM 7.4.2 sur l'exigence de multi-hébergement pour un ASN à émettre - pourtant certains membres ont besoin d'un ASN et exécutent BGP - mais avec un seul fournisseur de connectivité.
  • CPM 5.2.1.2 - l'exigence qu'un LIR enregistre les attributions d'adresses IP pour ses clients. Certaines de ces missions affichent des noms d'entreprises qui ne sont pas exacts ou corrects, parfois créés intentionnellement par le LIR pour falsifier des informations.

Dans le cas des ambiguïtés ci-dessus, la communauté est invitée à examiner le CPM et à proposer des changements de politique pour corriger ces problèmes.

Réactions:

• Un membre a indiqué qu'il était heureux d'écrire des propositions de politique pour chacun des éléments énumérés ci-dessus, mais a encouragé les personnes qui n'avaient pas encore rédigé de politique à venir et à rédiger des politiques pour résoudre ces problèmes.
• Il a été suggéré que certains membres d'AFRINIC qui ont déclenché les problèmes ci-dessus (et qui ont été directement touchés) pourraient être encouragés à proposer des politiques pour répondre à ces ambiguïtés.
• Il a été suggéré que le personnel rédige un plan de mise en œuvre de la politique publique contenant les différentes façons dont la politique aura un impact sur les membres. Ce document devrait être annoncé aux membres lorsqu'il sera utilisé. Un participant a suggéré que cette section fasse partie du rapport d'évaluation du personnel en tant que draft.
• Sur la question des différents conflits dans le CPM, la méthode ARIN pour indiquer ce qui a été supprimé pourrait être utilisée, de sorte que les suppressions peuvent facilement être connues ou vues publiquement.

 

4. Mise à jour sur l'élaboration des politiques à partir d'autres RIRs

Des mises à jour ont été reçues et partagées par les RIR représentants comme suit:

APNIC :

• La validation de la proposition de politique sur les boîtes aux lettres contre les abus (similaire à celle qui sera discutée ici) a été approuvée lors de l'apnic-46 et attend l'examen du Conseil exécutif.
• Politique «sans besoin» visant à abolir le contrôle de l'évaluation des besoins sur toutes les demandes de transfert à l'APNIC non passée à l'APNIC46
• Clarification sur IPv6 les sous-affectations (également similaires à celle à l'ordre du jour de cette réunion) introduisent un processus qui interdit le provisionnement de l'espace v6 à des appareils tiers en dehors de l'infrastructure réseau du détenteur de l'espace PI. Cela n'a pas abouti à un consensus à APNIC46.
• PDP Update - une proposition qui met à jour le PDP APNIC pour inclure la participation à distance aux décisions de consensus, ajuster le temps requis pour soumettre une proposition avant une réunion de politique publique et mettre en place un mécanisme d'appel plus simple. Il n'est pas parvenu à un consensus à l'APNIC46

 

ARIN :

• Clarification de l'allocation initiale du FAI: ajuste le IPv4 politique d'allocation initiale pour permettre aux entreprises IPv4 espace pour se qualifier pour un / 24 automatiquement, et plus grand si besoin est démontré.
• Interdire la création d'enregistrements d'organisations tierces: nécessite que les enregistrements d'organisations soient créés par l'entité représentée par l'enregistrement d'organisation, et uniquement via une demande explicite à ARIN.
• Clarifier les exigences de réaffectation au 4.2.3.7.1: simplifie les exigences de réaffectation de sorte que seul le nom d'un client est requis et pas d'autres informations.

  

LACNIC :

• Inter Milan RIR politique de transfert. Cela établit un mécanisme permettant le transfert de ressources (IPv4, IPv6, ASNs) entre différentes régions et d'aligner le LACNIC sur un marché existant auquel la région ne participe pas actuellement. La proposition est similaire à celle à l'ordre du jour pour AFRINIC29, et ne permet que l'héritage IPv4 espace à transférer hors LACNIC
• Politique d'utilisation acceptable pour la liste de diffusion des politiques: propose une politique d'utilisation acceptable (AUP) pour la liste des politiques, car aucun document de ce type n'existe actuellement au LACNIC. Il est proposé à la suite de plusieurs incidents d'activités ennuyeuses qui sont contraires à l'objectif et à l'esprit de la liste des politiques du LACNIC, y compris des cas d'abus, de diverses attaques personnelles et de propagande électorale que l'on a vu à plusieurs reprises sur la liste des politiques du LACNIC.
• Révision mineure du PDP: Corriger une faille dans le PDP LACNIC selon laquelle si une proposition de politique n'atteint pas le consensus et les commentaires qu'elle reçoit ne suffisent pas à montrer à l'auteur «une voie à suivre», comme écrit, le texte actuel forcerait les auteurs de soumettre «artificiellement» une nouvelle version afin de maintenir la proposition originale en discussion.
• Clarification sur IPv6 sous-affectations - également similaire à celle à l'ordre du jour de cette réunion) introduit un processus qui interdit l'approvisionnement IPv6 Espace PI vers des appareils tiers en dehors de l'infrastructure réseau du détenteur de l'espace PI.
• Enregistrement et validation de la boîte aux lettres abuse-c et abuse: Parce qu'il n'est pas clair si les coordonnées d'abus peuvent être jointes à certaines données de ressources dans le LACNIC whois db. Il n'est pas clair si les informations de contact en cas d'abus peuvent être jointes à certaines données de ressources dans le LACNIC whois db.
• Cette proposition vise à résoudre le problème en garantissant l'existence d'un bon contact-c d'abus et un processus pour son utilisation, cette proposition vise à résoudre le problème en assurant l'existence d'un bon contact-c d'abus et met en place un processus pour son utilisation.

  

MÛR: 

• Validation régulière d'abus-c: donne à RIPE NCC le mandat de valider annuellement les adresses électroniques d'abus et de faire un suivi lorsqu'elles ne sont pas valides. La proposition a été approuvée lors de la dernière réunion du RIPE.
• Clarification de la LIR de l'organisation IPv6 politique: clarifie les allocations LIR par compte LIR - l'ancienne politique utilisée pour déclarer qu'un IPv6 l'allocation est donnée à une organisation et n'a pas précisé le type d'organisation. Ceci est également déjà implémenté.
• Correction des informations obsolètes dans le IPv4 politique: cette proposition supprime certaines références obsolètes dans les IPv4 Stratégies./
• Clarification du PDP: indique clairement quelles actions peuvent se produire dans la «phase d'examen», ce qui n'était pas très clair.
• Clarification des affectations dans IPv6 missions - vise à clarifier la définition de «assigner» dans IPv6 .
• Publication de l'adresse légale des détenteurs de ressources dans la base de données RIPE: L'objectif est de publier les informations d'adresse légale et validée des détenteurs de ressources dans la région RIPE. L'auteur a été invité à apporter quelques éclaircissements.
• RIPE NCC IRR, nettoyage des objets de route sans autorité: l'objectif est de supprimer les objets de route sans autorité stockés dans le registre de routage RIPE en cas de conflit avec un ROA RPKI. 

 

5. Proposition: processus d'élaboration des politiques AFRINIC Bis v4

La proposition a été présentée par les auteurs, qui ont partagé les points saillants suivants:

• Le PDP actuel a 10 ans et les auteurs ont entamé le processus de modification en avril 2017, maintenant à la version 4.
• La rétroaction reçue de la dernière réunion a été de supprimer l'anonymat des auteurs de la proposition, de supprimer la possibilité que les coprésidents des politiques soient les éditeurs de documents, de supprimer l'inclusion du Conseil des anciens et de prévoir environ 2 semaines pour que les coprésidents déclarent le consensus (après adoption) et après la réunion de politique publique.
• La proposition a été mise à jour pour inclure tous les commentaires de la communauté ci-dessus.
• Il n'y a eu aucune discussion substantielle sur la proposition mise à jour, ni aucune suggestion ou contribution de la communauté (y compris le texte promis par certains membres).
• Cependant, une nouvelle proposition concurrente a été reçue à la place (Simple PDP Update).
• Les auteurs ont demandé aux coprésidents d'aller de l'avant.

Les réactions ont été reçues comme suit:

• Les coprésidents ont indiqué que les propositions devraient être examinées dans le meilleur intérêt de la communauté, et non des personnes qui ont rédigé ces propositions.
• Les coprésidents ont appelé l'auteur de la proposition «Mise à jour simple du PDP» à la présenter également, de sorte que des discussions sur les mérites des deux puissent avoir lieu après la présentation des deux, permettant à la communauté de discuter objectivement et aux coprésidents de mieux prendre décision par la suite.

 

6. Proposition: mise à jour simple du PDP

L'auteur a partagé les points saillants suivants de cette proposition:

• Bien que tout le monde puisse participer aux discussions sur les politiques dans la liste de diffusion (RPD) et / ou aux réunions semestrielles sur les politiques publiques, tous les participants à la SPR ne sont pas en mesure d'assister à toutes les réunions réelles où les présidents déterminent un consensus approximatif sur les propositions - et c'est la plus grande partie de la communauté. Avec cette exigence de prendre des décisions par consensus lors des réunions en face à face, cela pourrait être en partie la cause du faible niveau de participation communautaire au processus politique.
• Cette proposition simplifie le processus en n'exigeant pas la participation en personne aux réunions de politique publique pour qu'une proposition parvienne à un consensus - au lieu de cela, le consensus serait déterminé en équilibrant les contributions de la liste de diffusion et de la réunion - ce qui augmenterait donc la participation de la communauté.
• Les différents délais sont également adaptés à ce changement, avec quelques scénarios comme suit
  • Une proposition (ou une nouvelle version) est soumise 8 semaines (ou une période plus longue) avant le PPM. Le consensus sera déterminé par les présidents dans un délai maximum de deux semaines.
  • Une proposition (ou une nouvelle version) est soumise moins de 8 semaines avant le PPM. Le consensus sera déterminé par les présidents dans un délai maximum de deux semaines, une fois les 8 semaines de discussion sur la liste terminées.
  • Le chronométrage des minutes est également adapté, car il ne semble pas nécessaire d'attendre 3 semaines, si la détermination du consensus se fera dans 2 semaines.
• La proposition élimine donc l'exigence selon laquelle un consensus ne doit être atteint qu'au PPM. Il adapte les délais pertinents et clarifie en même temps la définition de «consensus» et de «dernier appel».
• La définition du consensus est adaptée pour s'aligner sur le concept de consensus approximatif de l'IETF.
• Divers changements aux délais sont proposés, y compris le fait que les coprésidents n'annoncent des changements aux décisions consensuelles antérieures que dans la semaine suivant le dernier appel.
• L'auteur a indiqué qu'une proposition similaire avait atteint un consensus dans la région du LACNIC en mai 2018 et avait déjà été mise en œuvre.

Réactions reçues:

• L'auteur de la proposition «PDP-bis» a indiqué qu'il existe de nombreuses similitudes entre les deux propositions, comme l'évaluation du personnel et le processus de consensus approximatif (car il ne s'agit pas seulement de la définition). L'auteur de «Simple PDP Update» a indiqué que la proposition PDP-bis est complexe, en raison des nombreuses (cinq) phases différentes, et qu'elle doit être simplifiée.
• Il a été noté que les propositions d'AFRINIC ne devraient pas être comparées à celles de la région LACNIC et d'autres régions.
• L'auteur de cette proposition a déclaré avoir lu attentivement la proposition PDP-bis et trouvé 15 points très faibles et de nombreux problèmes manquants qu'il a signalés aux auteurs et est disposé à les signaler si les deux parties peuvent être ouvertes à la discussion.
• Les coprésidents ont indiqué qu'il n'y a pas d'enregistrement officiel des problèmes ci-dessus sur la liste de diffusion.
• Plusieurs personnes ont fait remarquer que les deux propositions de politique sont très constructives et que les auteurs des deux parties devraient donc travailler ensemble pour proposer une version de la proposition qui soit bien améliorée.
• Quelques personnes ont indiqué que le PDP actuel n'a pas de problèmes majeurs à résoudre, mais de nombreuses personnes recherchent des moyens de manipuler le processus pour leurs intérêts personnels - et ce problème peut rester indépendant.
• Certains membres ont exhorté les coprésidents à s'abstenir d'accepter de telles propositions concurrentes, mais les coprésidents ont souligné qu'ils n'avaient pas un tel mandat selon le PDP, mais pouvaient encourager les parties à travailler ensemble.
• Comme mentionné précédemment, bien que le processus permette que plusieurs propositions concurrentes soient sur la table, la bonne volonté doit être utilisée de manière à ne pas se retrouver dans une telle situation. L'auteur de «Simple PDP Update» a indiqué que ce n'est pas nécessairement une mauvaise idée d'avoir des propositions concurrentes car cela permet à la communauté d'étudier différents points de vue.
• L'une des propositions favorise les participants éloignés, ce qui est une bonne chose car de nombreuses personnes ne peuvent pas voyager en raison de contraintes de temps et financières.

Les coprésidents ont indiqué que les auteurs des deux propositions concurrentes envisageaient de travailler ensemble pour arriver à une proposition unifiée qui combine les deux points forts des deux propositions, pour le bénéfice de la communauté ayant un PDP beaucoup plus large et amélioré.

L'auteur de "Simple update of the PDP" a décidé de retirer sa proposition de politique et a indiqué qu'il espérait fortement qu'il travaillerait avec les auteurs de la proposition de politique "AFRINIC PDP-bis"Dans cet effort pour améliorer le PDP.

Les auteurs de «AFRINIC PDP-bis» ont insisté sur le fait que dans l'effort de travailler ensemble, il doit y avoir un respect mutuel, car cela comprendra la fusion d'opinions fortes de deux parties distinctes.

Les coprésidents ont décidé de renvoyer la proposition AFRINIC PDP-bis sur la liste et d'engager un processus visant à engager les deux parties à travailler à une version améliorée prenant en compte les points des deux propositions.

 

7. Proposition: mise à jour de la politique relative aux contacts en cas d'abus

L'auteur a partagé les points saillants suivants de la proposition:

• Le CPM 8.0 actuel (spécification des coordonnées d'abus) ne rend pas obligatoire l'enregistrement d'un contact d'abus. En conséquence, de nombreux membres peuvent ne pas avoir ces informations de contact pour leurs inscrits et à jour pour leurs ressources.
• Il peut y avoir des cas où les membres utilisent une adresse e-mail inexistante ou qui n'est pas surveillée activement, ce qui rend difficile le signalement des abus de ces réseaux et entraîne généralement des problèmes de sécurité et même des coûts pour les victimes.
• Cette proposition vise à résoudre ce problème en garantissant l'existence d'un bon contact d'abus pour chaque ressource émise et également un processus pour garder ces informations exactes. La politique a été proposée à tous RIRs disposer d'une méthode uniforme à l'échelle mondiale pour le signalement des abus entre régions.
• La politique actuelle de CPM 8.0 fait référence à un «document sur les meilleures pratiques», qui n'est pas obligatoire et ne semble pas être utilisé par la communauté.
• Le document sur les meilleures pratiques suggère un objet IRT, et cette proposition recommande que l'abus-c proposé et l'IRT dans le BCP soient automatiquement liés. De cette façon, les processus de contact avec AFRINIC en cas d'abus s'aligneront sur d'autres RIRs. L'APNIC utilise maintenant l'IRT, mais comme une proposition équivalente a été acceptée, un «lien» automatisé avec l'IRT existant sera créé, donc abuse-c et abuse-mailbox continueront de prévaloir.
• Il n'est pas nécessaire de supprimer les autres données facultatives incluses aujourd'hui dans l'IRT. Cette politique garantit simplement que la boîte aux lettres d'abus est disponible et vérifiée périodiquement.
• Bien que la communauté Internet soit basée sur la collaboration, cela n'est pas suffisant dans de nombreux cas et nous devons tous pouvoir contacter les FAI qui peuvent rencontrer des problèmes dans leurs réseaux et ne sont pas au courant 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 LIR 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 devait 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 par AFRINIC dans un délai raisonnable qui permet à la fois au personnel de développer le logiciel nécessaire et aux membres de mettre à jour leurs contacts d'abus-c.
• L'auteur a indiqué que même si AFRINIC avait proposé que les détails opérationnels et les vérifications complexes soient supprimés de la proposition, il est important qu'ils restent, car ils constituent une fonction essentielle dans les vérifications des e-mails abusifs.
• Une proposition similaire a été acceptée par l'APNIC (est en cours de mise en œuvre) et est en cours de discussion dans les régions du LACNIC et du RIPE.

Les réactions de la communauté ont été les suivantes:

• La vérification des coordonnées est importante compte tenu du contexte et du travail des CERT.
• Que se passe-t-il lorsque les membres ne répondent pas aux demandes de vérification d'AFRINIC ? L'auteur a déclaré qu'AFRINIC bloquera l'accès à MyAFRINIC comme indiqué dans le texte de la proposition.
• Il a été précisé par l'auteur que ce qui est bloqué est l'accès à MyAFRINIC, pas l'utilisation des ressources en les révoquant ou en les récupérant. Cependant, la remise en état fait partie de l'accord entre le membre et AFRINIC.
• Le texte de la proposition mentionne « le blocage de l'accès du compte aux ressources » qui peut être interprété à tort comme une révocation des ressources ». L'auteur a précisé à nouveau qu'il s'agit d'un accès à MyAFRINIC.
• L'idée de la vérification des adresses électroniques a été appuyée.
• Il a été noté qu'un seul objet ou attribut de contact d'abus est plus facile à maintenir.
• Il a également été noté que lors de la vérification, AFRINIC ne devrait pas prendre de mesures punitives à l'encontre des membres qui ne répondent pas aux vérifications, car il ne s'agit pas de la police Internet. AFRINIC pourrait simplement étiqueter ceux qui ne répondent pas et rendre la liste publique pour que la communauté des opérateurs décide quoi faire, comme le dé-peering.
• Bloquer l'accès à MyAFRINIC a été pris en charge, mais il y a eu une proposition d'autoriser la connexion, mais d'avoir un message après la connexion pour indiquer que le membre doit d'abord mettre à jour/vérifier ses informations de contact en cas d'abus avant de pouvoir accéder à toute autre fonctionnalité.
• Il y avait une inquiétude au sujet des taux de réponse généraux des membres quand AFRINIC a tenté d'amener les membres à mettre à jour leurs contacts inexacts. Le PDG a déclaré que lors d'efforts similaires antérieurs, il y avait eu un taux de réponse de plus de 90%.
• Il a été suggéré qu'il est préférable de maintenir l'utilisation actuelle de l'objet IRT, car il stocke plus qu'une simple adresse e-mail et est déjà largement utilisé.
• Un membre note qu'AFRINIC doit pouvoir intervenir si les membres utilisent de manière inappropriée les ressources émises.
• Les délais pour un compte à bloquer et un compte bloqué à débloquer ne sont pas indiqués, et cela devrait être clarifié dans le texte de la proposition. L'auteur a précisé que les délais sont clairs dans le texte de la proposition.
• Il a été observé que MyAFRINIC est utilisé pour voter, et que bloquer l'accès à MyAFRINIC en période électorale prive les membres du droit de vote. L'auteur a déclaré que telles sont les questions qui inciteraient les membres à tenir leurs dossiers à jour, mais que la connexion à MyAFRINIC peut être utilisé pour voter, mais pas pour gérer les ressources.
• Le personnel d'AFRINIC a indiqué que la politique doit être explicitement claire sur la manière dont l'IRT existant sera lié à l'abus-c.

 

Décision du coprésident: Pas de consensus - la proposition revient à la liste de diffusion pour plus de contributions et d'affinements de la communauté.

 

8. Proposition: examen des ressources des numéros Internet par AFRINIC

Les auteurs de cette proposition ont procédé comme suit:

• Les auteurs ne s'attarderont pas trop sur le contenu, car la proposition a évolué sur deux ans (à travers six versions différentes) et est considérée comme suffisamment mûre à leur avis.
• Une voie à suivre est donc la meilleure approche pour aller de l'avant.
• Les coprésidents ont conclu de la dernière réunion de Dakar qu'en raison à la fois d'une forte opposition et d'un fort soutien à la proposition de politique pour diverses raisons exprimées en ligne et lors du PPM, la proposition revient à la liste RPD pour discussion et affinement. Les coprésidents ont également suggéré (après Dakar) que la communauté discute plus avant pour voir s'il existe de meilleurs moyens pour AFRINIC de s'attaquer au problème perçu / observé de l'utilisation irresponsable (ou des applications frauduleuses) des ressources de numérotation Internet.
• Les auteurs ont demandé comment les coprésidents peuvent briser le lien entre un soutien solide et une forte opposition, car beaucoup conviennent que l'examen et l'audit des ressources allouées sont nécessaires. Les auteurs ont suggéré une modification possible de 13.4b en n'exigeant pas une révocation de facto des ressources et en mettant en place des dispositions pour que le personnel gère la non-conformité au cas par cas.

 

Réactions de la communauté:

• La politique refuse aux utilisateurs finaux l'accès à Internet, mais ils ne seraient au courant d'aucun audit et déclencheur de ces audits au niveau du FAI.
• Il serait également coûteux et peu pratique, car AFRINIC devrait engager des parties externes pour effectuer des audits / examens. L'auteur a répondu que seules les questions étaient les bienvenues et les déclarations de soutien ou d'absence de soutien.
• Certains membres ont indiqué qu'AFRINIC procède actuellement à des examens ou à des efforts de diligence raisonnable sur l'utilisation des ressources émises, et ce n'est pas nouveau, par conséquent cette proposition n'est peut-être pas nécessaire après tout.
• Un membre a précisé que peu de personnes conviennent que la politique est nécessaire et qu'il n'y a pas non plus de consensus sur le fait que cette proposition est nécessaire. Il a également été noté que la même version et le même texte de proposition n'avaient pas été adoptés à la réunion précédente et qu'ils ne devraient logiquement pas être adoptés lors de cette réunion. À noter également que cette proposition fait d'AFRINIC une sorte de police Internet, ce qui ne fait pas partie de son mandat, et qu'elle devrait se concentrer sur ses fonctions essentielles.
• Le conseiller juridique d'AFRINIC a indiqué qu'il n'y avait pas de problèmes juridiques ou autres avec cette version après avoir travaillé avec les auteurs pour traiter les questions soulevées dans les évaluations du personnel.

 

Décision du coprésident: La proposition est renvoyée au dernier appel, mais d'autres engagements communautaires sont encore ouverts pendant cette période.

(Remarque: sur la base des discussions et engagements sur la liste après la réunion, la proposition a été renvoyée à la liste de diffusion.)

 

9. Proposition: clarification sur IPv6 Sous-affectations

L'auteur a partagé les points saillants de la proposition comme suit:

• La proposition a été soumise aux cinq RIR communautés.
• Lorsque le premier IPv6 la politique était drafted, le concept d'affectations / sous-affectations ne considérait pas une pratique très courante IPv4 qui est reproduit et même amplifié dans IPv6 - l'utilisation d'adresses IP pour les liaisons point à point ou VPN.
• In IPv4, ce n'est généralement pas un problème car l'utilisation de NAT.
• Dans le cas d' IPv6, au lieu d'adresses uniques, l'utilisation de préfixes uniques (/ 64) est de plus en plus courante. De même, la politique n'a pas pris en compte l'utilisation d'adresses IP dans les hotspots, ou l'utilisation d'adresses IP par des invités ou des employés dans Bring Your Own Device (BYOD) et de nombreux autres cas.
• Parfois, un utilisateur final engage un tiers pour effectuer certains services sur son propre réseau et il doit déployer ses propres appareils, même des serveurs, des équipements réseau, etc. Par exemple, les services de surveillance de la sécurité peuvent exiger que l'entrepreneur fournisse leurs propres caméras, système d'enregistrement, même leur propre pare-feu et / ou routeur pour un VPN dédié, etc. Bien sûr, dans de nombreux cas, ce système de surveillance peut avoir besoin d'utiliser l'espace d'adressage de l'utilisateur final.
• L'IETF a récemment approuvé l'utilisation d'un préfixe unique / 64 par interface / hôte (RFC8273) au lieu d'une adresse unique. Cela permet, par exemple, aux utilisateurs de se connecter à un hotspot, de recevoir un / 64 de telle sorte qu'ils sont isolés des autres utilisateurs (pour des raisons de sécurité, d'exigences réglementaires, etc.) et ils peuvent également utiliser plusieurs machines virtuelles sur leurs appareils avec un adresse unique pour chacun (dans le même / 64).
• La section 2.6 (Définitions générales / affectation) interdit explicitement de telles attributions, précisant que les affectations ne doivent pas être sous-affectées à d'autres parties. Il y a deux options, d'une part - demander aux utilisateurs finaux de s'assurer qu'ils utilisent correctement la politique et la faire respecter, et récupérer les ressources en cas d'utilisation abusive et, d'autre part, corriger nos erreurs dans le courant IPv6 politique - cette dernière option étant l'approche adoptée lors de l'introduction de cette proposition.
• Cette proposition clarifie cette situation et définit mieux le concept, compte tenu notamment des nouvelles utilisations IPv6 (RFC 8273), au moyen d'un nouveau texte à la fin de tout texte disponible sur le IPv6 Politique d'attribution des PI. Il précise également que l'utilisation de sous-attributions dans les FAI, les centres de données et les cas similaires n'est pas autorisée.
• En résumé, cette proposition stipule seulement que IPv6 L'espace PI est autorisé à être utilisé dans le réseau du titulaire de l'affectation et seuls les appareils tiers fonctionnant strictement au sein de cette infrastructure, y compris les interconnexions. Il n'est cependant pas autorisé d'utiliser IPv6 Espace PI pour fournir des services aux clients tels qu'un FAI et un centre de données ou des cas similaires. Tels sont les cas considérés ici comme des sous-affectations.
• Une proposition similaire est en cours de discussion au sein des communautés LACNIC, RIPE et APNIC.
• Le personnel a indiqué qu'il n'y avait aucune préoccupation dans son évaluation.

Réactions de la communauté:

• Il y a eu une déclaration de soutien à la proposition et aucune déclaration contre.
• Une préoccupation concernant la numérotation a été soulevée par le personnel - et l'auteur a précisé que le texte de la proposition devrait être inséré juste après le texte existant dans l'article 6.8 de la RPC, car il est plus facile à lire et à interpréter.

Décision du coprésident: La proposition passe au dernier appel - mais d'autres engagements communautaires restent ouverts pendant cette période.

 

10. Proposition: Inter-RIR Transferts de ressources

La proposition a été présentée par son auteur - qui a souligné ce qui suit:

• Permet à AFRINIC de pénétrer un marché existant pour les transferts IPv4, IPv6 et ASN Ressources.
• Il a été noté que IPv6 transfère de l'aide dans le cas où une entreprise déménage dans un autre RIR région et veulent se déplacer avec leurs ressources vers cette nouvelle RIR.
• Ne pas faire partie du marché pendant les phases de IPv4 l'épuisement désavantagera les FAI AFRINIC.
• Pour limiter beaucoup IPv4 l'espace sortant du continent, la proposition ne permet que le transfert sortant de l'héritage IPv4 espace. Ceci est important car l'enregistrement précis de ces ressources est essentiel, mais elles sont probablement utilisées hors de la région.
• Les tailles minimales transférables sont / 24 pour IPv4 et / 48 pour IPv6. Dans les deux cas, le destinataire doit démontrer le besoin de transférer la ressource.
• In IPv6 le bloc ne peut être transféré que 2 ans après l'attribution ou l'affectation initiale.
• En ce qui concerne le transfert d'autres types de ressources, AFRINIC a déjà souligné (dans le rapport de mise en œuvre des politiques) que lesRIR le transfert ne permet IPv4 transferts, et pas d'autres types de ressources.
• Les ressources transférées ne peuvent être retransférées qu'après 1 an du transfert le plus récent.
• Il existe des politiques équivalentes dans d'autres régions et le LACNIC discute d'un texte presque identique. ARIN exporte le plus grand nombre de ressources sur le marché des transferts.

 

Les réactions et commentaires ont été reçus comme suit: 

• Il a été noté qu'un bloc tel que 196 possède à la fois un espace hérité et non hérité qui existe à la fois en AFRINIC et dans d'autres régions.
• La politique ne devrait être faite que pour les transferts entrants, afin que les ressources AFRINIC restent en Afrique. L'auteur a noté que d'autres régions ont besoin de réciprocité, d'où la nécessité de fournir des options sortantes.
• Certains ont noté que, puisque la politique autorise uniquement les IPv4 l'espace hérité seulement, c'est une bonne politique.
• La politique a été appuyée car elle permet à AFRINIC de participer au marché mondial, et la politique telle qu’écrite est acceptable.
• Il a été noté qu'il fallait des transferts bidirectionnels pour que la proposition soit réciproque et compatible avec la politique de transfert ARIN.
• On a demandé à l'auteur pourquoi il n'y avait pas de bloc transférable maximum (alors qu'il y a des tailles minimales). L'auteur a indiqué que personne n'avait encore suggéré cette idée, mais a laissé entendre qu'elle n'était peut-être pas nécessaire - mais qu'elle est ouverte aux suggestions de la communauté.

  

Décision du coprésident: Pas de consensus - la proposition revient à la liste de diffusion pour plus de contributions et d'affinements de la communauté.

 

11. Proposition: IPv4 Atterrissage en douceur BIS

Les remarques des auteurs étaient les suivantes:

• La proposition d'atterrissage en douceur-bis devait mettre à jour la politique actuelle d'atterrissage en douceur adoptée en 2011.
• Il était clair dans le rapport de mise en œuvre de la politique d'AFRINIC que certaines des préoccupations mentionnées sont traitées dans cette proposition.
• L'une des questions à traiter est déjà abordée dans l'autre proposition de politique des auteurs à l'ordre du jour, intitulée «SL Update».
• Les auteurs ont donc décidé d'autoriser la proposition «IPv4 Soft Landing bis ”expire.

[Remarque: la proposition de politique a expiré le 01er décembre 2018 conformément au PDP]

 

12. Proposition: SL-Update 

Les faits saillants ont été partagés par les auteurs comme suit:

• La section 5.4.7.1 du CPM de la politique actuelle d'atterrissage en douceur réserve un / 12 du dernier / 8 pour des utilisations futures imprévues.
• La section 5.4.7.2 du CPM permet au Conseil d'AFRINIC à sa discrétion (compte tenu de la demande et d'autres facteurs) - au moment où AFRINIC ne peut plus répondre aux demandes d'espace d'adressage du dernier / 8 ou de tout autre espace d'adressage disponible, de reconstituer le pool d'épuisement avec n'importe quel espace d'adresse (ou une partie de celui-ci) qui peut être disponible à ce moment-là et le faire d'une manière qui est dans le meilleur intérêt de la communauté.
• La section 5.4.7.2 donne donc au Conseil le pouvoir absolu et unique de décider de la manière d'utiliser le bloc réservé pour éventuellement reconstituer le pool d'épuisement et peut même être de déterminer les règles d'allocation / d'attribution.
• Le problème est que si aucune politique communautaire n'est adoptée pour déterminer comment utiliser l'espace réservé avant l'épuisement de la piscine, le Conseil peut agir à sa discrétion avec ou sans la participation et le consentement de la communauté.
• La communauté est donc mieux placée pour déterminer ce qui est dans son intérêt et cela est mieux discuté par le biais du PDP.
• Cette proposition reformule donc le 5.4.7.2 pour annuler le pouvoir discrétionnaire du Conseil, pour: "Si le / 12 réservé reste inutilisé au moment où l'espace disponible restant a été alloué, le / 12 sera retourné au pool AFRINIC pour distribution dans les conditions de la phase 2 de la politique d'atterrissage en douceur.

 

Les réactions et commentaires de la communauté ont été reçus comme suit:

• AFRINIC a été invité à préciser si les morceaux de petits blocs reçus de l'IANA seront également émis dans le cadre de la politique d'atterrissage en douceur. AFRINIC a précisé que l'atterrissage en douceur a commencé lorsque AFRINIC a commencé à allouer à partir du dernier / 8, et que tout l'espace dans l'inventaire (et pas nécessairement seulement le dernier / 8) serait tous émis dans le cadre du mécanisme d'atterrissage en douceur.
• Rien n'indique que l'Office doit suivre la politique d'atterrissage en douceur lorsqu'il détermine ce qu'il faut faire de la réserve, il est donc bon de corriger ce risque et cette incertitude si l'Office décide de gérer la réserve en dehors des processus d'atterrissage en douceur.
• Les politiques devraient être axées sur l'amélioration et la promotion IPv6, et ne pas ajouter plus de restrictions à la diminution IPv4 bassin. Les auteurs ont déclaré que IPv4 est toujours d'actualité car il y a des discussions actives sur IPv4 les transferts et comment la communauté AFRINIC peut encore bénéficier du marché.
• Il a été noté que la région ARIN IPv4 politique d'atterrissage en douceur et qu'il existe un marché dynamique dans cette région en même temps IPv6 taux d'adoption.

Décision du coprésident: Pas de consensus - la proposition revient à la liste de diffusion pour plus de contributions et d'affinements de la communauté.

 

13. Microphone de politique ouverte

Les points suivants ont été soulevés par la communauté lors de la session Open Microphone: 

• En ce qui concerne la décision d'avancer les propositions jusqu'au dernier appel ou de les renvoyer à la liste de diffusion, il est préférable que les coprésidents indiquent les raisons pour lesquelles la proposition a été renvoyée à la liste, afin que cela soit clair pour tout le monde. Sur la question de la proposition SL-Update, les coprésidents ont précisé que la proposition a besoin de plus de temps pour être discutée, bien que les auteurs aient noté que le temps était suffisant, conformément à ce que prévoit le PDP. Un membre a souligné que le PDP contient des dispositions pour faire appel des décisions des coprésidents en cas de mécontentement.
• Il a été noté que la soumission dans le délai imparti ne se traduit pas par des discussions suffisantes et que la réunion en face à face donne également à la communauté un meilleur aperçu de l'esprit de la proposition, ce qui permet des discussions supplémentaires éclairées et enrichies.
• Jordi a proposé d'aider toute personne qui n'a pas contribué au processus politique à le contacter, afin que les questions soulevées dans le rapport de mise en œuvre de la politique par le personnel d'AFRINIC puissent être traitées par le biais de propositions politiques de ces personnes.
• Un membre applaudit les coprésidents pour leurs efforts dans leur travail, ainsi que divers auteurs de politiques pour leurs efforts.
• Il a été noté que les discussions de cette réunion étaient cordiales et qu'il n'y avait pas eu d'attaques insultantes comme cela aurait pu être le cas auparavant, et que la manière cordiale des discussions devrait être maintenue à la fois sur la liste de diffusion et lors des réunions futures.
• Un boursier a remercié AFRINIC au nom de tous les autres boursiers pour l'opportunité et l'exposition d'AFRINIC aux engagements qui ont eu lieu lors de cette réunion. Un autre boursier a également apprécié l'expérience de ces discussions en face à face par rapport à ce qu'il a vu sur la liste, et a remercié Jordi pour son offre de recruter de nouveaux auteurs de politiques.
• La communauté devrait se concentrer moins sur la politique et davantage sur l'amélioration de meilleures politiques bien qu'elles ne soient pas parfaites à 100%, ainsi que sur d'autres sujets comme RPKI.
• Un participant à distance a exhorté les coprésidents à reconsidérer leur décision de faire avancer la proposition d'examen des ressources de numéros Internet jusqu'au dernier appel, et de la renvoyer à la liste, car des problèmes importants ont été soulevés contre elle, et que certaines personnes vont certainement faire appel - échanges inutiles. Il a également exhorté les auteurs à envisager de le retirer, car il pourrait ne pas y avoir de consensus à l'avenir.
• Il y a eu une enquête sur la possibilité pour AFRINIC de payer les auteurs de politiques pour assister aux réunions de politique publique.
• Il a été noté que, puisque le personnel a souligné dans le rapport de mise en œuvre des politiques différentes incohérences, il est nécessaire de faire preuve de cohérence, et les propositions d'examen définissent la voie de la cohérence dans la bonne direction. 

 

Résumé des décisions du coprésident sur les propositions de politiques 

Proposition	Décision	Commentaires
Processus d'élaboration des politiques AFRINIC Bis v4	Retour à la liste
Mise à jour simple du PDP		Retiré par l'auteur
Mise à jour de la politique Abuse Contact Policy Update	Retour à la liste
Revue des ressources des numéros Internet par AFRINIC	Retour à la liste	La décision initiale a changé après la réunion
Clarification sur IPv6 Sous-affectations	Dernier appel
Inter-RIR Transfert de ressources	Retour à la liste
IPv4 Atterrissage en douceur BIS		Retiré par les auteurs
Mise à jour SL	Retour à la liste