Subject: Re: [homenet] RFC 7788 and ".home"

From: "[email-masked]" <[email-masked]>
Date: Mon, 18 Jul 2016 16:22:29 +0200

ICANN may not have handed it out yet, and may be on a hold about doing so, but many still expect some resolution to that road block. I certainly do.
Making assumptions about icann‘s future behavior on this _policy_ issue is a bad bet.
Some questions I still do not understand the answers for
- why do you need a TLD? Why won't a SLD work?
- why do you need a word from natural language? I know many still maintain the myth that it is a coincidence when a string matches natural language, but many have other used for natural language words. In fact I assume you picked it because of its similarity to a natural world. But why do you need it?
- what sort of implementer hard codes name strings in their code?
Avri( coincidentally Co-chair ICANN new gTLD Subsequent Procedures working group)
Sent from my T-Mobile 4G LTE Device
-------- Original message --------From: Mikael Abrahamsson <[email-masked]> Date: 7/18/16  15:33  (GMT+01:00) To: Terry Manderson <[email-masked]> Cc: HOMENET <[email-masked]>, Ray Bellis <[email-masked]> Subject: Re: [homenet] RFC 7788 and ".home" 

The option 4 mentioned updating RFC7788. It's not clear to me what this 
update would be.

.HOME has not been handed out by ICANN yet, what's the odds that RFC6761 
process reserving .HOME for special use would succeed?

-- 
Mikael Abrahamsson    email: [email-masked]

_______________________________________________
homenet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/homenet

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Jul 2016 18:10:14 +0200

Please read draft-lemon-sutldr-ps, and participate in the discussion about
this on the dnsop mailing list.   Discussions about the RFC6761 problem are
off-topic for the homenet mailing list.   We are customers of the existing
IETF consensus process as documented in RFC 6761.   We get into enough
ratholes on the homenet mailing list; please don't get us into this rathole
as well.

On Mon, Jul 18, 2016 at 4:22 PM, [email-masked] <[email-masked]> wrote:

>
> ICANN may not have handed it out yet, and may be on a hold about doing so,
> but many still expect some resolution to that road block. I certainly do.
>
> - why do you need a word from natural language? I know many still maintain
> the myth that it is a coincidence when a string matches natural language,
> but many have other used for natural language words. In fact I assume you
> picked it because of its similarity to a natural world. But why do you need
> it?
>
> Avri
> ( coincidentally Co-chair ICANN new gTLD Subsequent Procedures working
> group)
>
> -------- Original message --------
> From: Mikael Abrahamsson <[email-masked]>
> Date: 7/18/16 15:33 (GMT+01:00)
> To: Terry Manderson <[email-masked]>
> Cc: HOMENET <[email-masked]>, Ray Bellis <[email-masked]>
> Subject: Re: [homenet] RFC 7788 and ".home"
>
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 20 Jul 2016 00:13:12 +0200

> - why do you need a TLD? Why won't a SLD work?

We want something short and memorable.  ".co.uk" is short and memorable.
".univ-paris-diderot.fr" is not.

> - why do you need a word from natural language?

We want something short and memorable.  ".home" is short and memorable.
".in-addr.arpa" is not.

> - what sort of implementer hard codes name strings in their code?

I do.

This group is designing a set of protocols that are meant to enable an
intelligent layman to deploy a well-designed (no NAT) local area network.
We use a number of techniques, such as highly refined distributed
consensus algorithms, but also defaulting to standardised values where
flexibility is not needed or not desirable.  In the particular case of the
choice of the top-level domain, there is agreement in this WG that having
a standardised default is more robust, more predictable, and easier to
understand than using a distributed consensus algorithm.

As to how this is implemented (hard-wired in the code or learned from
a configuration file that is shipped with standard-compliant defaults) --
with all due respect, that is none of your business.

-- Juliusz

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Jul 2016 05:10:35 -0400

> ".univ-paris-diderot.fr" is not.

Why?  This is, I suspect, part of the issue: it seems that we have
some assumptions about the use of these names, and I'm not entirely
sure what they are.  It is not obvious to me that "short and
memorable" is a requirement that falls out of section 3.7 of RFC 7368. 
 
> We want something short and memorable.  ".home" is short and memorable.

"Something short and memorable" is again a requirement here that isn't
obviously imposed by RFC 7368.  But worse, "home" is actually only
memorable for people who know what that word is in English, and it's
only even useful to people who use Latin characters.  It's not like
internationalization considerations in naming are unknown (and it
would appear that if there is a requirement for natural language
strings then we haven't attended to RFC 2277 section 6).  Since the
point of this is to be intuitive for users who aren't professional
administrators, I guess I assumed that it also has to be intuitive for
such users who happen not to speak and read English.  I'm prepared to
admit my assumption may be wrong, but if so I'd like the WG to think
about that first.

> understand than using a distributed consensus algorithm.

It appears to me that an interpretation equally consistent with the
results of the WG is that the WG proceeded with a simplifying
assumption and more or less ignored the details implicit in this
issue, partly because the WG had already decided mostly to kick the
issue of naming down the road a little.

I appreciate that it's annoying to discover that there's a problem
quite this late, and it's super annoying that we have to cope with it
quickly.  And I take my full share of the blame: I missed this, and
should not have.  But cope with it we must, because the use of
home. or any other name without having answered the questions in
section 5 of RFC 6761, and without registering a well-known domain
name in the DNS, is bad for the network and a threat to the very users
we're supposed to be serving with this effort.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Wouter Cloetens <[email-masked]>
Date: Wed, 20 Jul 2016 11:29:19 +0200

On 20/07/16 11:10, Andrew Sullivan wrote:
> only even useful to people who use Latin characters.
Speaking as a residential gateway (stack) vendor who has deployed close 
to 20 million units in (at my last count) 15 countries across Europe, 
the Middle East and Africa, none of them English speaking, primarily in 
France which is very protective of its language, I would say that that 
is a non-issue. The DNS lingua franca started with Latin for .edu, .com, 
.mil, .org, and moved to English with the likes of .net, .biz and most 
gTLD's. There is a global acceptance that English and the Latin 
character set are used for some things on the Internet, and everyone can 
input left-to-right, Latin character strings on their keyboards. Nobody 
is calling for translations of "http" or "www", to my knowledge.

"Short and memorably" seems like an obvious goal to me. .home fits this, 
and is a well known word among non-English speakers. Even 
extraterrestrials point at the night sky and request to "phone home."

A notable exception is Deutsche Telekom whose gateways use ".lan". Which 
is an English acronym.

bfn, Wouter

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 20 Jul 2016 11:50:05 +0200

> memorable" is a requirement that falls out of section 3.7 of RFC 7368.

I suggest we put this question to the WG.  Perhaps the chairs would be
willing to ask whether the WG would prefer a name that is short and
memorable, or one that is long and impossible to remember?

> But worse, "home" is actually only memorable for people who know what
> that word is in English,

I seem to always hear this argument from native speakers of English.
I have spent much of the last 20 years working with native speakers of
French and Maghribi Arabic, many of whom have very little English, and we
have never had any issue with remembering short English words without
complex consonant clusters ("for" and even "while" are fine, but "length"
tends to cause problems).  My sample is certainly biased, but these are
first year students at a non-elite university (no tuition fees), so they
are probably representative of the public we're aiming for.

> and it's only even useful to people who use Latin characters.

I could be wrong, but I do not believe there exists any country in the
world where literate people are not familiar with the Latin alphabet.

-- Juliusz

---

From: Ralph Droms <[email-masked]>
Date: Wed, 20 Jul 2016 12:01:35 +0200

> On Jul 20, 2016, at 11:50 AM 7/20/16, Juliusz Chroboczek <[email-masked]> wrote:
> 

I think there are some important questions to answer first:

What is the meaning of .home and, precisely, how will names that end in .home be resolved?

Where and by whom will this label actually be used?  What is the research to back up the answer?

Although many people have given me a answer to the first question, and the answers often include phrases like "it just means..." or "everybody agrees that..." or "it's obvious...", I don't think I've seen a citable definition for the intention and semantics of .home; pointers welcome.

Without that definition, I don't think I know where and by whom the label will actually be used.  Will it turn out to be like .local, which, as far as I know, is rarely used anywhere and only ever by a certain class of expert user.

- Ralph

---

From: Suzanne Woolf <[email-masked]>
Date: Wed, 20 Jul 2016 06:04:34 -0400

> On Jul 20, 2016, at 5:50 AM, Juliusz Chroboczek <[email-masked]> wrote:
> 

Plenty of useful names— domain names and otherwise— are neither short nor memorable. Some are one but not the other. And while “short” is an objectively quantifiable property, “memorable” is quite a lot fuzzier. 

I admit I’m still not sure who’s going to see these names, so I don’t know for whom they’re intended to be memorable.

Which leads me to wonder why “short, memorable, already known to be polluted by other uses, and already the subject of an allocation process in another organization” is preferable to “short, memorable, highly likely to be conflict-free, and uncontroversial”?

I still hope for answers to the questions several of us have now asked repeatedly about how these names will be used. So far, I’ve heard repeatedly why “home” is believed to be an acceptable string to serve this purpose. What continues to confuse me is why it’s apparently believed to be the one and only acceptable string, or even the most preferred one.

Suzanne

---

From: Brian Haberman <[email-masked]>
Date: Wed, 20 Jul 2016 06:05:54 -0400

On 7/20/16 6:01 AM, Ralph Droms wrote:
>>>> We want something short and memorable.  ".co.uk" is short and
>>>> memorable. ".univ-paris-diderot.fr" is not.
>> 
>>> Why?  This is, I suspect, part of the issue: it seems that we
>>> have some assumptions about the use of these names, and I'm not
>>> entirely sure what they are.  It is not obvious to me that "short
>>> and memorable" is a requirement that falls out of section 3.7 of
>>> RFC 7368.
>> 
>> I suggest we put this question to the WG.  Perhaps the chairs would
>> be willing to ask whether the WG would prefer a name that is short
>> and memorable, or one that is long and impossible to remember?
> 
> Although many people have given me a answer to the first question,
> and the answers often include phrases like "it just means..." or
> "everybody agrees that..." or "it's obvious...", I don't think I've
> seen a citable definition for the intention and semantics of .home;
> pointers welcome.
> 
> Without that definition, I don't think I know where and by whom the
> label will actually be used.  Will it turn out to be like .local,
> which, as far as I know, is rarely used anywhere and only ever by a
> certain class of expert user.
> 

If the above holds, I would suggest (only partly in jest) a TLD that
contains a certain unicode value that can be visually displayed by an OS...

http://apps.timwhitlock.info/unicode/inspect/hex/1F3E0

Regards,
Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Jul 2016 06:22:28 -0400

> memorable, or one that is long and impossible to remember?

I think the questions that Suz and Ralph have already posted are ones
that must be answered first.  But …

> are probably representative of the public we're aiming for.

First year students in what, pray tell?  For I note that anyone who
works with any regularity on anything like computer code needs to have
some facility with Latin characters.  There was a presentation in the
HRPC RG in Buenos Aires claiming that this was a serious problem that
needed to be addressed.  I don't know that I agree, but it is a
significant difference between those who work with code and those who
merely want to be able to use their computers and networks.

> world where literate people are not familiar with the Latin alphabet.

"Familiar with the Latin alphabet" is hardly the point.  If your
writing system goes right to left, for instance, then plopping left to
right text into it is at least a pain in the neck and at worst a
significant source of bugs and security problems.  If I normally write
in Arabic, and use domain names that have U-labels in Arabic, then
suddenly running into a label "home" is going to make a mess.

Internationalization isn't hard because people doing it are morons.
It's hard in part because protocol elements that leak into user
interfaces haul in a whole bunch of UI considerations that the IETF is
traditionally very bad at.

Best regards.

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Jul 2016 06:24:30 -0400

> http://apps.timwhitlock.info/unicode/inspect/hex/1F3E0

This is the second time this has been suggested, actually, and the
only problem with it is that anything not somehow a letter or digit
isn't permitted under IDNA2008, which means that no emoji are allowed.
(There are actually good reasons for this -- it turns out to be hard
to read emoji out loud, for instance.)

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: joel jaeggli <[email-masked]>
Date: Wed, 20 Jul 2016 12:32:29 +0200

> to read emoji out loud, for instance.)

