Search RPD Archives
Limit search to: Subject & Body Subject Author
Sort by:

[rpd] Conflit entre le RSA et la politique existante

Owen DeLong owen at delong.com
Mon Jun 10 15:36:53 UTC 2019


Fatma,

If I understand your issue correctly (and admittedly, reading the Google
Translate from your French is not so clear), you are concerned about
the following:

1.	RSA can be read to require immediate return rather than transfer of
	resources no longer needed.

2.	RSA and CPM do not clearly provide a mechanism for legitimately
	repurposing addresses as technology changes.

I think 1 could benefit from some language cleanup in the CPM and the RSA,
but I don’t see it as a real problem. Let us consider the purpose of  the transfer
policy…

	The policy goal here, IMHO, is to maximize the utilization of addresses and
	facilitate the movement of addresses from those who are not using
	them to those who are.

If we take that as the policy goal, then it stands to reason that we want to
use policy to encourage entities who are not utilizing their addresses to
transfer them relatively quickly. To that end, there is actually quite some
delay built into the reclamation process. More than enough time to allow
a legitimate transfer to take place.

So the existing policy and process does actually facilitate the policy goal
rather nicely, as far as I am concerned. Cleaning up the language to state
this more directly would be fine with me, but I think the existing effect is
roughly correct.

As to item 2, I agree that there is work to be done here. It would be nice
to see a policy proposal that amends the RSA to add a provision which
allows an entity to simply file with AfriNIC a statement which describes
their new purpose for a defined portion (or all) of their existing space.
Said new purpose must be in line with current CPM policies. Absent a
conflict with existing policy, AfriNIC should be required to accept that
statement and thence that stated purpose should be binding as if it were
the original requested purpose.

I think a small number of well thought out edits to the CPM could easily
accomplish this and would greatly improve the situation. I would like to
hear feedback from other members of the community on this matter.

Owen

