Subject: [homenet] draft-cheshire-homenet-dot-home-01

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Nov 2014 10:26:05 +1300

What's the mechanism for formal consultation with the DNS TLD
community on this? Just acknowledging comments from someone at
ICANN is not nearly enough.

   Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Nov 2014 16:31:02 -0500

> ICANN is not nearly enough.

Apart from liaisons to ICANN, we don't really have one.

For whatever it's worth, I think it would be a completely insane idea
to register this label in the special use registry.  It's already in
ICANN's namespace, because ICANN has taken requests for allocation.
As far as I'm concerned, that puts it in the root name space and
therefore we shouldn't reserve it.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Ralph Droms <[email-masked]>
Date: Wed, 12 Nov 2014 11:31:56 -1000

Brian - I missed the discussion in homenet, so this reference may have already been cited: RFC 6761

- Ralph

On Nov 12, 2014, at 11:26 AM 11/12/14, Brian E Carpenter <[email-masked]> wrote:

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

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Nov 2014 18:03:06 -0500

> Brian - I missed the discussion in homenet, so this reference may have already been cited: RFC 6761

That's the way we register the special use names.  What we don't have
is a way, apart from sending a liaison statement, to tell ICANN what
we're planning to do.

In this particular case, I think it would be extremely important to
get positive affirmation that ICANN as an organization is in favour of
registering these names for special use, because the names in question
have in fact been applied for and applicants have spent not
inconsiderable money on those applications.  I'm not convinced that it
would be safe for the IETF to make such a special-use registration at
this point without an explicit declaration from ICANN not only that
they wanted not to delegate for an indeterminate period of time, but
that they would like the special-use registration as well.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Peter Koch <[email-masked]>
Date: Thu, 13 Nov 2014 00:14:17 +0100

> inconsiderable money on those applications.  I'm not convinced that it

therefore it would be important for the IETF as an organization that
the policy decision not only happens on the ICANN side of things but
is also clearly documented as such - to avoid policy laundering.
6761 is not the tool for the IETF to recall names out of ICANN's barn.

> that they would like the special-use registration as well.

Well, that might be a level to deep.  All that ICANN should be concerned
with is that the IETF asks for that TLD 'for protocol purposes'. Topic
for a different venue, though.

-Peter (just adding to layer 9, not voicing an opinion +/- the initial idea)

---

From: Michael Thomas <[email-masked]>
Date: Wed, 12 Nov 2014 15:23:27 -0800

On 11/12/14, 3:03 PM, Andrew Sullivan wrote:
[]

So I have a high level question: the routing area of this working group 
is predicated on
the ability for a homenet to get a prefix delegated to them from its 
upstream provider(s).

Why can't we make a similar assumption that a homenet can get a dns 
delegation from
some upstream provider as well, be it an ISP, or some other DNS serving 
entity? There is
no requirement that I have my own vanity domain and pay a registrar to 
get a delegation
in somebody else's name space, though I can do that if I want. Why can't 
we work from
that assumption too?

Mike

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 12 Nov 2014 18:30:53 -0500

On Wed, Nov 12, 2014 at 03:23:27PM -0800, Michael Thomas wrote:
> entity? 

I think you can make that assumption.  There's a gap between "DNS" and
"top-level domain", however.  

For instance, you could ask for something under arpa.  The IAB
controls the arpa domain.  It turns out, also, that this is basically
infrastructure, so that might be another reason in its favour.

Of course, not everyone likes to type "thisnetwork.arpa."  So maybe a
TLD is important.  For that case, however, I don't want us to go
digging for TLDs over which there could be some controversy when we
could pick from an enormous list of possible strings that nobody has
ever asked for.  As the old saw goes, "Don't borrow trouble."

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Wed, 12 Nov 2014 15:36:26 -0800

> ever asked for.  As the old saw goes, "Don't borrow trouble."

I was thinking more along the lines of:

