Subject: [homenet] RFC 7788-bis

From: Ray Bellis <[email-masked]>
Date: Thu, 16 Jun 2016 18:26:03 +0100

As was alluded to in my email of 9th June, we have been asked to replace
RFC 7788 (HNCP) with an RFC 7788-bis as soon as possible to incorporate
the errata raised by the DNSOP chair regarding the unintended apparent
reservation of ".home" as the default domain TLV within HNCP.

We should also take that opportunity to fix the error in the diagrams
for the DHCPv4_DATA and DHCPv6_DATA TLVs where the numbers shown
conflict with the IANA registrations for those TLVs.

Those two changes will be the only ones made, unless any further errata
are made in the meantime.

Slightly longer term, and notwithstanding our previously stated desire
to wait until Ted Lemon's Naming Architecture was further progressed, we
would like to obtain WG consensus on whether ".home" is indeed a
suitable default domain for HNCP.  In the meantime, implementors are
hereby advised that ".home" is potentially subject to change.

It should be noted (as pointed out to us by the Chair of the IAB) that
the default domain need not be a single-label "pseudo-TLD" - it could be
a sub-domain of an existing name in the DNS such as ".arpa".

Whichever domain is chosen, we will then instigate a new WG document (or
perhaps resurrect draft-cheshire-homenet-dot-home if ".home" is
preferred) to follow due process and formally reserve a default domain
as a "special use domain name".

Ray and Mark

---

From: Ralph Droms <[email-masked]>
Date: Thu, 16 Jun 2016 14:48:46 -0400

> On Jun 16, 2016, at 1:26 PM 6/16/16, Ray Bellis <[email-masked]> wrote:
> 

In my opinion, it is important for the exact requirements and semantics for the default domain be defined, perhaps even before the default domain itself is selected.  It's not clear to me whether the domain carried in the Domain-Name TLV can be a delegated domain or it has to be a special use domain name for location-relative name resolution like .local, or if either type of name is OK.

- Ralph

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

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 16 Jun 2016 14:49:33 -0400

> In my opinion, it is important for the exact requirements and semantics for the default domain be defined, perhaps even before the default domain itself is selected.  It's not clear to me whether t…

+1 on this.

tim

---

From: Ray Bellis <[email-masked]>
Date: Thu, 16 Jun 2016 19:55:53 +0100

On 16/06/2016 19:48, Ralph Droms wrote:

> In my opinion, it is important for the exact requirements and
> semantics for the default domain be defined, perhaps even before the
> default domain itself is selected.  It's not clear to me whether the
> domain carried in the Domain-Name TLV can be a delegated domain or it
> has to be a special use domain name for location-relative name
> resolution like .local, or if either type of name is OK.

It's my understanding (albeit this may change depending on Ted's work)
that it may be either.

The particular point of ".home" (or whatever) would be to provide a
"special use" domain that is known to have "homenet site local"
semantics that should leak as little as possible outside of that.

I think it would also be appropriate to add whatever name is chosen to
the BCP 163 list of "Locally Server DNS Zones" such that any queries
that do happen to leak beyond the site get sunk by the recursive
resolver that receives them.

Ray

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Jun 2016 15:21:21 -0400

Ray Bellis <[email-masked]> wrote:
    > the default domain need not be a single-label "pseudo-TLD" - it could
    > be a sub-domain of an existing name in the DNS such as ".arpa".

I propose that we use something like:
          THING.hn.arpa

Where THING is the local translation of "home".  
I'm open to something other than hn (HomeNet), but it has to be really short.
If we could get away with h.arpa, that would be cool too.

Thus:
        home.hn.arpa
        ホーム.hn.arpa
        maison.hn.arpa

الصفحة الرئيسية.hn.arpa

Well, the last one is supposed to be arabic, assuming that google translate worked, and my emacs's mixed left/right, and right/left stuff worked right, and my  MUA all do the right thing.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Jun 2016 13:26:29 -0700

See RFC3172.

I don't think .arpa is the correct place for this sort of stuff.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Jun 2016 17:13:53 -0400

Yeah, we went down the .arpa path with .local back in ~2000 and it was
soundly rejected. :)

On Thu, Jun 16, 2016 at 4:26 PM, Joe Touch <[email-masked]> wrote:

> > Well, the last one is supposed to be arabic, assuming that google
> translate worked, and my emacs's mixed left/right, and right/left stuff
> worked right, and my  MUA all do the right thing.
> >
> > --

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 17 Jun 2016 01:13:09 +0200

> Where THING is the local translation of "home".  

Let us please not open this particular can of worms:

  - how does software running on my laptop, which just connected to an
    unknown network, find out what is the local translation of "home"?

  - how does a user, even one who knows the local language, find out which
    of the possible translations of "home" is the right one?  (What should
    it be for Greek?  oikos?  opiti?  You are allowed to consult speakers
    of Greek, but you must get them to reach consensus before the end of
    the week.)

  - how do I type οίκος on my French keyboard?

There's some precedent for this kind of problems -- Outlook used to
(incorrectly) internationalise the prefix "Re:" in e-mail replies.  Since
software couldn't be expected to know all of the Microsoftese for "Re",
you'd end up with subject lines such as "Re: Rép: Antw: Odp: ...".
(Re, of course, is Latin for "about such thing", not the abbreviation of
"reply".)

(The right choice for Homenet, of course, is ".domus".  Although, now that
I think about it, RFC 1034 doesn't mention whether domain names are in the
nominative or the locative, so perhaps we should also consider ".domo".)

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Thu, 16 Jun 2016 19:53:42 -0400

Those who come from cultures that speak languages descended from older or
different roots might challenge the universality of that proposal.  Perhaps
they might argue in favor of .kotiin or .घर.

I don't think there is a correct answer to this.   .local has worked, which
is the best we can hope for with whatever name we come up with.   If i18n
motivates different names depending on the UI language, that will be a
problem.   If we really think that the name shouldn't be in english, which
is a position to which I can certainly relate, it probably shouldn't be a
word in any language.

---

From: "Edmon Chung" <[email-masked]>
Date: Fri, 17 Jun 2016 07:58:10 +0800

perhaps it would be easier/better to pick a name from the "reserved names" at the ICANN/IANA which cannot otherwise be used anyway?...

e.g. 2 character non-countrycodes:
QM 	QN 	QO 	QP 	QQ 	QR 	QS 	QT 	QU 	QV 	QW 	QX 	QY 	QZ
XA 	XB 	XC 	XD 	XE 	XF 	XG 	XH 	XI 	XJ 	XK 	XL 	XM 	XN 	XO 	XP 	XQ 	XR 	XS 	XT 	XU 	XV 	XW 	XX 	XY 	XZ

The above are considered "User-assigned: free for assignment at the disposal of users" in the ISO3166 standard but are still reserved by ICANN/IANA not to be used anyway.

Another option would be to add "-" or a digit to avoid collision, since those are also not currently accepted in ICANN TLDs. e.g. .H1 , .h-h

Just some thoughts... rather than using an alphabetic "word" 

Edmon

> -----Original Message-----
> From: homenet [mailto:[email-masked]] On Behalf Of Juliusz
> Chroboczek
> Sent: Friday, 17 June 2016 07:13 AM
> To: Michael Richardson <[email-masked]>
> Cc: HOMENET <[email-masked]>
> Subject: Re: [homenet] alternatives to .home
> 
> (incorrectly) internationalise the prefix "Re:" in e-mail replies.  Since software
> couldn't be expected to know all of the Microsoftese for "Re", you'd end up with
> subject lines such as "Re: Rép: Antw: Odp: ...".
> (The right choice for Homenet, of course, is ".domus".  Although, now that I think
> about it, RFC 1034 doesn't mention whether domain names are in the nominative or
> the locative, so perhaps we should also consider ".domo".)
> 
> -- Juliusz
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Jun 2016 17:05:41 -0700

> e.g. 2 character non-countrycodes:

 All currently unused 2-letter codes can still be assigned by ISO as
country codes.

Hint: if something is "reserved", there's probably a reason.

Joe

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 16 Jun 2016 21:00:44 -0400

Quite apart from the correct remark of Ralph and Tim,

On Thu, Jun 16, 2016 at 06:26:03PM +0100, Ray Bellis wrote:
> suitable default domain for HNCP.

… it is not.  We know both that (1) it is already in use in the wild
in undetermined ways and (2) that some people have spent a bunch of
money attempting to get it delegated to them in the global DNS.  We
should not, IMO, even for a moment consider using a name with
well-known conflicting properties.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 16 Jun 2016 21:04:56 -0400

> I don't think .arpa is the correct place for this sort of stuff.

Why?  "[T]his domain name undertakes a role as a limited use domain
for Internet infrastructure applications," and

   This domain is termed an "infrastructure domain", as its role is to
   support the operating infrastructure of the Internet.  In particular,
   the "arpa" domain is not to be used in the same manner (e.g., for
   naming hosts) as other generic Top Level Domains are commonly used.

If the names beneath this special-use name are supposed to cause
software to do something differently than it would with any other
domain name, then that sounds like "infrastructure" to me.  That's why
we used it for the special IPv4 only name in dns64, for instance.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 16 Jun 2016 21:10:39 -0400

On Thu, Jun 16, 2016 at 07:53:42PM -0400, Ted Lemon wrote:

>.local has worked

But mostly because ordinary humans never see it.  That's what's not
clear to me.

Is this a name that will mostly be hidden by user-interface sugar
(which is mostly how it works with mDNS -- please don't tell me about
ssh.  That's not our audience, I maintain)?  If so, then any domain
will do, and putting it under arpa would be fine.

Is it a name that we expect people often to use in you-type-it-in
contexts?  If so, then the story is very different.

In any case, I'd really like "translation" to be off the table.  We
are not competent to do that, and anyway we're specifying a permanent
part of infrastructure that will not be able to evolve as (say)
language evolves.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 16 Jun 2016 21:55:26 -0400

> semantics that should leak as little as possible outside of that.

Yes, agreed. When you as for printer.home, you expect a ULA that you can reach.
When you ask for printer.delegatedomain.isp.example.net, you could get a
number of things: GUAs, or even ULAs that you can't reach (because they are
in my home, or because they are in your *other* home [and the VPN is down?]...)

    > resolver that receives them.

Agreed... and AS112?

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Jun 2016 21:32:41 -0700

>    naming hosts) as other generic Top Level Domains are commonly used.
The use of .home is a lot more like a conventional TLD than it is like
any other use in .arpa (e.g., reverse lookups based on IP addresses,
telephone number mapping, etc.).

> we used it for the special IPv4 only name in dns64, for instance.

The software does exactly the same thing. Having a response is based on
a local database, such that the same query in different places gives
different results, is not uncommon in other TLD lookups.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Jun 2016 00:42:31 -0400

Ordinary humans see names all the time.   See section 2.1 of the homenet
naming architecture; if you disagree with the reasoning there, please
suggest text!   :)

https://tools.ietf.org/html/draft-lemon-homenet-naming-architecture-00#section-2.1

---

From: "Edmon Chung" <[email-masked]>
Date: Fri, 17 Jun 2016 12:47:36 +0800

the ones identified are allocated for user specific use so they cannot
become country codes.
Edmon

> From: homenet [mailto:[email-masked]] On Behalf Of Joe Touch
> Sent: Friday, 17 June 2016 08:06 AM
> To: Edmon Chung <[email-masked]>; 'Juliusz Chroboczek' <[email-masked]
> paris-diderot.fr>; 'Michael Richardson' <[email-masked]>
> Cc: 'HOMENET' <[email-masked]>
> > perhaps it would be easier/better to pick a name from the "reserved
names" at the
> ICANN/IANA which cannot otherwise be used anyway?...
> >
country codes.

---

From: "Edmon Chung" <[email-masked]>
Date: Fri, 17 Jun 2016 13:23:44 +0800

see: https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
for explanation.
Edmon

> From: homenet [mailto:[email-masked]] On Behalf Of Edmon Chung
> Sent: Friday, 17 June 2016 12:48 PM
> To: 'Joe Touch' <[email-masked]>; 'Juliusz Chroboczek' <[email-masked]
> diderot.fr>; 'Michael Richardson' <[email-masked]>
become country
> codes.
> > To: Edmon Chung <[email-masked]>; 'Juliusz Chroboczek'
> > <[email-masked] paris-diderot.fr>; 'Michael Richardson'
> > <[email-masked]>

