On Jul 6, 2015, at 5:08 PM, Edward Lewis <edward.le...@icann.org> wrote:
> 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. Thanks. I didn’t check the tables before writing. I was pretty sure xq wasn’t already assigned to a specific country or territory, but I didn’t think about a “1918” style designation of two letter codes. Perhaps we need another subset to put these into. It would be a “final” state in the sense that once a two letter code is put into that state, it can’t move to another state. And the purview would be the ISO 3166-1 Maintenance Agency. > 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.” Hmm… I understand your point, but I think it would feel odd to our audiences. If the ISO 3166-1 Maintenance Agency were to tinker with established codes, e.g. DE, JP, CN, etc., all hell would break loose. >> 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. I think this is a non-problem. Strings beginning with “x n - -“ are in subset 1 until they are moved into either subset 7 (Active ccTLD) or subset 6 (Active gTLD). It doesn’t matter whether they moved into the Active ccTLD subset because of the current FastTrack or some future process. > > As far as I know, if the Fask Track the only source of IDN ccTLD names? I believe this is true at present. There may be other processes in the future. > >> 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. Heh. Good point. Well, for other reasons I’ve been thinking we may need three additional subsets, and perhaps the experimental IDN TLDs would fit into one of these. The three are: o The two letter codes reserved by the ISO 3166-1 Maintenance Agency that will never be assigned to countries or territories, i.e. what you said above. This subset would be carved out of subset 3 and be a final state. o Names that have shown up in queries with some frequency but may subside in the future and hence may be available for assignment in the future. They would arrive into this subset from subset 1 (or possibly subset 3), and either return to the subset they came from or progress to subset 5. I would put the test IDNs into this subset. o Names that have been permanently excluded from use by both the IETF and ICANN and hence fall into both subsets 4 and 5. I think there’s value in keeping all of these subsets distinct from each other, it’s necessary to create a new subset for names that both groups have excluded. This would be a final state, arrived at either from subset 4 or subset 5. > >> 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? Interesting and informative. Thanks. This require splitting off a piece of subset 5 to create yet another subset. > - - - > > 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? I agree we don’t want to create unnecessary code paths. I don’t have enough context to contribute to the rest of your comments here, but I’m sure others do. Thanks, Steve > > 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. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