mikeshome.myisp.net

or

mikeshome.dnstube.google.com

or something like that. ie, that the names really are in the global name 
space, and
that my cpe somehow manages that much like my cpe needs to manage the 
upstream
v6 prefix it is delegated.

Mike

---

From: Ralph Droms <[email-masked]>
Date: Wed, 12 Nov 2014 13:44:09 -1000

> is a way, apart from sending a liaison statement, to tell ICANN what

Thanks - that's an important clarification.

> inconsiderable money on those applications.

Agreed.

- Ralph

>  I'm not convinced that it

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Nov 2014 13:34:21 +1300

>> inconsiderable money on those applications.

Violently agreed. There are definite feelings in ICANN-land that the IETF
didn't consult enough over RFC 6761, and adding a new TLD reserved for
technical purposes REQUIRES a careful liaison process (to establish that
it *is* a technical rather than a commercial or policy-based TLD name).

Given that there are currently 11 commercial applications* to delegate
the TLD home., I think the first step for the draft in question is
to choose a new name. It's close to the definition of insanity to
compete with the several million dollars already paid to ICANN.

* Search for "home" at
https://gtldresult.icann.org/application-result/applicationstatus/viewstatus

    Brian

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 13 Nov 2014 02:14:07 +0000

> delegation from some upstream provider as well, be it an ISP, or some other
> DNS serving entity? There is no requirement that I have my own vanity
> domain and pay a registrar to get a delegation in somebody else's name
> space, though I can do that if I want. Why can't we work from that
> assumption too?

I think it's dangerous to assume all people *want* dns delegation. Or, if a person does want it for certain hosts, to assume they want it for *all* hosts in the home.
Barbara

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Nov 2014 05:58:40 -0500

STARK, BARBARA H <[email-masked]> wrote:
    >> delegation from some upstream provider as well, be it an ISP, or some
    >> other DNS serving entity? There is no requirement that I have my own
    >> vanity domain and pay a registrar to get a delegation in somebody
    >> else's name space, though I can do that if I want. Why can't we work
    >> from that assumption too?

    > I think it's dangerous to assume all people *want* dns delegation. Or,
    > if a person does want it for certain hosts, to assume they want it for
    > *all* hosts in the home.  Barbara

We seem to keep having the same conversation.
I wonder if this pretty much sums it up.

It does like this:
   1) Mechanism FOO permits a CPU to offer hosts in the home a way to publish
      a populated forward (reverse) DNS zone.
      (1B - but lots of ISPs do not want to do this.)
      (1C - mechanism FOO can be used by any service provider, and maybe 
          you have more than one ISP)
      (1D - market forces might change this)
   2) Home equipment is too weak to run DNS servers.
      (2A - it's not .com, mechanism FOO means the CPE runs a server, but it
          might be a stealth primary)
      (2B - we need home DNS to resolve in the home, insert DNSSEC considerations)
   3) Lightbulbs can't be configured with DNS names, they don't have keyboards.
      (3A - lightbulbs have APIs)
      (3B - lightbulbs have controllers which have web servers)
      (3C - not all lightbulbs need names, but other things might)
   4) you can't just fill the zone with all the names -- it won't be secure.
      (4A - things that don't want global reachability, perhaps, shouldn't
            have globally reachable addresses)
      (4B - things that want global reachability, probably want global names)

-- 
]               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: Ted Lemon <[email-masked]>
Date: Thu, 13 Nov 2014 05:29:57 -1000

>            have globally reachable addresses)

There is a privacy issue here.   And if a global prefix is advertised, present state of the art is that all devices on the wire will wind up with an address on that prefix.  However, attacking those devices from outside requires guessing their address, unless it's conveniently published in a DNS zone.

I think there's room for addressing both of these issues, but you shouldn't just dismiss them.   I agree with your other points.

---

From: Dave Taht <[email-masked]>
Date: Thu, 13 Nov 2014 08:08:50 -0800

On Nov 13, 2014 2:58 AM, "Michael Richardson" <[email-masked]> wrote:
>       (1B - but lots of ISPs do not want to do this.

>           you have more than one ISP)

We already added features to dnsmasq that make it possible to have more
than oneupstream reverse resolver.

>       (1D - market forces might change this)

I would certainly like otherwise vanity dns names to actually be useful.

>    2) Home equipment is too weak to run DNS servers.

At least on the now 7 year old cpe gear I work on, it proved utterly
feasible to run an outward facing bind dns server, something like 3 years
back. As continuing proof of concept lab.bufferbloat.net still runs bind
with dnssec in a box with 64MB ram and 16MB flash. So do several isc devs.

It didn't really prove desirable to run bind in these circumstances, as it
is nearly impossible to configure bind via a web interface, and the binary
was overlarge vs the amount of available flash, and due to 1 CVE per
quarter, a PITA to keep upgraded - so we added the core features needed to
dnsmasq (adding dnssec and slave zone push), and others are using unbound,
also.

The latest generation of home APs have gobs more flash (128MB or more), and
ram, and when you compare the computational overhead of doing WPA, or
pushing packets at gig speeds, the overhead of a local dns server is
trivial, and it is very desirable to have a local caching server
regardless....

Certainly more work is needed in this area - I'd like multiple local
caching dns servers to easily co-exist (anycast in the homenet anyone?),
and I'd like the work on mdns-proxy and hnetd to also be available in
mainline linux, perhaps as part of systemd, and other OSes besides those
openwrt-derived.

>           might be a stealth primary)

I think the stealth primary approach is a good one.

>       (2B - we need home DNS to resolve in the home, insert DNSSEC
considerations)

Well it does, and has for over a year now.

>    3) Lightbulbs can't be configured with DNS names, they don't have
keyboards.

Sigh. mdns has a mechanism to auto-rename devices that present the same
name, dhcp can be used to do the same, and users have the ability to easily
name devices from the mac address. You plug all your devices in, you look
at the web page on the router showing the mac addresses in use, and you
give them all names that are logical for your setup.

>    4) you can't just fill the zone with all the names -- it won't be
secure.

Well, there is another concern in that you don't want to export rfc1918 or
ula addresses into the global namespace.

>       (4B - things that want global reachability, probably want global
names)

This is kind of hard. As for the security concern, lightbulb-1.taht.net
needs to be guessable, random walks of the dns take a long time... but with
the rise of dhcpv6, guessing from a reverse lookup is tons easier (this is
partially why I still favor SLAAC and privacy addresses vs dhcpv6 in the
home)

I would argue for a simple switch (publish all valid addresses in the
global dns/only publish selected) in the cpe, defaulting to the latter
option. I would certainly like to see some sort of DHT for rendezvous be
standardized for things like webrtc to supercede dns as a main mechanism
for sharing information about your machine and location.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Nov 2014 09:05:16 -0800

On 11/13/2014 08:08 AM, Dave Taht wrote:
> feasible to run an outward facing bind dns server, something like 3 
> years back. As continuing proof of concept lab.bufferbloat.net 
> <http://lab.bufferbloat.net> still runs bind with dnssec in a box with 
> 64MB ram and 16MB flash. So do several isc devs.
>

Let's be clear that we aren't designing homenet for 7 year old cpe. Or 
even 0 year old cpe. That way lies madness.

Mike

---

From: Evan Hunt <[email-masked]>
Date: Thu, 13 Nov 2014 17:28:55 +0000

> even 0 year old cpe. That way lies madness.

I think the point is if a 7-year-old CPE can do it, it's likely to be
feasible on newer gear too.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Nov 2014 11:16:26 -0800

> feasible on newer gear too.

Sorry, Dave -- I read your "feasible" as "infeasible". Not enough caffeine.

Mike

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Nov 2014 15:09:34 -0500