---

From: Joe Touch <[email-masked]>
Date: Thu, 16 Jun 2016 23:05:32 -0700

> the ones identified are allocated for user specific use so they cannot
And the citation you give (the Wikipedia entry) indicates how some of
them are being used - not for countries, but in other ways that could
interfere with their use by IANA.

Joe

---

From: Pierre Pfister <[email-masked]>
Date: Fri, 17 Jun 2016 09:37:48 +0200

I think this is a key point indeed.

mDNS works really hard to *not* show any name to the user.
I would like it to be the same for homenet, but I am not sure we have a complete solution for no-name multi-link service discovery for homenet yet.

So either we seriously address the service discovery problem. And we make the assumption that non-geeky users shall not see names, never. In which case the name we pick does not matter.
Or we assume users will see names, in which case allocating a user-friendly name is utterly important.

Regards

- Pierre

> Le 17 juin 2016 à 03:10, Andrew Sullivan <[email-masked]> a écrit :
>

---

From: Markus Stenberg <[email-masked]>
Date: Fri, 17 Jun 2016 11:22:43 +0300

> I would like it to be the same for homenet, but I am not sure we have a complete solution for no-name multi-link service discovery for homenet yet.

Agreed; dealing with naming collisions is mainly the painful part on implementation front.

> Or we assume users will see names, in which case allocating a user-friendly name is utterly important.

For home use case, I suspect there is no need for multiple zones _at all_, at least visible to the user, and users do not typically care about the domain unless they want remote access (and I am not sure many really do, and in that case it would be something sourced from ISP anyway).

e.g. even if we (for implementation purposes) use hybrid proxy underneath, the published data would be just ‘legacy browse’ (flat, no domain at all) names and not ‘browse’ (full domain _including_ whatever .hn.asdf.arpa we wind up with). To make names unique we might want to garbage-fy them if we want to use mdns as source of information, but that’s it.

Cheers,

-Markus

---

From: Ray Bellis <[email-masked]>
Date: Fri, 17 Jun 2016 09:37:06 +0100

> well-known conflicting properties.

<nohat>

Whilst there may be "undermined" ways it's being used, it's clear that
most of the ways it's used are just because some vendors and sites
decided to use that for their default *site local* domain which makes it
completely consistent with what we need.

I therefore completely disagree on point #1 - officially allocating
.home for this purpose and having it "sunk" by default on internet
facing recursive resolvers would IMHO actually *help* with the traffic
hitting the root and reduce leakage of it.

As for #2, yeah, that's hard, but it seems ICANN won't do anything about
".home" because of #1 anyway, but they seemed stalled on outright
rejecting it and have said (AFAICR) that an RFC 6761 registration would
allow them to reject (and refund) those applications.

Ray

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Jun 2016 09:17:19 -0400

> unknown network, find out what is the local translation of "home"?

It doesn't. It uses HNCP.

    >   - how does a user, even one who knows the local language, find out
    > which of the possible translations of "home" is the right one?  (What
    > should it be for Greek?  oikos?  opiti?  You are allowed to consult
    > speakers of Greek, but you must get them to reach consensus before the
    > end of the week.)

    >   - how do I type οίκος on my French keyboard?

You don't. You type "printer", and/or select "printer" from a selection menu.

    > (incorrectly) internationalise the prefix "Re:" in e-mail replies.

yes. I agree that this is annoying.

    > Since software couldn't be expected to know all of the Microsoftese for
    > "Re", you'd end up with subject lines such as "Re: Rép: Antw: Odp:
    > ...".  (Re, of course, is Latin for "about such thing", not the
    > abbreviation of "reply".)

That's definitely a good point. Outlook should have a bug that the English
translation of "Re" is wrong.

    > (The right choice for Homenet, of course, is ".domus".  Although, now
    > that I think about it, RFC 1034 doesn't mention whether domain names
    > are in the nominative or the locative, so perhaps we should also
    > consider ".domo".)

I'm open to this idea... I prefer domus.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Jun 2016 09:21:20 -0400

