Summary

  • APNIC identifies NewMountainView Satellite Corporation through organisation handle ORG-NSC1-AP and links that registrant to AS135345, AS136031, and AS136032. The records establish registry identity and maintenance relationships, not production use of every registered ASN.
  • RIPEstat observed AS135345 as announced at the research cutoff. It did not observe AS136031 or AS136032 as announced at that time. This difference is a useful example of why a registered capability and running routing state must be reported separately.
  • RIPEstat listed 31 IPv4 /24 announcements for AS135345 in the bounded observation period. Its routing-status view showed IPv4 visibility from 330 of 330 RIS peers and no IPv6 visibility from the 324 peers in that snapshot. Those are routing observations, not uptime, traffic, capacity, or customer-experience measurements.
  • PeeringDB maps network record 25086 to AS135345 and lists operational attachments at GetaFIX Manila and BBIX Manila. The directory records 10 Gbps and 100 Gbps port speeds, respectively. Port speed is provisioned interface metadata, not observed throughput.
  • APNIC records portable IPv4 and IPv6 resources under the same organisation. Maintaining accurate registrations, route policy, security metadata, contact paths, exchange records, and incident ownership creates supervision, integration, maintenance, and exception-handling costs that a transit or port price does not capture.

NewMountainView Satellite Corporation is a useful company to study because its public footprint crosses several layers that are often compressed into one vague description such as "network operator." APNIC records the organisation and its number resources. RIPEstat reports what route collectors could see at a defined time. PeeringDB records a self-reported interconnection profile. Each system answers a different question. None is a complete description of the company, and none should be promoted into a universal reliability score.

The distinction matters operationally. A registry can show that an autonomous system number exists and name the organisation associated with it. That record does not make the ASN visible on the internet. A route collector can observe an origin and a set of prefixes. That observation does not prove that every intended route is present, that every path is healthy, or that a user received an acceptable service. An exchange directory can list a port and its nominal speed. It does not show sustained throughput, congestion, packet loss, route policy, or contractual performance.

The public record nevertheless supports a substantial analysis. AS135345 is not merely a reserved identifier. RIPEstat observed it as announced and listed a visible IPv4 footprint. PeeringDB places it at two Manila exchange fabrics. APNIC records portable IPv4 and IPv6 resources and publishes maintenance and incident-contact structures. Together, those sources identify a real routing and interconnection control surface.

The evidence also preserves uncertainty. AS136031 and AS136032 are active registry objects, but RIPEstat did not observe them as announced at the cutoff. The descriptor for AS136031 names Terraserv Technologies Inc., while the registrant chain points to the same APNIC organisation handle used by NewMountainView. AS136032 carries the NewMountainView name and a Ludeco Network descriptor. Those facts support questions about delegation, customer or affiliate contexts, dormant capacity, and record maintenance. They do not support an invented corporate structure or a claim that either ASN carries production traffic.

This article treats registries as public ledgers and running routing state as a separate reality layer. It asks what must be supervised, integrated, maintained, and repaired when a company operates visible number resources and interconnection edges. It also records the failure modes that public evidence can reveal and those it cannot.

Registry identity is a starting point, not a performance result

APNIC's RDAP response for AS135345 records the object as active, names it NEWMOUNTAINVIEW-PH, places it in the Philippines, and links the registrant role to ORG-NSC1-AP. The organisation record names NewMountainView Satellite Corporation. APNIC's WHOIS view independently presents the company as a local internet registry organisation in the Philippines. These records are strong identity evidence because they come from the regional internet registry responsible for the resource records.

The records also expose administrative structure. They include maintenance objects, technical and administrative contacts, an incident-response team object, and an abuse-contact path. These are not decorative fields. They are part of the operational chain used when another operator, a registry, a security team, or a customer needs to identify responsibility for a number resource.

Accurate public records reduce ambiguity, but they do not eliminate operational work. A contact can exist in a database while an escalation message goes unread. A maintenance object can be correctly named while access is concentrated in one person. An organisation handle can be current while a private inventory is stale. A registry record therefore supplies a reference point for reconciliation. It is not proof that the organisation can execute a change or respond to an incident within a particular time.

AS136031 and AS136032 show why the boundary is necessary. APNIC records both as active objects under the same registrant entity. AS136031's description names Terraserv Technologies Inc. RIPEstat's holder string also names Terraserv. AS136032 names NewMountainView and includes a Ludeco Network description. The records may reflect service relationships, historical assignments, operating arrangements, or other legitimate contexts. The public evidence does not establish which interpretation is correct.