家 become homograph attacks are grand

---

From: Ralph Droms <[email-masked]>
Date: Wed, 20 Jul 2016 12:41:09 +0200

On Jul 20, 2016, at 12:24 PM 7/20/16, Andrew Sullivan <[email-masked]> wrote:

Perhaps we could use the punycode, xn--um8h?  That choice would be wonderfully ironic in that the only people who ever use the label will get the joke...

Best regards,

A

--
Andrew Sullivan
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 20 Jul 2016 13:15:32 +0200

The name should be short, easily recognized, and make some kind of sense.
It is important that the name look reasonable because we want the natural
human pattern matching ability that nearly all users can be expected to
have to notice when someone uses a name that is not quite correct, and to
not reject the name because it looks weird.

Honestly, discussions like this make me feel genuine despair for the IETF.
Why do we keep having this silly argument?  I was up until two in the
morning last night because I couldn't let go of the sorrow and frustration
that I feel about being forced to have this discussion again when we are
already doing with to address this problem in a different working group,
and we already had the same discussion over .onion.

Why do we need to talk this through again?

On Jul 20, 2016 12:42, "Ralph Droms" <[email-masked]> wrote:

> Perhaps we could use the punycode, xn--um8h?  That choice would be
> wonderfully ironic in that the only people who ever use the label will get
> the joke...
>
>
> Best regards,
>
> A
>
> --
> Andrew Sullivan
> [email-masked]
>

