Summary

  • APNIC RDAP identifies AS139618 as FY-AS-AP and records Zhu Hai Shi Fu Yuan Le Yu Technology Limited as the registrant.
  • The APNIC record carries country code CN, status active, registration time 2019-08-28T09:48:19Z, and last-changed time 2020-09-08T13:13:56Z.
  • RIPEstat’s captured overview names the same holder and marks the ASN as announced=false.
  • At 2026-08-01T16:00:00Z, the captured routing-status view reports no visible IPv4 or IPv6 prefixes or addresses.
  • Visibility is reported as 0 of 328 IPv4 peers and 0 of 322 IPv6 peers, with zero observed neighbours.
  • The captured announced-prefix response contains an empty current list.
  • Historical fields identify 2001:df1:4580::/48 as first seen on 2019-10-22 and 2405:84c0:ff80::/44 as last seen on 2024-02-14.
  • Those historical fields are boundaries in the returned data, not a complete chronology, while the current zeroes remain collector-bounded observations rather than universal Internet truth.

The name attached to the number

AS139618 has a clear identity in APNIC RDAP. The handle is AS139618, the network name is FY-AS-AP, and the recorded registrant is Zhu Hai Shi Fu Yuan Le Yu Technology Limited. Country is recorded as CN. The status is active. These fields create a compact answer to a registry question: which named party is attached to this autonomous-system number in the captured APNIC record, and how is that record presently classified?

That answer is useful because number-resource analysis begins with exact identity. Similar-looking company names, spacing variants, and abbreviations can blur a comparison if the number itself is not fixed first. Here, AS139618 is the stable join between the APNIC record and the RIPEstat views. FY-AS-AP appears in both operational-data context and registry context, and the holder wording in RIPEstat matches the exact APNIC registrant. The consistency supports identification of the same recorded resource across the captured views.

The dates add another layer, but only within their stated meanings. APNIC gives 2019-08-28T09:48:19Z as the registration time and 2020-09-08T13:13:56Z as the last-changed time. Registration time marks the event represented by that field. Last-changed time marks the most recent change represented by the captured RDAP data. Neither timestamp, standing alone, describes what the ASN was doing on every day before or after it.

The active label is similarly specific. It belongs to the registry record. It says nothing by itself about whether routes are visible at a particular moment, how broadly they might be visible, or what services might sit behind them. A registry can continue to carry an active resource record even when a routing collector does not expose a current announcement. That is the central distinction in AS139618’s captured state.

The public directory name, Zhuhai FuYuanLeYu Technology Limited, connects the network-resource evidence to an existing company entry. The APNIC registrant spelling is more segmented: Zhu Hai Shi Fu Yuan Le Yu Technology Limited. The analysis does not need to smooth away that distinction or embellish it. The ASN, the FY-AS-AP name, and the exact recorded holder provide the evidence-bounded link. Beyond that link, the registry offers identity metadata, not a description of a present operating footprint.

Recorded status and observed routing answer different questions

A registry record and a routing observation occupy different evidentiary planes. APNIC RDAP records who is associated with AS139618 and labels the record active. RIPEstat’s AS overview, in the captured response, reports announced=false. The two values are not competing votes on one condition. They describe different conditions: the administrative state of a number-resource record and the observed state of public route propagation in the queried view.

Treating active as a synonym for visibly routing would collapse that distinction. So would treating announced=false as a negation of the registry entry. The APNIC record remains present under a named holder. The current RIPEstat observation exposes no announcement. Both statements can be true at once because neither source is answering the other source’s question.

This separation prevents a common analytical error: turning permission or registration metadata into proof of current operation. The APNIC status does not demonstrate that AS139618 is originating an IPv4 or IPv6 prefix in the captured routing view. It does not demonstrate a delivered product, a premises-based footprint, or a specific use of the number. For those questions, observed routing and additional direct evidence would be needed.

