Summary

  • La section 3.7 du manuel en vigueur d’ARIN impose à l’organisation destinataire d’une réattribution détaillée ou d’une réallocation d’exister déjà dans sa base et de disposer d’au moins un Point of Contact validé. Faute de contact validé, la demande est rejetée. La réattribution simple n’établit pas ce lien.
  • Dans son guide de gestion des ressources, ARIN précise que le nom du client sur une fiche simple est saisi librement sans vérification et que le titulaire direct garde la gestion. Les fiches détaillées et les réallocations ouvrent des droits de gestion distincts au client, avec identifiant d’organisation et accord de services.
  • Le modèle de notification d’échec indique au client de valider un contact, puis de demander au fournisseur amont de soumettre de nouveau l’opération. La fiche refusée est une transaction de registre; le modèle ne contient aucune mesure du trafic.

Le détail le plus franc du guide d’ARIN tient à trois mots : « free text ». Dans une réattribution simple, le fournisseur inscrit le nom du client comme un champ libre. ARIN ne vérifie pas ce nom. La fiche peut servir à montrer qui utilise une partie des adresses. Le client ne peut pas administrer le bloc depuis cette fiche. Le titulaire direct peut modifier ou supprimer l’entrée à tout moment. Le registre voit le client; la main qui écrit reste celle du fournisseur.

Une réattribution détaillée change la relation. ARIN demande un Organization Identifier, ou Org ID, et un Registration Services Agreement pour le destinataire. Celui-ci peut alors ajouter ses contacts et gérer les adresses reçues dans ARIN Online. Les deux parties peuvent intervenir sur les objets du registre de routage Internet et le DNS inverse. Le titulaire direct garde la faculté de reprendre la réattribution. La nouvelle autonomie est donc concrète, mais elle s’exerce dans une fiche que l’amont peut reprendre.

La réallocation pousse la délégation plus loin. Elle sert à un organisme, souvent un fournisseur d’accès, qui distribuera ensuite des portions à ses propres clients. Son Org ID et son accord avec ARIN sont également requis. Il peut créer des fiches de réallocation et de réattribution en aval. Là aussi, le titulaire direct conserve une faculté de reprise. Ces trois régimes dessinent une échelle : le client nommé par le fournisseur; le client qui gère sa fiche; le client qui peut inscrire d’autres clients. Chaque marche exige une identité plus ferme.

La section 3.7 du manuel de politique fixe le cran décisif. Pour la réattribution détaillée et la réallocation, l’organisation destinataire doit déjà figurer dans la base ARIN avec au moins un contact validé. S’il n’en existe aucun, ARIN doit rejeter la demande. Le texte ajoute que les réattributions simples se font sans lien avec des objets organisation ou contact de cette base. Le même espace d’adresses peut être utilisé par le même client, mais les pouvoirs inscrits dans le registre diffèrent radicalement.

Pourquoi demander une fiche plus lourde? Le guide d’enregistrement des réattributions fournit des raisons techniques précises. Un client qui veut administrer sa propre délégation DNS inverse ou afficher des contacts distincts a besoin d’une réattribution détaillée. S’il doit sous-déléguer des adresses à ses clients, il lui faut une réallocation. Une fiche simple plus facile à soumettre laisse ces fonctions de l’autre côté du comptoir. Le coût administratif du contact apparaît au moment exact où le client réclame un rôle opérationnel.

ARIN publie même la scène du refus. Ses modèles de messages indiquent qu’une demande n’a pas abouti parce que l’Org ID aval n’a aucun contact validé. Le message adressé au client lui demande de valider un POC dans ARIN Online puis de prévenir son fournisseur. Le message adressé au fournisseur lui demande d’obtenir cette validation et de réessayer. L’amont déclenche, l’aval corrige, l’amont renvoie. Aucun des deux ne termine seul la transaction.

La validation s’inscrit dans un calendrier distinct. Selon la section 3.6, ARIN adresse chaque année une notification aux contacts concernés; ils disposent de soixante jours au plus pour confirmer ou rectifier leurs informations Whois. Après analyse attentive, son personnel peut déclarer invalide une fiche complètement et définitivement abandonnée ou autrement illégitime. L’expiration des soixante jours n’est pas décrite comme une invalidation automatique. Un contact invalide n’a plus accès qu’au paiement et à la mise à jour des coordonnées dans ARIN Online. Une organisation sans contact valide perd les autres fonctions du compte jusqu’à validation ou correction par un contact administratif ou technique.

L’amont ne peut pas fabriquer seul l’identité manquante. La section 3.8 prévoit la création d’une fiche organisation sur demande directe d’un représentant autorisé d’une entité qu’ARIN peut valider, et écarte la demande d’un tiers. La barrière protège contre les destinataires fictifs. Elle oblige aussi le client réel à prendre part au travail de registre avant d’obtenir les commandes qui lui sont promises.

Les sources officielles ne donnent aucun dossier client daté permettant de mesurer le retard provoqué par ce contrôle. Une notification de refus suivie de sa nouvelle soumission établirait le délai d’un cas. La règle et les modèles montrent déjà l’enjeu : ARIN accepte un client comme nom libre tant que l’amont tient la fiche; dès que le client veut une main sur la fiche, il doit présenter une organisation et un contact qui répond.