Clean up top dir.

[libradsec.git] / tools / README

diff --git a/tools/README b/tools/README
deleted file mode 100644 (file)
index 4e6d2bc..0000000
--- a/tools/README
+++ /dev/null
@@ -1,48 +0,0 @@
-Mail[1] to the radsecproxy mailing list Wed, 14 Apr 2010 from Stefan
-Winter explaining the radsec-dynsrv.sh and naptr-eduroam.sh scripts.
-
-------------------------------------------------------------
-Hi,
-
-the radsec-dynsrv.sh script right now looks up _radsec._tcp.$REALM. For
-eduroam, the production discovery will rely on S-NAPTRs of "s" type and
-subsequent SRVs.
-
-I have attached a preliminary version of the discovery script which
-takes this logic into account. It could use some public scrutiny (where
-"public" might very well evaluate to Kolbjørn Barmen, who wrote the SRV
-script and knows much more about bash scripting than I do *cough cough*).
-
-As with the other script, you call
-
-naptr-eduroam.sh <realm>
-
-If you need a test case, the DNS domain restena.lu has the NAPTR and the
-SRV record live in place. On my system, you get:
-
-> ./naptr-eduroam.sh restena.lu
-server dynamic_radsec.restena.lu {
-host radius-1.restena.lu:2083
-type TLS
-}
-
-with our live DNS data (radius-1.restena.lu isn't really
-production-ready yet though).
-
-If you're curious, the S-NAPTR for eduroam right now is
-
-x-eduroam:radius.tls
-
-with a possibility of a later IETF allocation of either
-
-aaa:radius.tls (probable)
-eduroam:radius.tls (wishful thinking)
-
-, in which case changing the script to use the new ones is trivial.
-
-Greetings,
-
-Stefan Winter
-------------------------------------------------------------
-
-[1] https://postlister.uninett.no/sympa/arc/radsecproxy/2010-04/msg00011.html