A weak report would flatten the three ASN objects into one statement that NewMountainView "operates three networks." The evidence does not support that wording. A stronger report says that APNIC links three active ASN records to the organisation's registry chain, while current public routing observations distinguish one announced ASN from two that were not observed as announced. This version preserves both the ledger and the running state.

That separation is not merely editorial caution. It affects control design. Registered-but-silent resources still need an owner, an intended-state record, contact maintenance, access control, and a decision about continued retention. If an ASN is reserved for contingency or a relationship, the organisation should know the activation conditions and route-policy safeguards. If it is obsolete, the organisation should know the retirement process. If it belongs to a customer or affiliate context, the boundary of authority should be explicit.

The public registry does not answer those internal questions. It gives accountable owners a list of questions that should not be ignored. The cost of answering them belongs in the ownership model for number resources.

Running-code primacy: what the route collectors observed

RIPEstat's AS overview recorded AS135345 as announced at the query time. Its announced-prefixes endpoint listed 31 IPv4 /24 prefixes over the bounded observation interval. The routing-status view recorded a first-seen observation in 2016 and a last-seen observation at the research cutoff. It also reported IPv4 visibility from all 330 RIS peers included in that snapshot.

These observations make AS135345 materially different from a registry-only object. The ASN was visible in the global routing system from the route-collector perspectives used by RIPE RIS. Its prefixes were not inferred from a marketing page or a generic company description. They were present in public routing data.

The evidence still needs a denominator and a boundary. Thirty-one announced /24 routes are not thirty-one independent networks, customer systems, or sites. The count does not describe traffic volume. It does not show how many routes were intended, how many were covered by route-origin authorisations, or how traffic was distributed. It does not show path diversity from every customer location.

The BGP-state endpoint returned a much larger number of route-view rows. That figure should not be described as a prefix count. Route collectors may hold multiple paths or observations associated with an origin. The value is useful as proof that the endpoint contains a substantial routing-state view, but it is not a capacity metric.

RIPEstat's visibility field also needs careful interpretation. Seeing IPv4 from 330 of 330 RIS peers indicates broad visibility inside that collector set at that moment. It does not prove that every network on the internet had a working path. It does not test application reachability, DNS resolution, last-mile performance, or customer acceptance. A route can be visible and still be undesirable because of a leak, a policy error, a path change, or a more-specific announcement.

For AS136031 and AS136032, RIPEstat reported announced=false at the same bounded query time. That observation is not proof that either ASN has never been used or will never be used. It is a point-in-time result. It does, however, prevent a responsible writer from treating the registry entries as active production networks without additional evidence.

This is running-code primacy in practice. The registry establishes that identifiers and responsible parties are recorded. Route collectors establish what selected observers saw in BGP. Neither source is sovereign over the other. When the two views differ, the difference becomes a reconciliation item.

An operator's internal controls should preserve the same distinction. The intended-state inventory should list which ASNs are expected to originate routes, which prefixes each is authorised to announce, what route policy should apply, and which systems or suppliers enforce it. Independent observations should then test the declared state. A difference should create a bounded exception with an owner and a deadline.

The work does not end when the observations match. Routing is dynamic. Upstream changes, exchange sessions, maintenance, address transfers, customer relationships, and security-policy changes can alter the visible state. Continuous observation creates its own costs: data collection, alert tuning, false-positive review, ownership, escalation, and evidence retention.

Address resources and the obligation to keep records aligned

APNIC's WHOIS records provide two concrete allocation examples. The IPv4 range from 115.42.120.0 through 115.42.127.255 is recorded as allocated portable and associated with NewMountainView's organisation handle. The IPv6 block 2403:15c0::/32 is likewise recorded as allocated portable under the same organisation and maintenance chain.

Portable status matters because number resources can remain associated with an organisation rather than being represented only as a provider-assigned service. It does not remove dependency. The resources still depend on accurate registry data, valid routing policy, upstream or peering relationships, secure access to maintenance systems, and operational ability to announce or withdraw routes.

The visible IPv4 prefixes in RIPEstat overlap the broader picture of address stewardship, but the public sources do not provide a complete mapping from every registered range to every intended announcement. A rigorous internal inventory would connect each allocation, route object, route-origin authorisation, origin ASN, business owner, technical owner, and current operational purpose.

Such a map should be versioned. Address space may be assigned to access networks, infrastructure, customers, partners, testing, reserves, or services. The public evidence does not identify those uses, and this article does not infer them. The important governance point is that each use creates a maintenance obligation.

