Résumé

  • Le projet ARIN-2025-1 affirme que tous les fournisseurs de services Internet sont des registres Internet locaux, mais pas l’inverse. Sa définition du LIR exige une fonction de registre, l’adhésion à un RIR, la réception d’allocations et leur distribution.
  • La définition proposée de l’ISP se contente d’une fourniture de services à des tiers : connectivité, services web, colocation, serveurs dédiés, VPS ou VPN. Ces critères ne suffisent pas à établir l’inclusion annoncée.
  • Une correspondance versionnée entre rôles, fonctions de ressources et occurrences de termes permettrait de rendre la décision reproductible, sans transformer le modèle commercial ou l’architecture du demandeur en norme commune.

Le métier déclaré n’est pas encore le rôle de registre

Les catégories paraissent simples lorsque l’exemple est un opérateur d’accès classique. Il vend une connexion, reçoit un bloc directement, en affecte des parties à ses clients et enregistre ces distributions. Les mots ISP et LIR décrivent alors la même organisation vue depuis deux angles.

Une règle n’a pourtant pas besoin d’être précise seulement au centre. Elle doit indiquer ce qui se passe à la frontière. Un hébergeur peut fournir un service web avec des adresses de son fournisseur amont. Une université peut recevoir une allocation et la distribuer dans plusieurs composantes sans vendre un accès grand public. Une grande entreprise peut exercer une fonction de registre interne ou aval sans adopter le métier commercial d’un ISP.

Le tableau de suivi de NOG Alliance, indépendant du registre, classe ARIN-2025-1 comme Draft Policy et date son dernier changement du 13 août 2026. Le projet part d’un vrai défaut documentaire : LIR est défini, tandis que la définition explicite d’ISP manque. Son énoncé du problème ajoute une relation précise : par implication et selon la pratique commerciale courante, tous les ISP sont des LIR, mais tous les LIR ne sont pas des ISP.

Ce n’est pas seulement une remarque d’usage. C’est une affirmation d’inclusion. Chaque organisation qui satisfait la définition ISP doit nécessairement satisfaire la définition LIR. Dire que les catégories se recouvrent souvent, qu’ARIN les emploie ensemble ou qu’un opérateur connu relève des deux ne suffit pas à établir cette nécessité.

Le choix politique peut être parfaitement défendable. Ce sont les prédicats publiés qui ne le rendent pas encore vérifiable.

Le LIR est défini par une chaîne de distribution

Le texte du projet conservé dans une archive indépendante de PPML datée de mars 2026 donne plusieurs maillons au LIR. Il s’agit d’un Internet Registry, membre d’un RIR, qui reçoit de celui-ci des allocations de numéros Internet puis les alloue à ses clients, aux utilisateurs finaux et à son infrastructure.

Cette définition suit la ressource. Elle demande qui reçoit, qui distribue et qui enregistre. Les exemples dépassent volontairement le fournisseur d’accès : grandes entreprises, universités et ISP figurent parmi les LIR possibles.

La même diffusion archivée montre l’ampleur de la migration proposée. Des titres et des clauses jusque-là libellés ISP passeraient à LIR ; la clause terminologique dirait qu’ISP est un sous-ensemble de LIR. Il ne s’agit donc pas d’une simple note de glossaire. Le nom de rôle traverserait les règles d’allocation, de réaffectation, d’utilisation et de clientèle aval.

L’archive prouve ce qui a été diffusé, non ce qui fait autorité. Le tableau de suivi établit seulement une version ultérieure et son état. Le dossier de publication doit conserver les deux limites : le texte exact analysé et la borne de version plus récente dont il faudra relire l’intégralité avant toute mise en œuvre.

L’ISP est défini par ce qu’il vend

La nouvelle définition de l’ISP commence sur un autre axe. Est ISP toute organisation qui fournit des services Internet à des organisations, à ses clients ou à des personnes autres que ses employés. La liste ouverte comprend la connectivité, les services web, la colocation, les serveurs dédiés, les serveurs privés virtuels et les réseaux privés virtuels.

