On 7/5/15, 7:26, "DNSOP on behalf of Steve Crocker" <dnsop-boun...@ietf.org on behalf of st...@shinkuro.com> wrote:
>3. (ICANN) Two letter Latin characters that have not yet been assigned by >the ISO 3166 maintenance agency but might be in the future. Names in >this subset may move to subset 7 to become active ccTLDs. Examples: > > xq 'pq' is a better example. 'xq' is classified as User Assigned, which means it has been assigned for use by anyone for their own purposes. 'pq' is (using Wikipedia's term) unassigned. In recognition of this, though, I'd lump all of the alpha-2 codes ([A-Z][A-Z]) into category 3, and call it informally "being at the mercy of the ISO 3166-1 Maintenance Agency." >4. (IETF) Names the IETF has formally recognized as reserved for >particular non-DNS uses. Names in this subset are effectively permanent. > (“Effectively permanent” means they are expected to remain in this >subset forever and there is no defined process for changing the status of >names in this subset.) Examples: > > example, local (Left in for the discussion later in this message.) >7. (ICANN) ccTLDs, both Latin and IDN. Names in this subset are expected >to last indefinitely. If they are taken out of service they move to >subset 8. Examples: > > jp, uk, na, xn--fzc2c9e2c The quirk I have here is the IDN Fast Track [https://www.icann.org/resources/pages/fast-track-2012-02-25-en] and trying to anticipate what names will be in that. The Latin ccTLD codes I can anticipate from category 3 above. But the IDN ccTLD names aren't distinguishable from other IDN names without consulting the Fast Track and even so, well I'll put this under - I don't understand if a name coming through the Fast Track might also be on a generic TLD track. As far as I know, if the Fask Track the only source of IDN ccTLD names? >8. (ICANN) Previously used TLDs that have been taken out of service. >Names in this subset must remain out of service for a very long time, >currently estimated at 50 years, to avoid unintended consequences. >Examples: > > cs Perhaps there's an 8-1/2: I've been told that the 11 IDN test TLDs which have been rescinded (NS records removed) are eligible to be reinstated if needed for further testing. "I've been told" means that I have never seen this in print and thus have no citation to give. >ISSUES > >o Should there be some sort of operational penalty for leakage of names >in subsets 2, 4, 5 and 8 into the public DNS, e.g. a slow response from >DNS servers? For the e.g., no. If just because that delaying an answer opens the time a cache can be poisoned. Others have mentioned this. But there's a wider issue suggested by this specific suggestion. What reaction should name servers have upon seeing a name in a certain category? Take category 4 - example and local. When running a tutorial/demo, I would expect to be able to use "example." as my TLD in live use of general purpose DNS software. In that case, example. should mean nothing special to the DNS. However, in the universe of registration, that as a TLD (application) is to be rejected. (But the name can be used 'down low' in the tree.) I don't expect the same for "local." When running the same tutorial/demo, I may want to use the functionality of "local." while running a name server on ::1 - using "local." in my name server configuration will cause some confusion. Are these categories "felt" in the DNS protocol layer or the registration service above it? Or in the resolution service? - - - In thinking about this, I have a number of past influences, mostly coming from DNSSEC development. One is seeing the impact of dealing with "expedient operational short cuts" that resulted in long-lasting architectural issues. Round robin was one (which I feel I keep harping about) that required DNSSEC validation to be able know how to reset the order of the records for the digital signature operation and then revert. Then there are other oddities, like CNAME processing's many quirks. From this I always ask - will the change be expected to be seen in name server code paths? Or will anything derived here be a registry accessed by applications inserting and/or retrieving data from the system? Another is the drive towards future proof-ness. How can any improvement drive towards a data-driven solution rather than a something that needs more code paths? Is the change compatible with current code paths, even past code paths? And, how much of this is about domain names and how much is about TLDs? Isn't this all about TLDs as where name spaces are rooted? (Or sub-rooted?) BTW, I've been trying to read back in time, as far back as RFC 799 "Internet Name Domains" and RFC 805. If there are earlier discussions, I'd like to know. Some of the pre-1034 RFCs are close to today's understanding, but Mill's 799 seems to have been passed by. The purpose of this is to determine what the intent of domain names were (originally), whether applications have appropriately stuck to that, whether the DNS of STD 13 is a subset of domain names or a superset of domain names, and how host names of RFC 1123 applies to all of this. In some sense, all of the problems are the use of host names in other forms. And in trying to put the horse in front of the cart, all of this seems to date back to email (pre-SMTP even) and how to address a mailbox somewhere. The usual data structures I think of are URI, X.509, and email headers and they are hostnames. But Tor's onion isn't, I think. This makes me think less about the DNS rules for domain names as the place to root all of this. But I'm not sure. To sum up, as much as the categorization is interesting, I'm not sure it sets up the equation properly - as far as eventual impact on code.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