IPv6 illustrates the difference between capability and deployment. APNIC records a /32 allocation. PeeringDB's network profile says the operator supports IPv6 and lists an IPv6 address at the GetaFIX Manila attachment. RIPEstat's bounded routing-status snapshot, however, reported no IPv6 visibility for AS135345 from the included RIS peers.

Those facts can coexist. An allocation may exist before broad origin visibility. IPv6 may be present on an exchange attachment without a globally visible origin in the observed collector set. A directory may contain intended or self-reported capability while the route collectors show a different state. None of these sources alone establishes the exact deployment model.

The operational requirement is reconciliation, not a forced narrative. Owners should know whether IPv6 is expected to be globally originated, used only in specific interconnection contexts, staged for future deployment, or represented incorrectly in a directory. The answer should come from approved intent and current technical evidence.

Security metadata belongs in the same model. RPKI can help other networks determine whether an observed origin is authorised for a prefix. A route-origin authorisation is not a guarantee that the route is desirable or that the path is safe. It is one cryptographically verifiable statement in a wider routing-control system.

The RIPEstat RPKI history endpoint confirms that a public history surface exists for AS135345, but the captured source does not justify a blanket percentage or a claim that all current routes are valid. A production assessment would evaluate current prefixes individually, record valid, invalid, and not found states, and reconcile them against intended policy.

The cost of address stewardship therefore includes more than registry fees. It includes access recertification, contact review, route-policy maintenance, RPKI lifecycle work, inventory reconciliation, change validation, monitoring, incident response, and retirement. These activities are easy to omit when a procurement comparison focuses only on transit, exchange, or equipment prices.

Peering edges: directory facts and operational questions

PeeringDB's network record maps NewMountainView Satellite to AS135345. It classifies the network as Cable/DSL/ISP, reports an open peering policy, and indicates support for unicast IPv4 and IPv6. The same record lists two exchange attachments.

The first is GetaFIX Manila, where the directory records an operational 10 Gbps port, IPv4 and IPv6 exchange addresses, and route-server participation. The second is BBIX Manila, where the directory records an operational 100 Gbps port and an IPv4 exchange address. These are concrete interconnection records.

They are also self-reported directory data. An operational flag does not prove that every BGP session is established. A port speed does not prove that traffic reached that speed or that usable capacity remained after overhead, policy, and failure reservations. Route-server participation does not describe every bilateral session or traffic-engineering choice.

The two attachments nevertheless create a real integration surface. Exchange connections require physical or virtual delivery, address assignment, routing configuration, policy filters, max-prefix settings, route-server or bilateral session management, monitoring, escalation contacts, and maintenance coordination. Each exchange has its own operational procedures and failure modes.

The nominal difference between 10 Gbps and 100 Gbps can tempt a simplistic conclusion that one attachment is ten times more capable. That is not a defensible customer result. The useful capacity depends on how the ports are used, what routes are exchanged, what traffic is eligible, how links are protected, and what demand exists. The public record does not provide those details.

Peering can reduce transit dependence for eligible traffic, improve path control, or create additional operational options. It can also increase configuration and supervision work. Every additional session needs policy, monitoring, change control, and an incident path. Route-server participation simplifies some relationship management while concentrating attention on correct filters and exchange operations.

The current PeeringDB facility endpoint returns no facility rows for the network record. That absence should not be reported as proof that the company uses no facilities. The network attachments may be delivered through arrangements not represented in that endpoint, or the directory may be incomplete. Empty directory data is an evidence limitation, not a factual description of physical topology.

A strong internal interconnection map would therefore distinguish directory state, contracted service, physical or virtual delivery, configured sessions, observed sessions, traffic use, and accepted outcomes. It would name an owner for each layer. It would also record which evidence is authoritative and how often it must be refreshed.

Supervision cost

Supervision connects technical activity to accountable decisions. For a network operator, it includes deciding which ASNs and prefixes should be active, who may change routing policy, which exchange relationships are accepted, how incident severity is classified, and when a degraded condition is tolerable.

The public records show multiple control surfaces but not the internal authority model. Someone must own APNIC records. Someone must control route-policy changes. Someone must maintain PeeringDB. Someone must receive abuse reports and NOC escalations. These may be the same people in a small team or separate functions in a larger organisation.

Concentration can be efficient until it becomes a continuity risk. A person who knows every portal, password, supplier contact, and routing exception may keep the network moving, but the organisation depends on that person's availability. A named alternate is meaningful only if the alternate can authenticate, locate intended state, execute a bounded procedure, and preserve evidence.

