Summary
- Net-Glyph Data Center has a real registry footprint: APNIC RDAP for AS24310 names NGDC-AS-AP, describes Net-Glyph Data Center at Tsinghua University in Beijing, records China as the country, and shows a 2008 registration with a 2020 last-changed event.
- The current public routing footprint is much weaker than the name suggests. On 12 July 2026, RIPE NCC's routing-status view for AS24310 showed zero announced IPv4 prefixes, zero announced IPv6 prefixes, zero observed neighbours and no RIS peers seeing the ASN.
- The older APNIC route-policy text says AS24310 imported routes from AS4538, AS9407 and AS9929 and exported AS24310 back to them. That is evidence of historical multihoming intent through CERNET, DRAGONTAP and China Unicom-related networks, not evidence that live carrier diversity exists now.
- A customer, investor or university stakeholder should not treat the phrase "Data Center" as proof of rack capacity, protected power, cooling redundancy, fire separation, carrier-meet diversity or current service availability. Those facts require site-specific operating evidence.
- The appropriate public evidence grade is Negative for current public BGP activity and Weak for any wider facility claim: the identity record is credible, but public evidence does not show a current, reachable, capacity-bearing data-centre network.
Registry identity is real, but it is not the same thing as a current facility
The strongest fact about Net-Glyph Data Center is not a sales page, a route map or a facility specification. It is the registry record. APNIC's RDAP entry for AS24310 identifies the autonomous system as NGDC-AS-AP, gives the country as CN, and carries the description "Net-Glyph Data Center", "Tsinghua University" and "Beijing 100084, China." The same record shows a registration event in September 2008 and a last-changed event in September 2020. It also points the abuse and administrative contacts to CERNET-related roles, including an abuse contact at the Network Center, FIT-3-220, Tsinghua University, Beijing 100084.
That is a meaningful identity anchor. It places the network name in the APNIC registry, ties the entity to a major Chinese academic-network environment, and gives an administrative path through CERNET. It is enough to say that the name is not merely an invented directory label. It is not enough to say that Net-Glyph has an operating commercial data centre, sells colocation, has a live public customer base, or maintains usable capacity in 2026.
The old-style APNIC Whois rendering for AS24310 adds routing-policy detail that RDAP compresses away. It lists AS24310 as importing from AS4538, AS9407 and AS9929, exporting AS24310 to the same three autonomous systems, and using AS4538 as the default. It also says the network is a multihome member of CERNET. Those statements matter because they show how the network was expected to sit in relation to larger carriers or research-network backbones.
They still have to be read historically. A route-policy entity can remain long after a service is withdrawn, consolidated, renumbered or made private. It can describe an intended relationship, a past relationship, or a maintained but inactive administrative arrangement. Registry text is a control record; it is not a packet capture. The difference is central to this company because the current routing views do not show live public reachability.
The operating boundary is also unresolved. The record names Net-Glyph Data Center and Tsinghua University, while the maintainers and contacts sit in the CERNET orbit. That could mean a university-linked research facility, a campus server room, an academic network service, a historical project, or a named data-centre environment under a larger operator. It should not be automatically converted into a standalone data-centre company with its own building, power plant, maintenance team and commercial service desk.
For a reader assessing risk, the first question is therefore institutional. Who is the contracting party behind the name? Is Net-Glyph an operating unit, a project name, a facility name, a legacy routing entity, or a brand used by a campus data-centre team? Which organisation owns the racks, power distribution, cooling equipment, fibre handoffs and customer obligations? If the answer is CERNET, Tsinghua, a separate supplier, or a combination, that boundary should be documented before any capacity claim is accepted.
This point is not pedantic. In data-centre diligence, the party named in a network registry often differs from the party that controls the building, the electrical room, the cooling plant, the security desk, the contract and the incident call tree. A buyer can tolerate a layered operating model if the layers are clear. It cannot price risk when the public record shows one name, one university context and one national education-network contact structure, while the actual facility responsibility remains unstated.
Current public routing evidence points to dormancy, not active reachability
The most important current fact is the absence of public BGP announcements. On 12 July 2026, RIPE NCC's AS overview for AS24310 identified the holder as "NGDC-AS-AP - Net-Glyph Data Center" and marked the ASN as not announced for the query day. RIPE NCC's announced-prefixes endpoint returned an empty prefix list. RIPE NCC's routing-status endpoint reported zero IPv4 prefixes, zero IPv4 addresses, zero IPv6 prefixes, zero observed neighbours and no RIS peers seeing the ASN.
That is a strong negative observation for public reachability. It does not prove that every piece of equipment under the Net-Glyph name is powered off. A private data-centre network can exist without originating a public ASN. A campus or research facility can sit behind another autonomous system. A service can use private addressing, provider-assigned space, overlay connectivity or internal routing. But if the claim being tested is public Internet capacity under AS24310, the public routing evidence does not support it.
IP2Location's AS24310 page reaches the same broad public conclusion from its own view: it labels the ASN as Net-Glyph Data Center, lists zero total IPv4 addresses, zero total IPv6 addresses, no known IPv4 ranges and no upstream or downstream ASNs. That is a commercial intelligence page rather than a registry source, so it should not outrank APNIC or RIPE. It is useful because it independently shows how the ASN appears to a market observer: named, but not carrying visible address space.
PeeringDB's network API query for ASN 24310 returned no public network record during review. PeeringDB is voluntary, so absence there is not proof that Net-Glyph lacks private interconnection, facility presence or exchange ports. Many real networks do not maintain public PeeringDB entries. Yet the absence removes a common way to verify contact roles, traffic policy, exchange presence, public facility names and peering posture.
This combination changes the diligence question. For an active small host, the usual starting point is to map visible prefixes, upstreams, route-origin authorisations, reverse DNS and customer-facing services. For Net-Glyph, the starting point is more basic: is there a current service under this name at all, and if so, is it deliberately hidden behind another network, or has the public routing entity simply gone quiet?
There are benign explanations. The network may have been absorbed into a larger CERNET or campus backbone. It may be preserved for administrative continuity even though public routes were withdrawn. It may serve an internal research or education function where public announcements are no longer needed. It may also be a historical data-centre label attached to equipment that was decommissioned, renamed or migrated.
There are riskier explanations as well. A stale ASN can survive in registries after operational responsibility has become unclear. Contacts may still resolve to institutional mailboxes, while the people who originally used the entity have moved on. Documentation can lag equipment moves. Customers or dependent services may believe a data-centre route exists when actual recovery depends on another network. None of those possibilities can be settled from public BGP alone.
The article's practical conclusion is therefore narrow but firm. AS24310 should not be marketed or evaluated as an active public data-centre network without current evidence of announcements, upstream sessions, address resources and reachable services. If a private or provider-routed service exists, the operator should show the alternative path and explain why the public ASN is dormant.
Historical multihoming needs current proof
The APNIC policy text names three important counterparties. APNIC RDAP for AS4538 identifies the China Education and Research Network Center at Tsinghua University, and RIPE NCC's AS4538 overview shows it as an announced autonomous system. APNIC RDAP for AS9407 identifies DRAGONTAP Internet Transit Access Point, a CERNET-related transit-access-point entity in Beijing, while RIPE NCC's AS9407 overview marked that ASN as not announced on the query day. APNIC RDAP for AS9929 identifies China Unicom Industrial Internet Backbone, and RIPE NCC's AS9929 overview shows it as announced.
Those names create a plausible historical picture. Net-Glyph sat in an academic-network setting, defaulted to CERNET, and had route-policy language pointing toward a China Unicom backbone and a CERNET transit-access point. If those relationships were live, they could form a useful carrier-diversity story: education network reach, commercial backbone reach and a specialised transit-access path.
But live redundancy is not proved by names in an old aut-num entity. Carrier resilience has three layers. The first is logical diversity: more than one BGP neighbour, more than one route path, and route policies that continue to work when one neighbour fails. The second is commercial diversity: contracts, repair commitments, escalation routes and service demarcations with separate providers or separate units. The third is physical diversity: separate building entrances, fibre ducts, meet-me rooms, optical shelves, power sources and upstream sites. Public registry text can hint at the first layer.
It says almost nothing about the second and third layers.
The current public route state weakens even the first layer. RIPE NCC's ASN-neighbours endpoint for AS24310 returned no observed neighbours on the query day. RIPE NCC's AS path length endpoint for AS24310 returned no path-length statistics for the ASN. If AS24310 is not observed in the public routing system, then a customer cannot use public BGP data to confirm whether the older AS4538, AS9407 and AS9929 relationships still carry traffic.
That does not make the old policy useless. It tells a buyer what to ask for. Does AS24310 still have BGP sessions with AS4538, AS9407 or AS9929? If not, when were they retired? If AS9407 is no longer publicly announced, what replaced that path? Are Net-Glyph services now behind AS4538 or another CERNET ASN? Does any customer traffic use AS9929? Are routes filtered, private, or visible only to Chinese domestic collectors? Which organisation can authorise changes to the route policy in an emergency?
The answers have operating consequences. If Net-Glyph depends on a single larger research-network backbone, a fibre or routing incident there could become a common-mode failure. If it depends on separate CERNET and China Unicom paths, the physical route and facility entrance evidence matters. If all public-facing service has migrated away from AS24310, then the ASN itself is not the capacity entity; the relevant asset is the new network or facility behind the migration.
Route security also remains unresolved. Public route-origin validation matters only when prefixes are announced. With no visible prefixes, there is no current public origin set to validate for AS24310 in the ordinary way. If the network resumes public announcements, customers should expect current route-origin authorisations, accurate route objects, maintained abuse and NOC contacts, and a published change process. A route that suddenly reappears after years of dormancy can be legitimate, but it should receive more scrutiny than a continuously operated route because stale records and old filters can create surprises.
The carrier verdict is therefore conditional. Net-Glyph's registry history suggests a network once designed to sit among serious Chinese education and telecom backbones. Present evidence does not show that design operating. Until the operator demonstrates live sessions, path diversity and failover results, the safe assumption is not "multihomed data centre"; it is "historical multihoming record with current public inactivity."
Beijing and campus context make the asset boundary especially important
The address in APNIC is not an anonymous industrial park. It points to Tsinghua University and CERNET contact infrastructure in Beijing. That context is valuable and limiting at the same time. A major university and national education network can host sophisticated computing, research, network operations and data-centre environments. They can also use internal names and legacy network entities that were never intended to describe a commercial colocation product.
This matters because the assignment for a data-centre company normally asks where the physical asset sits, what market it serves, how much power it can use, how much heat it can reject, which carriers enter the building and who is affected when the system fails. For Net-Glyph, public evidence does not even settle whether the relevant asset is a stand-alone facility, a room inside a campus network centre, a logical network service, or a retired project label.
The location question should therefore be stated in layers. The registry context is Beijing, China. The administrative environment is CERNET and Tsinghua University. The public service area, if any, is not proved. The data-centre asset, if any, is not specified. The ownership and operating boundary are not disclosed. A public directory entry can identify the entity, but customers still need a facility schedule that names the actual building, floor, room, access controls, utility demarcations, fire zone, cooling system and network handoff points.
China's own data-centre policy language reinforces why those details matter. The State Council-posted New-Type Data Center Development Three-Year Action Plan describes new-type data centres as high-efficiency, high-security infrastructure supporting digital transformation. It sets national expectations around layout, utilisation, network quality, green and low-carbon operation, power-use effectiveness, renewable energy use, reliable power supply, cooling, fire protection, lightning protection, flood protection and seismic protection. It also distinguishes national hub nodes, provincial facilities and edge data centres, and it calls for upgrading old, small and scattered facilities.
That national plan does not certify Net-Glyph. It does provide a sensible benchmark for what a contemporary Chinese data-centre claim should answer. If Net-Glyph is a current data-centre operation in Beijing, it should be able to explain whether it is a campus edge facility, a research-network node, a general hosting site, or part of a larger hub strategy. It should disclose whether it serves public customers, academic users, internal university systems or network infrastructure. It should state whether capacity is expanding, stable, constrained or decommissioned.
Beijing intensifies the power question. Dense urban sites compete for electrical capacity, cooling space, generator placement, fuel logistics, noise allowances and building-room constraints. A campus environment adds institutional controls around access, safety, permits, research use and shared utilities. These constraints do not make the site unreliable. They make the word "capacity" operational rather than abstract. Available floor area is not the same as available critical load.
A room that can host network equipment may not be suitable for high-density customer compute without upgraded power distribution, heat rejection and fire systems.
The public record reviewed here gives none of the numbers needed to size the asset. There is no published rack count, critical IT load, transformer rating, UPS output, generator rating, battery autonomy, cooling topology, rack-density envelope, fuel runtime, maintenance state, or customer service commitment. There is no current prefix set that could at least show customer-facing Internet activity. A buyer should therefore resist the temptation to fill in the gaps from institutional reputation. Tsinghua and CERNET are strong contextual names, but their presence in a registry record does not tell us what Net-Glyph can currently sell or support.
The most important document would be a current operating boundary statement. It should say whether Net-Glyph still exists as an operating service; whether AS24310 is intentionally dormant; whether any customer or institutional workloads depend on it; whether equipment remains at the Tsinghua/CERNET site; and whether continuity relies on campus utilities, CERNET backbone operations, a commercial carrier, or a third-party data-centre provider. Without that document, physical-location analysis has to remain provisional.
Installed equipment is not usable capacity
Even if Net-Glyph still has racks in a Beijing facility, installed equipment would not by itself establish usable capacity. Data-centre capacity is the simultaneous availability of space, power, cooling, network reachability, operations staff, spares, security, fire protection and recovery procedures. The weakest component sets the real limit.
The distinction is especially important when the public network is dormant. If there are no visible AS24310 routes, then public routing cannot supply even a rough proxy for service activity. There are no visible prefixes to count, no route-age record to compare, no upstream changes to inspect and no reverse-DNS concentration to evaluate. That leaves only the registry identity and broader context. Those are identity facts, not utilisation facts.
A current capacity claim should start with critical IT load. The operator should disclose how much load is installed, how much is contracted, how much is available for new service, and under which failure state that number remains true. If the facility has N+1 UPS modules but only enough cooling for normal operation, then protected electrical capacity may exceed usable thermal capacity. If the facility has empty racks but no spare breaker positions, no additional chilled-water or air-cooling margin, or no approved utility expansion, then the empty racks are not saleable capacity.
The same rule applies to network capacity. A historical import policy with AS4538, AS9407 and AS9929 does not tell us committed information rate, burst policy, port speed, congested-hour performance, repair targets or physical route diversity. A single modern upstream with strong service levels may be more valuable than three historical names with no current sessions. Conversely, a private service behind a larger CERNET backbone could be perfectly adequate for academic users if its purpose and limits are explicit.
The Uptime Institute Tier Certification overview is useful here as a vocabulary benchmark, not because Net-Glyph claims certification. It separates basic site infrastructure, redundant capacity components, concurrent maintainability and fault tolerance. These are outcomes of a topology under test. A site does not become concurrently maintainable because it has two of something. It becomes concurrently maintainable when each capacity component and distribution path can be removed for planned work without interrupting the supported load. Fault tolerance goes further by surviving a failure or distribution-path interruption.
The public Net-Glyph record contains no evidence against those categories. It does not say Tier I, II, III or IV; it does not show a topology; it does not show a maintenance state. Therefore no buyer should attach a Tier-like resilience assumption to the name. The only defensible position is to ask for a one-line electrical diagram, a cooling diagram, a network path diagram and recent test evidence.
Installed server count is not a substitute. A rack can hold hardware that is powered down, used only for research, blocked by cooling limits, or dependent on a shared campus electrical path. It can also hold critical systems that must not be treated as commercial spare capacity. If Net-Glyph is tied to a university network centre, the facility may have internal mission priorities that differ from a commercial host's priority order. A campus incident might restore research-network backbone systems before a secondary hosted service, or it might prioritise institutional applications over external tenants.
Customers need to know that order before they buy.
The capacity question also includes decommissioning risk. If AS24310 has no public announcements because services moved elsewhere, the old facility may be partially retired. Decommissioning can leave residual dependencies: DNS entries, monitoring assumptions, backup paths, authentication servers, or old documentation that still refer to the former network. Those dependencies can create brittle recovery behaviour even when the main service moved successfully. A clean retirement should include route withdrawal records, customer notification, DNS cleanup, inventory closure and a named successor network.
Power and cooling proof should be site-specific
Power is the point where a data-centre name becomes a physical promise. Net-Glyph's public records do not disclose any utility-feed design, UPS autonomy, generator runtime, load test, maintenance bypass, battery age, power-distribution redundancy or fuel contract. The absence matters because Beijing campus or urban facilities can be highly capable but physically constrained. A buyer cannot infer power resilience from an ASN, a university address or a multihome remark.
A current operator should disclose the critical electrical chain. That chain begins at the utility source and continues through transformers, main switchgear, automatic or manual transfer equipment, generators, UPS modules, bypass paths, distribution boards, branch circuits and rack power strips. Each element should carry a continuous rating, present peak load, maintenance state and failure consequence. The useful capacity number is not the largest nameplate rating in the chain. It is the load that can be supported in the intended resilience state after support systems are included.
Generator evidence needs the same discipline. The Uptime Institute fuel-system reliability discussion treats fuel systems as chains of tanks, pumps, valves, controls, day tanks, delivery arrangements and operating procedures. Runtime at measured load matters more than tank size. If a site has a generator but limited fuel, shared refuelling access, no load-bank record, no transfer test, or no generator-backed cooling, the protected IT load may be far lower than a sales claim implies.
Battery evidence is equally concrete. UPS batteries bridge utility interruption and generator acceptance, and they absorb power-quality disturbances. Their usable duration depends on load, age, chemistry, temperature and maintenance. A credible operator should provide recent test results, replacement dates, alarm history and transfer evidence. If Net-Glyph's equipment is inside a campus network centre, the question becomes whether the relevant racks are on the same protected bus as critical network systems, whether that bus has capacity for any external service, and how priority is assigned during an emergency.
Cooling turns the electrical answer into a service answer. Servers convert nearly all consumed electricity into heat. That heat has to move through air or liquid, coils, condensers, pumps, fans, control systems and a heat-rejection path. If cooling loses one component, if filters load, if a pump trips, if outside air conditions reduce efficiency, or if a control system fails, usable IT load can fall before electrical capacity is exhausted. The ASHRAE contamination guidance for data centres is a reminder that temperature and humidity are not the only environmental variables; particulate and gaseous contamination can affect reliability as well.
China's national plan also connects capacity with energy efficiency. It sought to reduce PUE for new large and above data centres and called for green, low-carbon operation, high-efficiency cooling, efficient power supply systems and better operation management. That does not mean every small or legacy room must meet a single national number. It does mean a current data-centre capacity claim in China should disclose PUE measurement boundaries, cooling technology, load factor and whether older infrastructure is being upgraded or consolidated.
Water and fire safety should not be treated as background details. A water-cooled or evaporative design depends on supply, storage, treatment, pumps and water-quality controls. An air-cooled design may reduce water dependence but increase hot-weather power draw. Fire safety requires early detection, compartmentation, suppression suitable for the space, cable sealing, battery-area controls and trained response. Flood or leak risk requires floor-level, roof, drainage and pipe information. Net-Glyph's public sources provide none of these site details.
The right proof is a test, not a brochure. A credible test would remove utility power, demonstrate generator start and load acceptance, keep cooling online, record rack inlet temperatures, run long enough to reach meaningful thermal behaviour, and show that the network path and management access remain available. A carrier failover test should remove each external path while representative traffic continues. A recovery test should restore a representative workload from backup and report time, data loss and exceptions. Without such evidence, protected capacity remains unproved.
Who is affected depends on whether Net-Glyph is a public host, a campus service or a legacy entity
The failure path depends on the operating model. If Net-Glyph is a current commercial host, an outage could affect customers' web, mail, DNS, virtual server, storage or managed-service workloads. If it is a campus or research-network facility, the affected parties could be university departments, research projects, education-network services or institutional applications. If it is only a legacy ASN, the main risk is not an immediate service outage but stale assumptions in documentation, monitoring, dependency maps and third-party directories.
The public evidence points more strongly to the latter two possibilities than to an active commercial host. AS24310 has a registry identity and a historical multihome record. It has no visible public route set in RIPE's current view, no observed neighbours, no PeeringDB record and no IP2Location address inventory. That does not prove absence of all service, but it does make a public hosting proposition unsubstantiated.
For a campus or academic service, resilience should be judged against the mission, not against generic colocation language. A private research cluster may tolerate planned maintenance that a commercial host could not. A backbone node may have excellent network protection but no obligation to serve external tenants. A university data room may prioritise core campus connectivity, safety and research continuity over public customer service. Those priorities are reasonable if users know them. They are risky if the public label "Data Center" leads outsiders to assume commercial availability standards.
For a legacy entity, governance is the key risk. Who is responsible for keeping the APNIC record accurate? Who can update abuse and administrative contacts? Who decides whether to preserve or retire route-policy references? Who watches for unauthorised reappearance of the ASN in routing tables? Dormant numbers and stale entities can create security and operational exposure if nobody owns them. A malicious or mistaken route leak involving a dormant ASN might be noticed late if monitoring assumes the number is unused but not retired.
NIST's contingency-planning guide is written for US federal systems, not for Net-Glyph, but its core lesson applies broadly: continuity planning has to cover applications, data, telecommunications, people and facilities. If Net-Glyph is still part of a service chain, the continuity plan should say what depends on it, how users are notified, how service is restored, and which alternate network or facility takes over when the primary path fails.
The customer-impact map should be explicit. If no customers exist, say so. If only internal campus services depend on the facility, define them. If external customers still use a different network behind the Net-Glyph name, disclose the current ASN and facility boundary. If AS24310 is kept for possible future use, state the conditions under which it could be reactivated and what validation would happen first. The worst answer is ambiguity, because ambiguity causes people to build risk models around the wrong asset.
Contracts and public pages should follow the same boundary. A service-level promise should name the service being measured, the measurement point, the excluded maintenance windows, the remedy and the recovery target. If AS24310 is dormant, a service level based on that ASN is meaningless. If services are now provided through AS4538 or another backbone, the promise should cite that architecture instead. If a facility exists but has no public network of its own, the promise should be facility-specific rather than ASN-specific.
The practical blast radius could be small, but the evidentiary gap is large. A dormant ASN might affect almost nobody. A hidden internal facility could matter to a university. A rebranded or privately routed data centre could matter to many users but leave little public trace. The responsible editorial position is to state that public sources do not identify the affected population. They identify a registry entity whose current operating state must be clarified before impact can be measured.
What would settle the question
Net-Glyph does not need to publish every internal drawing to become understandable. It needs to publish enough current evidence for outsiders to separate identity, network, facility and service. The first evidence item is a current operator statement: whether Net-Glyph Data Center is active, dormant, renamed, absorbed into another service, or retired. The statement should identify the responsible organisation and the role of Tsinghua University, CERNET and any commercial carrier.
The second item is network evidence. If AS24310 is active privately or planned for reactivation, the operator should state which prefixes it will originate, which upstreams it will use, whether AS4538, AS9407 and AS9929 remain relevant, and what route-origin validation will apply. If public announcements are intentionally absent, the operator should identify the current public network that carries any customer or institutional services. It should also maintain monitoring for unexpected AS24310 visibility and keep abuse contacts current.
The third item is facility evidence. A customer-facing capacity claim should include the building or room boundary, the owner and operator of the space, the utility source, protected load, cooling design, fire and water controls, physical access model, carrier entry points and maintenance responsibility. For a campus-linked site, the operator should explain how shared utilities and institutional priorities affect service restoration.
The fourth item is tested recovery evidence. The operator should show recent results for loss of utility power, generator transfer, UPS operation, cooling-component failure, carrier failover, management access during an incident and restoration from backup. These do not have to expose sensitive details. They do have to show dates, load levels, duration, exceptions and responsible parties.
The fifth item is customer impact evidence. If external services are sold, the operator should publish service classes, support hours, escalation routes, backup and restore terms, data-location boundaries and the meaning of any availability percentage. If no external services are sold, the public label should not encourage customers or directories to infer a commercial host.
Until those items exist, the investment and procurement view should be conservative. The identity record is real. The public network is not currently visible. The facility is not described. Capacity is not quantified. Redundancy is not proved. Recovery is not tested in public. For a data-centre buyer, that means Net-Glyph is not a capacity supplier to shortlist on public evidence alone. For an investor, it means the asset cannot be valued from the registry entity. For a university or network stakeholder, it means the useful task is documentation: preserve, retire or reassign the name in a way that matches the actual infrastructure.
The final verdict is deliberately stricter than the title might suggest. Net-Glyph Data Center does not merely have to prove that marketed capacity can survive power and carrier constraints. On public evidence, it first has to prove whether there is marketed, reachable, capacity-bearing service under this name at all. If there is, the usual data-centre questions follow: protected power, cooling resilience, carrier diversity, maintenance state and recovery. If there is not, the responsible move is to say so clearly, retire misleading assumptions and keep the registry record accurate.