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

From: Suzanne Woolf <[email-masked]>
Date: Mon, 11 Jul 2016 09:18:30 -0400

Hi,

See below on a new draft that attempts to help make some sense of some general challenges around naming in internet protocols. It attempts to discuss some of the questions that arise around attempting to re-use DNS protocol and domain names in contexts separate from the global public DNS database and protocol.

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.

Questions: 

1. Is something like this document useful?
2. What should it cover?
3. What status should we be aiming for: Informational? BCP?

thanks,
Suzanne

Begin forwarded message:

> From: [email-masked]
> Subject: New Version Notification for draft-stw-whatsinaname-00.txt
> Date: July 8, 2016 7:37:23 PM EDT
> To: "Suzanne Woolf" <[email-masked]>
> 
> 
> A new version of I-D, draft-stw-whatsinaname-00.txt
> has been successfully submitted by Suzanne Woolf and posted to the
> IETF repository.
> 
> Name:		draft-stw-whatsinaname
> Revision:	00
> Title:		Some Considerations on the Choice of Naming in IETF Protocols
> Document date:	2016-07-08
> Group:		Individual Submission
> Pages:		11
> URL:            https://www.ietf.org/internet-drafts/draft-stw-whatsinaname-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-stw-whatsinaname/
> Htmlized:       https://tools.ietf.org/html/draft-stw-whatsinaname-00
> 
> 
> Abstract:
>   From time to time, networking protocols need to be able to name
>   things used within the protocol, and resolve the names created or
>   referenced.  It's common for protocol designers in this predicament
>   to attempt to use domain names as the starting point for their
>   systems of names, and the DNS as the starting point for name
>   resolution.
> 
>   This is completely understandable-- domain names, and DNS resolution,
>   are well-established in both the expectations of network users and
>   developers, and well-supported by fielded software.  It also has
>   significant limitations.
> 
>   This document deals principally with the questions a protocol
>   designer or software developer should ask themselves about what
>   behavior they want from the names they use in the context of a new
>   protocol or scope for names.  Depending to the answers to these
>   questions, the answer may be that domain names will not meet the
>   constraints at hand.  Future versions of this draft will provide some
>   comments on alternatives.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: "John Levine" <[email-masked]>
Date: 12 Jul 2016 20:30:57 -0000

>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.

R's,
John

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 12 Jul 2016 17:13:52 -0400

> 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

---

From: "John R Levine" <[email-masked]>
Date: 12 Jul 2016 17:47:40 -0400

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

Oh, I agree, but if we're just giving advice, wouldn't that be about two 
sentences?  If you want to use a domain name, register one and use that as 
the root of your tree, or else use something in *.alt.

R's,
John

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 12 Jul 2016 18:34:53 -0400

On Jul 12, 2016, at 5:47 PM, "John R Levine" <[email-masked]> wrote:

> Oh, I agree, but if we're just giving advice, wouldn't that be about two sentences?  If you want to use a domain name, register one and use that as the root of your tree, or else use something in *.alt.

That draft would provide no guidance at all on deciding whether you want to use a domain name, use something from the subset of domain names that are DNS names, or do something else. 

It would also provide no guidance at all on the characteristics of an acceptable string. Just to take an easy example, why on earth would you want to risk collision by choosing a human-friendly string as a single label DNS name when your protocol is strictly a locally-scoped machine-to-machine variant of DNS, and no human will see the names it uses in the course of normal operation? "I want to reserve my cat's name as a single label" is a nice-to-have in that case, not a need-to-have, and probably a thing to avoid, particularly if it comes with the documented certainty of collision with a name already in the global-scope DNS. (Or not-- people use split-horizon configuration in their DNS all the time, committing to different answers for "the same name" depending on the implicit scope of the query. But it works a lot better if they do it on purpose.)

"If you want to use a domain name" is an enormous "If", and an answer comes at the tail end of a process that's currently driven primarily by whim and mythology. Maybe we can do better.

Suzanne

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 13 Jul 2016 08:33:31 +1000

> On 13 Jul 2016, at 6:30 AM, John Levine <[email-masked]> wrote:
> 

I tend to agree. Inside the IETF, we have a documented procedure on how to add new names for standard purposes -- although we seem to have a healthy chunk of confusion about its use.

For people doing work outside the IETF, I somehow doubt they'll ever find RFC6761 before they ship a protocol, much less any additional documents published to help interpret it.

Those external people will have to accept that they're working "outside the system" and may not ever have their TLD blessed by registration (thereby risking collision and other problems). OTOH, if an external use sees broad enough adoption, we'll probably be in the position of considering it as a special-use domain name, just as happened with .onion.

As such, IMHO it seems like there are only a few useful things we can do:

1) Clarify within the IETF community what criteria we use for minting special-use domains in this situation (and I'd suggest that broad deployment is a key metric).
2) State, as simply as possible, that people minting their own TLDs run a variety of risks, and may never be recognised by registration (.onion notwithstanding). Basically, we want a short statement to point people at when they ask; an IESG statement would serve. 

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: "John R Levine" <[email-masked]>
Date: 12 Jul 2016 19:14:34 -0400

> That draft would provide no guidance at all on deciding whether you want 
> to use a domain name, use something from the subset of domain names that 
> are DNS names, or do something else.  ...

Hm, I take your point.

> It would also provide no guidance at all on the characteristics of an acceptable string.

Some people I know were looking for names to use within a VPN and I 
suggested that the ISO 3166 list permanently reserves .xa through .xz 
which are unlikely ever to be TLDs, so they picked something like blah.xz. 
I wonder if that was good advice.

R's,
John

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 13 Jul 2016 08:23:37 -0400

On Jul 12, 2016, at 7:14 PM, John R Levine <[email-masked]> wrote:

>> That draft would provide no guidance at all on deciding whether you want to use a domain name, use something from the subset of domain names that are DNS names, or do something else.  ...
> 
> Hm, I take your point.
> 
> Some people I know were looking for names to use within a VPN and I suggested that the ISO 3166 list permanently reserves .xa through .xz which are unlikely ever to be TLDs, so they picked something like blah.xz. I wonder if that was good advice.

I don't know. 

Would asking the questions in Sec. 4 of the whatsinaname draft have helped them/you be sure? Do other questions come to mind?

Suzanne

---

From: Edward Lewis <[email-masked]>
Date: Wed, 13 Jul 2016 13:06:35 +0000

On 7/12/16, 19:14, "Arcing on behalf of John R Levine" <[email-masked] on behalf of [email-masked]> wrote:

> ...and I suggested that the ISO 3166 list permanently 
> reserves .xa through ...
>

About a year ago I submitted this draft:

https://tools.ietf.org/id/draft-lewis-user-assigned-tlds-00.txt

It got no public response and I didn't push it further.  I have no real plans to, I just recalled the draft reading the email cited above.

(As far as Special Use Domain Names, I don't know if these two-letter strings as well as the numbers 0 through 255 [as top-level names] ought to be added.  That's a whole'nuther topic/wild idea that comes to mind now and then.)

---

From: "John R Levine" <[email-masked]>
Date: 13 Jul 2016 11:27:52 -0400

> Would asking the questions in Sec. 4 of the whatsinaname draft have helped them/you be sure? Do other questions come to mind?

Dunno.  Some other questions that come to mind:

* If the names are not resolved in the public DNS, will they be used in 
the same contexts as names that are?

* Are the names likely to be used by people, e.g., typed into a box in a 
form, or only by software?

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.