Summary

  • The RIPE Database records AS12637 under the name SEEWEB and lists SEEWEB s.r.l. in a registrant role; PeeringDB carries a Seeweb profile for the same ASN; and RIPEstat reported 45 prefixes observed for AS12637 at latest_time 2026-08-10T00:00:00 while excluding routes seen by fewer than 10 RIS full-feed peers. Together, those records support a public network-identity link.
  • That alignment does not establish ownership of a facility or prefixes, route authorisation, present network design, capacity, customers, performance, uptime, exclusive control or company-wide operational authority. A dated Frosinone facility interior remains separate visual context and contributes no evidence to the network claims.

The evidence problem comes before the company story

A photograph of a facility and a record for an autonomous system number can both look authoritative. One appears tangible, while the other appears precise through its number, name, status and formal-looking fields. Put the two beside a company name and it is easy to tell a story in which the building, the network and the company all become one controlled system. The story may feel coherent, but coherence is not proof.

The more useful question is narrower: what does each record actually establish? The linked BTW directory entity identifies the company subject of this article as SEEWEB s.r.l. The RIPE Database records an autonomous-system identity. PeeringDB presents profile information supplied for that network identity. RIPEstat reports what its collectors observed at a stated time and above a stated visibility threshold. The dated Frosinone facility interior provides visual context only. These are five different objects, maintained for different purposes, on different timetables and with different limits.

Keeping them separate does not make the record weaker. It makes the conclusion testable. A reader can trace which statement comes from which kind of evidence and can see where another record would be needed. The company and AS12637 align across public identity records, yet that alignment stops short of proving who controls a particular building, who owns an address block, who authorises a route, how a network is engineered or what level of service it delivers.

This boundary matters because infrastructure decisions often turn on verbs that sound interchangeable but are not. To be named, registered, listed, observed, operated, authorised, owned and controlled are different relationships. A registry can name a registrant without proving property ownership. A directory can carry a policy label without measuring whether that policy is executed. A collector can see a route without deciding whether the announcement is authorised. An image can show a place without revealing the current equipment or decision rights inside it.

For a non-specialist reader, the practical lesson is simple: begin with the question, then choose the record designed to answer it. If the question is public ASN identity, the registry is relevant. If it is how a network presents itself to the interconnection community, a peering directory is relevant. If it is what announcements were visible through a particular observation system at a particular time, a routing observation is relevant. If it is current ownership, capacity, performance or operational authority, none of those records is sufficient by itself.

Five records, five different jobs

The first record is the linked directory entity, SEEWEB s.r.l. Its job in this article is editorial identity: it tells the reader which company object the article is about. That link prevents a company name from drifting into a generic brand or an unrelated organisation with a similar label. It does not, simply by existing, prove a technical relationship. Directory identity is the subject anchor, not a substitute for network evidence.

The second record is the RIPE RDAP autnum object for AS12637. An ASN is an identifier used to distinguish an autonomous routing domain in Internet routing. The RDAP object gives structured registry information about that identifier. It is the appropriate place to ask what name the registry records, which number the object covers, what status it carries and which organisation appears in a registrant role. It is not a deed to a building, a corporate-standing certificate or an operating manual.

The third record is the PeeringDB profile returned for ASN 12637. PeeringDB is a directory used by the interconnection community. Its profile fields describe how a network presents itself in that directory: its name, site link, type, scope, general policy and profile status. Those fields help readers compare identity across records. They remain profile metadata, not an independent measurement of topology, traffic, capacity, customers, uptime, performance or policy execution.

The fourth record is the RIPEstat announced-prefixes result. It is an observation derived from routing data, not a claim about corporate identity. It answers a bounded question: how many prefixes met the service's observation conditions for the specified ASN at the specified latest time? Because the result applies a visibility threshold, it also describes what its count excludes. It does not decide ownership or authorisation and does not promise that the same view continued after the timestamp.

