Re: [Arcing] New Version Notification for draft-stw-whatsinaname-00.txt

[Suzanne Woolf <[e-mail]>]

On Jul 12, 2016, at 4:30 PM, John Levine <[e-mail]> wrote:

>> There seemed to be strong feeling in the ARCING BOF in BA that we needed a document that could serve as advice to
>> protocol designers and software implementers, although it's not entirely clear where such a document should live. It's
>> *not* intended for adoption by DNSOP; although it may ultimately include advice to DNS operators, that's not the
>> primary purpose.
> 
> I read it, and it's all reasonable and informative, but I fear it'll
> just be preaching to the converted.  The unconverted will continue to
> say "yeah, ok, I know all that but I still need to reserve .BANANA"
> 
> We have a severe perverse incentive.  On the one hand, we tell people
> that squatting on domain names is bad for all sorts of reasons, and
> we're not going to let people reserve desirable names for non-DNS use
> for other reasons.  Then anyone who's paying attention can see that
> what you actually do is pick the name you want and squat on it with
> extreme vigor, until we say, oh, all right, just this once.  Or maybe
> we don't, but unless there's some external situation like the one for
> .onion certificates, they hand out software that uses the name they
> want anyway and if the names leak, too bad.
> 
> Until and unless we can de-perversify the situtation, I don't see much
> point in offering more advice.

I understand this argument, but have a couple of reservations about it as a reason to just throw up our hands:

First, some people actually would probably prefer to avoid name collisions, ambiguous resolution semantics, etc. in their standards and specifications-- the resulting software is easier to write, debug, operate, and troubleshoot. A little clear thinking about what protocols you're using and what you're assuming about names can go a long way.

Probably more importantly, I don't think "there's nothing we can do" is a good answer for protocol developers within the IETF. 

See, for example, the current effort in homenet to define a naming architecture: there's already an RFC 7788bis I-D to correct the bad edit that set "home" as a default without any corresponding process for the special use names registry, but there's still a belief that they need to set a default-- and still some ambiguity about the behavior of the naming protocol they're using. "Do whatever you want, and we can't help you decide what to want" doesn't strike me as a good policy for the IETF to have for its working groups on this subject.


Suzanne