If you're looking at designing dynamic realms here are the parts we use that might not be preserved in all designs: * Being able to dynamically specify tls information * Per Alan's recommendation, being able to have home servers that are not part of the standard rbtrees, so we can avoid a security exposure. If two realms claim to be served by a server with IP address 192.0.2.23, we don't want one of these realms to be able to overwrite the key for the other. Either both keys will work for the same IP address, or someone is being dishonest, but it's important not to combine home servers in this instance just because they have the same IP and hostname * Being able to have the over-the-wire realm name different than the internal representation. (The suffix of the user-name attribute ends up not being the same as the realm name returned) * Being able to evaluate periodically with access to connection stats for the home servers whether a realm is still good or whether we want to dynamically contact it again