> On Jun 9, 2019, at 11:14 , Fatma ELKORY OUMRANE <felkory2 at gmail.com> wrote:
> 
> Selon RSA, si le demandeur n'a plus besoin d'espace, il doit le
> retourner à AFRINIC sans condition.
> 
>       (iv)  s’astreint par les présentes à :
> 
> (1) informer AFRINIC chaque fois que des changements interviennent au
> point où il n’est plus dans le besoin des ressources de numéros qui
> lui sont fournies ou en cours de fourniture dans le cadre d’une
> Convention de prestation de services ;
> 
> (2) remettre à AFRINIC, dans un délai de 15 jours suivant la
> signification de l’avis évoqué au (iv) (1) ci-dessus, les ressources
> de numéros Internet fournis ou en cours de fourniture dans le cadre
> d’une Convention de prestation de services;
> 
> (3) mettre à jour toute donnée soumise à AFRINIC dans le cadre :
> 
> 
> Toutefois, si vous n'avez plus besoin de l'espace dont vous disposez,
> par stratégie, vous pouvez le transférer à une  autre organisation qui
> en a besoin. Cela créé un paradoxe. Comme le contrat d'enregistrement
> de service ou Registration Service Agreement (RSA) le stipule, vous
> devez redonner l'espace. Mais si vous le reprenez, comment allez-vous
> le transférer ? En ce sens, il est bien évident que le RSA actuel
> interdit le fonctionnement de la politique de transfert existante. Les
> RSA sont créés par des avocats – mais dans toute affaire liée à la
> gestion des ressources, les stratégies viennent en premier. C'est
> pourquoi nous venons de mettre à jour le RSA.
> 
> 
> RSA demande également :
> 
> 
> 1.    (i)  s’engage à utiliser les services qui lui sont fournis
> uniquement pour le but pour lequel ces services ont été demandés ;
> 
> Certains membres de la communauté ont souligné qu'AFRINIC ne détenait
> pas de données auparavant. Par conséquent, l'AFRINIC n'a aucun moyen
> de faire en sort que ses membres utilisent l'espace à un seul fin –
> leur politique n'exige pas que les membres utilisent l'espace aux fins
> demandées.
> 
> 
> Dans la pratique, cet espace était réservé aux réseaux d'accès à
> distance qui étaient depuis longtemps invalides et aux développements
> de la technologie. C'est particulièrement vrai avec la vitesse
> d'internet d'aujourd'hui – il est donc illusoire de demander que tout
> l'espace soit utilisé au fin initial sans permettre à un membre de le
> mettre à jour.
> 
> 
> Comme pour le dernier problème, cela rentre en conflit avec la
> politique de transfert existante – encore une fois, l'espace demandé
> pour le transfert  n'est pas un besoin valable ; si une organisation
> n'a plus besoin de l'espace et le transfère, elle valide l'obligation
> contractuelle en s'engageant à utiliser uniquement le service au but
> demandé.
> 
> 
> 
> Il s'agit essentiellement d'une clause imposée par un avocat sur la
> façon de gérer la ressource. Les ressources appartiennent à la
> communauté, pas aux avocats. Il est évident et clair que le RSA rentre
> en conflit avec la politique existante, il doit donc être mise à jour.
> 
> 
> Donc pour conclure:
> 
> 1. RSA devrait supprimer toute clause relative à la gestion des
> ressources plutôt que de simplement la diriger vers la politique
> actuelle, l'avocat ne devant avoir aucun droit dans la gestion des
> ressources, ces droits n'appartenant qu'à la communauté.
> 
> 2. Le changement de l’objet de la ressource numérotée, ou n’a plus
> besoin de cette ressource numérotée, ne devrait en aucun cas permettre
> à AFRINIC de récupérer l’espace; le membre devrait être autorisé à
> modifier l’objet de l’espace demandé ou peut même le laisser inutilisé
> pour y être transféré c’est le seul moyen logique pour AFRINIC de se
> conformer à la politique de transfert en vigueur.
> 
> 
> 
> RSA - 4
> 
> 
> 
> (c) Utilisation du service par le Demandeur
> 
> Le Demandeur, par les présentes, et ce de manière irrévocable :
> 
> (i) s’engage à utiliser les services qui lui sont fournis uniquement
> pour le but pour lequel ces services ont été demandés ;
> 
> (ii) s’engage à utiliser les services dans le respect total et
> inconditionnel des stratégies et du mandat d’AFRINIC :
> 
> 
> 
> (1) sans sciemment porter atteinte aux droits et / ou aux intérêts des
> autres usagers de tels services,
> 
> 
> 
> (2) dans les strictes limites des lois et / ou règlements applicables
> de la juridiction dans laquelle il mène ses activités.
> 
> 
> 
> (iii) reconnaît en outre qu’AFRINIC peut, à sa seule discrétion, pour
> la bonne cause et l’intérêt commun de la stabilité de l’Internet,
> enquêter ou requérir auprès de l’autorité compétente ou des autorités
> compétentes une enquête sur l’utilisation des services par le
> Demandeur ;
> 
> (iv) s’astreint par les présentes à :
> 
> (1) informer AFRINIC chaque fois que des changements interviennent au
> point où il n’est plus dans le besoin des ressources de numéros qui
> lui sont fournies ou en cours de fourniture dans le cadre d’une
> Convention de prestation de services ;
> 
> (2) remettre à AFRINIC, dans un délai de 15 jours suivant la
> signification de l’avis évoqué au (iv) (1) ci-dessus, les ressources
> de numéros Internet fournis ou en cours de fourniture dans le cadre
> d’une Convention de prestation de services;
> 
> (3) mettre à jour toute donnée soumise à AFRINIC dans le cadre :
> 
> a. d’une demande de Convention de prestation de services ou
> 
> b. du renouvellement de toute Convention de prestation de services.
> 
> Au cas où ces données font l’objet de modification, de changement, ou
> sont dépassées,
> 
> 
> 
> CPM - 5.7
> 
> 5.7 Transfert de ressources IPv4 dans la région AfriNIC
> 
> Comme les autres registres Internet régionaux, AfriNIC épuisera
> bientôt son pool d’adresses IPv4. Afin de répondre aux besoins des
> demandeurs tardifs de ressources, il est nécessaire d’élaborer une
> politique de transfert des ressources IPv4 dans la région. Cette
> politique aura pour but de définir les conditions dans lesquelles les
> transferts doivent avoir lieu. Lorsqu’une organisation africaine aura
> besoin de ressources de numérotations IPv4 après l'épuisement du pool
> d’adresses IPv4 d'AfriNIC, ou lorsqu’AfriNIC ne pourra plus répondre
> aux besoins d'une telle organisation, cette politique permettra de
> traiter ces enjeux.
> 
> 5.7.1 Résumé de la politique
> 
> Cette politique s'applique à une organisation dont les besoins
> justifiés en ressources IPv4 ne peuvent être satisfaits par AfriNIC.
> 
> 5.7.2 Les ressources IPv4 à transférer doivent provenir d'un compte
> existant des membres d'AfriNIC ou d'un détenteur de ressources
> héritées dans la région desservie par AfriNIC.
> 
> 5.7.3. Conditions relatives à la provenance du transfert
> 
> 5.7.3.1 La source doit être le détenteur légitime actuel des
> ressources d'adresses IPv4 reconnues par AfriNIC, et ne doit être
> impliquée dans aucun différend quant à l'état de ces ressources.
> 
> 5.7.3.2 Après approbation d’un transfert, les entités sources ne
> pourront recevoir aucunes autres assignations ou attributions
> d'adresses IPv4 d'AfriNIC pour un délai de 12 mois.
> 
> 5.7.3.3 Les entités sources ne doivent avoir reçu aucun transfert,
> assignation ou attribution de ressources de numéros IPv4 d'AfriNIC au
> cours des 12 mois précédant l'approbation de la demande de transfert.
> Cette restriction exclut les transferts de fusions et d’acquisitions.
> 
> 5.7.4. Conditions relatives au destinataire du transfert
> 
> 5.7.4.1 AfriNIC doit approuver les besoins du destinataire pour des
> ressources de numérotation IPv4. Pour qu'une organisation soit
> admissible à un transfert, elle doit d'abord justifier ses besoins en
> ressources IPv4
> 
> 
> 
> Fatma Elkory OUMRANE
> Mauritanie-ALS
> NTIC ET CITOYENNETE/MAURIFEMME (résea
> Isoc-Mauritanie (membre fondateur et présidente sortante)
> felkory2 at gmail.com/ felkory at yahoo.fr
> NOUAKCHOTT -MAURITANIE
> 
> _______________________________________________
> RPD mailing list
> RPD at afrinic.net
> https://lists.afrinic.net/mailman/listinfo/rpd




More information about the RPD mailing list