Ted Lemon <[email-masked]> wrote:
    >> 4) you can't just fill the zone with all the names -- it won't be
    >> secure.  (4A - things that don't want global reachability, perhaps,
    >> shouldn't have globally reachable addresses)

    > There is a privacy issue here.  And if a global prefix is advertised,
    > present state of the art is that all devices on the wire will wind up
    > with an address on that prefix.  However, attacking those devices from
    > outside requires guessing their address, unless it's conveniently
    > published in a DNS zone.

If we conclude that ULA will always be present in the home, then devices
ought to only have a ULA by default, and need to enabled to have a GUA.
That's one of my major reasons I always want ULA to be available.

    > I think there's room for addressing both of these issues, but you
    > shouldn't just dismiss them.  I agree with your other points.

okay.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Nov 2014 10:14:12 -1000

> That's one of my major reasons I always want ULA to be available.

How would we accomplish that?   Make the global prefix managed and use DHCP?   How could this be done automatically?   Do we recommend that hosts that provide services that only make sense on the local network always choose the ULA and not any available GUAs if they see advertisements for both?

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Nov 2014 12:23:22 -0800

> That's one of my major reasons I always want ULA to be available.

Given how easy it is for a device to configure a gua -- intentional or 
otherwise -- i
don't think i'd want to stake any security properties a device's 
non-routability. Nor do
I think that the obscurity of not having a DNS name provides much in the 
way of privacy.
There's way too much that can go wrong to count on either of these 
properties.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Nov 2014 10:36:56 -1000

On Nov 13, 2014, at 10:23 AM, Michael Thomas <[email-masked]> wrote:
> Nor do
> I think that the obscurity of not having a DNS name provides much in the way of privacy.
> There's way too much that can go wrong to count on either of these properties.

Not having a DNS name just means you have to guess the IP address directly, rather than doing a dictionary search on a likely much smaller namespace.   If stable privacy addresses are used, then guessing internal IP addresses is pretty difficult.   Enumerating the domain name space isn't trivial and would present a substantial load on the DNS server, but it's a lot easier than guessing a stable privacy address.

Of course if there is a firewall, neither attack will allow you to reach a host that doesn't use PCP or some similar technique to open a hole in the firewall for its listeners.  But in that case the DNS attack will reveal that the device is there.   Whether this is a significant privacy issue depends on the device.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Nov 2014 13:35:06 -0800

> Not having a DNS name just means you have to guess the IP address directly, rather than doing a dictionary search on a likely much smaller namespace.   If stable privacy addresses are used, then gu…

Why guess when you can break into $MEGACORP and steal their server logs? 
If there's
anything that the Snowden/NSA bizness should teach us is that brute 
force is not the
only other option.

> Of course if there is a firewall, neither attack will allow you to reach a host that doesn't use PCP or some similar technique to open a hole in the firewall for its listeners.  But in that case th…

There's always two faced dns too. I would think you can do that even 
with, say, a provider
dns delegation. The CPE would need to know "in" from "out" and decide 
what to serve up
(rr requests, (i)xfer, hidden master zone xfer...) based on who it's 
talking to.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Nov 2014 11:44:13 -1000

On Nov 13, 2014, at 11:35 AM, Michael Thomas <[email-masked]> wrote:
> Why guess when you can break into $MEGACORP and steal their server logs? If there's
> anything that the Snowden/NSA bizness should teach us is that brute force is not the
> only other option.

Different threat models demand different solutions.   I doubt that the NSA is going to try to brute-force everybody's DNS tree, for the simple reason that if they did so, it would be obvious and would look like a DoS attack.   They certainly are not going to exhaustively probe everyone's address space.   But yes, they will be able to notice any device that ever communicates to the internet and transits a network location they are monitoring.   This isn't the risk model I'm talking about in the case of address probing.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Nov 2014 11:44:46 -1000

On Nov 13, 2014, at 11:35 AM, Michael Thomas <[email-masked]> wrote:
> There's always two faced dns too. I would think you can do that even with, say, a provider
> dns delegation. The CPE would need to know "in" from "out" and decide what to serve up
> (rr requests, (i)xfer, hidden master zone xfer...) based on who it's talking to.

This has been discussed in the working group before and is understood to be a possible solution that might be described.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Nov 2014 14:12:56 -0800

> Different threat models demand different solutions.   I doubt that the NSA is going to try to brute-force everybody's DNS tree, for the simple reason that if they did so, it would be obvious and wo…
"They" of course is not limited to the NSA or even nation-state actors.

That said, I really do wonder -- given how trivial it is with v6 to get 
a GUA, -- how easy it is
to keep things within, say, the home that we don't want to accidentally 
leaking  out onto
the internet from doing so[*]. My guess: hard.

Mike

[*] especially since they have a lot of motivation to call the 
mothership from their manufacturers, etc

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Nov 2014 13:15:00 -1000

On Nov 13, 2014, at 12:12 PM, Michael Thomas <[email-masked]> wrote:
> That said, I really do wonder -- given how trivial it is with v6 to get a GUA, -- how easy it is
> to keep things within, say, the home that we don't want to accidentally leaking  out onto

Unfortunately, I think that we don't have a ready answer for this.   Even if you have a firewall that emulates the behavior of a NAT in terms of preventing unsolicited incoming connections, any device on the network can in principle connect off network.   The only way to prevent this is to have specific policies per device, which pretty much requires a UI.   So e.g. if your printer is programmed to check the vendor's site for updates, you would have to explicitly block it from doing so if you wanted it to be invisible to off-network surveillance.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Nov 2014 18:17:09 -0500

Ted Lemon <[email-masked]> wrote:
    >> If we conclude that ULA will always be present in the home, then
    >> devices ought to only have a ULA by default, and need to enabled to
    >> have a GUA.  That's one of my major reasons I always want ULA to be
    >> available.

    > How would we accomplish that?  Make the global prefix managed and use
    > DHCP?  How could this be done automatically?  Do we recommend that
    > hosts that provide services that only make sense on the local network
    > always choose the ULA and not any available GUAs if they see
    > advertisements for both?

I would say exactly that: they should prefer ULA over GUA, if they see both.
(That should clearly be overridde-able).  If they wind up using DHCPv6 (M=1),
then they should take whatever the DHCP server gives them, assuming that it
knows better.  (That doesn't mean they should have no ACL, though)

If only a GUA is available; I'm not sure. I think that just not operating
might be appropriate for some devices, but I'd say that was slightly rare.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Nov 2014 13:18:51 -1000

On Nov 13, 2014, at 1:17 PM, Michael Richardson <[email-masked]> wrote:
> I would say exactly that: they should prefer ULA over GUA,

Who is "they"?

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Nov 2014 18:19:19 -0500

Michael Thomas <[email-masked]> wrote:
    >> Ted Lemon <[email-masked]> wrote: >> 4) you can't just fill the zone
    >> with all the names -- it won't be >> secure.  (4A - things that don't
    >> want global reachability, perhaps, >> shouldn't have globally
    >> reachable addresses)
    >> 
    >> > There is a privacy issue here.  And if a global prefix is
    >> advertised, > present state of the art is that all devices on the wire
    >> will wind up > with an address on that prefix.  However, attacking
    >> those devices from > outside requires guessing their address, unless
    >> it's conveniently > published in a DNS zone.
    >> 

    > otherwise -- i don't think i'd want to stake any security properties a
    > device's non-routability. Nor do I think that the obscurity of not
    > having a DNS name provides much in the way of privacy.  There's way too
    > much that can go wrong to count on either of these properties.