The reverse error is just as serious. A collector-bounded zero should not be expanded into a claim about the continuing legal, corporate, or administrative state of the registrant. The current route view does not rewrite the RDAP holder field. It supplies a time-stamped operational observation: the monitored surface exposed no route for AS139618 under the returned conditions.

Precision therefore depends on carrying both labels together. The record is active in APNIC RDAP. The ASN is marked announced=false in the captured RIPEstat overview. The useful finding is the gap between those statements, not an attempt to force one into the vocabulary of the other.

The routing snapshot at 2026-08-01T16:00:00Z

The current routing evidence has a defined observation time: 2026-08-01T16:00:00Z. At that time, the captured RIPEstat routing-status response returns a row of zeroes for AS139618. It reports zero IPv4 prefixes and zero IPv4 addresses. For IPv6, it reports zero prefixes and zero /48 equivalents. These are the quantities exposed by that response, not estimates of unseen activity.

Routing-status field Captured value
IPv4 prefixes 0
IPv4 addresses 0
IPv6 prefixes 0
IPv6 /48 equivalents 0
IPv4 peer visibility 0 of 328
IPv6 peer visibility 0 of 322
Observed neighbours 0

The consistency of the zeroes matters. There is no mismatch in which a prefix count is positive while address count is zero, or a visibility ratio is positive while the prefix list is empty. Within the captured RIPEstat responses, the overview says announced=false, routing status exposes no current prefixes, peer visibility is zero across each reported peer set, observed neighbours are zero, and the announced-prefix list is empty.

Consistency is not the same as completeness. Several aligned fields make the bounded observation clearer, but they do not expand the collector’s reach. They support the statement that the captured RIPEstat view exposed no current public routing surface for AS139618 at the stated time. They do not support a statement about every routing system, every possible vantage point, or every use that may not appear as a public announcement.

The timestamp is indispensable because routing evidence can change. A bare statement that an ASN “is not announced” can outlive the observation that justified it. Tying the zeroes to 2026-08-01T16:00:00Z keeps the claim auditable and allows a later observer to repeat the same query without pretending that two observations made at different times are simultaneous.

The snapshot also gives a disciplined stopping point. It is unnecessary to invent a reason for the measured silence. The data establishes the state returned at one observation time. Cause, intention, duration, and any activity beyond that observable surface remain separate questions.

What 0 of 328 IPv4 peers establishes

The IPv4 visibility field is more informative than a solitary zero because it carries its denominator. RIPEstat reports that 0 of 328 IPv4 peers saw routing for AS139618 in the captured view. The numerator says that none of the peers counted by the response exposed the ASN in that measurement. The denominator identifies the size of the IPv4 peer set against which the zero was calculated.

That ratio provides strong evidence inside its defined frame. It is not merely that one selected path lacked an entry. Across the 328 IPv4 peers represented in the returned metric, visibility was zero. Paired with zero IPv4 prefixes and zero IPv4 addresses, the ratio describes a uniformly silent IPv4 surface in the captured RIPE RIS observation.

The denominator also defines the boundary. Three hundred and twenty-eight peers are not a synonym for all routers, all networks, or the entire Internet. A route collector observes through the peers available to it and reports what those perspectives expose. The correct public statement therefore retains the observer: RIPE RIS did not expose IPv4 visibility for AS139618 across the 328 peers counted in this response.

Nothing in 0 of 328 identifies a cause. The ratio does not say whether a route was intended, whether a configuration existed elsewhere, or what the recorded holder expected the number to do. It does not distinguish among possible explanations. The measurement is valuable precisely because it need not be inflated into a causal account.

The ratio is also a useful baseline. If a later response reports a positive numerator, the change would establish that at least part of the then-reported peer set exposed IPv4 routing for the ASN at the later observation. Comparison would still require attention to time and denominator. A change from 0 of 328 to another fraction would combine two possible changes: visibility itself and the composition or size of the reported peer set.

For that reason, monitoring should preserve both sides of the fraction. Recording only “zero” discards scope. Recording only “328 peers” discards the observed result. The paired value, observation time, resource, and collector context form the smallest useful unit of evidence.

