概要
- ICTZ Hosting Service 在公共网络记录中与 AS212922 关联。有价值的问题不是名称是否出现在注册表中，而是该记录是否映射到荷兰实际可恢复的客户服务。
- RIPEstat 显示 1 个当前公告前缀，包括 178.218.195.0/24。路由起源检查返回 1 个未知路由起源验证结果。这些是积极的网络信号，但它们不揭示机架数量、功率余量或支持容量。
- 互联证据显示：PeeringDB 名称 ICTZ Hosting Service；通用策略开放；0 个交换连接点；0 个设施；配置文件中 1 个 IPv4 前缀；0 个 IPv6 前缀。邻居证据显示：AS24785（左）。这些记录有助于定位运营表面，但不能证明物理路径多样性或商业传输独立性。
- 客户面临的风险是注册容量与可用容量之间的差距。一个活跃的 ASN 仍可能因一个机架、一个上游、一个远程手排队、一个计费锁定或一个迁移陷阱而失败；一个休眠的 ASN 仍可能被营销超出公共证据所能支持的范围。
- 证据等级为中等。公共证据支持一个活跃的 AS212922 路由和一个与 ilionx 关联的身份，但未公布恢复目标、设施合同或客户安置规则。
云账单仍在物理位置落地
误解 ICTZ Hosting Service 最简单的方式是停留在“云”这个词上。云或托管账户是处理器、内存、存储、路由器、地址资源、设施访问和能在故障时介入的人员的商业包装。公共路由表只显示该安排的控平面边缘。它不显示电缆桥架、锁定的机柜、电源馈线、备用光学模块或能在午夜后进入站点的工程师。
对于 ICTZ Hosting Service，可见边缘是 AS212922。本文使用的公共网络捕获发现 1 个当前公告前缀，包括 178.218.195.0/24。这足以说明存在可观测的运营表面，而不仅仅是公司列表中的名称。但不足以说明每个客户工作负载位于何处，或移除一个组件后还有多少余量。
托管服务的经济契约是，提供商将混乱的物理状态转换为月度费用。客户收到界面和发票；提供商保留机架计划、运营商合同和维修计划。该契约可能合理，但它集中了判断力。当 ICTZ Hosting Service 负责可达性时，客户必须询问当第一条好路径消失时实际仍可用的是什么。
公共证据始于RDAP、RIPEstat 概览、路由状态、公告前缀、邻居、路由历史、PeeringDB、Cloudflare Radar、BGP.tools、Hurricane Electric、IPinfo、RPKI 验证。这些记录不是营销文案。它们是机械性的观察，有助于将实时路由足迹与需要合同证据的主张区分开来。
身份记录有用，但不是服务本身
AS212922 标识一个网络边界。它不标识每个法律实体、员工、数据大厅或 ICTZ Hosting Service 下销售的产品。这一区别很重要，因为责任可能分散。注册对象可能列出一个持有人，PeeringDB 可能使用一个交易名称，网站可能描述一个更广泛的服务，客户合同可能由另一个关联公司签署。
RIPEstat 概览中的持有人标签是 ICTZ-NL-ASN ilionx Hosting Services BV。该标签有助于将 ASN 与主题联系起来，但它不是服务级别承诺。它说明数字资源证据指向何处。它不说明客户是接收裸机托管、虚拟机、IP 传输、托管网络服务还是内部企业网络功能。
品牌重塑使得运营边界很重要：路由仍携带旧的托管服务名称，而公共网站指向一个更广泛的咨询集团。因此，买家应区分三个问题。谁控制数字资源？哪个服务（如果有）当前在使用它？当服务失败时，谁在合同上负责？公共数据有助于第一个问题。第二和第三个需要实时技术和商业证明。
这种区别对于托管品牌名称尤其重要。托管术语可能在服务器迁移、客户迁移或 ASN 变为未使用后仍然存在。该标签应引发询问，而不是替代询问。
路由历史不应过度解读
历史路由证据有用，但不应被当作当前容量来推销。RIPEstat 列出了第一次观察到的路由 178.218.195.0/24 在 2020-09-08T08:00:00，最后一次观察到的路由 178.218.195.0/24 在 2026-07-11T08:00:00。
历史有助于识别连续性风险。公司可能因迁移客户、变更上游、出售资产、外包交付或停止服务而停止宣告前缀。每个原因对客户都有不同含义。如果没有运营商声明或当前流量证据，路由收集器无法区分它们。
因此，路由历史视图最好用作时间线。它可以显示路由是短暂测试、长期运行、间歇性还是在一段时间后撤回。它不能证明服务器位于何处、客户是否受影响，或同一组织是否仍控制该服务。
对于采购，规则很简单：不要用过去的 BGP 购买现在的弹性。历史公告可以支持身份和过去运营。它们不能建立当前容量、备份路径或事件响应。
RPKI 有助于来源风险，但不适用于所有故障
路由起源验证提出一个具体问题：AS212922 是否被授权宣告给定前缀？对于 ICTZ Hosting Service，验证快照返回 1 个未知路由起源验证结果。此处使用的第一个验证 URL 是RIPEstat RPKI 验证。
有效的来源数据有用，因为它减少了路由被强制执行路由起源验证的网络拒绝的机会。它还表明，拥有数字资源控制权限的人已采取行政步骤发布授权。这比相同活动前缀的未知或无效来源状态好。
RPKI 不能解决所有故障。它不能证明服务快速、冗余、本地、人员充足或物理多样化。它不能防止接入光纤被切断、上游过载、电源转换失败、防火墙配置错误或等待远程手的支持工单。它保护了控平面的一个切片，而不是整个服务。
更广泛的方法由RFC 6811以及APNIC和ARIN的操作材料描述。这些文档解释了为什么起源验证属于弹性对话，同时明确它只是众多控制之一。
对等和设施线索不是容量审计
PeeringDB API 查询在PeeringDB返回 PeeringDB 名称 ICTZ Hosting Service；通用策略开放；0 个交换连接点；0 个设施；配置文件中 1 个 IPv4 前缀；0 个 IPv6 前缀。人工配置文件是PeeringDB 网络页面。
PeeringDB 很有价值，因为它经常暴露互连的实用词汇：策略、交换点数量、设施数量、近似前缀数量，有时还有查看镜。对于 ICTZ Hosting Service，这些字段有助于框架化公共足迹是像一个孤立的可路由块、一个交换连接网络，还是一个更广泛的互连参与者。
但 PeeringDB 不是审计。配置文件可能过时、稀疏或理想化。设施数量不能保证客户工作负载位于这些建筑中。交换连接点不能证明付费传输多样性。通用策略如开放、选择或限制不能说明哪些路由被接受、哪些会话默认有能力，或故障后如何处理拥塞。
实际用途是将公共配置文件转化为问题。哪个列出的设施实际用于客户入口？是否有两个路由器、两个电源域和两个光纤入口？有没有交换路由服务器会话承载关键流量，还是仅用于选定目的地的无结算对等？如果设施、交换或一个上游变得不可用，提供商能否保持服务存活？
传输多样性必须被证明两次
传输多样性必须在路由层和物理层都得到证明。RIPEstat 邻居视图显示 AS212922 的 AS24785（左）。这告诉我们公共 BGP 能看到什么，但没有告诉我们这些邻居是上游、对等、客户还是交换学习到的路径。它也没有揭示会话下方的管道或交叉连接。
一个网络可以有两个共享一个建筑入口的逻辑上游。它可以有两个使用同一个电源插头的路由器。它可以有一个在繁忙时段太小无法承载流量的备份传输合同。它可以有一个表面上多样化的 BGP 表，但仍然依赖一个交换交换机、一个远程手队列或一个管理跳板主机。
因此，客户需要区分术语。路由多样性意味着控平面有替代路径。运营商多样性意味着不同的商业和操作对手方。物理多样性意味着光纤路径、入口、机架和电源安排不会同时故障。容量多样性意味着剩余路径可以在不丢弃流量的情况下承载关键负载。
这就是MANRS和RFC 7454成为有用背景的地方。它们定义了良好的路由行为和操作卫生。它们不证明 ICTZ Hosting Service 已购买或测试了客户可能需要的每条多样化路径。
安装容量不是客户能用的容量
安装容量和可用容量在故障期间迅速偏离。安装容量是看似存在的东西：可路由前缀、端口、服务器、存储、传输承诺和设施合同。可用容量是在组件停机、维护窗口开始或上游撤回路由后仍然工作的东西。可恢复容量是在客户操作截止日期前可以恢复的东西。
对于 ICTZ Hosting Service，公共证据可以描述地址空间和一些互连线索。它不能告诉我们有多少虚拟机管理程序已通电、存储如何镜像、备用光学器件和服务器是否在现场，或一次可以移动多少客户工作负载。一个具有有效路由和公共配置文件的网络，如果恢复站点规模不足或支持队列过载，仍可能缺乏可恢复容量。
同样适用于 IPv6。可见的 IPv6 聚合可以表明技术成熟度，但不能证明客户应用程序、监控、支持工具和接入网络同样准备好。当双栈操作只有在两个栈都得到操作维护且一个栈的故障不会导致关键服务瘫痪时，才会增加弹性。
买家应要求按层测量的余量：客户接入、汇聚、边缘路由、存储、计算、备份和支持。一个平均利用率数字太粗糙。重要的数字是在测试故障期间剩余的量，而不是在安静时段存在的量。
电源、备件和人工决定维修时钟
物理维修是服务抽象变得具体的地方。如果路由器线路卡故障，有人需要备件和安装权限。如果服务器失去电源供应，有人需要进入房间。如果交叉连接故障，设施操作员可能控制工作订单。如果云存储卷变得不一致，提供商可能需要专家团队而不是现场技术员。
公共记录很少发布这些细节，ICTZ Hosting Service 也不例外。缺席是正常的，但不应被忽视。购买托管能力的客户也在购买提供商的接入安排、维护合同、供应商关系和人员配置模型。故障时钟在正式事件通知之前就开始计时；当检测、分类和站点访问开始时，时钟就开始计时。
维修问题应根据操作时间提问，而不是宣传册语言。从警报合格所有者需要多长时间？到达设施需要多长时间？哪些部件本地库存？哪些维修需要第三方工单？变更窗口是否由处理紧急恢复的同一批人员值班？如果支持门户是受影响系统的一部分，客户如何得到通知？
这些问题对于较小或区域性的网络尤其重要。大的足迹可以隐藏弱的地方流程；小的如果备件有纪律、升级路径清晰和容量限制诚实，可以具有弹性。公共路由证据不能决定这个问题。
数据本地性是布局问题，而不是国家代码
数据本地性通常被简化为附加在公司或 ASN 上的国家代码。那太简单了。ICTZ Hosting Service 在此与荷兰关联，但托管工作负载可能将客户数据、日志、备份、管理访问和支持记录放在不同地方。ASN 国家不自动是存储国家、支持国家或法律合同国家。
客户需要一个布局矩阵。主要服务在哪里？恢复副本在哪里？备份存储在哪里？哪些供应商可以访问系统？日志和工单存在于何处？哪个国家的法律管辖访问请求和删除？网络路由可以跨边界而客户未察觉，支持工程师可以从与机架不同司法管辖区访问系统。
数据主权还有恢复角度。如果提供商失败或客户退出，客户能否以可用格式获得完整数据？是否可以在主服务降级时生成导出？导出是否包括文件、元数据、日志和配置，还是仅数据库提取？终止后的导出窗口有多长？
此处引用的公共记录不能回答这些合同问题。它们只能显示为什么这些问题重要：地址资源和互连是服务表面的一部分，但客户的操作依赖通常延伸到存储、身份、计费和支持过程，这些在 BGP 中不可见。
支持条款是基础设施的一部分
支持不是基础设施的软附加组件。它是无形故障变为修复服务的机制。提供商可以有有效的路由，但如果工单接收缓慢、升级路径不清晰或能进行更改的团队在事件期间不可用，仍可能使客户陷入困境。
最重要的支持事实是可测量的。谁可以声明重大事件？哪些症状符合电话升级条件？状态通道是否独立于生产控平面？客户是否可以看到路由、设施或存储事件细节，还是只能看到通用中断通知？如果正常控制台不可用，支持人员能否执行数据导出？
计费和账户状态也是基础设施。暂停的账户、失败的付款、过期的域名、锁定的控制面板或有争议的支持权利，可以像断纤一样停止服务。托管能力依赖于行政连续性以及技术连续性。
对于 ICTZ Hosting Service，公共网络证据足以证明这些支持问题是合理的，但不足以回答它们。这就是公共研究的适当边界：它不应编造服务级别，也不应因缺乏公共细节而隐藏操作风险。
监控将路由转化为操作信号
AS212922 的实际价值在于它可以被监控。客户可以从多个地方监控前缀集、路由起源验证、邻居变化和基本可达性。这不能替代提供商的监控，但为客户提供了独立方式查看公共边缘是否发生变化。
监控应区分症状。路由撤回不等于服务器故障。一个国际路径上的丢包不等于设施故障。控制面板中断不等于客户工作负载丢失。买家在事件前区分这些层次越充分，事件期间损失的时间就越少。
此处使用的公共工具有用，因为它们独立于提供商自身的故事。RIPEstat、PeeringDB、Cloudflare Radar 和公共 BGP 聚合器各自看到边缘的不同部分。它们之间的一致增加信心。不一致不自动是故障，但它告诉客户在哪里问下一个问题。
监控计划也需要所有权。有人必须决定哪个变化重要、谁致电提供商、捕获什么证据、以及何时业务转移到备用方案。没有这种操作习惯，公共路由数据变得有趣但未使用。
变更控制是一个隐藏的依赖
托管能力即使客户不动也会变化。路由器接收策略变化，服务器打补丁，证书续期，存储池扩展，过滤器调整，供应商执行维护。每个变化可以保护服务或引入新故障。客户很少看到完整的变更日历，因此他们需要明确的通知和回滚期望。
对于 ICTZ Hosting Service，此处审查的公共记录没有发布变更政策。这很正常，但它使合同语言变得重要。客户应了解紧急变更如何批准、影响客户的维护是否公告、变更是否先在较小群体上测试、以及提供商如何沟通回滚。
变更控制也是薄弱的公共证据变得有风险的地方。如果提供商不能展示当前路由、设施或支持边界，客户可能不知道存在哪些变更域。上游、设施、经销商或云供应商的变更可以影响服务，即使发票上的品牌名称从未改变。
良好的变更实践不会消除事件。它使事件可诊断。它保留了变更了什么、谁批准了、监控看到了什么、以及哪个恢复步骤是安全的记录。该历史是客户购买的容量的一部分。
迁移是最终的弹性测试
托管能力的最后测试是客户能否离开。仅在提供商健康时工作的服务给客户效率而非独立性。能够导出完整记录、配置和操作证据的服务给客户一个备用方案，即使主平台变得不可用或在商业上不合适。
对于 ICTZ Hosting Service，公共网络层不能显示导出路径。它只能显示为什么它们重要。如果提供商的路由边缘、支持渠道或计费系统故障，客户可能需要在压力下移动 DNS、地址、备份、应用程序数据和访问控制。迁移规划属于弹性审查，而不仅仅是终止条款。
客户应询问哪些数据可以在没有专业服务下导出，哪些需要提供商协助，导出保留多长时间，是否包括日志和附件，以及提供商能否在生产事件活跃时生成导出。在依赖之前，应在小而完整的工作负载上测试导出。
迁移不是对提供商的威胁。它是提供商理解客户依赖的证据。一个有弹性的托管服务应使客户在故障期间更有能力，而不是更受困。
买家应如何测试声明
买家应从证明实时服务开始。询问哪些面向客户的服务使用 AS212922，哪些前缀分配给产品，以及是否也涉及提供商分配或云提供商地址。将答案与RIPEstat 公告前缀和独立观察如BGP.tools或Hurricane Electric比较。
然后询问站点模型。提供商应识别生产设施或云区域、恢复站点、备份位置和网络入口。应说明站点是主动-主动、主动-备用还是仅备份。应解释当一个站点被隔离时会发生什么，以及恢复后如何协调客户数据。
第三，询问测试结果。从未移动过流量或恢复过工作负载的弹性计划是一个假设。客户应看到最近的演习日期、测量的恢复时间、数据丢失结果、事件沟通样本以及任何对第三方远程手或云支持的依赖。
最后，询问退出证据。提供商应演示客户如何检索数据、在其他地方重建服务，并在托管服务降级时保持基本记录可用。没有该证据，客户拥有依赖，但没有实际出路。
证据等级
本文中 ICTZ Hosting Service 获得中等证据等级。该等级不是对公司质量的判断。它是关于公共证据能支持什么的判断。此处，有用的公共事实是 AS212922、1 个当前公告前缀（包括 178.218.195.0/24）、1 个未知路由起源验证结果、PeeringDB 名称 ICTZ Hosting Service；通用策略开放；0 个交换连接点；0 个设施；1 个 IPv4 前缀；0 个 IPv6 前缀，以及邻居证据 AS24785（左）。
这些事实显示了一个依赖候选，在当前路由情况下是一个运营表面，但未达到弹性证明。公共路由可见性可以告诉客户从哪里开始测试；它不能显示每个机架、电源馈线、备件、支持人员名单或合同边界。那个差距是托管能力采购应以证据为导向而非品牌为导向的原因。
实际的结论是狭窄且有用的：公共证据支持一个活跃的 AS212922 路由和一个与 ilionx 关联的身份，但未公布恢复目标、设施合同或客户安置规则。客户应将可见的网络足迹视为开始地图，而不是完成的保证报告。
该公司重要，因为故障不会是抽象的。如果托管服务或网络边缘故障，客户可能失去可达性、管理访问、数据移动、计费控制或迁移选项。公共记录有助于命名该依赖；合同和测试必须证明它如何生存。
谁感受到故障
ICTZ Hosting Service 最直接的用户可能是客户管理员、经销商、开发者、远程员工或其他依赖托管边缘的网络运营商。但故障的影响很少停止在第一个看到超时的人。路由撤回、存储故障或支持延迟可以停止配置、监控、发票访问、软件部署、客户门户、备份或本应减少其他风险的迁移。
这种传播就是为什么小的基础设施名称值得关注。有限的可视前缀集仍可以承载管理服务或面向客户的端点。小的支持团队仍可以成为短暂事件与一整天临时工作之间的分水岭。稀疏的公共记录仍可以位于下游公司视为例行公事且无形直至失败的服务之下。
对于荷兰的客户，品牌与基础设施之间的距离尤其重要。附加在 AS212922 上的国家或地区不自动告诉他们数据位于何处、使用哪条运营商路径、哪个法院或监管机构重要，或者本地支持渠道能否在不等待另一个供应商的情况下行动。故障在成为法律或合同之前是操作性的。
实际问题不是每个依赖都是坏的。托管服务存在是因为共享基础设施可以比许多客户自建系统更便宜、更有人手和更安全。实际问题是客户是否知道他们接受了哪个依赖，以及提供商能否演示恢复而不仅仅是描述可用性。
公共证据如何误导
公共网络证据强大，因为它独立于销售演讲。它也容易过度解读。AS212922 可见但客户服务实际运行在另一网络上。前缀可以公告但只有管理组件使用它。PeeringDB 配置文件可以由技术联系维护但不反映当前客户产品。休眠的 ASN 可以在底层服务移动后长时间保留在记录中。
最安全的阅读是分层的。注册证据支持身份。路由收集器证据支持某一时刻的公共可达性。路由起源验证支持一种形式的路由授权。PeeringDB 支持互连发现。这些层单独都不能证明站点冗余、可用计算、存储耐久性、客户安置、帮助台权限或导出就绪。
这种分层阅读既保护 ICTZ Hosting Service 也保护读者。它避免因公司保持设施细节私密而指责其弱点。它也避免因一个公共层看起来健康而给予公司不应得的弹性信任。公共证据应使下一个问题更尖锐，而不是将答案变成口号。
纪律是清楚地陈述不确定性。当前路由是当前路由。有效起源是有效起源。邻居是观察到的邻居。设施数量是目录字段。这些术语有用因为它们狭窄。一旦它们被拉伸到更广泛的保证，读者就失去了证据的价值。
供应商边界决定恢复
托管服务可能失败在提供商拥有的部分、租赁的部分或供应商操作的部分。区别很重要，因为维修路径会变化。提供商拥有的路由器可能由其自身工程师修复。托管电源事件可能依赖建筑员工。云配额或存储事件可能依赖超大规模支持渠道。光纤故障可能依赖运营商和民用维修队。
围绕 ICTZ Hosting Service 的公共记录没有揭示这些供应商边界。这就是为什么买家应要求责任地图而不是通用的正常运行时间承诺。地图应命名谁控制设施、谁控制路由器、谁控制存储、谁控制备份、谁控制 DNS、谁控制身份以及谁可以批准紧急变更。
供应商边界也是财务边界。提供商可能有强大的技术技能，但只有有限的支持权利与设施或上游。客户可能与提供商有强合同语言，但对实际控制故障组件的供应商没有直接权利。恢复随后依赖于在公共路由数据中不可见的升级关系。
最清晰的提供商将这些边界视为服务的一部分。他们可以解释什么是内部的、什么是外包的、哪些承诺通过、哪些不通过，以及当供应商是瓶颈时他们如何让客户知情。这种解释是一种容量形式，因为它减少了故障期间因混乱而损失的时间。
恢复必须经过演练
从未被演练过的恢复计划只是理论。演练不一定是戏剧性的。它可以是一个客户工作负载的受控故障切换、从备份恢复到隔离环境、路由撤回测试、支持升级演习或数据导出排练。重要的是提供商已测量时间且客户已看到什么出问题。
对于 ICTZ Hosting Service，公共证据不能显示演练结果。因此，客户应直接请求它们。有用的证据是近期、具体且谦虚的：测试了什么、什么失败了、改进了什么、恢复花了多长时间、丢失或重放了多少数据、以及需要哪些客户操作。光鲜的高可用性声明不如坦诚的演习报告有用。
演练也暴露隐藏的顺序。备份可以快速恢复但需要 DNS 更改。路由可以快速故障切换但监控指向旧地址。支持团队可能知道技术修复但缺乏联系设施的权力。客户可能有数据但没有员工培训以降级模式操作。这些不是边缘情况。它们是恢复的正常纹理。
在事件之前发现这些依赖的最佳时间。一旦客户离线，每个缺失的权限、过时的联系人和未记录步骤都变得更昂贵。演练将弹性从承诺转变为实践的操作习惯。
狭窄的结论更有用
ICTZ Hosting Service 的狭窄结论比宽泛的更强，因为它是可测试的。公共证据识别 AS212922，提供了路由和注册基线，显示了哪些互连数据可见或不可见，并框架化了客户在将服务视为弹性托管能力之前必须回答的问题。
该结论不需要对隐藏资产确定。它不需要猜测设施或编造客户。它只是认识到现代基础设施经常在服务标签后面隐藏物理层，并且公共网络数据可以重新打开足够多的该层，使严肃的买家能够提出知情问题。
剩余工作属于提供商和客户。提供商必须展示当前服务布局、路径多样性、支持权限、恢复演练和数据退出。客户必须决定哪些故障它可以容忍、哪些它必须通过合同转移、以及哪些它必须用自己的备用流程处理。
如果这些证明到达，证据等级可以改善。如果它们没有，公共记录应保持为依赖地图而非弹性证书。这不是胆小的结论。这是唯一既尊重证据价值也尊重其限制的结论。
下一步关注什么
ICTZ Hosting Service 的下一个公共变化是具体的：新增或撤回的前缀、AS212922 的不同持有人标签、PeeringDB 更新、路由起源验证变更、新的可见邻居，或命名生产地点和支持职责的网站及服务页面。每个都将改变足迹的实际解读。
买家也应关注沉默。如果配置文件保持过时而提供商营销增长，差距本身就成为问题。如果路由变化但客户通知没有，客户应询问移动是否计划、测试和协议覆盖。
最强的未来证据将结合公共和私人证明：当前 BGP、有效路由起源授权、维护的互连记录、命名的设施、测试的恢复和数据导出演示。在该证据组装之前，最安全的位置是自律的好奇心。
操作尽职调查的简单术语
ICTZ Hosting Service 的简单尽职调查测试是要求遵循依赖的证据，而不是仅仅重复品牌的证据。客户应能指向其购买的服务、承载它的地址或上游服务、托管它的位置或提供商类别、修复它的支持路径以及让客户离开的导出路径。如果这些部分中有任何一个含糊，风险只是从视线中移出。
同样的测试应在实质性变化后重复。新的上游、不同的设施、修订的支持计划、新的备份目标、更改的计费平台或更改的产品名称都可以改变风险概况而不改变标题服务。客户经常在中断期间才发现这些变化，此时实际问题不再是承诺了什么，而是谁能采取行动以及多快。
好的提供商可以在不向公众暴露敏感图表的情况下回答。它可以共享机密架构说明、当前责任矩阵、近期恢复演习、状态通道设计和数据返回程序。它也可以解释它不会承诺什么。那种诚实有价值，因为它让客户决定复制、投保、监控或接受什么。
对于 ICTZ Hosting Service，公共网络证据给出了一个起始地图。该地图有用，因为它识别了公共边缘及其周围的空白。如果被视为整个领土，它就没有用。公共记录应开启关于路由可见性、站点布局、电源、传输、支持和退出的实际对话。它不应结束那个对话。