The fifth record is the dated Frosinone facility interior used as accompanying context. Its role is deliberately separate. None of the registry, directory or routing records connects that interior to current equipment, ownership, capacity, customers, performance, uptime, route authority or control of AS12637. The image therefore adds no network fact to the analysis. It should not be used to make an abstract ASN feel like proof of a particular physical control arrangement.

These distinctions protect the reader from a common pattern of evidence inflation. The process begins with one supported statement, such as “the registry names SEEWEB for AS12637.” It then moves, without a new record, to “the company owns the network,” then to “the company owns the facility,” and finally to “the facility currently delivers the observed services.” Each step adds a different relationship. Unless a record directly supports that relationship, the chain is not evidence; it is a sequence of assumptions.

What the RIPE registry object records

The RIPE RDAP autnum object for AS12637 names the object SEEWEB. Its startAutnum and endAutnum are both 12637, so the object concerns that single ASN. The object carries the status “active” and lists SEEWEB s.r.l. in a registrant role. Those are precise registry facts, and they establish the strongest direct identity connection in the public record used here.

The word “active” must stay inside its registry context. It describes the status field on the autnum object. It does not by itself establish that SEEWEB s.r.l. has a particular current corporate status under company law, owns a particular building, owns every resource associated with the ASN or presently exercises every operational decision connected with routes carrying that number. A registry is a recordkeeper. Its fields are valuable because they create a stable, queryable identity record, not because they settle every legal and operational question.

The registrant role needs the same discipline. It records SEEWEB s.r.l. in that role for the object. It does not turn the role label into evidence of property title or exclusive control. “Registrant” can be reported as the relationship shown by the record. “Owner of the pictured facility,” “owner of all observed prefixes” or “sole operator of every route” would be different claims requiring different proof.

The RDAP output also indicates that it is filtered. That matters because the response a reader sees is a published view of registry data rather than a complete account of every possible relationship, historical change or operational process. Contact-role content and remarks in the object are registry-published declarations. They can be quoted or paraphrased with attribution, but they should not be described as the result of an independent current examination of the network.

The object remarks describe web hosting, colocation and cloud services. They also discuss routing policy in carefully limited language. The remarks warn that import and export attributes are only an upper bound and should not be interpreted literally. They say filters use RIPE routing-registry data as much as feasible. Both qualifications are important. Removing “upper bound” or “as much as feasible” would turn a bounded declaration into a stronger promise than the object makes.

For a business reader, an upper bound is not a description of what always happens. It marks the outside of what may be represented, not a verified inventory of every current relationship. “As much as feasible” likewise signals a method with an explicit practical limit. It does not demonstrate which inputs were used for a particular route, whether every filter was current at a particular moment, or whether every policy was applied without exception. The remarks are informative because they describe an approach. They are not proof of execution.

This is an example of why exact wording matters more than confident summary. It would be easy to reduce the registry remarks to “Seeweb filters routes using the RIPE routing registry.” That sentence drops the stated limit. A more faithful account is that the AS12637 object says peer filters use RIPE routing-registry data as much as feasible and separately warns that its import and export attributes are only an upper bound. That formulation tells the reader both what is declared and how far the declaration reaches.

What PeeringDB adds as a self-described profile

PeeringDB returned one profile for ASN 12637. The profile is named Seeweb, links to the seeweb.it site, classifies the network as “Content” with “Regional” scope, gives the general policy as “Open” and shows the profile status as “ok.” The ASN creates an exact bridge to the RIPE registry object, while the name provides a human-readable bridge to the company subject.

The profile adds useful context, but its evidence class is different. A PeeringDB entry is directory-profile metadata. It tells readers how the network is represented in that directory. “Content,” “Regional” and “Open” are profile fields, not measurements. “Ok” is the profile status, not a finding that the network, every service or every facility was operational and healthy at the time a reader opened the record.

