Summary

  • APNIC’s RDAP record identifies AS136022 and associates the administrative object with Janani Technology. Its active label belongs to the registry object; it does not establish routing, interconnection or service health.
  • The captured PeeringDB profile contains one exact ASN row but no exchange-connection rows and leaves several coordination fields empty. Those are missing participant declarations, not proof that peering, address resources or operational activity are absent.
  • A frozen RIPE RIS response reports qualifying IPv4 and IPv6 routes within its listed peer set at 7 August 2026, 00:00 UTC. The figures retain their timestamp, denominator and low-visibility exclusion and cannot support claims about universal reachability, authorisation, capacity, resilience or customer service.

One identifier, three different questions

An autonomous system is a network, or a group of networks, that presents a common routing policy to the wider internet. Its autonomous system number, usually shortened to ASN, provides a unique public identifier. Networks use the Border Gateway Protocol, or BGP, to exchange information about which address ranges can be reached through which routing domains.

AS136022 is the join key across the records examined here. It helps a reader distinguish Janani Technology’s network object from a similar company name, an unrelated service or another routing domain. Yet a shared identifier does not make every surrounding field equivalent.

The APNIC record asks who is associated with the number resource in an administrative registry. The PeeringDB record asks what a participant has chosen to publish in a coordination directory. The RIPE Routing Information Service, or RIS, asks what qualifying routes its collectors saw under a stated method. One object can therefore have a clear registry identity, a sparse directory profile and observable routes without any of those facts contradicting the others.

This distinction matters during both routine verification and an incident. A registry entry can direct a question to the recorded organisation. A coordination profile can reveal declarations worth checking. A collector view can show that routes appeared at defined vantage points. None alone answers whether a customer application worked, why a path was selected or whether a physical dependency survived a failure.

APNIC provides the administrative ledger

Registration Data Access Protocol, or RDAP, is a structured way to retrieve public registry information about internet number resources. The APNIC RDAP response covers exactly autonomous-system number 136022: both its starting and ending number are 136022, and its handle is AS136022. The object name is JANANITECHNOLOGY-AS-AP, and Janani Technology appears among the entity names in the response.

The record labels the object active. It also records a registration event at 3 February 2019, 08:31:56 UTC, and a last-changed event at 18 January 2021, 03:52:25 UTC. These are useful administrative facts. They make the number resource identifiable and provide a reviewable event history.

They are not measurements of the running network. Active does not say that a router is powered, that a prefix is visible, that a BGP session is established or that an application is available. A registry can accurately preserve the identity and history of an ASN while the operating state changes independently.

That is the registry’s strength as a ledger rather than a weakness. Unique numbers and traceable records make coordination possible. Operators can begin with the correct object and avoid assigning a route or incident to the wrong organisation. The disciplined next step is to consult evidence designed for the operational question, not to stretch an administrative label beyond its purpose.

A sparse PeeringDB profile is a declaration gap

PeeringDB is a participant-maintained coordination directory used by networks and interconnection facilities. Its captured response contains one row for ASN 136022, record id 40097, named Janani Technology. The row carries the profile status ok and an updated timestamp of 4 April 2026, 16:50:22 UTC.

The captured profile is notably sparse. It contains no netixlan rows, which are the records PeeringDB uses for network connections on exchange LANs. Its website, network type, general peering policy, IRR AS-set and IPv4 and IPv6 prefix-count fields are empty or null.

Those fields describe the response, not the entire network. No exchange row means that this particular profile supplied no such declaration in the captured data. It does not prove that Janani Technology has no exchange presence, no bilateral interconnection, no private connection or no peering elsewhere. An empty policy field does not establish whether the operator follows an open, selective or restrictive policy. Empty prefix-count fields do not prove that the ASN originates no address space.

The same caution applies to the profile’s ok status. It is a status attached to the directory row, not BGP-session telemetry or a health check for equipment and services. The directory can help a network publish coordination details, but it does not continuously observe every session or route.

Sparse records are still useful when handled honestly. They tell a prospective peer or investigator which public declarations are unavailable and therefore which questions require another authorised source. They also prevent a mistaken inference in the opposite direction: a richly populated directory record would remain a declaration until session, route or traffic evidence confirmed the relevant operating state.

What the frozen RIPE RIS response observed

RIPE RIS collects BGP information from participating observation points. The routing-status response used here is a frozen snapshot with query_time set to 7 August 2026, 00:00 UTC. Every conclusion below is limited to that dated response.