IPv6 is silent within a different measured frame

IPv6 has its own denominator. The captured routing-status response reports visibility from 0 of 322 IPv6 peers, alongside zero IPv6 prefixes and zero IPv6 /48 equivalents. It would be inaccurate to merge that figure with the IPv4 ratio or describe a single undifferentiated set of 650 peers. The two protocol families are returned as distinct measurements, with distinct peer counts and distinct resource quantities.

The IPv6 prefix count and /48-equivalent count answer related but not identical questions within the response. One counts visible prefixes; the other expresses visible IPv6 space in the response’s /48-equivalent measure. Both are zero for AS139618 at the observation time. The agreement removes any ambiguity about whether the captured view saw IPv6 space expressed in one field but not the other.

As with IPv4, 0 of 322 is a bounded collector result. It establishes silence across the IPv6 peers represented by this RIPE RIS view. It does not certify that no device or private context could use the number, and it does not convert a routing measurement into a conclusion about the company’s wider condition. The claim remains attached to the captured public-routing observation.

Keeping IPv4 and IPv6 separate also improves future comparisons. A later IPv6 signal could appear without an IPv4 signal, or the peer denominators could move independently. The 2026 snapshot supplies a clean dual baseline: zero in every returned resource count, 0 of 328 for IPv4, and 0 of 322 for IPv6.

The empty announced-prefix list

The announced-prefixes endpoint adds a direct list-level check. For AS139618, the captured current response contains an empty prefix list. There is therefore no current prefix in that response to enumerate, compare, geolocate, or interpret. The responsible reading stops at emptiness rather than filling the absence with an assumed route.

This empty list aligns with announced=false in the AS overview and with the zero IPv4 and IPv6 prefix counts in routing status. Each endpoint presents a different facet of the same captured condition: a Boolean overview, quantitative routing-status fields, and a list that contains no current entries. Their agreement strengthens confidence in the narrow current-state statement.

An empty current list does not erase historical observations. RIPEstat’s routing-status response separately returns a first-seen IPv6 prefix and a last-seen IPv6 prefix. Current-list emptiness and historical fields can coexist because they refer to different temporal views. One describes what the announced-prefix endpoint returns now; the others preserve bounded markers from observations represented in routing status.

Nor does the empty list reveal where a historical prefix might be visible under another origin, whether any resource is used outside public routing, or why AS139618 has no entry in the current result. None of those questions can be answered by absence alone. The empty response supports only a current, resource-specific conclusion.

List-level evidence has an additional practical advantage: it prevents a count from being mistaken for an unidentified route. Here, the count is zero and the list is empty, so there is no hidden item requiring a name. A later non-empty list would create a new object for verification—the exact prefix returned at that later time—without retroactively altering what the 2026 capture showed.

Zero observed neighbours is corroboration, not a topology map

The routing-status response also reports zero observed neighbours. In the context of the other fields, that value is unsurprising: a view that exposes no current announcement for the ASN also exposes no adjacent ASN relationship derived from that visible routing state. It is another internally consistent part of the captured result.

The word observed carries the boundary. Zero observed neighbours means the returned RIPEstat view did not identify neighbours for AS139618 under its current observation. It does not prove that the company has no external counterparties, no configured sessions, or no private connections. Those would be different claims requiring different evidence.

A positive neighbour field can provide relational context around a visible origin. A zero field cannot be inverted into a complete description of the registrant’s arrangements. There is no named ASN in the captured result to treat as an upstream, downstream, peer, or any other kind of counterparty. Assigning one would be invention.

For monitoring, the zero is still useful. It establishes a current baseline alongside the peer-visibility ratios. If a future observation reports one or more neighbours, that would be a material change in the public routing view and could be recorded as such. The later field would still describe observation, not a contractual interpretation.

The combination of empty prefixes, zero peer visibility, and zero observed neighbours gives the current surface its distinctive shape: there is no visible route object, no peer in the reported sets exposing it, and no observed adjacency to analyse. The shape is sparse, but it is not vague. Every part can be stated with a value and a scope.