> But mostly because ordinary humans never see it.  That's what's not

I think so. I also think that it shows up in logs and ...

    > will do, and putting it under arpa would be fine.

+10.

and yes, it shows up in ssh for the geeks.

    > In any case, I'd really like "translation" to be off the table.  We are
    > not competent to do that, and anyway we're specifying a permanent part
    > of infrastructure that will not be able to evolve as (say) language
    > evolves.

We specify "THING.hn.arpa" (it's really "hn.arpa" that we are reserving, and
suggesting that it have one additional label) and let local culture come to
their own consensus.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Jun 2016 09:23:15 -0400

Edmon Chung <[email-masked]> wrote:
    > e.g. 2 character non-countrycodes: QM QN QO QP QQ QR QS QT QU QV QW QX
    > QY QZ XA XB XC XD XE XF XG XH XI XJ XK XL XM XN XO XP XQ XR XS XT XU XV
    > XW XX XY XZ

.xh
.xn

seem like the best.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Jun 2016 09:30:57 -0400

Michael, the reason to have a consistent name is that the name _will_ show
up in UI elements, and therefore _should_ behave in a comprehensible
manner.   The IETF tends to be understandably dismissive of the end-user's
capacity to correctly model the functioning of the network, but we should
not use techniques that deliberately subvert the user's ability to make
models.

The problem with presenting something that is not the actual token that is
being used to address the device to the user is that the user cannot then
tell the difference between that device and some other device with the same
presentation name, but a different identifying name.   This then becomes an
attack surface for malware that wants to trick the user.

Even if the user doesn't understand the structure of the name, there is no
harm in revealing that name in the UI.   It can appear next to the
descriptive name.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Jun 2016 09:39:32 -0400

Ted Lemon <[email-masked]> wrote:
    > Michael, the reason to have a consistent name is that the name _will_
    > show up in UI elements, and therefore _should_ behave in a
    > comprehensible manner. The IETF tends to be understandably dismissive
    > of the end-user's capacity to correctly model the functioning of the
    > network, but we should not use techniques that deliberately subvert the
    > user's ability to make models.

I violently agree, but you seem to be saying I missed this.

Perhaps you can explain to me what it is that you think I'm suggesting?

That's also why I think that it should be possible for the underlying name to
be in the native language.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Jun 2016 09:44:49 -0400

If the name is not consistent wherever the user encounters it, the model
that the user forms will be wrong.   If .home and .domus are treated as
equal by the system, but presented inconsistently, then the user will form
a mental model that sees the two as distinct.   And, to be clear, any time
you have a UI that is responsible for faking things out for the user, you
will have inconsistencies, and the user will see these inconsistencies.

It's much better not to do this.   I think that the model of hiding
".local" is wrong for just this reason.   The user interface should be
operable by someone who does not have a correct mental model of how the
network works, but should still present information that is consistent with
that model and doesn't hide information.

---

From: avri doria <[email-masked]>
Date: Fri, 17 Jun 2016 15:38:42 -0400

> nominative or the locative, so perhaps we should also consider ".domo".)

I think there is an important point in this bit of humor.  If it is
decided that a TLD needs to be reserved for the purposes of a protocol,
it does not need to be a natural language word from any particular
living language.  

Additionally, it is good to include in the requirements that any name
selected should not be one that is in use already, whether by delegation
or de-facto, or is in contention elsewhere. It should be a combination
of characters that brings no baggage with it.

Neologisms like "homenet" are good compromises between human factor
understanding and avoidance of problem areas.

avri

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 17 Jun 2016 15:52:50 -0400

Ted Lemon <[email-masked]> wrote:
    > model that the user forms will be wrong. If .home and .domus are

I don't propose that they be the same.

I'm suggesting that the HNCP will pick one or the other (or some other
translation) is picked as the single choice.

    > ".local" is wrong for just this reason.

Please explain more. Is it that I should be able to copy and paste from the
UI to my command line?  How is showing .local in the GUI important?

---

From: Jacques Latour <[email-masked]>
Date: Fri, 17 Jun 2016 20:05:43 +0000

How about a single internationally recognised symbol?

. 🏠     (for those in text, it’s .[emoji for a home])

. xn--um8h

