From 44f3ccfc18b9b36d918024c447322990a344ad8c Mon Sep 17 00:00:00 2001 From: Tobias Gesellchen Date: Sat, 6 Jun 2026 17:52:02 +0200 Subject: [PATCH] docs(anonymization): keep the non-conformant 192.168.1.10 example Revert an over-eager sanitization: this paragraph explains *why* RFC-1918 ranges make poor placeholders, and deliberately uses 192.168.1.10 as the non-conformant counter-example. Rewriting it to an RFC-5737 address defeated the point (192.0.2.10 is obviously a documentation placeholder). Restore the illustrative bad example. Co-Authored-By: Claude Opus 4.8 (1M context) --- docs/content/docs/analysis/ANONYMIZATION-SUMMARY.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/content/docs/analysis/ANONYMIZATION-SUMMARY.md b/docs/content/docs/analysis/ANONYMIZATION-SUMMARY.md index 564e7d6..d2ed52e 100644 --- a/docs/content/docs/analysis/ANONYMIZATION-SUMMARY.md +++ b/docs/content/docs/analysis/ANONYMIZATION-SUMMARY.md @@ -42,7 +42,7 @@ pattern) but stay numeric for parsers that expect integer-looking IDs. An earlier anonymisation pass used `192.168.1.x` as its target. That range is RFC-1918 private space — perfectly valid on real networks, -which means a reader can't tell whether `192.0.2.10` is a +which means a reader can't tell whether `192.168.1.10` is a placeholder or a documented LAN address. RFC-5737 ranges fix that: because they're reserved for documentation only, any reader knows on sight that they don't represent a real device.