Supervision also governs claims. A dashboard showing green sessions does not prove a customer outcome. A registry page showing an active ASN does not prove it is routed. A PeeringDB port marked operational does not prove usable capacity. Leaders need reviewers who can challenge these category errors before they become assurance statements.

The cost can be measured through review time, decision latency, unresolved exceptions, evidence age, and coverage of alternate operators. Meeting count is not a useful denominator. The relevant question is whether supervision produces timely decisions, current evidence, and repaired exceptions without encouraging hidden workarounds.

Routine governance can remain compact. A monthly control review might reconcile active ASNs, originated prefixes, RPKI state, exchange sessions, registry contacts, directory entries, access roles, open incidents, and planned maintenance. Event-driven reviews should follow a new upstream, exchange change, address transfer, contact departure, access failure, or unexpected route observation.

The three ASN records deserve explicit review. If AS136031 and AS136032 are intentionally silent, the intended state should say so. If they are expected to be active, the observed absence is an exception. If they relate to other operators or services, the authority boundary should be documented. The public record cannot make this decision.

Integration cost

Routing does not operate in isolation. Registry data, RPKI, route policy, upstreams, exchanges, monitoring, incident management, address management, DNS, security tooling, billing, customer provisioning, and change management all exchange information.

Integration failures often occur between systems that are individually working. APNIC may hold the approved organisation record while an internal contact list is stale. A route may be correctly originated while a monitoring system expects an old prefix. An exchange port may be available while route filters reject a new announcement. A RPKI object may be correct while a downstream cache has not refreshed.

The minimum integration map should identify producers and consumers for critical fields. APNIC is authoritative for registry objects. Internal IPAM or source-of-truth systems hold intended use. Routers implement origin and propagation policy. RPKI repositories publish authorisations. Route collectors observe selected external effects. PeeringDB communicates directory state. Monitoring and incident systems create operational evidence.

Every handoff needs a format, owner, freshness expectation, and failure path. If a prefix is added, who updates the intended-state inventory? Who creates or changes the route-origin authorisation? Who updates filters? Who validates external visibility? Who checks that the change did not create a leak or an unintended more-specific? Who closes the task?

Automation can improve these handoffs. It can compare approved prefixes with observed origins, flag stale contacts, detect a directory mismatch, check RPKI state, or open a bounded exception. It should not silently decide that an unexpected route is safe or that a missing route is intentional.

Integration work also includes supplier and exchange procedures. GetaFIX Manila and BBIX Manila are separate operating contexts. Maintenance windows, escalation paths, route-server behavior, addressing, and change processes may differ. The public record does not reveal the contracts, so the article does not claim a specific responsibility split.

Portability adds another integration dimension. Portable address resources can support provider changes, but they do not make a migration automatic. A change may require routing policy, RPKI, upstream filters, exchange sessions, reverse DNS, security controls, monitoring, and customer communication to converge. The cost appears during transition, not on a static price sheet.

Maintenance and exception handling

Network-control assets accumulate maintenance even when no major incident occurs. Contacts expire. Certificates and credentials rotate. Route policies change. Exchanges update systems. Prefix inventories grow. Monitoring rules need tuning. Evidence becomes stale.

The APNIC records include recent validation dates for several contact addresses. That is useful public evidence of maintenance activity. It does not prove response time or round-the-clock coverage. A production control would test the escalation path and document what happens when a primary contact is unavailable.

PeeringDB records also change over time. The network profile and exchange attachments carry update timestamps. Those timestamps show that the directory has been maintained, but they do not prove that every field matches running configuration. A periodic reconciliation should compare the directory with contracts, router state, and exchange confirmations.

Routing exceptions deserve special treatment. A temporary more-specific announcement, an emergency filter change, a max-prefix increase, or a route-server workaround can be necessary. Every exception should have an owner, reason, scope, expiry, monitoring condition, and permanent repair.

Without expiry, temporary controls become architecture. A manual prefix list created during an incident may remain after the intended state changes. An access grant issued for emergency maintenance may outlive the event. A monitoring suppression may conceal a later failure. Exception debt is therefore part of network risk and ownership cost.

Maintenance quality can be measured without pretending to know private performance. Useful indicators include record age, unresolved drift, expired access, route-policy review age, RPKI mismatch age, session-change failure rate, incident ownership time, and repeat exceptions. The exact thresholds belong to the operator.

The same method applies to silent ASN records. An annual attestation can confirm intended purpose, owner, access, contact state, and activation or retirement criteria. If the resource has no current purpose, the organisation can make a deliberate retention or return decision rather than leave it in an ambiguous state.

Failure modes

The public evidence supports a concrete failure catalogue. It does not show that NewMountainView experienced any of these failures. The value is to identify where controls should exist.

Registry drift. The organisation, contacts, maintenance objects, or resource descriptions may stop matching current authority. External operators can then escalate to the wrong place, and internal staff may rely on obsolete records.

Access concentration. One operator may retain the only working credentials or procedural knowledge for registry, RPKI, exchange, or routing changes. Normal operations can appear healthy until that person is unavailable.

Unexpected ASN activation. A registered but normally silent ASN could become visible because of configuration error, hijack, test leakage, or an undocumented activation. The correct response depends on approved intent.

Unexpected ASN silence. An ASN expected to originate routes could disappear from selected collectors because of withdrawal, upstream failure, filtering, or monitoring limitation. A point-in-time absence needs investigation, not an automatic outage declaration.

Route leak or origin error. A router can advertise unintended prefixes, an upstream can propagate policy incorrectly, or a more-specific can escape a test context. Registry ownership does not prevent a routing error.

RPKI mismatch. A route-origin authorisation can be missing, stale, overly broad, or inconsistent with an intended origin. RPKI validation is useful evidence, but a valid route can still be operationally wrong.

Exchange session drift. A PeeringDB attachment can remain listed while the session, addressing, route-server participation, or policy has changed. Conversely, running relationships may not be fully represented in the directory.

Port-speed overclaim. A nominal interface speed can be repeated as capacity, performance, or resilience without traffic and failure-domain evidence. This creates misleading procurement and customer claims.

IPv6 representation drift. An allocation, directory capability flag, exchange address, and global route observation can disagree. The difference may be legitimate, but it needs an owner and an intended-state explanation.

Abuse-path failure. Published contact addresses may not reach an owned queue, may lack triage coverage, or may not connect to route and customer owners. Public validation of an address is not proof of effective case handling.

Monitoring blind spots. A route collector view can miss local failures, customer-specific reachability, DNS behavior, or application outcomes. Monitoring based on one evidence class can produce false assurance.

Supplier boundary confusion. Upstream, exchange, hosting, security, and registry responsibilities can overlap. During an incident, each party may believe another owns validation or communication.

Emergency change residue. Temporary filters, access, prefixes, or suppressions can remain after the incident. The immediate recovery succeeds while the long-term control state degrades.

Evidence collapse. A report may treat registry, BGP, PeeringDB, and customer experience as interchangeable. This is a reporting failure because it hides which layer was actually tested.

A useful incident design links each failure mode to a detector, primary owner, alternate owner, authority to act, evidence to preserve, and closure condition. The detector should match the failure. A registry-drift alert cannot prove application impact. A customer ticket cannot by itself identify route origin. A BGP withdrawal does not explain its cause.

Capability, reliability, and customer outcomes

Capability is the narrowest layer. NewMountainView is associated with number resources. AS135345 was publicly visible. Portable IPv4 and IPv6 allocations exist. Exchange attachments are listed. These facts support statements about available control surfaces.

Repeatable reliability asks whether the capability behaves correctly over time and under change. Relevant evidence could include expected origin sets, route-policy checks, RPKI coverage, session state, monitored reachability, change success, alternate access, escalation tests, and recovery exercises.

The public sources do not supply that complete set. They provide snapshots and directory records. A route seen by all included RIS peers is a strong observation inside that method. It is not evidence of permanent availability. A port marked operational is a directory statement. It is not proof of traffic delivery.

Customer production outcome is stricter. It requires a defined service or user, a measurement window, acceptance criteria, exclusions, and an owner who accepts the result. Examples might include stable access to a broadband service, successful delivery of a business circuit, or accepted reachability for a hosted application. The public record does not identify such outcomes.

This separation prevents several common mistakes. A large prefix count is not a customer count. A 100 Gbps port is not 100 Gbps of delivered traffic. An active ASN record is not an active network. An RPKI-valid route is not proof of low latency or no loss.

Management reporting should preserve the layers. A capability view lists resources, access, endpoints, contracts, and owners. A reliability view lists monitored behavior, change results, exercise evidence, drift, and exception age. An outcome view lists defined services, accepted measures, defects, and business impact.

The denominator matters. If leaders compare network options by component price alone, they omit supervision, integration, maintenance, incident handling, evidence production, and transition work. A cheaper port can be more expensive if it creates hidden manual work or weak ownership. A higher-capacity port can be wasteful if eligible traffic and policy do not use it.

