Re: [homenet] alternatives to .home

[Michael Richardson]

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

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Ralph Droms]

> On Jun 20, 2016, at 10:23 AM 6/20/16, Michael Richardson  
> wrote:
> 
> Juliusz Chroboczek  wrote:
 - how does software running on my laptop, which just connected to an
 unknown network, find out what is the local translation of "home"?
> 
>>> 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
> 
> 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.

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

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

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.

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

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

> 
> 
> --
> ]   Never tell me the odds! | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works| network architect  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Michael Richardson]

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

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

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


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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Ted Lemon]

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

On Fri, Jun 17, 2016 at 5:31 PM, Suzanne Woolf 
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
>
>
> > On Jun 17, 2016, at 3:52 PM, Michael Richardson 
> wrote:
> >
> >
> > Ted Lemon  wrote:
> >
> >> It's much better not to do this. I think that the model of hiding
> >> ".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?
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Ted Lemon]

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.

On Fri, Jun 17, 2016 at 3:52 PM, Michael Richardson 
wrote:

>
> Ted Lemon  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.
>
> > It's much better not to do this. I think that the model of hiding
> > ".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 , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Juliusz Chroboczek]

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

> 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Suzanne Woolf]

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  wrote:
> 
> 
> Ted Lemon  wrote:
> 
>> It's much better not to do this. I think that the model of hiding
>> ".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?

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Juliusz Chroboczek]

> Those who come from cultures that speak languages descended from older or
> 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Michael Richardson]

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

> It's much better not to do this. I think that the model of hiding
> ".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 , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[avri doria]

On 16-Jun-16 19:13, Juliusz Chroboczek wrote:
> (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 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Ted Lemon]

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.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Michael Richardson]

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






--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Ted Lemon]

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.

On Fri, Jun 17, 2016 at 9:23 AM, Michael Richardson 
wrote:

>
> Edmon Chung  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.
>
> --
> Michael Richardson , Sandelman Software Works
>  -= IPv6 IoT consulting =-
>
>
>
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Michael Richardson]

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

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Michael Richardson]

Andrew Sullivan  wrote:
>> .local has worked

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

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

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

+10.

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

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

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.

--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Michael Richardson]

Juliusz Chroboczek  wrote:
> 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"?

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.

> There's some precedent for this kind of problems -- Outlook used to
> (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.


--
Michael Richardson , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Markus Stenberg]

On 17.6.2016, at 10.37, Pierre Pfister  wrote:
> 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.

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

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

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Joe Touch]

On 6/16/2016 9:47 PM, Edmon Chung wrote:
> the ones identified are allocated for user specific use so they cannot
> become country codes.
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


> Edmon
>
>
>
>> -Original Message-
>> From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Joe Touch
>> Sent: Friday, 17 June 2016 08:06 AM
>> To: Edmon Chung <ed...@registry.asia>; 'Juliusz Chroboczek' <j...@pps.univ-
>> paris-diderot.fr>; 'Michael Richardson' <m...@sandelman.ca>
>> Cc: 'HOMENET' <homenet@ietf.org>
>> Subject: Re: [homenet] alternatives to .home
>>
>>
>>
>> On 6/16/2016 4:58 PM, Edmon Chung wrote:
>>> 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:
>>  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
>>
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Edmon Chung]

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



> -Original Message-
> From: homenet [mailto:homenet-boun...@ietf.org] On Behalf Of Joe Touch
> Sent: Friday, 17 June 2016 08:06 AM
> To: Edmon Chung <ed...@registry.asia>; 'Juliusz Chroboczek' <j...@pps.univ-
> paris-diderot.fr>; 'Michael Richardson' <m...@sandelman.ca>
> Cc: 'HOMENET' <homenet@ietf.org>
> Subject: Re: [homenet] alternatives to .home
> 
> 
> 
> On 6/16/2016 4:58 PM, Edmon Chung wrote:
> > 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:
> 
>  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
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Ted Lemon]

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

On Thu, Jun 16, 2016 at 9:10 PM, Andrew Sullivan 
wrote:

> 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
> a...@anvilwalrusden.com
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Joe Touch]

On 6/16/2016 6:04 PM, Andrew Sullivan wrote:
> On Thu, Jun 16, 2016 at 01:26:29PM -0700, Joe Touch wrote:
>> See RFC3172.
>>
>> 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.
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.).

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

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Andrew Sullivan]

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
a...@anvilwalrusden.com

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Andrew Sullivan]

On Thu, Jun 16, 2016 at 01:26:29PM -0700, Joe Touch wrote:
> See RFC3172.
> 
> 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
a...@anvilwalrusden.com

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Joe Touch]

On 6/16/2016 4:58 PM, Edmon Chung wrote:
> 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:

 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Edmon Chung]

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:homenet-boun...@ietf.org] On Behalf Of Juliusz
> Chroboczek
> Sent: Friday, 17 June 2016 07:13 AM
> To: Michael Richardson <m...@sandelman.ca>
> Cc: HOMENET <homenet@ietf.org>
> Subject: Re: [homenet] alternatives to .home
> 
> > 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
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Ted Lemon]

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  wrote:

> See RFC3172.
>
> I don't think .arpa is the correct place for this sort of stuff.
>
> Joe
>
> On 6/16/2016 12:21 PM, Michael Richardson wrote:
> > Ray Bellis  wrote:
> > > 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".
> >
> > 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  [
> > ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on
> rails[
> >
> > ___
> > homenet mailing list
> > homenet@ietf.org
> > https://www.ietf.org/mailman/listinfo/homenet
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] alternatives to .home

[Joe Touch]

See RFC3172.

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

Joe

On 6/16/2016 12:21 PM, Michael Richardson wrote:
> Ray Bellis  wrote:
> > 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".
>
> 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  [
> ] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails
> [
>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

[homenet] alternatives to .home

[Michael Richardson]

Ray Bellis  wrote:
> 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".

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  [
] m...@sandelman.ca  http://www.sandelman.ca/|   ruby on rails[

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet