RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)
Single label names are local in scope. Attempting to use them in a global context does not work. As the names in . get more interesting the probability of collisions with existing names goes up. Not many people choose two letter labels for the least significant parts of their host names unless they are choosing their initials. Single label hostnames are not globally unique. They SHOULD NOT be used in a context where globally unique names are required. Mark, With the understanding that I agree with everything you say above, there are some interesting problems Referring to the point Mark is making as a problem is a bit like saying that someone attempting to sell the Brooklyn Bridge has a problem. While the potential bridge purchaser may in fact very much desire to own the bridge, the problem is that the seller may not in fact have the right to sell it. That's really at the core of what Mark is arguing -- that various RFCs allocate single-label names for local use, and therefore that ICANN may not possess the right to sell that property to another party. (1) ICANN is well aware of the problem you mention As I understand it, they have explicitly decided to ignore that problem... Someone attempting to sell the Brooklyn Bridge can also explicitly decide to ignore the problem of whether they in fact own it. That won't make the problem go away. In this particular case, we are talking about RFCs that are included as requirements for purchase worth billions of dollars annually, as well as local names currently in local use by hundreds of millions of people. So we're not talking about selling a single Brooklyn Bridge here, but many. (2) Regardless of what some of us may think about the desirability (or not) of associating services with TLD names The issue is not desirability. Someone might very much desire to purchase the Brooklyn Bridge. It has many excellent qualities -- it is used by many people over the course of a day, it is a registered historical site making it of great interest to tourists, etc. The problem is whether the seller can establish title. So, much as I'd like it if we could say Single label names are local in scope...does not work Mark's point is that several RFCs already say this. So what we have here isn't really an technical argument or one about desirability -- it's a property rights argument. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)
--On Friday, 04 July, 2008 10:49 -0700 Bernard Aboba [EMAIL PROTECTED] wrote: Single label names are local in scope. Attempting to use them in a global context does not work. As the names in . get more interesting the probability of collisions with existing names goes up. Not many people choose two letter labels for the least significant parts of their host names unless they are choosing their initials. Single label hostnames are not globally unique. They SHOULD NOT be used in a context where globally unique names are required. Mark, With the understanding that I agree with everything you say above, there are some interesting problems Referring to the point Mark is making as a problem is a bit like saying that someone attempting to sell the Brooklyn Bridge has a problem. While the potential bridge purchaser may in fact very much desire to own the bridge, the problem is that the seller may not in fact have the right to sell it. That's really at the core of what Mark is arguing -- that various RFCs allocate single-label names for local use, and therefore that ICANN may not possess the right to sell that property to another party. (1) ICANN is well aware of the problem you mention As I understand it, they have explicitly decided to ignore that problem... Someone attempting to sell the Brooklyn Bridge can also explicitly decide to ignore the problem of whether they in fact own it. That won't make the problem go away. In this particular case, we are talking about RFCs that are included as requirements for purchase worth billions of dollars annually, as well as local names currently in local use by hundreds of millions of people. So we're not talking about selling a single Brooklyn Bridge here, but many. (2) Regardless of what some of us may think about the desirability (or not) of associating services with TLD names The issue is not desirability. Someone might very much desire to purchase the Brooklyn Bridge. It has many excellent qualities -- it is used by many people over the course of a day, it is a registered historical site making it of great interest to tourists, etc. The problem is whether the seller can establish title. So, much as I'd like it if we could say Single label names are local in scope...does not work Mark's point is that several RFCs already say this. So what we have here isn't really an technical argument or one about desirability -- it's a property rights argument. Not really. ICANN isn't selling single-label domains. They are selling (and I believe selling is probably now the correct term) plain, ordinary, TLD delegations. If I get one of those and populate the TLD zone only with delegation records, there are no problems with what ICANN has done at all, whether you describe it a property rights or in some other way. On the other hand, if they delegate one and the enterprise that buys it chooses to populate the zone with service records, then ICANN's position will certainly be that any inability to use those service records isn't ICANN's problem -- any more than difficulties using .museum or .aero were ICANN's problem when those to whom those domains were delegated discovered that a lot of applications software thought that the one TLD label of more than three characters was ARPA. So the problem isn't whether some string not listed in 2606 can be allocated, it is how it is used after it is allocated. And _that_ situation has a lot more to do about buyer beware and understanding of conflicting expectations about use than it does about ownership. john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)
Not really. ICANN isn't selling single-label domains. They are selling (and I believe selling is probably now the correct term) plain, ordinary, TLD delegations. If I get one of those and populate the TLD zone only with delegation records, there are no problems with what ICANN has done at all, whether you describe it as a property right or in some other way. Agreed. On the other hand, if they delegate one and the enterprise that buys it chooses to populate the zone with service records, then ICANN's position will certainly be that any inability to use those service records isn't ICANN's problem -- any more than difficulties using .museum or .aero were ICANN's problem when those to whom those domains were delegated discovered that a lot of applications software thought that the one TLD label of more than three characters was ARPA. Is generic buyer beware disclaimer really sufficient here? The problem isn't just inability to use -- it's that other parties exist who may claim the usage right, and provide citations to RFCs to back up their claim. For example, typing http://brooklynbridgepark/ into a browser utilizing a resolver compliant with RFC 1536 will bring you to the web site of Brooklyn Bridge Park Conservancy, assuming that .org is in your searchlist. If ICANN sells the brooklynbridgepark TLD delegation to another party who populates the zone with service records, should that party expect that http://brooklynbridgepark/ will now resolve to their site? RFC 1536 says no. Similar problems will occur when the party purchasing the brooklynbridgepark TLD attempts to use the single-label name brooklynbridgepark for other uses, such as network access. And _that_ situation has a lot more to do about buyer beware and understanding of conflicting expectations about use than it does about ownership. Today there is a distinction between types of property rights - surface, subsurface, or rights to the air above a property. As noted at http://geology.com/articles/mineral-rights.shtml this was not always the case: If we go back in time to the days before drilling and mining, real estate transactions were fee simple transfers. However, once subsurface mineral production became possible, the ways in which people own property became much more complex. If the analogy holds (and I'm not a lawyer, so I have no idea if it does), then we could be talking about a fee simple transfer in a situation where sub-rights may be claimed to belong to someone else. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)
So the problem isn't whether some string not listed in 2606 can be allocated, it is how it is used after it is allocated. And _that_ situation has a lot more to do about buyer beware and understanding of conflicting expectations about use than it does about ownership. john I really wish it was *just* buyer beware. If http://museum/ only works for some clients and not other then there really isn't a problem. By works here I mean connects to 83.145.59.103 or nowhere. The problem is that it isn't just buyer beware. If the buyer adds any records are looked up by search mechanisms as a part on normal application activity, A, and MX are simple examples, then *ALL* the users of the Internet need to be aware that they are there. This is a security problem, not a buyer beware problem. This is a namespace clash and namespace clashes are bad for many reasons. Now as far as I can see there are two solutions which attack the problem from different ends. 1. ban the adding of any records which meet the above criteria. 2. rewrite resolvers to not lookup single labels against the root. Note banning would have to be described is a manner that didn't preclude the negative advertisement of a service. It would also have to be writen to exclude records that a looked up with a prefix added. Also what is the penalty for adding banned records? Mark ; DiG 9.3.4-P1 museum ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 61108 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 0 ;; QUESTION SECTION: ;museum.IN A ;; ANSWER SECTION: museum. 86034 IN A 83.145.59.103 ;; AUTHORITY SECTION: museum. 22099 IN NS ns-ext.vix.com. museum. 22099 IN NS ns1.getty.edu. museum. 22099 IN NS nic.icom.org. museum. 22099 IN NS ns.icann.org. museum. 22099 IN NS nic.museum. ;; Query time: 3 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Sat Jul 5 08:22:30 2008 ;; MSG SIZE rcvd: 162 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Services and top-level DNS names (was: Re: Update of RFC 2606 based on the recent ICANN changes ?)
Bernard, I'm going to try to respond to both your note and Mark's, using yours as a base because it better reflects my perspective. Before I go on, I think the three of us are in agreement about the situation. The question is what can (or should) be done about it. --On Friday, 04 July, 2008 13:52 -0700 Bernard Aboba [EMAIL PROTECTED] wrote: Not really. ICANN isn't selling single-label domains. They are selling (and I believe selling is probably now the correct term) plain, ordinary, TLD delegations. If I get one of those and populate the TLD zone only with delegation records, there are no problems with what ICANN has done at all, whether you describe it as a property right or in some other way. Agreed. On the other hand, if they delegate one and the enterprise that buys it chooses to populate the zone with service records, then ICANN's position will certainly be that any inability to use those service records isn't ICANN's problem -- any more than difficulties using .museum or .aero were ICANN's problem when those to whom those domains were delegated discovered that a lot of applications software thought that the one TLD label of more than three characters was ARPA. Is generic buyer beware disclaimer really sufficient here? The problem isn't just inability to use -- it's that other parties exist who may claim the usage right, and provide citations to RFCs to back up their claim. For example, typing http://brooklynbridgepark/ into a browser utilizing a resolver compliant with RFC 1536 will bring you to the web site of Brooklyn Bridge Park Conservancy, assuming that .org is in your searchlist. We agree so far, but let me note that 1536 is an informational document. We generally don't claim that systems are expected to be compliant with those. If ICANN sells the brooklynbridgepark TLD delegation to another party who populates the zone with service records, should that party expect that http://brooklynbridgepark/ will now resolve to their site? RFC 1536 says no. Similar problems will occur when the party purchasing the brooklynbridgepark TLD attempts to use the single-label name brooklynbridgepark for other uses, such as network access. Yes. And what I fear is that some applications and implementations will support services on brooklynbridgepark as a TLD and others will start searching. Yes, that goes well beyond buyer beware. And _that_ situation has a lot more to do about buyer beware and understanding of conflicting expectations about use than it does about ownership. Today there is a distinction between types of property rights - surface, subsurface, or rights to the air above a property. As noted at http://geology.com/articles/mineral-rights.shtml this was not always the case: If we go back in time to the days before drilling and mining, real estate transactions were fee simple transfers. However, once subsurface mineral production became possible, the ways in which people own property became much more complex. Sure. But I know who to call --title insurance companies, lawyers, judges, etc.-- when your mineral rights intrude on my surface building rights or vice versa. If the analogy holds (and I'm not a lawyer, so I have no idea if it does), then we could be talking about a fee simple transfer in a situation where sub-rights may be claimed to belong to someone else. But this gets back exactly to both the rude comments I've been making about ICANN and the example I tried to construct (not carefully enough) about a Microsoft TLD. Let's take the second one first. Suppose that Microsoft, at a high corporate level, decided that they wanted to have a TLD called microsoft and that they wanted to attach services to it. You would advise against that. I would advise against that. So would others. We would cite 1535, a number of other RFCs, and general bad taste. My assumption is that Microsoft would give it up -- even if they wanted the domain, they wouldn't expect to locate services at the top level. But suppose some marketing force took over and overwhelmed those arguments. The thing that makes Microsoft relevant to this example is that the company distributes a very popular browser and a couple of very popular email clients. Were a corporate decision to be made to support services on a TLD, at least services on that one special-case TLD, than that decision could extend to modifications to those application programs that would permit access to those services. Again, I don't expect that to happen, but it carries over directly into the main point I'm trying to make, which is that property rights are a relevant metaphor for this situation only if there is some basis or authority for enforcing those rights. As I've pointed out in other contexts recently, the last few times I've tried to call the Protocol Police, they didn't answer. Ultimately, I'm concerned about what the IETF can usefully do
