Résumé
- Le répertoire BTW fixe United Electric Cooperative comme fiche d’opérateur liée à AS393442, tandis que le Registration Data Access Protocol d’ARIN rattache exactement le même numéro au même déclarant dans un dossier administratif.
- Une réponse RIPE RIS figée indique une visibilité IPv4 qualifiante auprès de 327 pairs full-feed répertoriés sur 327, mais une visibilité IPv6 de 0 sur 321 ; ces chiffres restent bornés par le produit, le seuil, les collecteurs et l’heure de l’observation.
- PeeringDB fournit un profil exact United Electric Cooperative / AS393442, mais son statut et ses lignes d’interconnexion sont des déclarations du participant, non la preuve de sessions actives, d’une présence physique, d’une capacité ou d’un état de service.
Un numéro commun ne fusionne pas les sources
Le Border Gateway Protocol, généralement abrégé BGP, permet à des réseaux administrés séparément d’échanger des informations sur les blocs d’adresses qu’ils savent joindre. Un système autonome rassemble des décisions de routage sous une politique commune ; son ASN le distingue des autres domaines. Cette clé numérique est plus stable qu’un nom, qui peut être abrégé, stylisé différemment ou partagé.
AS393442 relie quatre documents publics. Le répertoire BTW indique de quel sujet il est question. ARIN conserve l’objet administratif correspondant à la ressource numérique. Le RIPE Routing Information Service, ou RIS, produit une vue du routage à partir de points d’observation participants. PeeringDB publie enfin un profil d’interconnexion renseigné par le participant.
L’accord sur le nom et sur l’ASN réduit le risque d’attribuer une mesure au mauvais réseau. Il n’accorde pas à une source les pouvoirs de l’autre. Une fiche d’annuaire ne mesure pas BGP. Un registre n’effectue pas de test de bout en bout. Une vue de collecteurs ne tranche pas une question juridique. Un profil d’interconnexion ne vérifie pas automatiquement chaque session ou chaque emplacement déclaré.
Le répertoire fixe l’identité, pas la condition opérationnelle
Lors de la capture, la route exacte du répertoire affichait le H1 United Electric Cooperative et rendait AS393442 visible. L’adresse demandée, l’adresse finale et la canonique concordaient. La page autorisait l’indexation et le suivi, et elle ne présentait pas de page introuvable déguisée. Ces éléments suffisent à établir un repère d’identité et de navigation.
La fiche est celle d’un opérateur. Cette précision évite de remplacer le sujet par une catégorie organisationnelle plus large. Elle ne prouve ni l’existence d’une route à un instant donné, ni l’autorisation d’une origine, ni des clients, des équipements, un territoire de service ou une situation de fonctionnement.
La page montrait également d’autres ASN comme contexte de relation. Leur présence n’en transfère ni la propriété ni le contrôle à United Electric Cooperative. AS395129 reste donc hors du périmètre d’attribution : aucune des sources admises dans ce dossier n’établit que la coopérative le possède ou l’exploite.
ARIN RDAP décrit un objet administratif exact
Le Registration Data Access Protocol, ou RDAP, fournit des données structurées sur les ressources numériques d’internet. La réponse d’ARIN couvre exactement un ASN : les valeurs de début et de fin sont toutes deux 393442, le handle est AS393442 et le nom de l’objet est UNITED-FIBER. Le déclarant porte le handle UEC-33 et le nom United Electric Cooperative.
Le tableau de statuts contient active. Ce mot qualifie l’objet dans le registre. Il permet de lire un dossier administratif précis, mais il ne dit pas si un routeur est alimenté, si une session BGP est établie, si un préfixe est visible ou si un service destiné aux usagers répond correctement.
Le RDAP ne décide pas davantage si une origine observée est autorisée, ni si le déclarant détient juridiquement chaque actif lié au réseau. Ces questions demandent des preuves adaptées à l’autorisation ou au droit. Le registre reste pourtant essentiel : des numéros uniques, des associations exactes et des changements traçables facilitent la coordination et l’investigation. Sa force vient de son rôle de grand livre, pas d’une prétention à mesurer les paquets en mouvement.
La réponse RIPE RIS est une photographie bornée
RIS reçoit des informations BGP depuis des points d’observation et en dérive des produits de routage. La réponse figée pour AS393442 conserve une heure de requête au 7 août 2026 à 16:00 UTC et une heure de réponse au 7 août 2026 à 23:03:34.737843 UTC. Ces deux repères empêchent de présenter les valeurs comme une description permanente.
Un message de la réponse précise que les routes à très faible visibilité sont exclues, cette catégorie désignant celles vues par moins de dix pairs RIS full-feed. Le seuil appartient à la méthode. Les nombres qui suivent concernent donc les routes ayant satisfait cette règle dans ce produit, et non toute route susceptible d’exister dans une autre vue ou dans une interconnexion privée.
Pour IPv4, les routes qualifiantes apparaissaient auprès des 327 pairs full-feed répertoriés sur 327. Les champs d’espace annoncé indiquaient 127 préfixes, soit 88 576 adresses. Pour IPv6, la visibilité qualifiante était de 0 sur 321 pairs, avec zéro préfixe et zéro bloc équivalent /48. Le champ des voisins observés valait dix.
Les dénominateurs et la famille d’adresses font partie du résultat. Une visibilité complète dans la liste IPv4 de ce produit n’équivaut pas à une joignabilité universelle depuis n’importe quel réseau ou terminal. Un résultat IPv6 de 0 sur 321 ne prouve pas l’absence de toute capacité, session ou connectivité IPv6. Il décrit ce que ces collecteurs ont retenu sous le seuil, à l’heure indiquée.
Les totaux ne mesurent ni le trafic, ni la capacité, ni la latence, ni les préférences de chemin, ni la topologie physique. Ils ne démontrent pas une diversité de liaisons, une résilience, un temps de disponibilité ou une expérience client. De même, voir une origine dans BGP ne suffit pas à décider si elle est autorisée.
first_seen et last_seen concernent deux préfixes
La réponse contient aussi deux champs historiques. first_seen associe le préfixe 209.152.140.0/24 à l’origine 393442 le 8 juillet 2014 à 08:00 UTC. last_seen concerne un autre préfixe, 66.255.208.0/20, avec la même origine le 7 août 2026 à 16:00 UTC.
Les dates ne peuvent être séparées de leurs préfixes. Les réunir pour raconter une exploitation continue de 2014 à 2026 créerait une chronologie absente de la source. L’endpoint ne dit pas que ces valeurs encadrent toutes les annonces d’AS393442, ni qu’elles expliquent les changements de chemin, la couverture des collecteurs ou les éventuelles lacunes.
Une analyse de continuité demanderait une série temporelle conçue à cet effet, une méthode déclarée et une couverture de points de vue connue. Un diagnostic de service exigerait en plus des mesures liées au service et à la période concernés. Deux repères portant sur des préfixes différents ne suffisent à aucun de ces usages.
PeeringDB apporte un contexte déclaré par le participant
La réponse PeeringDB capturée contenait un seul profil exact pour AS393442, nommé United Electric Cooperative, avec l’alias United Fiber. Elle indiquait le domaine unitedfiber.com, le statut ok et une mise à jour au 29 juillet 2026 à 16:30:30 UTC. La correspondance entre le nom et l’ASN renforce l’identification par une source indépendante du répertoire et d’ARIN.
Le profil contenait deux lignes netixlan et deux lignes d’installations. Ces données peuvent orienter une vérification, mais elles restent des déclarations du participant. Une ligne ne prouve pas qu’une session de serveur de routes est active, qu’un échange de trafic a lieu, qu’une présence physique a été vérifiée ou qu’une relation contractuelle subsiste.
Le statut ok concerne le profil PeeringDB, pas la santé d’un service. Pour établir une session en fonctionnement, il faudrait une observation opérationnelle appropriée ou une confirmation directe. Pour établir une présence, il faudrait une preuve indépendante adaptée à l’emplacement. La prudence conserve la valeur du profil sans en faire une carte certifiée du réseau.
Active, visible et ok répondent à trois questions
Les termes semblent aller dans la même direction seulement si l’on oublie leur producteur. Chez ARIN, active décrit un objet administratif. Chez RIPE RIS, 327 sur 327 et 0 sur 321 décrivent une observation qualifiante par famille d’adresses, avec une heure, des collecteurs et un seuil. Chez PeeringDB, ok décrit un profil tenu par le participant.
L’enregistrement d’ARIN, la réponse RIPE RIS figée et le profil PeeringDB tenu par le participant constituent des couches de preuve distinctes ; aucun ne démontre à lui seul une joignabilité ou une injoignabilité universelle, l’autorisation d’une route, la capacité, la résilience ou le service rendu aux clients.
Cette séparation n’affaiblit pas le dossier. Elle rend chaque conclusion vérifiable. L’ASN assure la jointure d’identité ; la méthode de chaque source détermine ce qu’elle permet d’affirmer. Le réel se trouve dans cette correspondance entre question et preuve, non dans l’extension d’une étiquette au-delà de son champ.
Une séquence de vérification utile
La première étape consiste à verrouiller l’identité : nom exact du répertoire, ASN, plage RDAP, handle et déclarant. Tout ASN supplémentaire aperçu comme relation doit rester un objet séparé tant qu’une preuve exacte ne justifie pas son attribution.
La deuxième étape consiste à figer l’observation de routage avec son endpoint, ses heures, son message de seuil, sa famille d’adresses, son numérateur et son dénominateur. Les préfixes historiques restent attachés à leurs dates. Une observation ultérieure peut être comparée si son produit et ses points de vue sont également exposés ; elle ne réécrit pas rétroactivement la capture.
La troisième étape lit PeeringDB comme un inventaire de déclarations à contrôler. Si la question porte sur l’autorisation, il faut examiner les éléments d’autorisation applicables. Si elle porte sur le routage présent, il faut des observations alignées dans le temps. Si elle porte sur un service, il faut des tests de bout en bout et des journaux correspondant à ce service et à cet intervalle.
Ce que les quatre sources n’établissent pas
Ces documents établissent une identité de répertoire, un objet ARIN pour AS393442, une observation RIPE RIS figée et un profil PeeringDB. Ils n’établissent ni une panne actuelle, ni un arrêt, ni un abandon, ni un transfert, ni une perte de contrôle. Ils ne prouvent pas une joignabilité universelle, une autorisation d’origine, une propriété juridique ou une compétence territoriale.
Ils ne prouvent pas non plus une clientèle, un territoire de service, des équipements, une présence physique vérifiée, des contrats amont, une taille d’activité ou une position de marché. Aucun champ admis ne mesure le trafic, la capacité, la latence, la topologie, la diversité, la résilience, la disponibilité ou l’expérience des usagers. AS395129 et les autres ASN de relation restent hors attribution sans preuve distincte.
Points à surveiller
Une vérification future du registre peut suivre la plage exacte, le handle, le statut et le déclarant d’AS393442. Une comparaison de routage doit conserver le produit, les heures, le seuil, les dénominateurs et la famille d’adresses. Une évolution du profil PeeringDB peut être documentée sans être assimilée à la preuve d’une session ou d’une installation active.
La prochaine preuve utile dépendra de la question : documents d’autorisation pour une origine, série historique pour la continuité, confirmation directe pour une interconnexion ou télémétrie propre à un service. En leur absence, la conclusion reste précise : les quatre sources s’accordent sur United Electric Cooperative et AS393442 tout en décrivant des couches administratives, observées et déclaratives différentes.