Re: [homenet] Homenet Naming Architecture

Douglas Otis <> Wed, 20 January 2016 21:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8F2C41ACEB8 for <>; Wed, 20 Jan 2016 13:10:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XfIKGlq0dqx6 for <>; Wed, 20 Jan 2016 13:10:14 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c03::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E8D751ACEB6 for <>; Wed, 20 Jan 2016 13:10:13 -0800 (PST)
Received: by with SMTP id pv5so821452pac.0 for <>; Wed, 20 Jan 2016 13:10:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=XQ5VP/G/AqpkTKzKbN5fGe7oaHMOCtUOEXRmfN+X56g=; b=N3lxcbmVLd3bNA1AGwEX4+36ctvgCDHUSvrletekHJ/GCInhI6sw21IpaC7fCvssZk qrOxVuLkk2in1jx/iD5HM1gP/Q4scRpyzxayB7GCiQNvDXtCv0vVOsuYn/KO+CPiJPzJ hVuXA40tWUfQmBXExDgb3oFewIXq2BWyk3qp1M730dgJ//i9Qm1jNyu+Dq8KlSALx2se cS7K+FSruUXW2+c4wIGY7j0sT+npQHGaNq6hetHZFnWGXDWJrH1AV4ElSwvXQtXgJM6Z 7jduZrwAyoJZEkcQpda5gvup+Mp+0xEiHbTzpSzWzFRX2pzuGbm7nv8rwHLZJScqqPqD D2cw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=XQ5VP/G/AqpkTKzKbN5fGe7oaHMOCtUOEXRmfN+X56g=; b=aoLZN5J7bNe8beqE/gtvFNsLeD3EUlab17B3TGcShjiBu95o0nwU/UKzQHr+g3Jpxy OeaA9G4cnXt1nZv4CDdCztXSo/9rvjku5490gc8QYdnRF+5G86Y+Dyg5vMUPjaFLyiAJ nY70PojiwoHfNBROlg4BqlOivKG21ybpShmaaNF1qtQ6CiRAIBJYsHnpF1WgfpqcAz3E sAvO7VBMhC60FhWpIQiweb+jwdgdLSfnW2vc6NHLyEy4Z4SIvC81dCxVjSASuXwceZm7 y1OoWgkjr33k1Jlx2OSAhA7eRUwZS2RkyhSOwZOIrCVdk19Ik8cUhPGx6srrZpjh/Fff m7wA==
X-Gm-Message-State: AG10YORW0AnhJVXQx6/fHJddeOiqBDTr5/PbKVUOET53b5D8ev4Ki5TqBxVdFMgemgmlZQ==
X-Received: by with SMTP id ks7mr41930714pab.71.1453324213579; Wed, 20 Jan 2016 13:10:13 -0800 (PST)
Received: from US-DOUGO-MAC.local ( []) by with ESMTPSA id p71sm50848040pfa.11.2016. (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jan 2016 13:10:12 -0800 (PST)
To: Suzanne Woolf <>
References: <> <> <>
From: Douglas Otis <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Wed, 20 Jan 2016 13:11:18 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Archived-At: <>
Cc:, Ray Bellis <>, Andrew Sullivan <>, Ray Hunter <>, Tim Chown <>, homenet-chairs <>,,
Subject: Re: [homenet] Homenet Naming Architecture
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Jan 2016 21:10:15 -0000

On 1/19/16 5:05 PM, Suzanne Woolf wrote:
> Hi,
> On Jan 18, 2016, at 7:14 PM, Douglas Otis 
> <> wrote:
>> RECOMMENDATION 1: The TLDs .corp, .home, and .mail be 
>> 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.
>> 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?
> 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

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.

Douglas Otis