Two historical markers, not a route diary

RIPEstat’s routing-status response retains two historical boundaries for AS139618. It lists 2001:df1:4580::/48 as the first-seen prefix, with first-seen time 2019-10-22T00:00:00Z. It lists 2405:84c0:ff80::/44 as the last-seen prefix, with last-seen time 2024-02-14T00:00:00Z.

These entries establish that the returned data associates AS139618 with historical IPv6 origin observations at those boundaries. They also show that the prefix attached to the first-seen field is not the same as the prefix attached to the last-seen field. That is as far as direct comparison can go without adding route records that the captured responses do not contain.

First seen should be read literally as the first observation represented by the field, not as proof of the first moment the prefix existed, the first moment anyone configured it, or the start of a continuous operating period. The field belongs to an observation system. It dates the beginning of what that returned historical marker exposes.

Last seen has the same discipline in the opposite direction. The 2024-02-14T00:00:00Z value is the last observation attached to 2405:84c0:ff80::/44 in the returned response. It does not, by itself, describe what happened immediately afterward. It cannot supply a reason, and it cannot establish what was visible from every possible vantage.

The two markers do not form a complete chronology. They do not enumerate every prefix that may appear in the underlying observation history, every interval of visibility, every change between the dates, or the relationship between the two IPv6 blocks. Drawing a line from the 2019 entry to the 2024 entry would create a continuous narrative that the captured fields do not provide.

Their value is narrower and more durable. They prove that the current zero is not the only temporal information in the response. AS139618 has historical observation boundaries in the returned RIPEstat data, while its announced-prefix list at the current capture is empty. Preserving both truths avoids two opposite mistakes: presenting silence as timeless, or presenting historical visibility as if it remained current.

Exact prefixes and timestamps matter here because summaries can easily blur boundaries. “Previously announced IPv6” is directionally useful but incomplete. Naming 2001:df1:4580::/48 with its first-seen field and 2405:84c0:ff80::/44 with its last-seen field lets a later check compare like with like and identify whether the returned boundaries have changed.

Five timestamps, each with a separate meaning

The evidence places five timestamps around AS139618, and none should be substituted for another. The APNIC registration time is 2019-08-28T09:48:19Z. The first-seen routing marker is 2019-10-22T00:00:00Z. APNIC’s last-changed time is 2020-09-08T13:13:56Z. The last-seen routing marker is 2024-02-14T00:00:00Z. The current routing observation is 2026-08-01T16:00:00Z.

Their order is visible, but order alone does not create causation. The registration timestamp precedes the first-seen marker; that does not explain the interval between them. The RDAP last-changed timestamp falls between the first- and last-seen routing markers; that does not show that the registry change affected routing. The last-seen marker precedes the 2026 zero observation; that does not identify what occurred in the intervening period.

Each timestamp belongs to a field with its own source logic. Registration and last changed describe the APNIC record. First seen and last seen describe returned RIPEstat historical boundaries. The 2026 time anchors the current routing-status snapshot. Mixing these clocks would turn a set of auditable observations into an unsupported corporate narrative.

A careful timeline therefore uses verbs that match the fields: APNIC registered, APNIC last changed, RIPEstat first saw, RIPEstat last saw, and the captured routing status reported. It avoids stronger verbs such as began, ended, stopped, resumed, or remained continuously, because those would add events or continuity not established by the returned data.

The registry record persists while the running surface is quiet

The APNIC record gives AS139618 durable referential identity. A reader can resolve the number to FY-AS-AP, the recorded registrant, country code CN, active status, and two registry timestamps. That identity is present even though the captured RIPEstat operational view exposes no current route.

The running surface is tested differently. It is represented by announced status, visible prefixes and address quantities, peer visibility, the current prefix list, and observed neighbours. For AS139618, every current routing indicator in the captured responses points toward the same bounded state: no visible announcement at 2026-08-01T16:00:00Z.

The contrast is not evidence that one system is wrong. A registry is a recordkeeper for the number and its associated metadata. A routing collector records what its observation points expose. The holder field may persist while the measured routing surface changes, because identity continuity and route visibility are not the same property.

This is why the ASN remains analytically meaningful even when the route list is empty. The number provides the key around which current observations, historical markers, and future measurements can be organised. If the record disappeared from discussion whenever visibility fell to zero, the continuity needed to compare those states would be lost.

At the same time, durable identity must not be mistaken for a durable operating claim. APNIC’s active status does not populate the empty prefix list. It does not turn zero peer visibility into positive visibility. It does not provide a substitute neighbour or infer a present use. The running evidence must stand on its own.

The most accurate description is consequently asymmetrical: identity evidence is positive and specific, while current routing evidence is negative and bounded. APNIC says who is recorded. RIPEstat says what its captured view does not currently expose. The gap between them is the finding.

Number-resource accountability begins with separable claims

An autonomous-system number is most useful as evidence when its identity, status, and observed use are recorded separately. For AS139618, identity is the named registrant and FY-AS-AP label. Registry status is active. Observed current route visibility is zero in the captured RIPEstat fields. Historical boundaries are the two exact IPv6 prefix-and-time pairs.

Separating those claims makes accountability possible without turning analysis into accusation. A reviewer can ask whether the registered name is still the name presented by APNIC, whether the last-changed timestamp moves, whether the announced flag changes, and whether visibility or prefix fields become positive. Every question has a corresponding observable field.

Accuracy is central because number resources need stable identifiers and clear attribution. The match between AS139618, FY-AS-AP, and Zhu Hai Shi Fu Yuan Le Yu Technology Limited across the captured registry and overview views reduces ambiguity about which record is under examination. The country code CN locates the registry entry’s recorded country field, not a measured route endpoint or physical site.

Operational continuity is a separate axis. Continuity cannot be declared from a persistent registration alone, just as its absence cannot be established from one silent snapshot. Instead, continuity is tested through repeated observations: does the same holder remain recorded, do current routes reappear, do peer-visibility values change, do historical boundaries move, and does the prefix list acquire entries?

Security-relevant metadata is another reason to preserve exact record state, but the present evidence does not describe misuse or harm. The prudent act is to retain the handle, holder, status, and timestamps accurately so that future changes can be recognised. A record that is reduced to a company name without its number or dates loses much of its audit value.

The current gap therefore produces a responsibility to phrase claims carefully. The recorded holder can be named because APNIC names it. The routing silence can be described because RIPEstat measures it. Motive, cause, corporate condition, and off-view activity cannot be assigned because none is contained in the available evidence.

This approach resists two opposite category errors. Registry status is not treated as proof of present route delivery, and a silent collector view is not treated as authority to erase the registered identity. The number remains in the registry record; the running observation remains the test for claims about visible routing.

Operational continuity is a set of questions, not an assumption

The gap between an active record and a silent route view raises legitimate continuity questions. Is the recorded holder field still accurate at the time of a future check? APNIC’s captured record answers yes for the present capture, but the question should be asked again if the record changes. Does AS139618 become visible in later RIPEstat observations? The 2026 snapshot cannot answer for a later date.

Another question concerns the historical boundary. Does a repeated routing-status query continue to name 2405:84c0:ff80::/44 at 2024-02-14T00:00:00Z as the last-seen marker, or does a newer observation replace it? A moved boundary would be evidence of later visibility. An unchanged boundary would only show that the returned field had not advanced at that later check.

The first-seen marker should also be retained. If a future response continues to name 2001:df1:4580::/48 at 2019-10-22T00:00:00Z, the historical lower boundary remains stable in the returned data. If it changes, the change should be recorded without assuming that the earlier capture was erroneous; observation systems and returned histories can evolve.

Peer scope presents another continuity question. Are the denominators still 328 for IPv4 and 322 for IPv6? If they change, a later visibility ratio must be interpreted in its own frame. A zero across a larger, smaller, or differently composed peer set is not numerically identical to the 2026 baseline, even when the numerator remains zero.