I am not saying: ULA=secure, GUA=insecure.

I'm saying: pick a GUA if you are a device which should be
discoverable/reachable by default.  That's not to say what your ACL should
be.  I presume that these devices do not otherwise use resources the way that
my phone or laptop does when I interact with it.

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Nov 2014 13:28:45 -1000

> my phone or laptop does when I interact with it.

Okay, so what devices should be discoverable/reachable by default?

I know this sounds easy, but I'm not convinced it is.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Nov 2014 15:32:53 -0800

> my phone or laptop does when I interact with it.
But all of my devices want to call home to the mothership to check for 
firmware
updates, etc, etc. So they want to get a GUA. Isn't that sufficient to 
be vulnerable
to incoming traffic assuming no other measures are taken (eg, firewall, 
etc)?
Isn't that even true with privacy addresses?

Mike

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Nov 2014 15:34:51 -0800

> Unfortunately, I think that we don't have a ready answer for this.   Even if you have a firewall that emulates the behavior of a NAT in terms of preventing unsolicited incoming connections, any dev…
Quite so. Which is why we need to be vigilant that we aren't creating IP 
Maginot Lines.

Mike

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 13 Nov 2014 23:50:23 +0000

> > discoverable/reachable by default.  That's not to say what your ACL
> > should be.  I presume that these devices do not otherwise use
> > resources the way that my phone or laptop does when I interact with it.
> 