This distinction is especially important for a general policy field. “Open” may help another network understand the profile's stated posture toward interconnection. It does not establish that every request will be accepted, that every technical or commercial condition is satisfied, that a session is currently running, or that a stated policy is executed in every case. Those outcomes depend on decisions and conditions that a profile label cannot show.

The scope field also needs restraint. “Regional” is the exact directory classification. It should not be converted into an independently verified map of where infrastructure exists, where customers are located or where traffic flows. A label can organise a directory without functioning as a geographic measurement. The same principle applies to the “Content” type. It is useful classification metadata, but it is not a complete business description or a technical inventory.

The profile's link to seeweb.it strengthens name alignment, not operational proof. A site link helps show that the profile intends to represent Seeweb. It does not verify every claim a linked site might make, and this article does not import facts from that site. The public record used here remains deliberately narrow: the relevant fact is that the PeeringDB profile links there.

PeeringDB therefore performs a valuable middle role. The RIPE object supplies registry identity. PeeringDB supplies an interconnection-community profile for the same number and a matching name. When the two agree, confusion is reduced. Yet agreement between two identity records still does not answer questions about current network design, facility ownership, capacity, traffic, customers, performance, uptime or exclusive control.

The temptation to overread the profile is strongest when a field appears numerical or operational. A reader may assume that anything stored in a network directory has been measured. That assumption is unsafe. Unless a value is explicitly produced by an observation method and presented with its conditions, it should be treated as profile information. This article therefore does not use PeeringDB notes or traffic-related fields to make claims about scale. It also does not repeat an affiliation or facility-count assertion as an independently established fact.

What the routing observation establishes

The RIPEstat announced-prefixes result belongs to a third evidence class: observation. In the time-stamped snapshot used for this analysis, RIPEstat reported 45 prefixes observed for AS12637 at latest_time 2026-08-10T00:00:00. The same result states that routes seen by fewer than 10 RIS full-feed peers are excluded. The count, timestamp and threshold must travel together.

The number 45 should not be read as an asset inventory. It is the number of prefixes that appeared in this particular announced-prefixes result under its stated conditions. It does not say who owns the underlying address space. It does not say that control is exclusive. It does not establish that each announcement was authorised. It does not show that every route remained visible after the timestamp. It does not measure capacity, performance, uptime or service quality.

The timestamp prevents a snapshot from becoming a permanent statement. At 2026-08-10T00:00:00, the retained result reported the stated count. That wording is intentionally different from “AS12637 announces 45 prefixes” without a time. Routes can change, collector views can change and the service's response bytes can change. A dated observation is useful precisely because it can be compared with another dated observation later; it should not be stretched into an undated truth.

The visibility rule matters just as much as the time. Routes seen by fewer than 10 RIS full-feed peers were excluded from the result. This means the observation does not purport to include every route that might have appeared somewhere in the routing system. It applies a threshold intended to define which routes enter the returned set. The result therefore describes visibility through a particular observation method, not the entire possible routing universe.

For non-specialists, a prefix is a block of IP addresses described for routing. An announcement is a statement, visible through BGP data, that a route to that prefix is being presented under an ASN. Seeing the announcement is evidence that the control plane exposed that route to the observing system. It is not the same as proving the legal right to announce it, the commercial relationship behind it, or the condition of the data path that would carry traffic.

This is where the idea of running systems becomes useful. A registry tells us what is recorded. A routing observation tells us something about what was visible in operation. The observation is closer to running code than a static profile, but it still has a boundary. It shows the result of one observation process, not the configuration files, authorisation documents, internal decision rights or end-to-end service outcome behind every route.

The difference can be expressed as three questions. Identity asks, “Which ASN is associated with which recorded name?” Observation asks, “What announcements met the collector's conditions at this time?” Control asks, “Who had the authority and practical ability to make, change, withdraw and sustain those announcements?” The sources used here answer the first question and part of the second. They do not fully answer the third.

