On Jan 8, 2014, at 7:06 PM, Robert Elz <kre@xxxxxxxxxxxxx> wrote: > Date: Wed, 8 Jan 2014 13:07:12 -0800 > From: manning bill <bmanning@xxxxxxx> > Message-ID: <94F13021-48B9-4CE9-995A-1081DC75A52D@xxxxxxx> > > | There can be/ have been multiple roots in the DNS - HOWEVER, there is > | a always a single root _per class_. > > I'm not sure that's correct. Nor do I know it is incorrect. Classes > were (and are) so under-specified that exactly how they were intended to > work (if there was ever a clear and understood interpretation of that) > seems lost in the mists of time. > <snip> > There really is no way out of this - people wanting multiple roots really > just want to change who controls that rot - usually to someone they consider > friendly to themselves (like themselves) rather than someone that they consider > the enemy (ietf/iana/icann/...) > > kre > The fundamental problem with multiple namespaces we have now is "how does one express what namespace the name is in?" Some people have tried to do this with postfix (eg. .onion or .local) Others have said look first in namespace X then in namespace Y (MDNS) Another signifiant problem is how to provide a programming interface to lookups in the new namespaces, for expediency people frequently start out by extending the functions that look up in DNS. Personally I think that if we want to to become serious about supporting multiple namespaces we need guidelines on: How new namespaces are identified How to "register" namespace identifiers and operators of the namespace root (if applicable) as well as how names are registered/selected in the namespace. I use the word register here loosely, as I do not know if anything other than centralized service will work to avoid conflicts. On top of existing name lookup functions we need a multiplexer function that understands how to access the namespace and calls appropriate lookup functions Automated discovery of how to use new namespaces without this new namespaces will take a long time to deploy. How/If to support Meta Namespaces i.e. check a series of namespaces in either in a particular order and use first match OR lookup in parallel in a number of name spaces. The difference in lookup function could be DNS vs DNS for different class vs Distributed hash. In the first and second case we can in theory use the same functions but with different starting point and different cache (if one is present) in the third case a different function is needed. <potentially moving into solution space to make a point, this is NOT A FORMAL PROPOSAL> No matter how we do the identification of name spaces other than DNS in class IN, postfix IMHO is the wrong answer. One possibility is to use a prefix, something like GNU##freedom.eff (## picked at random as separator) to express that lookup should take place in the namespace GNU for host freedom.eff. The advantage of a prefix is that it appears in a better location for a namespace multiplexing function when it is parsing the string and in theory the namespace multiplexing function does not need to understand the rest of the string past the namespace identifier. Thus in this notation DNS###tools.ietf.org is the corresponding expression for looking up the host name: tools.ietf.org in class IN of DNS, On a billboard or web page this would become either https://DNS##tools.ietf.org or DNS##https://tools.ietf.org depending if we put the protocol or Namespace first. Working out a timeline to complete an effort to make all of this work is left as an exercise to the reader Olafur