Re: reserved names draft, was Defining the existence of non-existent domains
On the table at 2.1.4 you need to add LATNIC that seems to be also reserved by ICANN, not sure why they missed it on the DAG but it's on every single Registry Agreement. For 2.2.4, I believe all the names listed in 2.1.4 are also reserved for second level domains and you are still missing a place where to record the names reserved by each Registry (if any) and listed on each individual Registry Agreement (http://www.icann.org/en/registries/agreements.htm), for example ABOUT.INFO, not sure if IANA has to be responsible to keep the list for them but it would be nice if they are all listed in a single place. What about tagged domain names like bq--1k2n4h4b or xn--ndk061n and one or two character names ? Regards Jorge On Tue, Jan 5, 2010 at 12:20 AM, John Levine jo...@iecc.com wrote: I've done another version of my reserved names draft. This time it proposes four registries: 1. Reserved and special top level names. ARPA is special, the others are reserved. 2. Reserved and special second level names. EXAMPLE.COM, ORG, and NET are reserved in the RFCs. ICANN has many more that I'd hope they would add to the regsistry, e.g., EXAMPLE.everything else. I'm not aware of any special 2LDs, but who knows what might be lurking. 3. Names in .ARPA. This updates the list in RFC 3172 and makes it a registry. They're all special unless SINK.ARPA is approved in which case it would be reserved. 4. Names that are special elsewhere. _service, _DOMAINKEY, etc. I'd be delighted to take this out if the project to codify service and protocol names agrees to include the handful of other _blah names defined in RFCs. http://www.ietf.org/internet-drafts/draft-levine-reserved-names-registry-01.txt R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: reserved names draft, was Defining the existence of non-existent domains
These are reasonable things to add, but I'm waiting to see if there's agreement that it's worth moving forward. On the table at 2.1.4 you need to add LATNIC that seems to be also reserved by ICANN, not sure why they missed it on the DAG but it's on every single Registry Agreement. You're right, but since it's not in the guidebook, I have nothing to document it. Perhaps this shows why it would be a good idea to create these registries, so missing entries are more immediately evident. For 2.2.4, I believe all the names listed in 2.1.4 are also reserved for second level domains and you are still missing a place where to record the names reserved by each Registry (if any) and listed on each individual Registry Agreement (http://www.icann.org/en/registries/agreements.htm), for example ABOUT.INFO, not sure if IANA has to be responsible to keep the list for them but it would be nice if they are all listed in a single place. What about tagged domain names like bq--1k2n4h4b or xn--ndk061n and one or two character names ? They're all in appendices to the various gTLD and sTLD agreements. I'm happy to add them but since it's a lot of work I'll wait and see where we're going. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: reserved names draft, was Defining the existence of non-existent domains
At 05:39 05-01-2010, Jorge Amodio wrote: On the table at 2.1.4 you need to add LATNIC that seems to be also reserved by ICANN, not sure why they missed it on the DAG but it's on every single Registry Agreement. PSO might also have to be added then. According to information published by IANA, these two names are still reserved. Transparency, once lost, is hard to regain [1]. We could reflect on that as we discuss about reserved names. Some people might argue that: The Domain Name System (DNS) provides an essential service on the Internet, mapping structured names to a variety of different types of [2] money making schemes. I can only hope that the domain name policy makers have read RFC 4367. Defining a registry for reserved names can be a perilous exercise. There are different viewpoints about whether the authority to do so is the Internet Engineering Task Force, the Internet Architecture Board, the Internet Corporation for Assigned Names and Numbers or the Internet Assigned Numbers Authority. There's the protocol angle where RFC 2860 gets invoked as in BCP 52. There's RFC 2606 which predates RFC 2860. There was a draft in 2005 (draft-eastlake-2606bis) which raised questions similar to the current draft about reserved names. There was also another draft (draft-ellermann-idnabis-test-tlds) written in 2008 which was an attempt to update RFC 2606 based on recent ICANN changes. Regards, -sm 1. http://www.rfc-editor.org/rfc/rfc4924.txt 2. http://www.rfc-editor.org/rfc/rfc4367.txt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
John Levine wrote on the IETF main list: [ re _proto and _service names ] ... Yes, I noticed that. As far as I can tell, the only _name entries other than SRV protocols and services are _domainkey, _vouch, and _adsp. It would be nice to collect them all in one place. Yes, these underscore labels are already in our focus for the upcoming other draft that Olafur had pre-announced on this thread. But don't forget, _adsp is subordinate to _domainkay, per RFC 5617. Since underscore labels are not considered normal DNS labels for domains representing (roughly) physical hosts and networks, everything below the topmost underscore label should not need to go in a central repository for underscore labels but be pointed to by the documentation referenced for the upper label in such repository. Also 3GPP has tentatively defined a bulk of non-IETF protocol related underscore labels for DNS based service discovery. One goal of the upcoming second draft will be to advice SDOs outside the IETF on how to 'socialize' with the IETF and use 'canonical' underscore labels. Your draft (draft-levine-reserved-names-registry) IMO should focus on the normal reserved labels. Kind regards, Alfred Hönes. P.S.: For everybody who wants more detailed information on draft-gudmundsson-dnsext-srv-clarify-00 than the I-D abstract but does not have the time to read the whole draft: please look at http://ops.ietf.org/lists/namedroppers/namedroppers.2009/msg03189.html (or the copies of that message posted to tsvwg and apps-discuss at ietf.org today) for a one-page explanation of that draft and its relations to the companion documents (in progress). -- +++ | TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. | | Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 | | D-71254 Ditzingen | E-Mail: a...@tr-sys.de | +++ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: reserved names draft, was Defining the existence of non-existent domains
I've done another version of my reserved names draft. This time it proposes four registries: 1. Reserved and special top level names. ARPA is special, the others are reserved. 2. Reserved and special second level names. EXAMPLE.COM, ORG, and NET are reserved in the RFCs. ICANN has many more that I'd hope they would add to the regsistry, e.g., EXAMPLE.everything else. I'm not aware of any special 2LDs, but who knows what might be lurking. 3. Names in .ARPA. This updates the list in RFC 3172 and makes it a registry. They're all special unless SINK.ARPA is approved in which case it would be reserved. 4. Names that are special elsewhere. _service, _DOMAINKEY, etc. I'd be delighted to take this out if the project to codify service and protocol names agrees to include the handful of other _blah names defined in RFCs. http://www.ietf.org/internet-drafts/draft-levine-reserved-names-registry-01.txt R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
On Mon, 28 Dec 2009, John Levine wrote: But I see little wisdom in adding another does-not-exist name with semantics not meaningfully different from .INVALID or FOO.INVALID. I think the semantics are meaningfully different, in that applications are allowed to know that .invalid is special, but should not know that sink.arpa (or nonexistent.arpa) is special. --apb (Alan Barrett) ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
In article 20091230172534.gb1...@apb-laptoy.apb.alt.za you write: On Mon, 28 Dec 2009, John Levine wrote: But I see little wisdom in adding another does-not-exist name with semantics not meaningfully different from .INVALID or FOO.INVALID. I think the semantics are meaningfully different, in that applications are allowed to know that .invalid is special, but should not know that sink.arpa (or nonexistent.arpa) is special. Aren't we arguing in circles here? The original proposal was for an RFC to mark SINK.ARPA as special. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
On 2009-12-30, at 14:13, John Levine wrote: Aren't we arguing in circles here? The original proposal was for an RFC to mark SINK.ARPA as special. To be slightly pedantic, it was a proposal to make a policy decision that the name SINK.ARPA should not be made to exist by those responsible for administration of the ARPA zone as described in 3172. The proposal did not seek to update the behaviour of protocols or applications to treat SINK.ARPA any differently from any other name in the DNS. Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
Aren't we arguing in circles here? The original proposal was for an RFC to mark SINK.ARPA as special. The proposal did not seek to update the behaviour of protocols or applications to treat SINK.ARPA any differently from any other name in the DNS. Right. For all practical purposes, its treatment would be identical to .INVALID. Technically there's nothing special, administratively the manager would promise never to delegate it. Regards, John Levine, jo...@iecc.com, Primary Perpetrator of The Internet for Dummies, Information Superhighwayman wanna-be, http://www.johnlevine.com, ex-Mayor More Wiener schnitzel, please, said Tom, revealingly. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
On 2009-12-27, at 20:16, John Levine wrote: It seems to me that if we think it's a good idea to specify a domain name that doesn't exist, we're better off clarifying the status of the ones already specified rather than inventing new ones. Since the people who manage .ARPA are the exact same people who manage the root (IANA, operated by ICANN, in both cases), one is as likely to flake as the other. Operational management is not what I was talking about (assuming it was my recent comments that triggered that observation). I was expressing concern over policy. I think the policy that governs the administration of the ARPA zone is far easier to characterise in an IETF context than that of the root zone. In fact, ICANN is quite aware of the reserved names list. In the current draft of the application process, one of the steps is to check to see if a proposed name is one of the Reserved ones, in which case the application fails immediately. Here's their reserved list: AFRINIC IANA-SERVERS NRO ALAC ICANNRFC-EDITOR APNICIESG RIPE ARIN IETF ROOT-SERVERS ASO INTERNIC RSSAC CCNSOINVALID SSAC EXAMPLE* IRTF TEST* GAC ISTF TLD GNSO LACNIC WHOIS GTLD-SERVERS LOCALWWW IAB LOCALHOST IANA NIC Again, I am not involved in existing or proposed future policy for the root zone, but I'm confused as to what you are attempting to achieve through draft-levine-reserved-names-registry-00. If you're proposing to ICANN that they cede control over the reserved names list for the root zone to an IANA registry controlled by an IETF process (RFC publication, according to your current text), then this doesn't seem like the venue to propose that. If you're proposing that the IETF document a list of names that has change control and authorship homed within ICANN, then I'm not sure what the benefit of that is. If you're making some other proposal, then I am currently missing it. Could you explain? Joe ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
On Tue, Dec 29, 2009 at 01:02:54PM -0500, Joe Abley wrote: If you're proposing that the IETF document a list of names that has change control and authorship homed within ICANN, then I'm not sure what the benefit of that is. Setting aside the mind-bending metaphysical consequences of the subject line in this thread, I actually think it would be a good idea if there were, somewhere, a list of undelegated top-level names for which change control and (policy) authorship nevertheless lie within ICANN. At the moment, the canonical list of the reserved names from ICANN's point of view is buried inside a document that many people have no reason to consult, because they're not trying to get a new top level delegation. It therefore seems to me to be not a bad idea to have an RFC or IANA registry for the reserved names, in ICANN parlance. It would also be good if some operational rules about what reserved names means were in an RFC somewhere (for instance, are there different classes of reserved names? Why? Do they come in and out of existence depending on other states of the world? Can they be resolved on the Internet? And so on. Depending on who was speaking, in my experience, these distinctions were not always made.) I'm actually indifferent to the publication means for this, though -- an RFC, an ICANN document that stands on its own, whatever -- but since we have IANA registries already that seems to me to be the obvious locus for yet another list. A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
On Tue, Dec 29, 2009 at 12:16 PM, Andrew Sullivan a...@shinkuro.com wrote: On Tue, Dec 29, 2009 at 01:02:54PM -0500, Joe Abley wrote: If you're proposing that the IETF document a list of names that has change control and authorship homed within ICANN, then I'm not sure what the benefit of that is. Setting aside the mind-bending metaphysical consequences of the subject line in this thread, I actually think it would be a good idea if there were, somewhere, a list of undelegated top-level names for which change control and (policy) authorship nevertheless lie within ICANN. At the moment, the canonical list of the reserved names from ICANN's point of view is buried inside a document that many people have no reason to consult, because they're not trying to get a new top level delegation. I believe that putting together a static list of something that is not clearly defined when there is no clear policy for adding/removing items from the list and no clear authority defined to execute the policy and responsible to keep the list updated will make the list useless on day D-1. Not only those reserved names are buried in an ICANN's *draft* document, as I mentioned on a previous message the current policy under discussion includes language to let registries of new gTLDs to create at its discretion additional reserved names within their gTLD, not specifying even at which level in the DNS tree the name might be. Also each registry agreement may include an specific appendix like in http://www.icann.org/en/tlds/agreements/verisign/appendix-06-01mar06.htm which states for each TLD/gTLD what names or particular constructs are reserved, such as one/two character or tagged domains with hyphens in the third and fourth char positions that I don't believe the proposed draft mentions. Perhaps instead of a static list a more complete fyi document could describe who has the authority to reserve names, how, and where the pertinent information can be obtained. I believe there is some work related to EPP about how registrars/registries exchange info about reserved names but I don't recall the specifics right now. My .02 Jorge ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
It therefore seems to me to be not a bad idea to have an RFC or IANA registry for the reserved names, in ICANN parlance. It would also be good if some operational rules about what reserved names means were in an RFC somewhere (for instance, are there different classes of reserved names? Why? Yes, that's what I'm trying to get at. As far as I can tell, there are at least three different kinds of reserved names. Names like .INVALID and .TEST are reserved forever and will never be delegated. Names like .IETF and .RIPE are names of identified Internet infrastructure organizations who could in principle have the name delegated to them. Names like .QQ are reserved until some third party (ISO 3166 in this case) says something about them. There are probably also names that are implicitly reserved like .123 or .XX--ABC (where the two letters in XX-- are anything other than xn) because of likely technical problems if they were used. And there appear to be names like single characters which are reserved until ICANN decides what to do about them. There's also one special purpose TLD, .ARPA, which is more or less delegated to the IAB although managed by IANA. For second-level domains, there are the three EXAMPLE names reserved by RFC2606, a fair number of names reserved by ICANN policy (single letters in gTLDs other than the few pre-ICANN ones), or by terms in gTLD contracts. Other than the EXAMPLEs I don't think any of those reservations are expected to be permanent. This is all reasonably well known to people familiar with ICANN folklore, but it sure would be nice to have it written down in one place so we can have an idea of what they are. I'm actually indifferent to the publication means for this, though -- an RFC, an ICANN document that stands on its own, whatever -- but since we have IANA registries already that seems to me to be the obvious locus for yet another list. IANA seems the most reasonable place to me, too. The trick is getting ICANN to agree to maintain its contents or at least contribute their entries to it. There's the somewhat separate issue of _foo tags used in SRV and other non-host records. That seems politically and technically straightforward, give or take liason with the group enumerating service and protocol names for SRV. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
On Tue, Dec 29, 2009 at 01:10:42PM -0600, Jorge Amodio wrote: I believe that putting together a static list of something that is not clearly defined when there is no clear policy for adding/removing items from the list and no clear authority defined to execute the policy and responsible to keep the list updated will make the list useless on day D-1. Which is why I think setting up an IANA registry makes sense: the setting up of the registry forces one to define all of that too. I believe there is some work related to EPP about how registrars/registries exchange info about reserved names but I don't recall the specifics right now. AFAIK there is no definition of reserved names in any of the EPP specifications. Are you referring to some other forum other than the IETF? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
Hi, On Dec 29, 2009, at 11:56 AM, John Levine wrote: There's also one special purpose TLD, .ARPA, which is more or less delegated to the IAB although managed by IANA. RFC 3172 is pretty explicit about how ARPA is managed: The Internet Architecture Board (IAB), in cooperation with the Internet Corporation for Assigned Names and Numbers (ICANN), is currently responsible for managing the Top Level Domain (TLD) name arpa. and As noted in section 3 of this document, the IAB may request the IANA to delegate the sub-domains of arpa in accordance with the IANA Considerations section of an IETF Standards Track document. IANA seems the most reasonable place to me, too. The trick is getting ICANN to agree to maintain its contents or at least contribute their entries to it. As it would seem to be in ICANN's best interest to ensure the contents of the list are maintained, I don't expect this to be too challenging. Aside from the list itself, what I personally think would be helpful would be a clear and mutually agreed process by which labels would be added/removed from the list. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
I believe that putting together a static list of something that is not clearly defined when there is no clear policy for adding/removing items from the list and no clear authority defined to execute the policy and responsible to keep the list updated will make the list useless on day D-1. Which is why I think setting up an IANA registry makes sense: the setting up of the registry forces one to define all of that too. I see your point. We also need to remember that some names are based on rules and not static strings. I believe there is some work related to EPP about how registrars/registries exchange info about reserved names but I don't recall the specifics right now. AFAIK there is no definition of reserved names in any of the EPP specifications. Are you referring to some other forum other than the IETF? Didn't cross reference with any drafts or ietf-wg mailing lists, but the text of the proposed new registry agreement says (page 197 of DAGv3): quote 4.5 Object Statuses. RFC 4930 (EPP) and related RFCs, see [1], [2], [3], [4] indicate permissible status codes for various registry objects. Additionally the status “reserved” is allowed for domains; it is used to indicate a reserved name on behalf of the Registry or ICANN. 4.6 Reserved Name Handling. Registries typically have a set of names reserved on behalf of themselves or IANA. Reserved names must be included in the DOMAIN file, and have the special reserved status associated with them in the DOMSTATUS file to indicate that they are reserved. /quote For the references 1,2,3,4 the doc says: quote [1] Extensible Provisioning Protocol (EPP), http://www.rfc-editor.org/rfc/rfc4930.txt [2] EPP Domain Name Mapping, http://www.rfc-editor.org/rfc/rfc4931.txt [3] EPP Host Mapping, http://www.rfc-editor.org/rfc/rfc4932.txt [4] EPP Contact Mapping, http://www.rfc-editor.org/rfc/rfc4933.txt /quote Jorge ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
On Tue, Dec 29, 2009 at 1:56 PM, John Levine jo...@iecc.com wrote: It therefore seems to me to be not a bad idea to have an RFC or IANA registry for the reserved names, in ICANN parlance. It would also be good if some operational rules about what reserved names means were in an RFC somewhere (for instance, are there different classes of reserved names? Why? Yes, that's what I'm trying to get at. As far as I can tell, there are at least three different kinds of reserved names. Names like .INVALID and .TEST are reserved forever and will never be delegated. Names like .IETF and .RIPE are names of identified Internet infrastructure organizations who could in principle have the name delegated to them. Names like .QQ are reserved until some third party (ISO 3166 in this case) says something about them. Remove the leading dots, ICANN and IANA related names are reserved at 2nd and all levels. Current registry agreement says: Labels Reserved at All Levels. The following names shall be reserved at the second level and at all other levels within the TLD at which Registry Operator makes registrations Jorge ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
Remove the leading dots, ICANN and IANA related names are reserved at 2nd and all levels. In ICANN's sTLD and gTLDs, yes, in most countries' ccTLDs, no, in .ARPA, who knows? R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
On Tue, Dec 29, 2009 at 3:20 PM, John R. Levine jo...@iecc.com wrote: Remove the leading dots, ICANN and IANA related names are reserved at 2nd and all levels. In ICANN's sTLD and gTLDs, yes, in most countries' ccTLDs, no, in .ARPA, who knows? That's right, ccTLDs are a different dimension. I've not checked or seen the agreements for the new IDN ccTLDs, can't remember now any discussions related to reserved names in that context, but the new IDN ccTLD operators will be now under a contractual relationship with ICANN so the new agreement may have some similarities with the new gTLD registry agreement. Again, just guessing since I've not seen any docs about the IDN ccTLD agreements. I'll look around. Jorge ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
John Levine writes: If other people agree that it's a good idea to have a place that IANA can point to for the reserved names, I'd be happy to move this ahead. Or if we think the situation is OK as it is, we can forget about it. I'd be happier with some sort of list (I was surprised by its length, and IMO that's a sign that the list is needed) and like your document. (BTW. You mention _proto and _service. Neither is reserved for SRV. SRV uses_tcp, _udp and other _proto names. I think it would be stupid by use them for any other purpose in the DNS, but don't think that justifies reserving _ah, _ax25, _ddp, _egp, _eigrp, _encap, _esp, _etherip, _fc, _ggp, _gre, _hmp, _icmp, _idpr-cmtp, _idrp, _igmp, _igp, _ip, _ipcomp, _ipencap, _ipip, _ipv6, _ipv6-frag, _ipv6-icmp, _ipv6-nonxt, _ipv6-opts, _ipv6-route, _isis, _iso-tp4, _l2tp, _ospf, _pim, _pup, _rdp, _rspf, _rsvp, _sctp, _skip, _st, _tcp, _udp, _vmtp, _vrrp, _xns-idp and_xtp. But we have a fun game of TLA bingo on the list and see who uses/remembers most of those!) Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
I seem to have a problem with short words this week (can, to etc.). They spontanteously mutate or disappear. Sorry. Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
I think that in regards to the management and supervision of .ARPA I'd suggest to include RFC3172 and RFC2860 as a reference. I find that using the word Registry will IMHO create some confusion with ICANNland. The list of reserved names from ICANN's DAGv3 2.1.1.2 you included in your message applies only to potential gTLDs, this list may become very dynamic and multilingual, how do you expect to include these names in your draft ? There are some particular names that based on the criteria defined in your draft can be listed as Special and Reserved like WHOIS, WWW, etc. Also from the proposed ICANN's Registry Agreement Article 2, Registry (in ICANN's sense of the word) Operators may establish policies concerning the reservation or blocking of additional character strings within the TLD at its discretion, then how do you propose to incoporate also those names to the reserved list ? Who is or should be the authority that will be responsible and assigned the task to keep the list updated ? My .02 Jorge ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: Defining the existence of non-existent domains
Haai, [not replying to anyone in particular] I think we should make and maintain a seperation between two classes of (reserved) symbols according to their fundamentally different origins: -Required for one or more protocols to correctly function; and -Reserved for administrative purposes (which may not hold true on another network). Examples of the former would include localhost and perhaps arpa; examples of the latter would include .example, .invalid, and gTLDs not in use (although a third category might be useful for the latter, to be managed by ICANN). The former should be encoded in RFCs, although I agree that a composite list would be useful. The latter should, in my view, be recorded in a seperate registry, to be maintained in a similar way to the services list (disclaimer: I have no idea how the latter is presently maintained); in both cases, subject to approval, anyone should be able to register a reserved TLD resp. a network service, and in the latter case, be assigned a number. In all cases, a flat-formatted text file similar to UNIX' services(5) list should be made available. Feel free to shoot me if any of the above is deemed heresy. Baai, De Zeurkous --- Friggin' Machines! -- # Proud -net.kook- IRC bot overengineer % NetBSD, zsh, twm, nvi and roff junkie From the fool file: I don't see why the way people have historically partitioned disks should dictate which kernels we build and distribute by default in the future. --Darren Reed (darr...@netbsd.org), NetBSD tech-kern ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
At 05:38 28/12/2009, Arnt Gulbrandsen wrote: John Levine writes: If other people agree that it's a good idea to have a place that IANA can point to for the reserved names, I'd be happy to move this ahead. Or if we think the situation is OK as it is, we can forget about it. I'd be happier with some sort of list (I was surprised by its length, and IMO that's a sign that the list is needed) and like your document. (BTW. You mention _proto and _service. Neither is reserved for SRV. SRV uses_tcp, _udp and other _proto names. I think it would be stupid by use them for any other purpose in the DNS, but don't think that justifies reserving _ah, _ax25, _ddp, _egp, _eigrp, _encap, _esp, _etherip, _fc, _ggp, _gre, _hmp, _icmp, _idpr-cmtp, _idrp, _igmp, _igp, _ip, _ipcomp, _ipencap, _ipip, _ipv6, _ipv6-frag, _ipv6-icmp, _ipv6-nonxt, _ipv6-opts, _ipv6-route, _isis, _iso-tp4, _l2tp, _ospf, _pim, _pup, _rdp, _rspf, _rsvp, _sctp, _skip, _st, _tcp, _udp, _vmtp, _vrrp, _xns-idp and_xtp. But we have a fun game of TLA bingo on the list and see who uses/remembers most of those!) Arnt ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf See: http://www.ietf.org/id/draft-gudmundsson-dnsext-srv-clarify-00.txt and older version of that is being split (second half is to contain the registry cleanups). http://tools.ietf.org/html/draft-gudmundsson-dns-srv-iana-registry-04 Olafur ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
On Dec 28, 2009, at 3:38 AM, Arnt Gulbrandsen wrote: I'd be happier with some sort of list (I was surprised by its length, and IMO that's a sign that the list is needed) and like your document. +1 I can think of all sorts of other use cases for such a list, such as verifying the accuracy of email addresses URIs before they're collected/clicked/etc. -- J.D. Falk jdf...@returnpath.net Return Path Inc ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
On 28 Dec 2009 01:16:47 -
John Levine jo...@iecc.com wrote:
Here's their reserved list:
...
LOCALHOST
This one caught my eye, as I know for sure that localhost.tld seems
to be registered in most TLDs (both gTLDs and ccTLDs) by actual users
(mostly because I recently looked into purchasing one such domain).
Reading through draft-levine-reserved-names-registry-00, you refer to
RFC 2606 for LOCALHOST's addition, but RFC 2606 specifies TEST,
EXAMPLE, INVALID, and LOCALHOST as reserved TLDs, not reserved
second-level domains. Only example.{com|net|org} are mentioned as
reserved second-level domains as per that RFC.
Also, in your I-D, you seem to use Top as the level for second-level
domains, which seems confusing and technically incorrect. Seems like
the ones that are second-level domains should be classified as
Second, Secondary, or maybe your Leaf class, though Leaf
seems odd here.
In other notes, I'm happy to see you included LOCAL and TLD in
your list (as reserved TLDs, I assume), as they have been proposed
multiple times in various places for their addition to the reserved
list, yet nobody has actually done that yet (according to a response
I received from IANA in November). Another possible addition would be
the new IDN test TLDs (http://www.iana.org/domains/idn-test/).
With regards,
~reed
--
Reed Loden - r...@reedloden.com
pgpKARY3eWiYz.pgp
Description: PGP signature
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
Here's their reserved list:
...
LOCALHOST
This one caught my eye, as I know for sure that localhost.tld seems
to be registered in most TLDs (both gTLDs and ccTLDs) by actual users
(mostly because I recently looked into purchasing one such domain).
ICANN reserves LOCALHOST as a TLD, not as a second level.
Reading through draft-levine-reserved-names-registry-00, you refer to
RFC 2606 for LOCALHOST's addition, but RFC 2606 specifies TEST,
EXAMPLE, INVALID, and LOCALHOST as reserved TLDs, not reserved
second-level domains. Only example.{com|net|org} are mentioned as
reserved second-level domains as per that RFC.
Yes, that's what the I-D is intended to say.
Also, in your I-D, you seem to use Top as the level for second-level
domains, which seems confusing and technically incorrect.
Acually, Top means top level domain. Is that less confusing?
I think I'll do another version which proposes separate IANA
registries of reserved TLDs, special purpose 2LDs in .ARPA, and
special _names. I see in namedroppers some effort to identify the
protocol and service names for SRV, which should be coordinated with
the more general list I'm doing.
R's,
John
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
[ re _proto and _service names ] See: http://www.ietf.org/id/draft-gudmundsson-dnsext-srv-clarify-00.txt and older version of that is being split (second half is to contain the registry cleanups). http://tools.ietf.org/html/draft-gudmundsson-dns-srv-iana-registry-04 Yes, I noticed that. As far as I can tell, the only _name entries other than SRV protocols and services are _domainkey, _vouch, and _adsp. It would be nice to collect them all in one place. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
Since underscore labels are not considered normal DNS labels for domains representing (roughly) physical hosts and networks, everything below the topmost underscore label should not need to go in a central repository for underscore labels but be pointed to by the documentation referenced for the upper label in such repository. That's reasonable, but it would be nice to have a repository somewhere. Your draft (draft-levine-reserved-names-registry) IMO should focus on the normal reserved labels. If you're offering to include _domainkey and _vouch in your list, that's great. If not, what's the plan? R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Defining the existence of non-existent domains
It seems to me that if we think it's a good idea to specify a domain name that doesn't exist, we're better off clarifying the status of the ones already specified rather than inventing new ones. Since the people who manage .ARPA are the exact same people who manage the root (IANA, operated by ICANN, in both cases), one is as likely to flake as the other. In fact, ICANN is quite aware of the reserved names list. In the current draft of the application process, one of the steps is to check to see if a proposed name is one of the Reserved ones, in which case the application fails immediately. Here's their reserved list: AFRINIC IANA-SERVERS NRO ALAC ICANNRFC-EDITOR APNICIESG RIPE ARIN IETF ROOT-SERVERS ASO INTERNIC RSSAC CCNSOINVALID SSAC EXAMPLE* IRTF TEST* GAC ISTF TLD GNSO LACNIC WHOIS GTLD-SERVERS LOCALWWW IAB LOCALHOST IANA NIC *Note that in addition to the above strings, ICANN will reserve translations of the terms test and example in multiple languages. The remainder of the strings are reserved only in the form included above. (That's ICANN's footnote.) Nonetheless, it occurs to me that the set of DNS names that are reserved or that have special meanings in some protocols are scattered over a lot of different RFCs. So I wrote a strawman to collect them all in one place and make a registry of them: draft-levine-reserved-names-registry-00.txt I think I got all the names, I did some greps over all of the text RFCs looking for things that resembled domain names, and I looked to see what's actually in .ARPA and the root. If other people agree that it's a good idea to have a place that IANA can point to for the reserved names, I'd be happy to move this ahead. Or if we think the situation is OK as it is, we can forget about it. But I see little wisdom in adding another does-not-exist name with semantics not meaningfully different from .INVALID or FOO.INVALID. R's, John ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Defining the existence of non-existent domains
--On Monday, December 28, 2009 01:16 + John Levine jo...@iecc.com wrote: It seems to me that if we think it's a good idea to specify a domain name that doesn't exist, we're better off clarifying the status of the ones already specified rather than inventing new ones. Since the people who manage .ARPA are the exact same people who manage the root (IANA, operated by ICANN, in both cases), one is as likely to flake as the other. While you are presumably right about flake, .ARPA is rather clearly under IAB supervision, while the root is under the supervision of the ICANN Board and ICANN policy-making processes. That distinction is fairly significant for some purposes. It may or may not be for this one. FWIW, I'm not aware of there being an established procedure for adding new names to the ICANN reserved list: while several of the names are ours, I don't recall their being requested in any systematic way. Others of the names are of entities who have leverage within ICANN. One could make a strong case for other bodies having their names blocked or reserved on a par with those listed: IEEE, ISO, and ITU come to mind as examples. In fact, ICANN is quite aware of the reserved names list. In the current draft of the application process, one of the steps is to check to see if a proposed name is one of the Reserved ones, in which case the application fails immediately. Here's their reserved list: ... Nonetheless, it occurs to me that the set of DNS names that are reserved or that have special meanings in some protocols are scattered over a lot of different RFCs. So I wrote a strawman to collect them all in one place and make a registry of them: draft-levine-reserved-names-registry-00.txt I think I got all the names, I did some greps over all of the text RFCs looking for things that resembled domain names, and I looked to see what's actually in .ARPA and the root. Two quick observations on that draft: (1) It would be good to have domain explicitly in the title. We have reserved names in other places. (2) While there are reasonable arguments for gathering a list in one place, having multiple lists under parallel development in multiple groups presents a synchronization problem. Since the RFC-writing process is not the only way that names can be added to the list and this is a list of names to not be allocated (i.e., IANA may not know), it is reasonably likely to diverge from reality even if it doesn't start that way. For example, the new names allocation process in ICANN might put another name on the list without identifying that fact clearly enough to IANA to get the name on the list. A clearly non-normative glossary of reserved names might be a more practical idea. If other people agree that it's a good idea to have a place that IANA can point to for the reserved names, I'd be happy to move this ahead. Or if we think the situation is OK as it is, we can forget about it. But I see little wisdom in adding another does-not-exist name with semantics not meaningfully different from .INVALID or FOO.INVALID. I see relatively little harm in reserving one subdomain of .ARPA for protocol use, since doing so would isolate the string from any ICANN issues. As I've said before, I think the notion of a registry process allocating more of those names at the second level would be a bad idea. And I'm not sure that the case has been made for the single reservation: your last sentence above is an argument that it has not been. best, john ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
