On Thu, Jul 06, 2017 at 11:15:34AM -0400, John C Klensin wrote: > --On Thursday, July 6, 2017 00:36 -0400 Phillip Hallam-Baker > <phill@xxxxxxxxxxxxxxx> wrote: > > The X.500 and UDDI models were broken because there is no > > point in putting information into a directory if the service > > can return it in a service handshake. > > The X.500 and UDDI approaches failed because... sorry, I lost > count of the reasons :-( The complexity and general ugliness of x.400/x.500 naming (indeed, the inability to correctly and canonically represent such names in TEXT!) are all the reason anyone ever should have needed. (See what I did there?) And yet some bits of that horrible thing are still with us (PKIX, LDAP), though of course with various adaptations (eg, SANs) to make them suck less and more Internet-like. DNS is not a directory, but when your only off-the-shelf choices are DNS or LDAP... I'll contribute this extension to your earlier argument about root sharing/non-sharing. I think new classes will only ever be feasible provided that a) they share roots with IN, or b) are like a local HS not really meant to federate at all (thus root sharing / alt. roots would be moot). (a) classes would basically be an RR type extension field for IN. (b) is probably not worth considering -- the lack of security in HS was a big reason for not using it, and so DNSSEC (or something like it) would be a requirement in order to use an HS-like class, but if you'll want DNSSEC then you'll want delegation hierarchy anyways and thus you'll want shared roots, making any HS-like classes just IN-class RR type extension fields. It's easier to develop a new protocol for (b) than to shove whatever it is into DNS. So new classes will only be useful to extend the IN-class RR type namespace. We won't get there. New RR types can be very difficult to deploy due to lack of interest by registrars and domain hosting services. TXT RRs forever. :( Cheers, Nico --