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

[Warren Kumari <[e-mail]>]

On Tue, Sep 20, 2016 at 9:33 AM, Stephane Bortzmeyer <[e-mail]> wrote:
> 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.

We could -- it is entirely possible that this is not a solvable
problem -- however, before we can make that determination, and even
more importantly, before we can clearly communicate that to the rest
of the IETF / IESG / <etc> we need to agree on what the *problem*
actually is.

This is what draft-tldr-sutld-ps is trying to do -- clearly document
the problems with special use names, not just the problems with
RFC6761.

Once we've documented the problem we can then discuss *mitigations* (I
suspect not solutions), and if there is anything useful we can
actually do...


W

> 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)?
>



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf