Re: [DNSOP] new DNS classes

[John C Klensin <[e-mail]>]

--On Thursday, July 6, 2017 00:36 -0400 Phillip Hallam-Baker
<[e-mail]> wrote:

> There are changes to the DNS that are practical and those that
> are not. For better or worse, I can't see any way that
> teaching DNS to use new classes makes any sense at this point.
> The only point at which it would have made sense was when
> internationalization happened. But the path chosen makes more
> sense.

As the author of the I-D that proposed using a Class to deal
with internationalization, it would not have worked, and the two
important reasons are perhaps worth understanding.   First, that
approach included a transition strategy that permitted legacy
clients and registrations to keep working in a way that users
would see as normal.  But that strategy depends on CLASSes
sharing the same root and hierarchy.  At Paul points out, that
interpretation of 1034/1035 is not universally accepted and
implemented.  Second, IIR, we intended that the different CLASS
allow a different set of matching rule assumptions and
conditions.  Because labels must generally be interpreted and
compared before CLASS values are accessed and, perhaps more
important, in optimization of databases, one probably needs
label types to do that, not CLASSes.   And label types don't
have a good history.

> ICANN will manage whatever bits of the DNS consensus agrees it
> should manage. The only events likely to break consensus would
> be an attempt by some government to strong arm ICANN into a
> breach of faith with the community and succeeding or some
> really spectacular peculation.

We disagree about that, but I no proof that my impressions/
predictions are any better than yours.

> It seems to me that if people want to do anything new with DNS
> that they should use prefixes, new RRs or both as the
> mechanism, not the class which is limited anyway.
> 
> DNS is not a full service directory. Nor does it need to be. A
> UDP packet is big enough for a link, a fingerprint and a
> digital signature. That is all that you ever need.

As I think you know, I just love "all you will ever need"
statements about the Internet (and its predecessors) although my
favorite remains "we will never need more than 8 bits of address
space".


> 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 :-(

    john