Thinking too much out of the box? ☺  Happy Friday

Jack

-----Original Message-----
From: homenet [mailto:[email-masked]] On Behalf Of Michael Richardson
Sent: June-17-16 3:53 PM
To: Ted Lemon
Cc: HOMENET; Juliusz Chroboczek; Edmon Chung
Subject: Re: [homenet] alternatives to .home

    > ".local" is wrong for just this reason.

Please explain more. Is it that I should be able to copy and paste from the UI to my command line?  How is showing .local in the GUI important?

--

Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Erik Kline <[email-masked]>
Date: Fri, 17 Jun 2016 14:04:11 -0700

> I'm open to this idea... I prefer domus.

Of course, like the redefinition of what "arpa" stands for (see RFC
referred to early), we could just decide that "home" stands for
"Household or Medium-sized Entity" (or some other suitably
entertaining and descriptive acronym) and then file the appropriate
requesting paperwork.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 17 Jun 2016 23:29:11 +0200

> different roots might challenge the universality of that proposal.

I strongly object to Sumerian cuneiform.

> I don't think there is a correct answer to this. .local has worked, which is
> the best we can hope for with whatever name we come up with. If i18n motivates
> different names depending on the UI language, that will be a problem. If we
> really think that the name shouldn't be in english, which is a position to
> which I can certainly relate, it probably shouldn't be a word in any language.

That's fine with me.  But having different names depending on the locale
is an absolutely horrible idea.

(What should happen when a Homenet localised for Amharic merges with one
that uses Tigrinya?  Should the Homenet advertise two zones and duplicate
everything within both?  Or should it pick one dominant language according
to the number of speakers?  Please provide working code with your answer.)

-- Juliusz

---

From: Suzanne Woolf <[email-masked]>
Date: Fri, 17 Jun 2016 17:31:26 -0400

Hi,

I’d like to gently suggest that if the long-running discussion on the topic of special use names in DNSOP has taught us anything, it’s that the behavior people would like to have from DNS resolvers, users, etc. for a name is of primary importance. The choices of name resolution protocol, format of a name in presentation and on the wire, and other characteristics of the context for resolution are more important than the specific string.

The discussion so far, and RFC 7788 AFAICT, assume that homenet is talking about names that are compatible with domain names. However, the discussion has not been clear about exactly what conditions are assumed around handling those names.

What defines a special use domain name is how it is *used*. Without details of how it’s to be used, it’s impossible to determine characteristics for suitable strings, such as “must be human-friendly” or “doesn’t matter if it’s known to collide with another set of names/resolution context cues” or “must result in a specific response when presented to DNS resolvers.”

The answers to the questions in RFC 6761, Section 5, are intended to constitute a description of how a proposed special use name is special in its use. Without answers to those questions, it’s simply not clear what’s special about the proposed names or what limits are appropriate to put on strings that might be reserved for that use.

Suzanne

> On Jun 17, 2016, at 3:52 PM, Michael Richardson <[email-masked]> wrote:
> 
>

---

From: Juliusz Chroboczek <[email-masked]>
Date: Fri, 17 Jun 2016 23:47:04 +0200

> It doesn't. It uses HNCP.

Please describe exactly how my laptop (which doesn't run HNCP) finds out
the right domain.  Please describe how an HNCP router that joins an
existing Homenet finds out the right domain.  Please describe what happens
when two equally-sized Homenets merge.

Michael, trust me -- this is not something that we want to implement.

-- Juliusz

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Jun 2016 18:00:09 -0400

You propose that .domus and .home both be possible presented names for the
same object: the home network.   Users will use many devices on the home
network; each of these devices will have to display the same name.   If the
actual name is the same, this is easy.   If the UI has to make it look like
it's the same, this will be hard, and will be gotten wrong.

Users will be expected to visit each others' homes.   Settings in each home
may be different.   Yet printer.domus in home A will reference printer.home
in home B, which will produce an unexpected error when that reference is
used.

The actual name of a thing should always be presented.   Whether it's
copy-and-pasteable is a UI detail, but if you are looking at a pointer, the
pointer should always look the same if it points to the same object, no
matter what device you are using.

Using the same name for every homenet that doesn't have its own global name
has the very nice quality that we don't have to do anything clever to make
it work.   That's why that's what I'm recommending.   I get that it would
be nicer to say .domus for homenets in the vatican, and .home for homenets
in english-speaking countries, but that's harder to achieve, and would have
to add a lot of value to be worth doing.   As Andrew says, answering a
slightly different question, we really don't want to have to do that.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 17 Jun 2016 18:01:45 -0400

Yes, exactly.   Thanks for putting it so succinctly, Suzanne.   :)

