Summary
- The BTW directory fixes the exact subject associated with AS59408, while RIPE NCC RDAP records the one-number ASN object, registry name
RULE-ASand exact registrant name. - A frozen RIPE RIS response reports IPv4 visibility among zero of 327 listed full-feed peers, IPv6 visibility among zero of 322, no announced space and zero observed neighbours; those product-, collector- and time-bounded values are not a universal network verdict.
- CAIDA AS Rank independently matches AS59408 with
RULE-AS, but itsseen, rank, cone and degree fields remain bounded to that dataset and do not prove route authorization, ownership or service status.
One number links records with different jobs
BGP is the protocol independently run 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 domain from other routing domains. Names can be abbreviated, expanded or formatted differently across systems. The number therefore provides a stronger join key than a name alone.
AS59408 connects four public evidence layers in this briefing. The BTW directory establishes the selected subject and navigation path. RIPE NCC's Registration Data Access Protocol, or RDAP, provides a structured administrative record for the number resource. RIPE RIS provides a frozen observation derived from routing collectors. CAIDA AS Rank provides a separately processed profile based on BGP data.
Agreement on AS59408 and RULE-AS reduces the risk of attaching records to the wrong subject. It does not make the sources interchangeable. A directory is not a route monitor. An administrative object is not an authorization decision. A collector response is not an end-to-end reachability test. A derived profile is not proof of live operation.
That separation is the key to reading the records. Each source is useful when it answers the question it was designed to answer. Confusion starts when an administrative label, a visibility counter or a profile field is stretched into a broader operational conclusion.
The distinction is especially important for readers who do not work with routing data every day. A single web search can place an administrative entry, a collector statistic and a derived ranking beside one another as if they were measurements of the same condition. They are not. Their common ASN makes comparison possible, but their different methods limit what can be concluded from that comparison. That boundary keeps the comparison useful and proportionate.
The responsible approach is to preserve both the link and the separation. The link is AS59408. The separation comes from the question behind each source: Who is the directory subject? What administrative object is recorded? What did one routing product return at a stated observation? What did one independent dataset derive? Answering those questions in order creates a useful public record without turning sparse data into a diagnosis.
The directory establishes the subject
The captured BTW directory route rendered the exact H1 Rule Communication - Nordic AB and visibly displayed AS59408. The requested address, final address and canonical address matched. The page also did not meet the bounded checks for a page-level soft 404. Those details make it useful for identifying the exact subject of this briefing.
The directory does not independently establish whether a route was announced, accepted or authorized at any moment. It does not measure reachability, traffic, latency or availability. Nor does it prove ownership of routers, address space or other physical assets. Its role is narrower and still important: it fixes which public directory identity the administrative and routing-oriented evidence is being compared with.
This distinction matters because a matching name can be ambiguous. An ASN displayed beside the exact subject creates a more precise identity bridge. It supports a careful comparison with the one-number RDAP object and independent routing-derived records without turning the directory page into operational evidence.
Identity checks should come first because every later inference depends on them. If a directory page named one organisation while an administrative record named another, the analyst would need to investigate the discrepancy before combining their fields. Here, the exact ASN and exact registrant name supply a direct bridge. That bridge supports comparison; it does not erase the possibility that each system updates on a different schedule or applies a different naming convention.
The directory also helps readers understand why a public article is about this subject rather than about an ASN in the abstract. The page supplies the public navigation context and associates the named directory entry with the number. It remains a contextual source, not an independent measurement of routing or service behaviour.
That boundary protects the subject as well as the reader. It prevents a page designed for identity and discovery from being cited as evidence of an outage, a service promise or an ownership claim that the page did not make. Accurate attribution begins with knowing what a source actually says and stopping where it stops.
RIPE NCC RDAP is an administrative ledger
The captured RIPE NCC response describes an autnum object whose starting and ending values are both 59408. Its handle is AS59408, its registry name is RULE-AS, and its status array contains active. The one-number range removes any need to infer which ASN the object covers.
The registrant handle is ORG-RCNA1-RIPE, and the registrant name is Rule Communication - Nordic AB, matching the directory subject. Other maintenance or contact records should not be promoted into registrant identity. The exact ASN and exact registrant name make the administrative bridge direct.
The word active belongs to the administrative object. It does not say that a route was visible to a particular collector, that an origin was authorized, or that an application was reachable. It does not establish legal ownership, operating control or permission to announce a prefix. Those questions require evidence designed for routing, authorization, legal or operational analysis.
Treating RDAP as a ledger preserves its value. Number-resource records support uniqueness, coordination and accurate recording. An administrative object can remain active while routing observations vary because the registry and the routing system describe different layers. A stable registry record is therefore compatible with a frozen routing product that returns zero qualifying values.
Administrative data can be essential even when it says nothing about current packet delivery. The handle, range and registrant create a reference point that other records can be checked against. Without that point, a visibility result would be harder to attribute. With it, the result can be tied to an exact ASN while remaining bounded to the method that produced it.
The ledger analogy is useful because a ledger records an organised fact set; it does not run the network. A registry object can tell a researcher that the exact number is represented in the registry and identify the recorded registrant. It cannot observe every BGP update, test every path, inspect a route-origin authorization or verify the condition of a customer-facing system.
This is not a criticism of RDAP. It is the reason RDAP is valuable. The interface gives structured administrative data rather than an uncertain mixture of operational claims. Readers get a clearer account when that administrative layer is used confidently for identity and carefully withheld from questions it cannot answer.
The RIPE RIS result is a frozen observation
RIPE RIS collects BGP information from participating observation points and publishes derived data products. The routing-status response used here retained a query time of 8 August 2026, 00:00 UTC and a response time of 8 August 2026, 06:13:08.924329 UTC. Keeping both timestamps prevents the returned fields from being treated as timeless.
Its messages array was empty. The response therefore supplied no threshold or exclusion notice to carry into the interpretation. This briefing does not invent one. It reports the denominators and counters as they appeared in the captured product.
For IPv4, qualifying visibility was zero of 327 listed RIS full-feed peers. For IPv6, it was zero of 322. The announced-space fields reported zero IPv4 prefixes and zero IPv4 addresses, together with zero IPv6 prefixes and zero equivalent /48 blocks. The observed-neighbours field was also zero.
These values describe one product, collector set and observation interval. They do not prove that every possible vantage point saw no route, that no private path existed, or that every destination was unreachable. They also do not identify a cause. A zero returned by a routing-status product cannot distinguish among routing policy, filtering, collector coverage, deliberate absence of announcements or another condition.
The word frozen matters. It means the fields are reported as an observation captured with their timestamps and source identity intact. It does not mean the values remain a description of the present. A later observation could differ without making the earlier record false. Conversely, the earlier record cannot be silently updated in prose to match a later result.
Collector-derived evidence is strongest when the observation population is explicit. The denominators show how many listed full-feed peers formed the product's relevant view for each address family. That is more informative than a bare zero because it tells the reader which measurement surface the numerator belongs to. It also makes clear that IPv4 and IPv6 were reported separately.
The empty messages array is another bounded fact. It tells the reader that this response did not supply a warning or explanatory message. It does not authorize the article to infer why the fields were zero. If a product had supplied a threshold or exclusion message, that message would need to be retained with the counters. Here, there was none to report.
Zero is a measurement, not a diagnosis
The safest way to report the visibility fields is to preserve each numerator and denominator. “Zero of 327 listed peers” is more precise than a blanket statement that an ASN was not visible, because it identifies the observation population. Keeping IPv4 and IPv6 separate also avoids turning a result for one address family into a claim about the other.
The announced-space and neighbour counters require the same restraint. They do not measure traffic, capacity, latency, route preference, physical topology, diversity, resilience, uptime or customer experience. They do not prove shutdown, abandonment, transfer or loss of control. A route-origin authorization question would require appropriate authorization material. A service-condition question would require evidence tied to the affected system and interval.
This does not make the frozen observation uninformative. It records exactly what the named product returned for a defined ASN and capture time. The disciplined conclusion is bounded rather than dramatic: the captured RIPE RIS routing-status fields were zero on their stated observation surface.
Readers often encounter zeros as if they were self-explanatory. In network measurement they are not. A zero can mean that a product found no qualifying item under its method. It does not automatically reveal whether nothing existed, whether nothing reached the product's observation points, whether the qualification rules excluded something, or whether the relevant activity occurred outside the captured interval.
This is why a public briefing should not replace the product's language with a stronger headline. A statement such as “the network was down” would introduce a service conclusion that the collector response did not test. A statement such as “the ASN had no routes anywhere” would erase the limits of the listed peers. A statement such as “the resource was abandoned” would turn an observation into a claim about intent and control.
Numerators, denominators, timestamps and source identity keep the observation accountable. They let another researcher understand what was captured and decide what additional evidence would be needed for a different question. That is more useful than a broad claim that cannot be reproduced from the cited fields.
IPv4 and IPv6 remain separate observations
The response reported qualifying IPv4 and IPv6 visibility with different denominators. That alone is enough reason to keep the address families separate. The routing system can carry different announcements, policies and observation coverage for IPv4 and IPv6. A result for one cannot be assumed to describe the other.
The announced-space fields also use different units. IPv4 space is represented through prefix and address counts, while the IPv6 field includes equivalent /48 blocks. Those units should not be combined into a single undifferentiated amount. The frozen response reported zero in each named field, but the meaning still comes from the individual field and method.
Keeping the families separate is not merely technical housekeeping. It prevents an article from using a familiar IPv4 result as shorthand for all internet routing. It also helps readers see why a future comparison would need to preserve the same field definitions. If later data used a different peer set, time window or aggregation rule, its values would need to be compared with care rather than placed beside these numbers as if the methods were identical.
The same discipline applies to any follow-up. An analyst asking whether visibility changed should compare like with like: the same product identity, understood peer population, address family and relevant time. If the method changes, the comparison should explain that change instead of presenting a raw difference as an operational event.
First seen and last seen are separate endpoints
The response also contains historical fields. Both first_seen and last_seen select 91.240.194.0/24 with origin 59408. The first timestamp is 12 September 2012, 16:00 UTC; the last is 28 March 2013, 16:00 UTC.
The selected prefix is the same at both endpoints, but that does not turn the span between the timestamps into one continuous announcement. The fields do not describe every update involving AS59408, explain any gaps, or establish how collector coverage changed. They also do not establish continuous service availability.
A defensible continuity analysis would need a purpose-built time series, stated vantage points and an explicit method for handling gaps. The two fields here support only two historical endpoints chosen by the response. Reading more into them would substitute an assumption for a measurement.
The labels “first” and “last” invite a narrative, but the response does not supply the events between them. It does not say that the selected prefix remained visible throughout the interval. It does not say that AS59408 originated no other prefix at any other place or time. It does not describe changes in the underlying observation system.
Historical endpoints are still valuable. They identify a prefix, origin and two times associated with the product. They can guide a more detailed route-history investigation. Their proper role here is to define the open question, not to answer it by implication.
If continuity mattered to an operational or policy decision, the next step would be to obtain time-series evidence with a clearly stated method. That evidence would need to distinguish observation gaps from actual routing gaps and avoid using application availability as a proxy for BGP history. The current sources do not provide that analysis, so this briefing does not pretend that they do.
CAIDA AS Rank corroborates identity
The frozen CAIDA AS Rank profile identifies ASN 59408, gives the name RULE-AS, names RIPE as the source and records country code SE. The exact ASN and registry-style name provide an independent BGP-derived identity match.
The same response records seen=false, rank 79459, one ASN in the cone, zero cone prefixes, zero cone addresses and total degree zero. These are outputs of CAIDA's dataset and processing. They are not universal measurements of the routing system and cannot establish that a route, network or service was absent everywhere.
The profile's role is therefore useful but bounded. It strengthens confidence that AS59408 and RULE-AS are the intended record, and it preserves a frozen set of derived fields. It does not prove announcements, authorization, peerings, traffic, facilities, capacity, physical ownership or service availability.
Derived datasets inevitably reflect their source material and processing choices. A field such as seen belongs to that dataset's definition and coverage. A rank belongs to the dataset's ranking method. Cone and degree values belong to its inferred graph. Those fields can support comparison within the dataset when their method is understood, but they do not become direct measurements of every routing relationship.
The identity match is the strongest cross-source use here. AS59408 and RULE-AS align with the administrative record, while the country field is consistent with the recorded context. That agreement reduces identity ambiguity. It does not create operational certainty because independent identity corroboration and independent service measurement are different achievements.
The safest public wording therefore keeps the profile attached to CAIDA AS Rank. Saying “CAIDA AS Rank recorded” preserves the source and method. Dropping that attribution could make a dataset-specific field sound like a universal fact about the network.
Active, zero and seen-false answer different questions
RIPE NCC's active status, the RIPE RIS zero counters and CAIDA's seen=false field can look contradictory if they are read as one health score. They are not contradictory. The registry status describes an administrative object. The routing-status response describes a product observation at stated times. CAIDA supplies a separately processed profile with its own coverage and method.
RIPE NCC RDAP registration, the frozen RIPE RIS response and CAIDA AS Rank's BGP-derived profile are separate evidence layers; none alone proves current route authorization, universal reachability or unreachability, capacity, physical-asset ownership or service status.
The ASN provides continuity of reference across those layers. It does not give any one source authority to answer every question. Keeping the records separate is not excessive caution; it is what lets each record remain useful without overstating what it measured.
One way to understand the compatibility is to imagine three different questions. The registry asks whether an administrative object exists and how it is recorded. The routing-status product asks what qualifying data appeared on its observation surface at the captured time. The derived profile asks what its dataset and processing produced for the ASN. “Active,” a zero counter and seen=false can all be valid answers because the questions differ.
Problems arise when those answers are collapsed. If active were interpreted as “currently visible everywhere,” the registry would be assigned a routing measurement it does not perform. If zero were interpreted as “administratively invalid,” the collector product would be assigned registry authority. If seen=false were interpreted as “no service exists,” a derived dataset would be assigned an application test it did not run.
The correct synthesis is not a compromise among the values. It is a map of their scope. The administrative object is recorded as active. The frozen routing-status response returned the stated zeros. The CAIDA profile returned its stated fields. The records agree on the key identity while leaving authorization, universal visibility, physical control and service condition unresolved.
What authorization would require
Route visibility and route authorization are separate questions. A collector may observe an announcement without proving that the origin was authorized. An authorization record may exist without guaranteeing that every collector sees the route. Neither the administrative status in RDAP nor the fields reported here settle the authorization question.
A focused authorization analysis would need evidence designed for that purpose and tied to a defined prefix and origin. It would need to state which material was checked, when it was checked and how conflicts or absence were interpreted. This briefing does not have that evidence and therefore makes no authorization claim.
The distinction matters because words such as valid, permitted and legitimate carry meanings that cannot be recovered from a generic registry status or visibility count. “Active” in an administrative object is not a route-origin verdict. “Seen” in a derived profile is not permission. A zero visibility result is not evidence of revocation.
Keeping authorization open also prevents an inverse error. The absence of a qualifying route in one product does not prove that an unauthorized route was present, just as the presence of an administrative object does not prove that any route was authorized. A precise article can identify which question remains unanswered without filling the gap with speculation.
What service condition would require
Service condition is farther removed from the admitted evidence. A customer-facing system may depend on routing, but its availability also depends on many other components and paths. Conversely, a sparse collector view does not by itself reveal what any specific user could reach or what application behaviour they experienced.
An operational finding would require evidence tied to the system, user population, interval and failure mode being discussed. That might include system-specific telemetry or measurements collected for the question. It would still need careful attribution and time boundaries. None of the four public sources in this briefing provides that evidence.
This boundary means the article cannot infer an outage, performance problem or customer impact from the zero counters. It also cannot infer healthy service from the active registry status. Both positive and negative service claims would exceed the source package.
For readers, this is a practical reminder that the internet has layers. Number-resource registration, BGP visibility and application service are connected, but they are not identical. Evidence from one layer can guide a question about another, yet it cannot replace the evidence that the other question requires.
A practical verification sequence
Start with identity. Confirm the exact directory subject, visible ASN, RDAP range and handle, registrant name, and independent profile identity. If those elements do not align, stop before combining facts from the sources.
Next, freeze observational evidence with its endpoint, query time, response time, messages, address family, numerator and denominator. Preserve the raw representation when possible. Keep historical timestamps attached to the prefix selected by the product.
Then match evidence to the question. For authorization, inspect relevant authorization material rather than inferring from RDAP status. For visibility, compare time-aligned observations from stated vantage points. For continuity, use a route-history method that handles gaps. For service condition, use measurements and records tied to the service and interval.
The sequence can be expanded into a repeatable checklist. First write down the subject and join key. Second label each source by function: directory, administrative registry, collector-derived observation or independent derived profile. Third record each time boundary and observation population. Fourth separate reported values from interpretations. Fifth list the claims that remain unsupported.
This method makes disagreements easier to diagnose. If two sources use different names but the same ASN, the researcher can check whether the difference is formatting or identity. If two observations use different denominators, the researcher can avoid treating their raw counters as directly comparable. If an administrative record and a routing product appear to differ, the researcher can ask whether they are simply answering different questions.
The checklist also improves corrections. A later update can identify which layer changed instead of rewriting the whole account. A registrant-name change would affect the administrative layer. A new collector result would affect the observational layer. A changed derived profile would affect the CAIDA layer. None should silently rewrite the frozen facts of another.
This sequence gives researchers a disciplined way to decide what evidence to gather next. It also prevents a public ASN record from becoming a diagnosis for an application dependency, user connection or outage that none of these four sources measured.
Common reading errors and how to avoid them
The first common error is treating the registry word active as proof of current operation. Avoid it by attaching the word to its object: the RDAP administrative object was recorded with active status. That sentence is accurate without claiming routing or service behaviour.
The second error is removing the denominator from a visibility result. “Zero” alone hides the product's observation population. Preserve “zero of 327 listed full-feed peers” for IPv4 and “zero of 322” for IPv6. The fuller form is less dramatic and more reproducible.
The third error is treating first and last seen as a continuous interval. Avoid it by calling them endpoints and retaining the selected prefix and timestamps. Do not fill the period between them with an assumption.
The fourth error is turning a derived profile field into a universal condition. Keep seen=false, rank, cone and degree attached to CAIDA AS Rank and its dataset. Do not convert them into claims about all BGP vantage points or any application.
The fifth error is using agreement on identity as agreement on condition. The directory, RDAP and CAIDA profile can all identify AS59408 and RULE-AS while saying nothing shared about authorization or service health. Identity agreement is valuable, but it is not a health assessment.
The sixth error is inventing a cause for sparse data. The frozen response does not tell us why its counters were zero. It supplies no threshold or exclusion message. A responsible article reports the observation and names the unresolved question rather than selecting an explanation from possibilities the sources did not test.
Who is affected by careful interpretation
Researchers benefit because bounded claims are easier to reproduce. An ASN, timestamps, denominators and named products give them a clear starting point. They can identify which observation was used and which questions remain open.
Network operators benefit because the article does not turn public administrative or collector data into an unsupported accusation. A sparse observation can be reported accurately without being labelled an outage, abandonment or loss of control. This distinction keeps operational conclusions tied to operational evidence.
Editors and readers benefit because the evidence hierarchy is visible. The directory identifies the subject. RDAP records the administrative object. RIPE RIS supplies a frozen observation. CAIDA provides a derived profile. That structure makes it easier to see where a statement came from and what it can support.
Policy readers benefit because registry and routing functions remain distinct. Administrative accuracy matters for coordination, yet running observations remain necessary for questions about what appeared in BGP. Neither layer becomes a substitute for legal or authorization analysis.
The named subject also benefits from exact attribution. The article does not infer facilities, equipment, customers, service areas or business performance. It confines itself to public records that can be joined through AS59408 and clearly states the limits of that join.
What these records do not establish
The four public sources support a narrow account: an exact directory identity, the RIPE NCC administrative object for AS59408, one frozen RIPE RIS response and one independent CAIDA profile. They do not establish universal reachability or unreachability, route-origin authorization, legal ownership, permission or jurisdiction.
They do not establish a present outage, shutdown, abandonment, transfer or loss of control. They do not establish customers, facilities, equipment, service territory or physical topology. None of the admitted fields measures traffic, capacity, latency, diversity, resilience, uptime or customer outcomes.
The records also do not explain why the frozen counters were zero or why CAIDA returned its dataset fields. Any explanation would require additional evidence matched to a defined hypothesis. The responsible result is to preserve the captured values, identify their boundaries and avoid substituting a narrative for missing measurements.
They do not establish that the historical prefix was continuously announced between the first and last endpoint. They do not establish what any particular network or user observed. They do not establish whether a route-origin authorization existed for a defined prefix and time. They do not establish whether the organisation provided or did not provide any particular service.
Listing exclusions is not an attempt to evade a conclusion. It is how a conclusion remains faithful to the evidence. The supported conclusion is precise: the sources identify the same ASN and registry-style name, while their administrative, observational and derived fields retain separate meanings.
What could change the evidence picture
A new administrative snapshot could show whether the RDAP object, handle, range, registrant or status changed. Such a change would belong to the registry layer. It would not retroactively alter what the frozen response recorded.
A new routing-status observation could report different counters, peer denominators or messages. That would be a new observation with its own timestamps, not a correction to the captured one. Comparing the two would require attention to product identity and coverage.
A route-history dataset could provide a more complete series for the selected prefix and origin. It could help answer continuity questions if its vantage points and gap-handling method were explicit. The current first and last endpoints are not a substitute for that series.
Authorization material tied to a defined prefix and origin could address a route-origin question. System-specific telemetry tied to an interval and affected service could address an operational question. Those evidence types would answer questions that the current sources leave open.
A later CAIDA AS Rank profile could also differ as its dataset and processing change. That would be useful within the profile's method. It still would not become a universal measurement of reachability or service condition.
The important principle is dependency-scoped updating. New evidence should change only the conclusion it supports. A registry update should not be presented as a collector result. A collector update should not be presented as authorization. A service measurement should not rewrite administrative history.
What to watch
Later checks should preserve the same evidence roles. A registry review can examine whether the exact ASN range, handle, registrant or administrative status changes. A routing review can compare observations only when it preserves product identity, timestamps, peer denominators and address-family separation. A derived-profile review can track identity and dataset changes without treating the profile as proof of operation.
The strongest next evidence would answer a defined open question: authorization data for an origin claim, a time series for route history, additional collector views for visibility, or system-specific telemetry for an operational finding. Until such evidence is available, the precise conclusion remains modest. The records align on the directory subject and AS59408, while the administrative registry, frozen routing observation and independent BGP-derived profile continue to describe distinct layers.
Readers should also watch the language used around future observations. A fresh zero would still need a method and denominator. A nonzero value would show that the named product observed a qualifying item; it would not by itself prove authorization, capacity or service health. A changed administrative status would describe the registry object and would not by itself explain a routing event.
The enduring value of this record is not a prediction. It is a disciplined baseline. AS59408 provides a stable join key, the sources provide bounded fields, and the article keeps those fields attached to the systems and times that produced them. That makes later verification more reliable and reduces the risk that a technical term will be mistaken for a broader verdict.