Info! Please note that this translation has been provided at best effort, for your convenience. The English page remains the official version.

IPv4 Transfert de ressources au sein de la Région AFRINIC v3

Print Friendly, PDF & Email
Informations
  • Réf. Prénom:
    AFPUB-2016-V4-003-DRAFT03
  • Soumis:
    23 Décembre 2016
  • versions: 3
  • Statut:
    Dernier appel
  • Author:
    - Ali HADJI, Comores Télécoms
    -Komi ELITCHA 
    - Damnam Kanlanfei BAGOLIBE
    - Serge Patrick GHANSAH-GNONKOTO, NIC CIS 
    - Nicolas Mbonimpa, RENU
    - Alain P. AINA, WACREN

1.0 Résumé du problème traité par cette proposition de politique

Comme les autres Registres Internet Régionaux, AFRINIC va bientôt épuiser ses IPv4 bassin. Afin de répondre aux besoins des demandeurs de ressources tardifs, une politique de transfert IPv4 des ressources dans la région sont nécessaires. Le but de cette politique est de définir les conditions dans lesquelles les transferts doivent avoir lieu.

 

2.0 Résumé de la façon dont cette proposition résout le problème

La politique résout le problème d'une organisation africaine ayant besoin IPv4 nombre de ressources après l'épuisement de l'AFRINIC IPv4 ou quand AFRINIC ne peut plus répondre aux besoins d'une telle organisation.

 

Proposition 3.0

Cette proposition modifie le CPM en introduisant un article 5.7 comme suit:

 

5.7 IPv4 Transfert de ressources au sein de la région AFRINIC

Comme les autres Registres Internet Régionaux, AFRINIC va bientôt épuiser ses IPv4 bassin. Afin de répondre aux besoins des demandeurs de ressources tardifs, une politique de transfert IPv4 des ressources dans la région sont nécessaires. Le but de cette politique est de définir les conditions dans lesquelles les transferts doivent avoir lieu.

La politique résout le problème d'une organisation africaine ayant besoin IPv4 nombre de ressources après l'épuisement de l'AFRINIC IPv4 ou quand AFRINIC ne peut plus répondre aux besoins d'une telle organisation.

 

5.7.1 Résumé de la politique

Cette politique s'applique à une organisation ayant un besoin justifié de IPv4 ressources qui ne peuvent être satisfaites par AFRINIC.

 

5.7.2 IPv4 les ressources à transférer doivent provenir d'un compte de membre AFRINIC existant ou d'un détenteur de ressources hérité dans la région de service AFRINIC.

 

5.7.3. Conditions relatives à la provenance du transfert

 

5.7.3.1 La source doit être le titulaire légitime actuel des adresses IPv4 reconnues par AFRINIC, et ne pas être impliqué dans un différend quant au statut de ces ressources.

 

5.7.3.2 Les entités sources ne seront pas éligibles pour recevoir d'autres allocations ou assignation d'IPv4 d'AFRINIC pour une période de 12 mois après l'approbation du transfert.

 

5.7.3.3 Les entités sources ne doivent pas avoir reçus de transfert, d'allocation ou d'assignation de ressources IPv4 d'AFRINIC pour les 12 mois précédant l'approbation de la demande de transfert. Cette restriction exclut les transferts de fusions et acquisitions.

 

5.7.4. Conditions relatives au destinataire du transfert

 

5.7.4.1 AFRINIC doit approuver la nécessité pour le bénéficiaire de IPv4 nombre de ressources. Pour qu’une organisation puisse prétendre à recevoir un transfert, elle doit d’abord passer par le processus de justification de IPv4 besoins en ressources avant AFRINIC. C'est-à-dire que l'organisation doit justifier auprès d'AFRINIC de son utilisation d'allocation / affectation initiale / supplémentaire, le cas échéant, selon les politiques en vigueur.

 

5.7.4.2 Le destinataire doit être un membre d'AFRINIC, se soumettre aux politiques AFRINIC actuelles et doit signer le contrat de services d'enregistrement pour les ressources reçues.

 

5.7.4.3 Les ressources IPv4 legacy transférées ne seront plus considérées comme des ressources legacy.

  

4.0 Historique des révisions

 

24 mai 2016 Prénom Version 1.0 affiché sur la liste pour discussion.
22 Jul 2016

Version 2.0

  • Ajout d'une section d'accusé de réception (5.0)
  • Modification de la numérotation de la police
  • Modification de la section 3.2.2 qui devient 3.4.2 
23 Dec 2016

Version 3.0 

  • Reformulation de 3.1 [actuellement 5.7.1]: la proposition de politique n'est plus soumise à la phase 2 du IPv4 Politique d'atterrissage en douceur
  • Reformulation de 3.2 [actuellement 5.7.2]: la proposition de politique tient compte IPv4 Ressources héritées
  • Suppression de l'ancien 3.4.2: la déclaration est déjà couverte par 3.4.1 [actuellement 5.7.4.1]
  • Reformulation de l'ancien 3.4.3 devenu 3.4.2 [actuellement 5.7.4.2]: Correction de la condition d'appartenance du destinataire après reformulation de 3.2 [actuellement 5.7.2] Ajout du nouveau 3.4.3 [actuellement 5.7.4.3]: À propos du changement de le statut de transféré IPv4 espace hérité
  • Suppression de l'ancien 3.4.4; Il n'est pas nécessaire d'exiger des destinataires du transfert qu'ils démontrent un besoin jusqu'à 12 mois IPv4 espace d'adressage. Justification fondée sur les politiques en vigueur.
  • Suppression de 6.0 (Références)

 

5.0 Remerciements

Les auteurs tiennent à remercier Owen Delong et Mark Elkins pour leurs réflexions. Ils remercient également tous ceux qui ont contribué activement aux discussions autour de cette proposition.

 

 

Dernière modification le -
Date et heure à Maurice -