On Fri, Jun 17, 2016 at 5:31 PM, Suzanne Woolf <[email-masked]>
wrote:

> Hi,
>
> I’d like to gently suggest that if the long-running discussion on the
> topic of special use names in DNSOP has taught us anything, it’s that the
> behavior people would like to have from DNS resolvers, users, etc. for a
> name is of primary importance. The choices of name resolution protocol,
> format of a name in presentation and on the wire, and other characteristics
> of the context for resolution are more important than the specific string.
>
> The discussion so far, and RFC 7788 AFAICT, assume that homenet is talking
> about names that are compatible with domain names. However, the discussion
> has not been clear about exactly what conditions are assumed around
> handling those names.
>
> What defines a special use domain name is how it is *used*. Without
> details of how it’s to be used, it’s impossible to determine
> characteristics for suitable strings, such as “must be human-friendly” or
> “doesn’t matter if it’s known to collide with another set of
> names/resolution context cues” or “must result in a specific response when
> presented to DNS resolvers.”
>
> The answers to the questions in RFC 6761, Section 5, are intended to
> constitute a description of how a proposed special use name is special in
> its use. Without answers to those questions, it’s simply not clear what’s
> special about the proposed names or what limits are appropriate to put on
> strings that might be reserved for that use.
>
>
>
> Suzanne
>
>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Jun 2016 10:23:52 -0400

> Please describe exactly how my laptop (which doesn't run HNCP) finds
    > out the right domain.  Please describe how an HNCP router that joins an

I think that it's in the DHCP.  You could ignore it.
DHCP/SearchPath is fraught with issues.

AFAIK, ".local" is not used on the wire with mDNS.
The .local is a clue from the end-user to the resolver that you should
use mDNS to resolve the name.

But, we aren't talking about mDNS, we are talking about names which are
resolved using standard DNS mechanisms, probably via search-path like thing,
which are split-horizon DNS and with return (mostly) ULA IPv6 names for parts
which are (possibly) more than one hop away.

We do need a special name with special treatment (whether it is localized or
not) because we need to teach tools like SSH and HTTPS that the name
"printer.home" can not be permanently bound to the same public key all the
time.  In particular, it needs to be qualified by the attachment point
(probably DHCP Server's DUID is best is available).

---

From: Ralph Droms <[email-masked]>
Date: Mon, 20 Jun 2016 11:01:40 -0400

> On Jun 20, 2016, at 10:23 AM 6/20/16, Michael Richardson <[email-masked]> wrote:
> 

wireshark seems to indicate .local is included on the wire with mDNS requests.

> which are (possibly) more than one hop away.

Is this architecture documented somewhere?  I ask because I'm a little surprised by:

* standard DNS mechanisms
* split-horizon DNS
* (mostly) ULA IPv6

I'll admit to not having paid close attention and I might have missed this discussion.  And telling me to reread Ted's homenet naming architecture document is a fine response.

> (probably DHCP Server's DUID is best is available).

Personally, I think there will be broader scope to the special treatment of homenet-relative names, but won't know for sure until the details are nailed down.

- Ralph

---

From: Peter Koch <[email-masked]>
Date: Mon, 20 Jun 2016 17:27:52 +0200

> allow them to reject (and refund) those applications.

which is even another reason for the IETF not to step into this particular trap.

-Peter

---

From: Michael Richardson <[email-masked]>
Date: Mon, 20 Jun 2016 15:35:33 -0400

Michael Richardson <[email-masked]> wrote:
    > AFAIK, ".local" is not used on the wire with mDNS.  The .local is a
    > clue from the end-user to the resolver that you should use mDNS to
    > resolve the name.

I stand corrected: it's on the wire.