Dear colleagues,
It’s taken a little longer than we initially expected, but we’ve been working on agenda and discussion details for the interim WG meeting next week. Logistics details will follow shortly, but we have a webex URL graciously provided by the IETF secretariat. We have the following drafts in front of us as requests to add names to the Special Use Domain Names registry (http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml <http://www.iana.org/assignments/special-use-domain-names/special-use-domain-names.xhtml>) as provided for in RFC 6761. Our charter (http://datatracker.ietf.org/doc/charter-ietf-dnsop/ <http://datatracker.ietf.org/doc/charter-ietf-dnsop/>) says we can (and probably should!) consider these drafts and the questions they raise. http://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/ <http://datatracker.ietf.org/doc/draft-appelbaum-dnsop-onion-tld/> http://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/ <http://datatracker.ietf.org/doc/draft-grothoff-iesg-special-use-p2p-names/> http://datatracker.ietf.org/doc/draft-wkumari-dnsop-alt-tld/ <http://datatracker.ietf.org/doc/draft-wkumari-dnsop-alt-tld/> http://datatracker.ietf.org/doc/draft-chapin-additional-reserved-tlds/ <http://datatracker.ietf.org/doc/draft-chapin-additional-reserved-tlds/> http://datatracker.ietf.org/doc/draft-lewis-user-assigned-tlds/ <http://datatracker.ietf.org/doc/draft-lewis-user-assigned-tlds/> http://datatracker.ietf.org/doc/draft-cheshire-homenet-dot-home/ <http://datatracker.ietf.org/doc/draft-cheshire-homenet-dot-home/> In prep for our interim meeting on these drafts, please read them. Please also review RFC 6761. As we discussed in Dallas, we have some process-based decisions to make for several of the drafts, but more importantly than deciding what to do with them formally, we should be discussing the merits of these requests and some larger questions about administration of the namespace (for DNS and for other protocols that might want to use DNS-compatible naming) and the process. Please don’t feel obligated to wait until the meeting to discuss the possible points of interest below on the list. thanks, Suzanne & Tim --------------- We've identified two general classes of concerns, and a few specific questions. Please keep these in mind for meeting topics. 1. Operational questions: operators are supposed to "do something" with RFC 6761 special use names. A short static list of those is now being expanded to a larger and potentially more dynamic one. Some questions that come to mind in such cases: a) RFC 6761 doesn't specify that we know anything about the proposed use of the requested special use name, only that the requester specify how DNS resolvers and applications treat it when it appears in a context where we expect a domain name. Is this enough for operators? b) For special use names to work as RFC 6761 envisions-- new features or protocols, handled locally, minimal leakage, no ambiguity-- local DNS operators ideally have to provide local configuration to support them. Historically the list of names to special-case for local handling is small, but since it seems unlikely that people will stop asking for special use names, how does this scale? c) The requests we're seeing for .onion and the other p2p names already in use are arguing that they should get their names to enable their technologies with minimal disruption to their installed base. While the requesters may well have valid need for the names to be recognized, there is still a future risk of name collision or other ambiguity. The IETF is being asked to recognize the pre-existing use of these names. Does this scale to future requests? d) The other requests we're seeing aren’t clear as to enabling "new functionality", and they may not meet the 7 steps outlined in the "Domain Name Reservation Considerations" of RFC 6761, where it needs to be clear what special treatment is required for a reserved name. Is this important? 2. Policy/namespace questions: This is having to do with both the policy specifics of what is/isn't reserved by the IETF from being put in the root zone, and the larger question of what happens to the DNS namespace. a) 6761 doesn't provide for any restrictions on what labels are requested, besides that they be legal domain names. It appears that the requirement reduces to "something that appears in a 'domain slot'" (which is IAB terminology from RFC 6055). In practice, for the same reasons why some domain names are worth a lot of money, this means people are asking for catchy, mnemonic single-label ("TLD") names, and will likely continue to do so. Is this advisable? (The .alt proposal suggests restricting this, to offer the tradeoff "use .alt, don't worry about TLD politics ever." Should this be permitted? or perhaps required?) b) Namespace policy and coordination. We realize this is potentially sensitive but don’t see an alternative to engaging on it. There are a couple of angles to consider: 1. ICANN makes policies about names that it adds to the root zone, based both on technical constraints that come from IETF documents and also other policy considerations. Under RFC 6761, the IETF can remove parts of the name space from being candidates for delegation in the root by Standards Action. This appears to mean that coordination is desirable regarding what specific, protocol-compliant names can be added to the root zone by ICANN, or can be kept out of the root zone by the IETF. What should be the coordination mechanism? 2. In the particular cases of home/corp/mail, ICANN has studied the possibilities of name collisions, and decided not to delegate those names at this time. The proposal is that the IETF reserve those names for unspecified special use permanently. It seems that an IETF action on those names is redundant, unless it’s in opposition to some action contemplated under ICANN policy (for which there is no apparent mechanism). Is the possibility of the same names considered under multiple policies a problem? 3. An IETF precedent to add names to the special use names registry based on the risk of name collision could easily change the dynamics around namespace policy for TLDs in the root zone, e.g. by providing incentives to “game the system”. Is this acceptable? 3. Moving forward: What should we do here? What other ideas might be useful? Should we be considering RFC 6761bis? What might an improved registration policy for this registry look like? We're available to discuss further and will be encouraging discussion but right now we're trying to focus the conversation.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