---

From: Ray Bellis <[email-masked]>
Date: Wed, 20 Jul 2016 13:33:25 +0200

> certain class of expert user.

<nohat>

I have three devices in my home that have web interfaces that are
accessible as http://<devicename>.local/ because they support Bonjour.

That URL is visible in the browser address bar, and not hidden away in
some device-specific control panel (e.g. the Printer chooser).  One of
those devices is a printer, and is therefore _also_ accessible like
that, hiding the '.local', but the other two are primarily accessed via
a browser.

Since those URLs must also be bookmarkable and because devices might
move around the network, any solution that mandates any subnet-specific
naming scheme would be unacceptable.

My expectation is that in a Homenet multi-subnet environment I will be
able to just use http://<device>.<TBD>/ and just have it work regardless
of which particular subnet that device is on [*].

It's also important to me that I be able to type those addresses in, and
for me that rules out the Unicode house symbol.

<still nohat>

I've previously argued that '.home' is fine for our purposes - I'm
coming around to the argument that it's better to start with a
greenfield "TBD" than to risk any conflict.

Ray

[*] notwithstanding name-collision issues...

---

From: Ray Bellis <[email-masked]>
Date: Wed, 20 Jul 2016 14:10:05 +0200

> of which particular subnet that device is on [*].

<really still no hat>

There's a further corollary to this:  since we can't mandate host
changes, the resolution of that name MUST be unicast DNS to an *on-net*
resolver.

Having different resolvers for different parts of the namespace is a bad
idea [*] so furthermore that resolver must also be capable of handling
queries received for the global namespace (whether by forwarding to an
off-net resolver, or performing full iterative resolution itself).

Ray

[ Current host stacks don't have support for saying "if the suffix is
".TBD", go here, otherwise go there.  If you have one resolver for
".TDB" and another for everything else and then just send all queries to
both, you still need host changes to cope with how you'll get a valid
answer from one but not the other ]

---

From: avri doria <[email-masked]>
Date: Wed, 20 Jul 2016 15:47:14 +0200

On 19-Jul-16 18:10, Ted Lemon wrote:
> Please read draft-lemon-sutldr-ps, and participate in the discussion
> about this on the dnsop mailing list.   Discussions about the RFC6761
> problem are off-topic for the homenet mailing list.   We are customers
> of the existing IETF consensus process as documented in RFC 6761.   We
> get into enough ratholes on the homenet mailing list; please don't get
> us into this rathole as well.   

I have done my reading.  Not only of your draft, the discussion in DNSOP
and the other drafts. Do not know why you presumed i hadn't.  Why, I
have even read RFC6761, several times.

I am also happy to avoid rat holes, but as far as I understand the case,
you did not follow the requirements of RFC6761 and thus this unassigned
usage does not have the imprimatur even of RFC6761, for whatever that
ends up being worth.  It was a decision made by this WG for this group's
reasons.  And it was missed in the review cycle.  Unfortunately I find I
only ended up working on this issue on 23 October, just as IET was
ending its last call.  Though I might have missed it as well.

I would also like to point out that the studies done for ICANN are by no
means the end of the story and do not represent a consensus decision of
ICANN at this point.  While there may be a 'restraining order' from the
ICANN Board on assigning the names at this point, that is not a
permanent consensus decision and is a situation that people in ICANN are
still actively working on.  To allocate a name that is under discussion
and contention and had been applied for in 2012,  at this point seems to
me to constitute an infringement of the policy prerogative given to
ICANN by RFC2860.  And while the recent 2015 study may have recommended
that ICANN ask IETF to reserve then name, an incredibly bad idea when
ICANN has its own policy development methods for reserving names, the
ICANN Board has not to my knowledge made any such formal request.

While IETF can certainly assign a name as a protocol parameter according
to RFC6761 ( despite any dispute that may or may not exist on the
validity of that process ) that does not mean they have the ability to
chose any name they wish, only that they may assign a name.  I would
recommend in the spirit of RFC2860 that you chose a name that is not the
point of a disagreement and that had not been applied for in 2012.  I
assume there is no technical reason why .home and only .home must be
used for protocol reasons alone.  As a protocol parameter, I would
assume any relationship between a string and dictionary word was just an
unhappy coincidence, and one to avoid.

If you want to hardcode a name into your protocol, I suggest you pick a
neologism like .homenet  or even .hmnt it you want something short and
pithy, and avoid the rat hole that is .home.

cheers,
avri

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 20 Jul 2016 17:11:12 +0200

> Current host stacks don't have support for saying "if the suffix is
> ".TBD", go here, otherwise go there.

Right, and I missed this point in my strawman.  I guess I've been spoiled
by dnsmasq.

-- Juliusz

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 20 Jul 2016 12:32:06 -0400

Hi,

> > of which particular subnet that device is on [*].

Note that only one of those expectations is actually given you by RFC
7368 -- that it will just work no matter which subnet you're on.  The
<device>.<TBD> pattern (assuming TBD is a single label) is not.

> changes, the resolution of that name MUST be unicast DNS to an *on-net*

I think this is probably entailed, but RFC 7368 doesn't say that
either.  It just says that it probably needs to be (or needs to work
somehow with DNS).

> idea [*]

Except, of course, that's precisely what we have with Bonjour: DNS for
everything except names ending in local.  That label functions as a
protocol switch to tell your combined resolver which names to resolve
by mDNS and which ones to resolve by DNS.

> answer from one but not the other ]

Not necessarily.  For instance, you could use Bonjour and the hybrid
proxy approach and do it that way.  It's not clear to me from RFC 7368
whether we're allowed to assume mDNS is available on any host, but
given the zeroconf pattern and the stated desirability of it, probably
we are.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ray Bellis <[email-masked]>
Date: Wed, 20 Jul 2016 18:58:51 +0200

> by mDNS and which ones to resolve by DNS.

I was talking in the context of unicast DNS, without a 'protocol switch'.

Ray