Within that response, qualifying routes for resource 136022 were visible to 326 of 327 listed IPv4 full-feed RIS peers and 320 of 320 listed IPv6 full-feed peers. The announced-space fields reported one IPv4 prefix representing 256 addresses and two IPv6 prefixes representing two /48 networks.

The endpoint also reported one observed neighbour. That value belongs to the collector product and its model. It is not a count of direct commercial peers, contracts, exchange sessions, facilities or physically independent paths. A relationship may be unobserved from the available collectors, and an observed routing neighbour need not describe the commercial or physical dependency a reader has in mind.

The response states that routes seen by fewer than ten RIS full-feed peers are excluded. Its visibility figures therefore describe the routes that qualified for the returned view. A route below that threshold could be absent from the result even if it appeared at some vantage points. Conversely, appearance at every listed peer in one address family would remain a statement about that collector set, not the entire internet.

This boundary is essential. The frozen snapshot can support a precise claim that qualifying routes were observed broadly within the listed RIS peer denominators at the stated query time. It cannot prove universal reachability, route authorisation, path preference, low latency, spare capacity, resilience, uptime or the condition of a service behind those routes.

Query time, first seen and last seen remain separate

The routing response includes several time fields, each attached to a different meaning. Its query time is 7 August 2026, 00:00 UTC. Its last-seen field names 103.134.41.0/24, origin 136022, at that same timestamp. Its first-seen field names 103.134.42.0/24, origin 136022, at 13 February 2019, 16:00 UTC.

The matching query-time and last-seen timestamps do not merge the two fields. Query time describes the returned routing-status context. Last seen belongs to one prefix field selected by the endpoint. First seen is another endpoint-defined historical field for a different prefix. Without route history designed for continuity analysis, the three values should not be converted into a claim about when the network started, stopped or changed an announcement.

Keeping the fields distinct also prevents accidental ownership or authorisation claims. A collector seeing a prefix with an origin ASN does not by itself prove that the announcement was authorised by the address holder or covered by a valid route-origin authorisation. Those questions require their own registry and security evidence.

How readers can verify the next layer

A useful verification sequence begins with the ASN. Confirm that AS136022 is the intended network object and that the APNIC identity and directory entity point to the same Janani Technology record. This protects the rest of the investigation from a name collision.

Next, inspect the administrative record for the exact number range, object name, entity name and event history. Use those fields to establish the registry identity and coordination boundary. Do not use them as a substitute for routing evidence.

Then examine PeeringDB for declarations that are actually present. In this captured response, the absence of exchange rows and policy fields becomes a list of open questions. An authorised operator can check internal configuration, contracts and session state. A prospective peer can request the relevant coordination details. A public reader should leave those matters unresolved rather than filling the blanks with assumptions.

For a routing question, preserve the collector product, query time, address family, peer denominator, threshold and exact prefixes. Compare another suitable observation source when the decision requires broader confidence. For an authorisation question, examine the applicable route-origin and registry records. For a customer-service question, add end-to-end application tests and time-matched service evidence.

Each step narrows uncertainty without making one source carry the burden of another. APNIC registration, the PeeringDB profile and the frozen RIPE RIS snapshot are different evidence layers; none alone proves a live peering session, universal reachability, route authorisation, capacity, resilience or customer service.

What the public record cannot establish

The source set supports a focused account of Janani Technology’s ASN identity, the contents of a sparse coordination profile and one frozen collector observation. It does not establish the company’s services, operating geography, customer base, facilities, equipment, upstream ownership, business scale or market position.

It also does not establish exchange presence, a route-server relationship, session state, traffic volume, throughput, latency, physical diversity, fault isolation or service performance. No outage conclusion follows from an empty PeeringDB field. No continuity conclusion follows from a visibility ratio. No capacity conclusion follows from an announced prefix count.

The public records are most valuable as a reality layer: named objects, stated declarations and bounded observations that a responsible reader can compare. The accurate conclusion is deliberately narrow. APNIC associates AS136022 with Janani Technology in its administrative record; the captured PeeringDB profile supplies few coordination declarations; and the frozen RIS response reports qualifying routes within its listed vantage-point set at a specified time.

What to watch

  • changes to the AS136022 object name, entity association, administrative status or event history in APNIC RDAP;
  • additions or revisions to Janani Technology’s PeeringDB identity, policy, prefix-count or exchange-connection fields;
  • later routing observations that clearly state their query time, address family, peer denominator and low-visibility threshold;
  • route-origin evidence relevant to an authorisation question;
  • authorised session telemetry or service-specific tests when the question concerns peering or customer experience.

Sources