Re: [DNSOP] On the call for adoption on Special Use Names (Please! Pretty please, with a cherry on top?!)

[Stephane Bortzmeyer <[e-mail]>]

On Fri, Sep 16, 2016 at 05:53:53PM -0400,
 Warren Kumari <[e-mail]> wrote 
 a message of 31 lines which said:

> However, if there is not sufficient review and feedback for the
> chairs to be able to select between them (or some other clear
> outcome), we will be stuck... and then we will continue to talk
> about this topic ad nauseam[0].

Or we could decide that the problem is not solvable in the current
context and tell that to the IESG. Some things are simply not
possible. And I'm still not convinced there is a problem to solve
(unless the real issue is "how to prevent the registration of .gnu and
.bit?")

The rest of this email is about
draft-adpkja-dnsop-special-names-problem-06. Executive summary: no, no
and no.

Problems
********

Despite many remarks on this list and in IETF meetings, the draft
continues to use disparaging terms like (section 1) "squatting".

Several remarks in the draft are dishonest because they could be
applied as well to many IETF technologies. It really seems the authors
felt the draft was too short and decided to pile in anything they
could find against 6761. For instance, section 3 says:

> [RFC6761] does not mention if the protocol using the reserved name
> should be published as an RFC document.

So what? It was never a problem at IETF to rely on protocols which are
not in a RFC. (See for instance the "Specification Required" policy in
RFC 5226.)

Another instance of the same problem, section 4 says:

> c.  Reserving a string in [RFC6761] does not guarantee queries will
> not leak in the DNS.

Requiring this is outrageous: there is no way to prevent
implementations to do stupid things. RFC 1918 does not "guarantee
packets will not leak [in the public Internet]" and nobody is going to
criticize RFC 1918 for that. (Not to mention the DNS leaks of
rfc1918-domains.arpa.)

Section 5:

> This leads to concerns about liability risks incurred by adding a
> particular string to the [RFC6761] registry.

There is no way to guard against any issue that a US lawyer may
raise. Until now, no owner of the Local or Onion trademarks
complained, or threatened to sue.

Errors
******

Section 1 :

> the GNU Name System (GNS) system is using block chains to build a
> decentralized name system

GNS does not use any blockchain. (Confusion with Namecoin?)

Little details
**************

Abstract :

> RFC 6761 introduced a framework by which a particular domain name
> could be acknowledged as being special.

Actually, suffix, not domain name (RFC 6761, section 4).

Section 1 :

> An algorithmic solution frequently chosen by application developers
> consists simply in using a special tag padded at the end of a name

Why calling it "tag", instead of "label" (or "suffix" if there are
several labels)?