[discuss] Root servers yet again (Re: Roadmap for globalizing IANA)

[David Conrad]

Elisabeth,

As has been pointed out to me privately a couple of times now, I missed one bit:

On Mar 4, 2014, at 2:42 AM, Elisabeth Blanconil <info at vgnic.org> wrote:
> The DNS IETF model supports 65,365 roots, one for each class.

While the IETF specified classes in RFC 1035, the specification is incomplete and the DNS as currently defined and implemented does _NOT_ support "65,536 roots, one for each class".  

It is, of course, entirely possible to complete the specification of classes and thereby allow the DNS to fully support them, but this would require doing actual work. It also would not address the more fundamental problem of how users of applications such as web browsers, mail clients, etc., would be able to specify _which_ class a particular domain name should be looked up in.  That is, since there is no way in _all_ current applications to specify a class, how is a user going to say "look up www.example.com in class "EB" instead of class "IN"?

> The sole class that people discuss on this list is the "IN" ICANN/NTIA class. 

The "IN" class is _NOT_ the "ICANN/NTIA class".  The definition of the IN class, as documented at https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml is for "Internet".  The reason it is the sole class discussed is simply because it is the only class actually being used (ignoring the diagnostic use of class CH). If you believe another class should exist, allocation of new classes is defined by the IETF to be "IETF Review":

     IETF Review - (Formerly called "IETF Consensus" in
            [IANA-CONSIDERATIONS]) New values are assigned only through
            RFCs that have been shepherded through the IESG as AD-
            Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
            intention is that the document and proposed assignment will
            be reviewed by the IESG and appropriate IETF WGs (or
            experts, if suitable working groups no longer exist) to
            ensure that the proposed assignment will not negatively
            impact interoperability or otherwise extend IETF protocols
            in an inappropriate or damaging manner.

            To ensure adequate community review, such documents are
            shepherded through the IESG as AD-sponsored (or WG)
            documents with an IETF Last Call.

Regards,
-drc



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://1net-mail.1net.org/pipermail/discuss/attachments/20140304/59f9ed67/signature.asc>