The empty announced-prefix list offers the most direct repeatable check. Does the endpoint remain empty, or does it return one or more exact prefixes? If an entry appears, the correct next step is to record that prefix and its observation time, then check whether routing-status and overview fields align. It is not to project a full operational story from the first positive signal.

Zero observed neighbours can be monitored in the same manner. A later positive value would add routing context, but the identities and meanings of any returned neighbours would need their own verification. The mere existence of an observed adjacency would not establish the nature of an arrangement.

These questions keep the analysis open without making it speculative. They identify what can be measured next, which values would count as change, and which interpretations remain out of reach. Continuity is built from comparable observations, not inferred from the emotional force of either “active” or “zero.”

A repeatable monitoring method

AS139618 can be monitored with a compact method that preserves scope. Begin with the resource itself, not the company name: AS139618. Record the observation time in UTC. Then collect the APNIC RDAP identity fields, the RIPEstat AS overview, routing status, and announced-prefix response for that same ASN. Keeping the resource constant prevents similarly named organisations or unrelated numbers from entering the comparison.

From APNIC RDAP, preserve the handle, network name, exact registrant spelling, country code, status, registration time, and last-changed time. These fields form the registry baseline. A later change should be described field by field. If only the last-changed time moves, that fact alone does not disclose which substantive field changed; the record values themselves must be compared.

From the AS overview, capture the holder string and announced flag. The holder string provides a cross-check against the RDAP identity. The announced flag supplies a compact current-state indicator. If the holder text diverges from RDAP in a future capture, the difference should be reported as a difference between views rather than silently normalised.

Routing status requires more detail. Record IPv4 prefix count, IPv4 address count, IPv4 visible peers and total peers. Separately record IPv6 prefix count, IPv6 /48 equivalents, IPv6 visible peers and total peers. Preserve observed-neighbour count. Finally, retain the exact first-seen prefix and time and the exact last-seen prefix and time returned in the historical fields.

The announced-prefix list should be saved as a list, including its empty state. “No data noted” is weaker than “the captured response contained an empty list,” because the former could describe a collection mistake. A list entry, if one appears later, should be copied exactly and compared with the quantitative routing-status values.

A clean monitoring row for the 2026 capture would therefore read: AS139618; 2026-08-01T16:00:00Z; APNIC active; RIPEstat announced=false; IPv4 prefixes 0; IPv4 addresses 0; IPv4 visibility 0/328; IPv6 prefixes 0; IPv6 /48 equivalents 0; IPv6 visibility 0/322; observed neighbours 0; current announced-prefix list empty. Historical markers should sit in adjacent fields rather than being blended into the current row.

Comparison should proceed by layers. First ask whether identity changed. Second ask whether registry status or timestamps changed. Third ask whether the announced flag changed. Fourth compare current prefix and address quantities. Fifth compare peer-visibility numerators and denominators. Sixth compare neighbours and the exact prefix list. Seventh check whether historical boundaries advanced or were revised.

That order prevents a positive signal in one field from overwriting all the others. Suppose a later announced flag becomes true while the prefix list remains empty in the captured response. The result would be a discrepancy to investigate, not permission to invent the missing route. Suppose a later list becomes non-empty while peer visibility remains zero. Again, the correct finding would be the mismatch among returned views at that time.

Time alignment matters. Responses gathered at materially different moments can describe different routing states. A monitoring record should therefore retain capture times and avoid presenting asynchronous values as one instantaneous truth. The 2026 evidence is coherent because its routing-status observation is explicitly anchored and the associated current views are treated as one captured set, not as eternal fields.

Raw ratios should never be reduced to adjectives alone. “Invisible” is concise, but 0/328 and 0/322 are auditable. “No routes” is readable, but zero IPv4 prefixes, zero IPv6 prefixes, and an empty announced-prefix list show how the statement was formed. Exact fields make later correction possible.