La phrase ne dit pas que l’ISP est un Internet Registry. Elle n’exige ni allocation directe du RIR, ni qualité de membre, ni réallocation ou réaffectation de numéros à des clients. Elle décrit une offre, pas la provenance et le mouvement d’une ressource.

L’ambiguïté apparaît dans un échange PPML conservé par Mail-Archive. Un participant y cite un guide qui assimile brièvement LIR et ISP tout en reproduisant une définition où les LIR ne sont que « généralement » des ISP ; il demande alors si les catégories sont identiques, incluses l’une dans l’autre ou facultatives pour un titulaire d’allocation directe. L’archive prouve qu’une confusion a été exprimée, pas la manière dont un analyste traiterait un dossier donné.

L’ordre reste instructif. Le catalogue de services oriente le lecteur vers une porte. Les critères placés derrière cette porte déterminent s’il peut la franchir. Vendre un VPN ne crée pas rétroactivement une allocation directe. Exploiter des serveurs dédiés ne prouve pas l’enregistrement de distributions aval.

Le projet original avait utilisé une articulation plus forte en qualifiant l’ISP de type d’organisation LIR. La version actuelle dit seulement type of organization. Quatre mots ont disparu ; avec eux disparaît le lien formel entre les ensembles.

Une implication absente du texte

Une notation minimale permet de voir le problème sans transformer la politique en logiciel.

Appelons IR(x) le fait que l’organisation x distribue des ressources numériques Internet et enregistre les distributions. M(x) représente le statut d’adhésion au RIR que la règle entend viser. A(x) signifie que l’organisation reçoit une allocation de ce RIR. D(x) indique qu’elle alloue ou sous-délègue des ressources vers l’aval. S(x) signifie qu’elle fournit au moins un service Internet répertorié à un tiers.

La définition proposée du LIR se lit alors LIR(x) = IR(x) ∧ M(x) ∧ A(x) ∧ D(x). La définition proposée de l’ISP se réduit à ISP(x) = S(x).

Pour que tout ISP soit un LIR, il faut une implication : S(x) → IR(x) ∧ M(x) ∧ A(x) ∧ D(x). Elle n’apparaît pas.

Cette observation ne prouve aucun dysfonctionnement d’ARIN. Une politique comporte aussi des clauses de qualification, des formulaires, des interprétations et un dialogue avec le demandeur. Elle prouve uniquement qu’un lecteur ne peut pas reconstruire la relation annoncée à partir des deux définitions publiques.

Plusieurs réparations restent cohérentes. La définition peut faire de l’ISP un type de LIR. Elle peut limiter l’ISP normatif au fournisseur qui exerce une fonction de distribution qualifiante. Elle peut reconnaître deux ensembles qui se chevauchent sans s’inclure. Elle peut enfin retirer ISP du droit d’éligibilité et lier chaque voie de demande à l’usage des ressources.

Le choix appartient à la communauté. L’implication, elle, ne devrait pas dépendre d’une convention orale.

Un cas de bord qui n’existe que pour tester la règle

Supposons une entreprise fictive. Elle vend un service web administré et un accès VPN. Toutes ses adresses proviennent d’un fournisseur amont. Elle ne détient aucune allocation directe d’un RIR et ne réalloue pas des ressources numériques à ses clients en qualité d’Internet Registry.

Ce scénario est synthétique. Il ne décrit aucune entreprise réelle, aucune demande ARIN et aucune décision d’analyste.

L’entreprise satisfait néanmoins le prédicat de service ISP : elle fournit à des tiers deux services cités. Elle ne satisfait pas au moins les prédicats d’allocation directe et de distribution aval du LIR. Selon le sens donné à member of an RIR, elle peut aussi échouer sur l’adhésion.

Il peut être utile de l’appeler ISP dans le commerce. Il peut être utile de la diriger vers la documentation ISP afin qu’elle détermine si son futur modèle d’affectation justifie une allocation. Aucune de ces commodités ne transforme l’espace amont en allocation RIR déjà reçue.

Le cas de bord n’accuse personne. Il révèle seulement le fait manquant entre deux définitions.

Fonction de ressource et étiquette d’organisation sont deux axes

RFC 7020 décrit le système des registres de numéros Internet comme une hiérarchie où des registres allouent des ressources à leurs clients et où les LIR sont typiquement des ISP. « Typiquement » décrit une relation fréquente ; ce mot n’établit pas l’identité entre un rôle de registre et toute organisation qui vend un service Internet.

Sur l’axe de la ressource, on trouve le demandeur, le titulaire d’une allocation directe, le distributeur aval, l’utilisateur final ou l’opérateur d’espace amont. Sur l’axe du service, on trouve la connectivité, l’hébergement, la colocation ou le VPN. Une classification peut consulter les deux, mais elle doit dire quelle combinaison déclenche le rôle normatif.

Une définition alternative proposée dans la discussion PPML rendait ce choix explicite : elle rattachait LIR au système de RFC 7020 et faisait de la consommation et de la justification des ressources pour les clients le trait important d’ISP. Ce texte était la suggestion d’un participant, non une règle adoptée. Il montre simplement que le pont manquant peut tenir en une phrase lorsque la fonction visée est connue.

Si member of an RIR demeure une condition du LIR, il faut encore nommer la relation exacte et le moment du cycle où elle doit exister. Une offre commerciale ne peut pas créer cet état par implication ; une relation de ressource ne doit pas être déduite d’un nom de métier.

L’histoire administrative a gardé les rôles distincts

RFC 2901, guide informatif publié en 2000, orientait les organisations vers des procédures différentes selon la manière dont elles obtiendraient et utiliseraient les adresses. Ses consignes sont historiques et n’établissent aucune exigence ARIN actuelle. Elles établissent un point analytique durable : ISP sert depuis longtemps d’étiquette de voie de demande, tandis que LIR appartient à la hiérarchie de registre.

Les mots peuvent converger dans la conversation alors que les procédures posent encore des questions différentes. La donnée commune utile n’est donc pas l’étiquette préférée de l’entreprise, mais la fonction de la ressource qui sélectionne une règle à une version et à une date données.

La discussion publique avait déjà trouvé le pont fragile

La discussion archivée ne portait pas seulement sur le style. Une réponse de mars 2026 approuvait le constat que la phrase proposée pour LIR était grammaticalement incomplète et contestait at a local level, certains LIR opérant au-delà d’une seule région RIR. Le même message reproduisait la définition d’ISP fondée sur les services.

Cette réponse ne décide rien et ne décrit aucune mise en œuvre. Elle montre que les participants testaient déjà les prédicats et leur périmètre avant la borne de version du 13 août. L’objet de cet article n’est donc pas une faute cachée, mais une question textuelle reproductible qu’une version ultérieure peut résoudre.

La terminologie est un état distribué. Une définition atteint les rubriques, les guides, les consignes, la formation et les champs de formulaire. Une version plus récente doit être réexaminée comme un nouvel objet, pas comme la continuation silencieuse du texte archivé de mars.

Une correspondance de rôles minimale et protégée

La solution n’est pas d’exiger la totalité du plan commercial. Il suffit de relier le rôle retenu, la version de la règle et la fonction réelle de la ressource dans une trace qu’un second analyste peut rejouer.

Seize champs forment un noyau raisonnable.

  1. Identité de l’organisation et Org ID. Conserver les identifiants juridique et registre, avec la période de validité de l’identité examinée.
  2. Identité de la demande ou décision. Attribuer une clé stable, une heure de dépôt et des liens explicites vers toute révision ou demande de remplacement.
  3. Version du vocabulaire. Nommer le NRPM, projet ou profil d’implémentation exact, sa date d’effet et les définitions appliquées.
  4. Objet de la classification. Indiquer la décision précise pour laquelle le rôle est testé ; une étiquette commerciale universelle ne doit pas trancher toutes les actions.
  5. Prédicat de service commercial. Enregistrer la classe limitée de service externe déclarée sans importer le catalogue privé dans la politique.
  6. Prédicat d’Internet Registry. Dire si l’organisation distribue des ressources et enregistre les distributions, avec référence protégée à la preuve.
  7. État de l’allocation directe. Séparer aucune, demandée, approuvée, émise, retournée, révoquée ou remplacée et relier l’état à l’événement.
  8. Fonction de délégation aval. Préciser réallocation ou reassignment, classe de destinataire et clause applicable.
  9. Usage de l’infrastructure interne. Distinguer l’usage propre limité de la distribution aux clients.
  10. État d’adhésion. Enregistrer demandeur non membre, Service, General, General en règle ou Trustee selon la version pertinente, sans déduire le vote du rôle de ressource.
  11. Accord et autorité. Relier RSA/LRSA et rôle organisationnel autorisé à une preuve protégée, sans publier les documents privés.
  12. Voie de politique applicable. Nommer sections, tests de qualification et exclusions sélectionnés par la fonction vérifiée.
  13. Correspondance des occurrences. Pour chaque terme conséquent, garder ancien terme, nouveau terme, section, surface et code d’effet sémantique limité.
  14. Liaison d’implémentation. Relier la même signification au guide public, aux consignes du personnel, à la formation, au champ d’application et à la version des tests.
  15. Résultat, explication et correction. Préserver les prédicats décisifs, l’issue, le recours, les transitions ultérieures et l’historique des corrections.
  16. Projection agrégée respectueuse de la vie privée. Publier les nombres par voie, changements de classification, écarts de version et corrections sans nom ni secret commercial.

Cette liste ne prescrit pas une base de données. Elle définit la quantité minimale d’information nécessaire pour reproduire le choix d’une voie de politique.

La couche commune connaît la fonction, pas le modèle d’affaires

La Minimum Initial Specification fournit une limite constructive. La coordination partagée doit être stricte sur les faits déterministes nécessaires à l’unicité, à l’interopérabilité, à la preuve, à la sûreté et à la sécurité. Les arrangements commerciaux et les préférences discrétionnaires restent hors de cette couche.

Ici, l’identité, la version du vocabulaire, le cycle de vie de la ressource, la fonction de délégation, la règle applicable et la transition d’état sont communs. Les preuves d’accord et d’autorité peuvent rester protégées. Les agrégats publics peuvent révéler les changements de voie et les corrections sans exposer les clients.

Le mélange de produits reste local. ARIN n’a pas besoin de décider quel poids a l’hébergement dans le chiffre d’affaires, comment un VPN est assemblé, quel hyperviseur porte le VPS ou quel routeur dessert une salle de colocation. Un fait commercial n’entre dans la trace que lorsqu’un prédicat nommé le rend pertinent.

Minimal ne veut pas dire approximatif. Plus la règle prétend peu sur l’entreprise, plus elle peut être exacte sur la fonction de ressource qu’elle coordonne.

Sources

Ce que les preuves ne montrent pas

Aucune source du paquet n’identifie une organisation réelle mal classée par ARIN à cause des mots ISP et LIR. Aucune ne mesure tickets supplémentaires, délais, refus, tailles modifiées ou différences entre analystes. Les champs internes actuels, les supports de formation et la logique complète de décision ne sont pas publics ici.

Les preuves suffisent donc pour une conclusion textuelle et une recommandation de migration. Elles ne permettent ni d’estimer une fréquence ni d’alléguer une faute.

Elles ne prédisent pas davantage l’issue du PDP. Le suivi indépendant classe ARIN-2025-1 comme Draft Policy. Une nouvelle version peut rétablir un lien explicite, retirer l’inclusion, conserver seulement LIR ou revoir les deux définitions. Une évaluation visant exactement ce nouvel objet serait un fait nouveau.