Re: [DNSOP] New Version Notification for draft-adpkja-dnsop-special-names-problem-00.txt

[David Conrad <[e-mail]>]

Stuart,

On Dec 29, 2015, at 1:32 PM, Stuart Cheshire <[e-mail]> wrote:
> There seems to have been lots of recent discussion regarding confusion surrounding RFC 6761. I’m a little surprised by this, since I didn’t think RFC 6761 was unclear. But then as co-author, that’s my failing. I thought it clearly stated our intention, and I thought the IETF Last Call scrutiny should have identified any ambiguity, but apparently not.

I don't believe the primary issue is ambiguity of the text, rather it is the implication of the text. See Geoff Huston's recent article on CircleID (http://www.circleid.com/posts/20151222_whats_in_a_name/), specifically:

"The publication of RFC 6761 by the IETF in February 2013 essentially opened up a competing and uncoordinated channel for drawing of top level domain names from the Domain Name Space pool.
[...]
What this is doing is effectively recanting on the agreement of RFC 2860 and re-interpreting it to mean that ICANN only has purview of those domain names that use the DNS resolution protocol, and that if the domain name uses a name resolution mechanism that does not rely on this protocol, then the name can be assigned by the IETF, via the IETF publication process."

In my view, RFC 6761 codifies a way by which a second mechanism by which a part of the domain namespace can be consumed, but does not describe the way in which conflicts between the two mechanisms (that is, namespace consumption via ICANN processes and namespace consumption via RFC 6761) can be avoided/resolved.

>>   This switch practice is not explicitly documented anywhere.
> 
> That was the intention of the seven-question list: to have protocol specifications explicitly document their “switch practice” -- i.e. how their special names are to be unambiguously recognized, and what software should do having recognized one of them.
> 
>>   Answers to these seven questions provide guidance to the
>>   corresponding seven audiences on how to handle a special-use domain
>>   name once it has been reserved by inclusion in the Registry.
>>   However, they are inadequate for making the determination whether a
>>   particular domain name qualifies as being special in the first place.
> 
> You have it backwards. The seven questions were not “what to expect *after* this special-use registration is done”; they were the justifications *why* the special-use registration should be granted, required in a document demonstrating that it (a) provides a result that the community judges to be good, and (b) the aforementioned good result cannot reasonably be achieved better another way.

This seems to contradict your previous statement above. My impression (which may well be wrong) has been that the interpretation of of RFC 6761 follows the first interpretation above, that is, what to expect/do *after* the registration is done NOT this is why the registration should be done.  Looking at the answers to the seven-question list in RFC 7686, it appears to me to be of the form "X SHOULD/MUST do Y".  It does not appear to me that the seven-question list provided anything in the way of an answer your assertions on (a) or (b) above.

>>   The lack of a more elegant way to specify a name resolution protocol
>>   in (for example) a URI amounts to an architectural oversight.
> 
> I’m not sure I agree that there *is* a more elegant way to achieve the desired effect. Unless you intend to actually describe some hypothetical “more elegant way” of doing this, I suggest simply removing this unsupported implication from the document.

"More elegant" is, of course, a subjective evaluation, but several have argued that the URI approach (mentioned in your quote from the document) is one "more elegant" (albeit, IMHO, not really deployable) way.  I personally think embedding semantics into arbitrary strings is far from being elegant (a painful lesson we learned back in the 80s when the DNS was being initially deployed, e.g., the hacks to support .UUCP, .BITNET, .CSNET, the JANET "coloured book" naming scheme, etc), rather it is an egregious hack that has as its sole reason to exist the simple fact that it is (more) deployable in today's Internet without having to redeploy every resolver library on the planet.

>>   Are applications supposed to check that registry to know what to do?
> No.

As mentioned, in practice, the answers to the seven-question list appear to describe the exact behavior applications are supposed to perform (i.e., the answer to question 2). So, while it is almost certainly true that applications are not likely to check the registry directly, presumably application developers are intended to check the registry and read the RFC used to reserve the name, reviewing the seven-question list and ensure the application abides by the restrictions in that RFC.

> I confess I has assumed that IANA would designate some person with the expertise and experience to evaluate whether “... special handling of this "Special-Use Domain Name" is appropriate ...”, much as requests for TCP and UDP ports are evaluated. That was my mistake. I should have been explicit about the intended review process.

Historically, the IANA "expert review" process used in situations such as how TCP and UDP ports are evaluated has been a relatively low impact type of assessment and ICANN, as the IANA function operator, as depended on volunteers to provide that service.  In the case of the domain namespace, you would be putting the expert reviewer in the sights of folks whose other alternatives are to either spend a minimum of $185,000 or squat on a name. I personally would not like to be put into that position, but that may just be me.

More pragmatically, my impression is that the implication of 6761 is that the IESG gets to make the decision. My experience within the ICANN community suggests that making these sorts of decisions are both difficult and tend towards inciting folks with more lawyers than brains. I'm unsure this is a business the IESG will enjoy being in.

>>   Going back to the previous point of prior usage of the protocol, in
>>   the case of LOCALHOST, LOCAL and ONION, those particular domain names
>>   were already in use by a substantial population of end-users at the
>>   time they were requested to be added to the Registry.  Rightly or
>>   not, the practical cost of a transition was argued as a justification
>>   for their inclusion in the registry.
> 
> No. The justification for having an entry in the registry was to facilitate the desired special behavior.

You're arguing against an assertion of fact. In the case of .ONION, I believe (but am too lazy to look it up in the DNSOP archive) the authors of 7686 folks did indeed argue (among other rationales) that the cost of migrating the millions of TOR deployments would be infeasible.

> As I read it, draft-adpkja-dnsop-special-names-problem seems to focus far too intently on the issue names. (But then, that is what ICANN is in the business of selling, so maybe it’s not surprising.)

Actually, ICANN is in the business of trying to coordinate the top-level of the Internet's system of unique identifiers, of which the domain namespace is one. In my personal view (and I gather from Geoff's article, in his view), RFC 6761 creates an ambiguity and potential conflict in that coordination. I see this as unfortunate and why RFC 6761 needs revision.

> The substance of RFC 6761 is about enabling special behaviours, and using special names to trigger those special behaviours is merely a means to the end. What is interesting and important, and worthwhile for the IETF to support, is the special behaviours, not the names.

If this were true, than alternative approaches such as the URI approach or requiring the use of .ALT would allow for the special behaviors.

Regards,
-drc
(ICANN CTO, but speaking, as I assume with anyone participating in IETF discussions, only for myself)