The method also needs a rule for negative evidence: absence narrows what can be claimed; it does not generate an explanation. If a field is zero, record zero. If a list is empty, record empty. If no neighbour is observed, record none in the captured view. Do not fill those spaces with presumed corporate decisions or unobserved network arrangements.

A concise repeatable checklist is enough:

  • Resolve AS139618 in APNIC RDAP and retain the exact holder and status fields.
  • Note the RDAP registration and last-changed timestamps without treating either as a routing event.
  • Query the RIPEstat overview and preserve both holder text and announced status.
  • Capture routing status with its UTC observation time.
  • Keep IPv4 and IPv6 counts and peer denominators separate.
  • Save the observed-neighbour count and the exact announced-prefix list, including an empty result.
  • Preserve the first-seen and last-seen prefix-time pairs as historical boundaries.
  • Compare one field at a time and attribute every conclusion to the captured view.

This procedure is intentionally conservative. Its aim is not to maximise the number of conclusions. Its aim is to make each conclusion reproducible and to expose exactly what new evidence would be needed before the interpretation could widen.

What the network-resource evidence cannot supply

The captured records establish a directory-linked company name, an ASN identity, registry metadata, a current routing observation, and two historical boundaries. They do not describe the company’s premises, equipment, staff, product catalogue, contractual arrangements, or the purposes for which the number may have been obtained or retained. Those subjects lie outside the fields being examined.

Country code CN is a registry attribute. It should not be converted into a map of operations or a statement about where any equipment sits. China / APNIC service region situates the registry context; it does not add measured geography to the routing data.

The Regional ISP classification likewise supplies navigation context, not proof of a currently delivered service. Taxonomy cannot fill an empty prefix list, identify a counterparty, or establish how AS139618 is used beyond the observed public routing surface. The classification should not carry more evidentiary weight than the underlying record.

No current route means there is no visible prefix in the captured list from which to derive a location, path, or connected network. Zero observed neighbours means there is no adjacency in the returned view from which to build even a bounded relationship analysis. Any diagram claiming to show an AS139618 topology would therefore exceed the evidence.

The historical prefixes do not solve that problem. 2001:df1:4580::/48 and 2405:84c0:ff80::/44 are exact, valuable observations, but they remain attached to first-seen and last-seen boundary fields. Without additional route records, they cannot support a full path history, a complete sequence of origins, or a description of how the recorded holder used them.

The data also offers no motive. It cannot say why the current view is silent, whether the state was expected, or what the recorded holder plans. Silence in a measurement is not a statement from the registrant. Treating it as one would substitute narrative for evidence.

Most importantly, there is no basis for a broad judgment about the company. A number-resource record can be examined without turning its routing state into a proxy for every dimension of corporate activity. The scope of the finding is AS139618’s registered identity and its captured public-routing visibility, no more.

This boundary is not a weakness. It is what makes the conclusion reliable. Readers can see where the evidence ends, future observers can repeat the same checks, and any new claim must arrive with a field or source capable of supporting it.

Why collector scope belongs in every conclusion

Routing observations acquire meaning through vantage. RIPEstat’s captured routing-status view reports what RIPE RIS exposed for AS139618, including the number of peers represented in each protocol-family metric. Leaving out that frame would make 0/328 and 0/322 sound like declarations from the Internet as a whole.

The phrase “not announced” also needs its context. In the captured AS overview, announced=false is a returned field. Paired with routing status and an empty current list, it supports a strong description of the RIPEstat view. It should not be restated as an unqualified claim that no possible observer anywhere could see anything associated with the ASN.

This does not make the measurement trivial. Collector-bounded evidence is the substance of public routing analysis. The discipline lies in retaining its bounds, not dismissing it because it is bounded. Zero across 328 IPv4 peers and 322 IPv6 peers is a clear result across the peer sets named by the response.

The current conclusion should therefore contain four elements whenever condensed: the resource AS139618, the observer RIPE RIS through RIPEstat, the observation time 2026-08-01T16:00:00Z, and the returned zero values. Removing any one makes the claim harder to audit.

Sources