Where the three network records align

The RIPE registry object, the PeeringDB profile and the RIPEstat observation converge on AS12637. The registry names SEEWEB and lists SEEWEB s.r.l. in a registrant role. PeeringDB returns one profile named Seeweb for the same ASN. RIPEstat reports a time-bounded set of observed announced prefixes for that ASN. This agreement supports describing Seeweb and AS12637 as an aligned public network identity.

The word “aligned” is doing careful work. It means the records point consistently to the same number and compatible names. It does not mean the records are interchangeable or that one verifies all the fields of the others. RIPE is acting as a registry publisher in the RDAP result. PeeringDB is presenting a directory profile. RIPEstat is reporting a routing observation. Their agreement is strongest on identity and weakest on questions none of them is designed to decide.

Cross-record alignment can reduce one kind of risk: mistaken identity. If the ASN, name and linked site conflicted, a reader would need to resolve that discrepancy before writing about the network. Here, the records align well enough to support the public identity connection. But reducing identity risk does not remove control risk. A consistent label can still sit above changing contracts, delegated operations, shared facilities, third-party transport or other arrangements that these records do not describe.

The negative conclusion should remain beside the positive one: Seeweb and AS12637 align as a public network identity, and this does not establish site-level or company-wide operational control. Separating those clauses would make it too easy for the positive identity statement to be quoted without its limit. The limit is not an afterthought; it is part of the conclusion.

The same rule applies to physical context. The dated Frosinone interior is not a fourth form of network proof. It does not connect the 45 observed prefixes to equipment at that location. It does not show who owns the building or any asset. It does not establish present operations, customers, capacity, performance or uptime. No inference about AS12637 becomes stronger merely because the article has a facility image.

For readers assessing hosting infrastructure, that may feel frustrating. Physical infrastructure matters, but the public records used here do not provide the chain needed to connect a particular place to a particular set of current network decisions. A strong site-level claim would need evidence that names the site, the responsible entity, the relevant function and the time period. A strong route-control claim would need evidence about authority and operation. Identity alignment alone supplies neither chain.

Why recordkeeping should not be mistaken for sovereignty

Internet registries are essential because unique identifiers and accurate records allow different networks to coordinate. That importance can encourage a mistaken belief that the registry is the ultimate source of every right and every operational fact. It is not. The registry records relationships within its remit. Legal rights, contracts, property, delegated authority and running configurations may be evidenced elsewhere.

Calling a registry a recordkeeper is not dismissive. Recordkeeping is a powerful function. It creates continuity across personnel changes and makes a public identity query possible. It also imposes a discipline on language: the record can be described exactly, while claims outside its remit remain open. That is more reliable than using the prestige of the registry to settle questions it does not answer.

The AS12637 object illustrates this balance. It gives a clear handle, name, status and registrant-role organisation. Its remarks provide attributed service and filtering descriptions, including explicit limits. A careful reader can learn a great deal from those fields. The same reader should decline to infer facility title, corporate standing, current topology or exclusive route authority from them.

Operational reality must also be respected. A registry record that remains unchanged does not prove that every system behind it remains unchanged. Conversely, a routing observation can show visible activity without resolving every administrative or legal relationship. The reality layer comes from comparing what is recorded with what is observed, while preserving the uncertainty between them.

This is why the RIPEstat result is useful even though it does not prove ownership or authorisation. It demonstrates that the analysis is not based only on names. There was a dated routing observation associated with AS12637 under a stated collection threshold. It brings evidence of visible operation into the discussion. It still cannot carry the reader all the way to a conclusion about who held every relevant decision right.

The most trustworthy account therefore resists two opposite errors. Registry determinism treats the record as total proof. Operational romanticism treats visible routing as self-explanatory and ignores the administrative record. The bounded reading uses both: the registry for recorded identity, the observation for time-specific visibility and explicit uncertainty for everything not shown.