If it does some form of multicast advertising of its "services", or is discoverable through a multicast discovery mechanism, over IP. 
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Nov 2014 13:55:45 -1000

> If it does some form of multicast advertising of its "services", or is discoverable through a multicast discovery mechanism, over IP. 

So to address this use case you'd want to say "if this is a device that provides services using local network multicast by default, it SHOULD NOT configure a GUA.   Such devices MAY configure a GUA when periodically checking for firmware updates, but SHOULD unconfigure the GUA as soon as the check completes, SHOULD randomize the check interval, and SHOULD use a temporary GUA address when making such connections."

Of course, we are discussing advice we should give without discussing where that advice might actually be given...

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 14 Nov 2014 00:07:15 +0000

> > If it does some form of multicast advertising of its "services", or is
> discoverable through a multicast discovery mechanism, over IP.
> 
> So to address this use case you'd want to say "if this is a device that provides
> services using local network multicast by default, it SHOULD NOT configure a
> GUA.   Such devices MAY configure a GUA when periodically checking for
> firmware updates, but SHOULD unconfigure the GUA as soon as the check
> completes, SHOULD randomize the check interval, and SHOULD use a
> temporary GUA address when making such connections."

Actually, I'm not a fan of recommending using GUA in the case of devices that should be "discoverable by default". I was merely providing a suggestion for the definition of types of devices that should be discoverable by default. Sorry -- I should have mentioned that. So, no, I wouldn't want to say what you suggest at all. After dealing fairly extensively with such devices, I've personally come to the conclusion that it depends on the specific application and the usage model of the application. I don't think a global recommendation is possible.
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Nov 2014 14:10:44 -1000

On Nov 13, 2014, at 2:07 PM, STARK, BARBARA H <[email-masked]> wrote:
> After dealing fairly extensively with such devices, I've personally come to the conclusion that it depends on the specific application and the usage model of the application. I don't think a global recommendation is possible.

Right, I agree.   I wrote the text with the hope that people would read it and reconsider the wisdom of solving this problem this way.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Nov 2014 19:13:11 -0500

> Who is "they"?

The devices that do not want to be discovered.

---

From: Michael Richardson <[email-masked]>
Date: Thu, 13 Nov 2014 19:15:02 -0500

> I know this sounds easy, but I'm not convinced it is.

Sorry, I missed the word "globally" in "discoverable/reachable by default"
And finally, that maybe brings up back to the subject line, because it's
about the name which one uses when not globally discoverable.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Nov 2014 14:27:04 -1000

> The devices that do not want to be discovered.

The point is that that description doesn't clearly identify any devices.