Subject: Re: [homenet] Homenet Naming Architecture

From: Douglas Otis <[email-masked]>
Date: Mon, 18 Jan 2016 16:14:46 -0800

Dear Ray,

Still willing.  At the last IETF meeting during Bits and
Bytes, Andrew Sullivan expressed concerns with respect to
use of .home (4th) with a 60% YtoY increase and .corp (21st)
with a 18% YtoY increase as TLD labels to declare
non-multicast conventions for local names excluding
multicast conventions related to .local.

<2013>
https://www.icann.org/en/system/files/files/name-collision-02aug13-en.pdf
,--
At the high end, the cluster includes the proposed TLDs that
occur with at least order-of-magnitude greater frequency
than any others (corp and home) and those that occur most
frequently in internal X.509 public key certificates (mail
and exchange in addition to corp).
'--
,--
RECOMMENDATION 1: The TLDs .corp, .home, and .mail be
referred to the Internet Engineering Task Force (IETF) for
potential RFC 1918-like protection/treatment.
'--

<2014>
https://www.icann.org/en/system/files/files/name-collision-mitigation-study-06jun14-en.pdf

Suggest alternative TLDs proposed by
http://tools.ietf.org/html/rfc6762
such as:
.intranet.
.internal.
.private.
.corp.
.home.
.lan.

Avoids problems caused with use of .local.

<2015>
https://centr.org/document/4601
,--
Conflict between RFC 6761 and the IETF-ICANN MoU (RFC 2860)?
>From the organisational point of view, RFC 6761 had somewhat
shifted the relation of the IETF and ICANN. According to RFC
2860 the IETF seized its role as a policy body for the DNS
and ICANN and the latter now had a process to delegate
names, albeit a heavy and costly one. A second open round
for new TLD applications was just under consideration,
Durand said.

While the MoU had made an – albeit vague – exemption from
the ICANN’s prerogative as the name space body in
charge, RFC 6761 had slightly changed that. For the review
now the intra-organisational problems (IETF lacking a
process to reserve names due to 6761 vagueness) and the
inter-organisational problems (was 6761 as such a violation
of the MoU?) had to be considered.

Questions around a potential invalidity of 6761 were quickly
rejected as a potential “rat hole”. An opening up of 2860
– in order to renegotiate the roles of ICANN and IETF – were
quickly dismissed by Arkko (“IESG asked WG to look at
6761. RFC 2860 is not on the table.”)
'--

Moving forward, the role for .home and .corp TLDs with
respect at establishing local naming conventions needs to be
clarified before meaningful headway can be made.  Can anyone
offer meaningful guidance on this point?

Regards,
Douglas Otis

On 1/5/16 1:12 AM, Ray Bellis wrote:
> Dear all,
> 
> You each indicated willingness to work on a document for the Homenet WG
> describing all aspects of Homenet Naming and Service Discovery.
> 
> With the holidays out of the way and the New Year now upon us it would
> be great if some progress could now be made on that.
> 
> Assuming that you are still willing, would you like to agree a main
> editor from amongst you?
> 
> thanks,
> 
> Ray

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 19 Jan 2016 08:25:19 -0500

On Mon, Jan 18, 2016 at 04:14:46PM -0800, Douglas Otis wrote:
> multicast conventions related to .local.

The reason that I don't like home or corp is that they are both bound
up in ICANN delegation issues.  Let's just pick something unrelated to
any of that, so that we can neatly avoid immediate problems of
co-ordination.

In any case, the label we pick is not an architecutral matter.  It's
the colour of the bikeshed.  Or maybe the colour of the paint used on
wood that is covered by a piece of trim on the bikeshed.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 19 Jan 2016 20:05:37 -0500

Hi,

> potential RFC 1918-like protection/treatment.

There was an individual draft proposing these names be reserved in the special use names registry that was extensively discussed in DNSOP last year. The WG did not decide to advance it.
> offer meaningful guidance on this point?

I'm not sure I understand the claim you're making here-- maybe I missed a great deal of progress on the homenet naming architecture, but it seems to me that there's plenty of work to be done in deciding what behavior we want from names before we start worrying about which specific strings to use. (One of the key questions to me, if in fact we end up choosing domain names for this purpose, is what value is actually added by using a human-friendly string at all in the homenet context; YMMV.)

In regards to the specific names you mention, it's my personal opinion that we wouldn't be doing anyone a service by trying to use them in homenet, both because they're contended within the ICANN policy space (as I think Andrew already pointed out) and because if we take the risk of collision with a global delegation of those names seriously, we should also take seriously the possibility that they're being used in ways that could lead to collisions in homenets.

thanks,
Suzanne

---

