Subject: [DNSOP] Questions about draft-adpkja-dnsop-special-names-problem-00

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 4 Nov 2015 12:20:27 +0900

draft-adpkja-dnsop-special-names-problem-00 raises several issues,
some are non-issues, some, if accepted, may deserve a 6761bis and some
do not.

1) "The discussions in the DNSOP WG and the IETF Last Call processes
about the .onion registration in the Special Use Domain Names registry
(1,200 messages) have made it apparent [...]" This sentence seems to
imply that the long and painful discussion of .onion registration was
because RFC 6761 is incomplete and/or unclear. But one could say as
well that *every* discussion regarding TLD allocation will generate
many messages: the subject is hot, and highly political and, I would
dare to add, a lot of money is at stake, which makes it even more
sensitive.

2) "The requirements of the operators of recursive resolvers in the
DNS cannot be relied upon to be implemented" This observation is
right. This could be added in a 6761bis, or in a new document
"Observations on RFC 6761" but it was obvious from the beginning (we
cannot rely on our beautiful RFCs to be implemented everywhere,
nothing new, or specific to special-use domain names).

3) "At the time of writing, the [RFC6761] registry does not include
direct guidance for any of the seven audiences, relying instead upon a
reference for each entry in the Registry to the document that
requested its insertion." I've heard (but it does not appear to be in
draft-adpkja-dnsop-special-names-problem-00) that some implementors regret
there is no formal way to derive code from the special-use domain
registry (doing it by hand is not a problem if the registry stays
small). Why not mentioning the possibility of an addition to RFC 6761:
a formal language to express the expected behaviour of software,
allowing programs to be automatically derived from the registry?
(Personal note: I could be volunteer to work on it.) Questions like
"Can/Should applications do this check dynamically?" could receive a
reply there (obvious reply: "that's local policy").

"Useful reservations of top-level domains should be accompanied by
documentation of realistic expectations of each of the seven
audiences" But it *is* the case. Simply, it is not in the registry
(but in the referenced RFC) and it is not in a formal language. But it
exists (RFC 6761, section 5).

4) "In particular, if the IETF formalizes this concept in the Internet
architecture, coordination will be require between ICANN and IETF on
such names." That's why there is an official liaison between IETF and
ICANN. I assume ICANN was duly informed of the discussion about
.onion. I fail to see why it is regarded as a problem.

5) "For example, it is not clear who is responsible for carrying out
an evaluation." Wrong, it is specified in RFC 6761 "an IETF "Standards
Action" or "IESG Approval" specification [RFC5226] MUST be published
describing the new functionality". (Note the "or", which the draft
calls an "inconsistency".)

6) "For example, is large scale prior deployment an
acceptable criteria?" Such a criteria would be useless if you cannot
define precisely how you measure "large scale prior deployment". Hint:
traffic at the DNS root is not a good metric (too easy to fake it). I
notice also that the requirments of IETF to P2P developers who want
"their" TLD to be reserved, are inconsistent: we ask them to reserve
the TLD in advance, before deployment, and at the same time we ask
them to prove that there is an existing deployment!

7) "When processing gTLD applications, ICANN has a process to review
those to check if the proposed names are potentially offensive to
certain communities, have political ramifications, etc.. It is worth
asking if the IETF should have a similar process in place to evaluate
specific proposed reserved names" Huge NO here: the ICANN process is
very expensive, arbitrary, long, and copying it is not certainly the
best use of IETF time.
   
Editorial: "the reserved names could be any label in any random
string, not just the rightmost one" The draft should say "most
significant" (or "last"), not "rightmost", which is not i18n-neutral.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 4 Nov 2015 21:52:17 +0900

On Wed, Nov 04, 2015 at 12:20:27PM +0900,
 Stephane Bortzmeyer <[email-masked]> wrote 

> draft-adpkja-dnsop-special-names-problem-00 raises several issues,

And I forgot one of the most important ones, but I remembered it
during a discussion over sashimi this evening (the sashimi were good,
thanks).

The entire section 2, about "switches" is questionable because using
.bit or .onion is not only to change the *resolution* protocol but
also (and specially) to change the *registration* process.

These are two different systems. Of course, they have some links (the
fact that domain names are organized into a tree is used by the DNS
protocol for fast resolution) but not identical. The current version
of the draft says "any TLD registered in IANA-maintained root-zone
(use DNS)" which is not quite exact. Names registered in the
RFC2826-root are often looked up through the DNS but not always (some
people use local hosts file or LDAP to do it). And, more important,
some TLDs outside of the RFC2826-root do not always indicate a
switch. This is the case of .bit (if you already know Namecoin, you
can skip the next paragraph).

Namecoin uses a blockchain to store registered names. That way, you
can have meaningful names without a registry. Because few clients
speak the Namecoin API, most of the times, name resolution is done
through the DNS: you set up a local authoritative name server to
export data from the blockchain into a .bit zone that you load.

This example clearly shows that the TLD is not a "protocol
switch". That's because Namecoin is intended to address perceived
problems with the registration system, not with the DNS.

---

From: Alain Durand <[email-masked]>
Date: Wed, 4 Nov 2015 13:34:32 +0000

Stephane,

The following paragraph in section 2 was an attempt at capturing your point:

"   Such usage, which a few commenters have referred to as "protocol
   switching," is not limited to "protocol switch" in the strict sense
   of indicating specific protocols on the wire.  It could indicate to
   switch to another name space (eg .onion), use a different protocol
   (eg tor, or mdns), or indicate to use a local DNS scope by not using
   the DNS root for name resolution (eg .home in homenet) or something
   else altogether.”

Alain.

> On Nov 4, 2015, at 7:52 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop