Summary
- The BTW directory fixes United Electric Cooperative as the exact operator entry associated with AS393442, while ARIN's Registration Data Access Protocol (RDAP) record connects the same number to the cooperative in an administrative ledger.
- A frozen RIPE Routing Information Service (RIS) response reports qualifying IPv4 visibility among 327 of 327 listed full-feed peers and IPv6 visibility among zero of 321, but those collector-, threshold-, product- and time-bounded figures are not universal reachability findings.
- PeeringDB independently pairs United Electric Cooperative and AS393442 in a participant-maintained profile; its status and interconnection rows are declarations, not proof of live sessions, physical presence, traffic, capacity or service condition.
One ASN connects four records with different jobs
BGP is the system independently operated networks use to exchange information about which internet address blocks they can reach. An autonomous system groups routing decisions under a common policy, and its ASN distinguishes that routing domain from others. Names may be abbreviated or reused, but an exact number lets a researcher connect records without assuming that every record measures the same thing.
AS393442 joins four sources here. The BTW directory identifies the public subject and provides navigation. ARIN RDAP provides the administrative number-resource record. RIPE RIS provides a frozen observation derived from routing collectors. PeeringDB provides a participant-maintained interconnection profile. Agreement on the ASN and the United Electric Cooperative name reduces the risk of attaching facts to the wrong subject.
That agreement does not erase the sources' different roles. A directory is not a route monitor. A registry status is not a service test. A collector view is not a legal or authorization finding. A participant profile is not independent verification of every declared interconnection or location. The useful account begins by asking what each layer actually supports.
The directory fixes the subject, not its operating condition
The exact directory route rendered the H1 United Electric Cooperative and displayed AS393442 when it was captured. Its requested, final and canonical addresses matched, its robots instruction permitted indexing and following, and the page did not present a page-level soft 404. Those details make it a reliable identity and navigation entry for this briefing.
The directory describes the linked subject as an operator entry. That classification keeps the article attached to the intended network identity rather than substituting a broader organisational category. It does not independently establish routes, authorization, customers, facilities, equipment, service territory or current operating condition.
The page also displayed other ASNs as relationship context. Their appearance is not evidence that United Electric Cooperative owns or operates them. AS395129 is therefore outside this article's attribution: none of the admitted registry, routing or peering evidence establishes control of that number by the cooperative.
ARIN RDAP records the administrative number object
RDAP is a structured protocol for retrieving registration data about internet number resources. ARIN's response is an autnum object whose starting and ending values are both 393442. Its handle is AS393442, its object name is UNITED-FIBER, and its status array contains active. The registrant handle is UEC-33, with the recorded name United Electric Cooperative.
These fields create an exact administrative bridge between the number and the named registrant. They also make the scope clear: the response concerns one ASN, not a range that needs another identity inference.
The word active belongs to the registry object. It does not report whether a router is powered, a BGP session is established, a prefix is visible or a customer-facing service is available. It does not establish route-origin authorization, legal ownership of physical infrastructure, or permission to make a particular announcement. Those questions need evidence designed for operational, authorization or legal analysis.
Registration remains valuable within that boundary. Unique and accurate number-resource records help networks coordinate, investigate errors and record changes. A durable administrative object can coexist with changing routing observations because the two systems answer different questions. Reading the registry as a ledger preserves its usefulness without stretching it into a live network probe.
The frozen RIPE RIS response is a bounded observation
RIPE RIS collects BGP information from participating observation points and publishes products derived from those views. The frozen routing-status response for AS393442 retains a query time of 7 August 2026, 16:00 UTC and a response time of 7 August 2026, 23:03:34.737843 UTC. Keeping both timestamps prevents the captured values from being treated as timeless.
The response also states that it excludes routes with very low visibility, defined as fewer than ten RIS full-feed peers seeing them. That threshold matters: the reported figures concern routes that qualified under the product's rule, not every route that might exist in another dataset or private view.
For IPv4, qualifying routes were visible to 327 of 327 listed full-feed peers. The announced-space fields reported 127 prefixes representing 88,576 addresses. For IPv6, qualifying routes were visible to zero of 321 listed peers, with zero prefixes and zero equivalent /48 blocks. The response's observed-neighbours field was ten.
The denominators and address families are part of the finding. Full visibility among the listed IPv4 peers is not proof that every network or endpoint on the internet could reach every address. Zero qualifying IPv6 visibility is not proof that no IPv6 connection or capability existed anywhere. The response describes what this product returned under its collector population, threshold and timestamps.
The same restraint applies to the prefix, address and neighbour totals. They do not establish traffic volume, route preference, authorization, latency, physical topology, diversity, resilience, uptime or customer experience. A route collector can describe observations without deciding whether an origin was permitted or whether a service worked end to end.
First seen and last seen are not one operating interval
The routing-status response also supplies two historical fields. Its first_seen value names prefix 209.152.140.0/24, origin 393442, at 8 July 2014, 08:00 UTC. Its last_seen value names a different prefix, 66.255.208.0/20, with the same origin at 7 August 2026, 16:00 UTC.
Those timestamps must remain attached to their individual prefixes. Joining them into a statement that the cooperative continuously operated one route or service from 2014 to 2026 would create a timeline the endpoint does not provide. The fields do not claim to bracket every announcement associated with AS393442, and they do not explain gaps, path changes or collector coverage across that period.
A defensible continuity study would require a purpose-built time series, stated vantage points and a method for handling gaps. A service finding would additionally need evidence tied to the named service and interval. Two endpoint-selected fields for different prefixes support neither conclusion on their own.
PeeringDB supplies participant-maintained context
PeeringDB's captured response contained one exact profile for AS393442 named United Electric Cooperative, with the alias United Fiber and the website domain unitedfiber.com. Its status was ok, and its update timestamp was 29 July 2026, 16:30:30 UTC. The ASN and name pairing independently corroborate the subject.
The profile contained two netixlan rows and two facility rows. These entries can help a researcher identify declarations to examine, but they remain participant-maintained profile data. A row does not by itself prove a live route-server session, physical presence, traffic exchange, contractual relationship, capacity or resilience. The ok status describes the PeeringDB record; it is not a service-health result.
This distinction is especially important for interconnection data. A profile can be useful for coordination even when its declarations have not been tested from the reader's vantage point. If a question concerns a live session, suitable routing evidence or direct operational confirmation is needed. If it concerns facility presence, the profile row needs separate verification appropriate to that claim.
Active, visible and ok answer different questions
ARIN's active status, RIPE RIS's visibility figures and PeeringDB's ok status may sound like a single positive verdict. They are not. ARIN describes an administrative object. RIPE RIS describes qualifying observations from a named product and peer set at a stated time. PeeringDB describes the status of a participant-maintained profile.
ARIN registration, the frozen RIPE RIS response and PeeringDB's participant-maintained profile are separate evidence layers; none alone proves universal reachability or unreachability, route authorization, capacity, resilience or customer service.
The disciplined reading is not scepticism for its own sake. It keeps each record useful by matching it to the question it can answer. The ASN joins identity across the layers. It does not grant any one layer authority over every administrative, technical, legal or service question.
A practical verification sequence
Start with identity. Confirm the exact directory subject, ASN, RDAP number range, handle and registrant name. This protects against confusing similar names and keeps later observations attached to the intended routing domain. Treat any additional ASN shown in relationship context as a separate research subject until exact evidence supports attribution.
Next, freeze routing evidence with its endpoint, query time, response time, messages, address family, numerator, denominator and product threshold. Preserve prefix identities beside historical timestamps. A later observation can be compared only when its product and vantage conditions are also disclosed; a changed value alone does not rewrite what the frozen response reported.
Then read the participant profile as a set of declarations. Confirm the exact ASN and name, record the update time, and separate profile rows from verified operations. If the question concerns authorization, inspect applicable authorization material. If it concerns present routing, gather time-aligned observations from appropriate vantage points. If it concerns service condition, use end-to-end tests and system records for the affected service and interval.
This sequence helps operators, researchers and incident responders narrow the next question. It also protects readers from unsupported escalation. A public ASN profile can identify a coordination boundary, but it cannot diagnose a customer connection, application dependency or outage by itself.
What these records do not establish
The four sources support a narrow account of United Electric Cooperative's directory identity, the ARIN record for AS393442, one frozen RIPE RIS response and one PeeringDB profile. They do not establish universal reachability or unreachability, route-origin authorization, legal ownership, permission or jurisdiction. They do not establish a current outage, shutdown, abandonment, transfer or loss of control.
They also do not establish customers, service territory, equipment, verified facility presence, upstream contracts, business scale or market position. None of the admitted fields measures traffic, capacity, latency, physical topology, diversity, resilience, uptime or customer outcomes. AS395129 and every other relationship ASN remain outside the attribution unless separately supported by exact evidence.
What to watch
Later checks should preserve the same layer boundaries. A registry review can look for changes to the exact AS393442 range, handle, status and registrant. A routing review can compare observations only when the product, timestamps, threshold, peer denominators and address family remain visible. A PeeringDB review can track profile changes without treating them as proof that a declared session, location or service is live.
The strongest next evidence would answer a specific open question: authorization material for an origin claim, a route-history series for continuity, direct confirmation for an interconnection, or service-specific telemetry for an operational claim. Until then, the precise conclusion is modest. The records align on United Electric Cooperative and AS393442 while describing distinct administrative, observational and participant-maintained layers.