From: Douglas Otis <[email-masked]>
Date: Wed, 20 Jan 2016 13:11:18 -0800

On 1/19/16 5:05 PM, Suzanne Woolf wrote:
>> referred to the Internet Engineering Task Force (IETF)
>>  for potential RFC 1918-like protection/treatment.
> 
> There was an individual draft proposing these names be 
> reserved in the special use names registry that was 
> extensively discussed in DNSOP last year. The WG did not
>  decide to advance it.
>> 
>> respect at establishing local naming conventions needs
>> to be clarified before meaningful headway can be made.
>> Can anyone offer meaningful guidance on this point?
> 
> I'm not sure I understand the claim you're making here--
>  maybe I missed a great deal of progress on the homenet 
> naming architecture, but it seems to me that there's 
> plenty of work to be done in deciding what behavior we 
> want from names before we start worrying about which 
> specific strings to use. (One of the key questions to me,
> if in fact we end up choosing domain names for this 
> purpose, is what value is actually added by using a 
> human-friendly string at all in the homenet context; 
> YMMV.)
> 
> In regards to the specific names you mention, it's my 
> personal opinion that we wouldn't be doing anyone a 
> service by trying to use them in homenet, both because 
> they're contended within the ICANN policy space (as I 
> think Andrew already pointed out) and because if we take
>  the risk of collision with a global delegation of those
>  names seriously, we should also take seriously the 
> possibility that they're being used in ways that could 
> lead to collisions in homenets.

Dear Suzanne,

Names rather than addresses, especially for IPv6, is well
ensconced as a means to establish user friendly network
configuration access. As such, special names greatly aid
network development, such as 'localhost' and '.local'.

Homenet is attempting to instantiate multiple router
configurations that function independent of external
services.  While names like 'localhost' and '.local' have
greatly aided network development, these names are limited
to immediate hosts or multicast. For this new environment, a
name able to establish user friendly configuration access is
needed.  DNSSD WG has proposed and supports '.home' for this
purpose.

Lacking standards body leadership or guidance, equipment
providers tend to use arbitrary names or hard-coded
addresses to bootstrap even single router configurations.
Homenet needs to standardize how to manage the configuration
of multiple routers.

As in the past, use of specialized names offered the least
onerous solution. As '.home' has been adopted in various
products, a special use names registry that includes at
least this name is both prudent and vital at aiding local
multiple router development.

Methods to further instantiate names within this specialized
environment is then better able to proceed and avoid
interfering with existing services. Names included within
this service might be derived from existing protocol hints
and less likely though explicit user interaction. In any
case, configuration must not depend on external services.

Regards,
Douglas Otis

---

From: Douglas Otis <[email-masked]>
Date: Wed, 20 Jan 2016 21:36:01 -0800

Dear Ted and Ray,

For many users, Internet obtainable services are fairly
limited. One major advantage offered by the Homenet approach
is an ability to cobble together several "limited"
providers to improve reliability.

The TLD '.lo' looks somewhat like a ccTLD and '.lan' has
already been suggested. Since ICANN asked '.lan' and '.home'
be set-aside, why worry about contested naming authority in
these cases? .home or .lan or .lo should not be considered
catch-all domains since they would not be visible beyond the
local network and yet function locally beyond uplink outages.

It seems counter-productive to suggest schemes where
Internet services must work in conjunction with
DNS dedicated at exposing previously private services whose
visibility is normally limited to the local network. Why
should private internal naming even depend on external DNS?
Such an approach is unlikely to be more robust and what
happens when uplinks go down?

Apple learned a valuable lesson when abandoning .me hosting.
Now it seems Homenet is intent at offering similar hosting
services. Such an effort is likely to necessitate an
inordinate level of support and incur additional risk. Are
providers interested in supporting dedicates DNS that sync
addresses and names for all internal services without
substantial cost increases?

Whether a multi-router system makes use of site dedicated
public DNS or not, a naming convention able to extend beyond
the bridge is still needed to properly support multi-device
multi-vendor system configuration, especially in cases where
trickle and babel don't meet their expectations. Naming
conventions able to span bridges would be able to adapt to
any number of strategies that might be used over Homenet
development and deployment.

Regards,
Douglas Otis

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jan 2016 08:07:01 +1300

On 21/01/2016 18:36, Douglas Otis wrote:
...
> The TLD '.lo' looks somewhat like a ccTLD

AFAIK, two letter TLDs are all implicitly reserved since any of them might
pop up in ISO 3166 in the future. I'm not enough of an ICANNologist to
point to where this is established (to my surprise, it is not established
by RFC 1591).

LO is currently unassigned in ISO 3166, but of course that could change
as a result of some future geopolitical event.

So it would be really foolish of the IETF to consider .lo at all.

    Brian