The useful denominator is accepted outcome, not nominal capability. That does not mean public research can calculate the answer. It means a responsible operator should.

How to evaluate the operating model

A bounded evaluation can begin without demanding private topology or confidential customer data. The first step is a current authority map. It should list ASNs, address blocks, RPKI objects, route-policy repositories, exchange attachments, upstream relationships, directory records, portals, and decision owners.

The second step is an intended-state baseline. For each ASN, identify whether it should be announced, by which prefixes, under which policy, and for what purpose. For each exchange attachment, identify expected addressing, route-server participation, bilateral sessions, filters, and escalation paths.

The third step is independent observation. Compare intended origins with route collectors, RPKI validators, exchange confirmations, and bounded reachability tests. No single observer should be treated as complete.

The fourth step is change evidence. Select a recent approved change and trace request, approval, execution, independent validation, defects, rollback readiness, and closure. A document stating that a process exists is weaker than an executed trace.

The fifth step is alternate capability. A qualified alternate should authenticate, locate the approved state, explain the control boundaries, and execute a low-risk exercise. A tabletop is useful, but it should not be reported as an executed technical recovery.

The sixth step is incident and abuse handling. Test that published contacts reach an owned queue, that cases are classified, that route and customer owners can be engaged, and that closure evidence is preserved. Do not publish personal contact details beyond what is necessary for the operational record.

The seventh step is portability and exit. Identify what must change if an upstream, exchange, or platform is replaced. Portable resources reduce one constraint, but routing, RPKI, monitoring, contracts, DNS, security, and communication still require coordinated transition.

The eighth step is cost. Include staffing, supervision, access recertification, registry maintenance, route-policy work, exchange coordination, monitoring, incident handling, exception repair, recovery exercises, supplier management, and transition. Report both normal operation and change cost.

The final step is claims review. Every published assurance should name its evidence class and boundary. "Registered," "observed," "monitored," and "accepted" are not synonyms.

A 90-day control cycle

A 90-day cycle can turn the evaluation model into operating evidence without requiring a large transformation programme. During the first 30 days, owners can reconcile APNIC organisation and resource records, the intended ASN and prefix inventory, route-origin authorisations, PeeringDB entries, exchange agreements, access roles, and monitoring coverage. Every difference should be classified as approved variance, stale record, missing evidence, or technical defect.

During days 31 through 60, the operator can test execution. A qualified alternate can demonstrate access to the relevant systems, explain intended origin and exchange policy, and follow a bounded change or simulation. Independent observations should confirm the result. The exercise should also test incident and abuse escalation without publishing sensitive topology or personal details.

During days 61 through 90, leadership can review defects and ownership cost. The review should identify unresolved drift, repeated exceptions, access concentration, stale evidence, supplier dependencies, and changes that required manual coordination. It should distinguish a missing measurement from a failed control and should avoid converting a successful exercise into a universal availability claim.

The cycle should produce a compact decision record. It can list the resources covered, evidence dates, accepted variances, open defects, owners, deadlines, and the next trigger for review. If AS136031 and AS136032 remain intentionally silent, the record should preserve that intended state. If the intended state changes, routing and security metadata should change through the same controlled process.

Repeating the cycle creates a stronger reliability case than a one-time inventory. It does not prove customer production outcomes, but it shows whether the organisation can keep declared records, running routes, interconnection directories, access, and incident ownership aligned over time.

Conclusion

NewMountainView Satellite Corporation's public footprint supports a serious company network analysis because it links authoritative registry records, observed BGP state, address resources, and exchange attachments. The evidence is stronger than a generic company profile and narrower than a performance review.

APNIC records the company and its resources. RIPEstat shows AS135345 in the running routing system and distinguishes two registered ASNs that were not observed as announced. PeeringDB records two Manila exchange attachments and an open peering profile. Those facts define a real control surface.

The cost of that control surface is not captured by ASN registration, port price, or transit price alone. It includes the people and procedures that keep registry, RPKI, routing, peering, monitoring, contacts, and intended state aligned. It includes the work of investigating silence, drift, leaks, stale records, and incomplete directories.

Public evidence cannot establish the company's private topology, uptime, customer count, delivered capacity, incident history, or customer outcomes. Keeping those unknowns visible is part of the analysis, not a weakness. The operational lesson is to treat records as ledgers, running routing as reality, and accepted service outcomes as a separate evidence layer.

Public sources