Subject: [homenet] Introduction to draft-ietf-homenet-simple-naming

From: Ted Lemon <[email-masked]>
Date: Wed, 23 May 2018 16:12:52 -0400

The chairs requested that we have a discussion on this draft on the mailing
list.   I've been a bit slack in bringing it up, as you can tell from the
lack of any actual discussion.   So, I'm bringing it up.   I've copied the
abstract, introduction and requirements sections to the message below.
It's a pretty quick read.   Please read it and try to notice anything
that's missing, or that shouldn't be there, or that is just plain wrong.
If it looks fine, it would be great if you could just reply to say "it
looks fine."   If all goes well, we'll move on to the next section next
week.

Abstract

   This document describes how names are published and resolved on
   homenets, and how hosts are configured to use these names to discover
   services on homenets.  It presents the complete architecture, and
   describes a simple subset of that architecture that can be used in
   low-cost homenet routers.

1.  Introduction

   This document is a homenet architecture document.  The term 'homenet'
   refers to a set of technologies that allow home network users to have
   a local-area network (LAN) with more than one physical link and,
   optionally, more than one internet service provider.  Home network
   users are assumed not to be knowledgable in network operations, so
   homenets automatically configure themselves, providing connectivity
   and service discovery within the home with no operator intervention.
   This document describes the aspect of homenet automatic configuration
   that has to do with service discovery and name resolution.

   The homenet naming architecture consists of two parts: the simple
   naming architecture, and the advanced naming architecture.  The
   advanced architecture provides approximate parity of features with a
   managed network, including the ability to publish services on the
   internet.  The simple architecture provides a minimal set of features
   required to enable seamless service discovery on a multi-link home
   network, but does not attempt to provide feature parity with a
   managed LAN.

   This document begins by presenting a motivational list of
   requirements and considerations, which should give the reader a clear
   idea of the scope of the problem being solved.  It then explains how
   each requirement is addressed, and provides references for relevant
   standards documents describing the details of the implementation.
   Some requirements are not satisfied by the simple architecture; these
   are discussed in this document, but explained in more detail in the
   Advanced Homenet Naming Architecture document, which is to follow.

2.  Requirements

   Name service on a local area network (LAN) requires the following:

   o  Name: a forward domain under which information about local
      services will be published

   o  Authority: a name server that is authoritative for at least a
      forward and one or two reverse domains that are applicable to that
      network

   o  Resolution: a full-service caching DNS resolver

   o  Publication: a mechanism that

      *  allows services on the LAN to publish information about the
         services they provide

      *  allows services to publish information on how to reach them

      *  manages the lifetime of such information, so that it persists
         long enough to prevent spoofing, but protects end users from
         seeing stale information

   o  Host configuration: one or more automatic mechanisms (e.g.  DHCP
      or RA) that provide:

      *  caching resolver information to hosts on the LAN

      *  information about how services on the LAN can publish
         information

   o  Trust: some basis for trusting the information that is provided by
      the service discovery system

2.1.  Managed LAN versus Homenet

   On a managed LAN, many of these services can be provided by
   operators.  When a new printer is added to the network, it can be
   added to the service discovery system (the authoritative server)
   manually.  When a printer is taken out of service, it can be removed.
   In this scenario, the role of "publisher" is filled by the network
   operator.

   In many managed LANs, establishment of trust for service discovery is
   simply on the basis of a belief that the local resolver will give a
   correct answer.  Once the service has been discovered and chosen,
   there may be some security (e.g., TLS) that protects the connection
   to the service, but the trust model is often just "you're connected
   to a network you trust, so you can trust the printer that you
   discovered on this network."

   A homenet does not have an operator, so functions that would normally
   be performed by the operator have to happen automatically.  This has
   implications for trust establishment--since there is no operator
   controlling what services are published locally, some other mechanism
   is required for basic trust establishment.  Additionally, whereas in
   a managed LAN with multiple links to the Internet, the network
   operator can configure the network so that multihoming is handled
   seamlessly, in a homenet, multihoming must be handled using multiple
   provisioning domains [RFC7556].

2.2.  Homenet-specific considerations

   A naming architecture for homenets therefore adds the following
   considerations:

   o  All of the operations mentioned here must reliably function
      automatically, without any user intervention or debugging.

   o  Because user intervention cannot be required, naming conflicts
      must be resolved automatically, and, to the extent possible,
      transparently.

   o  Devices that provide services must be able to publish those
      services on the homenet, and those services must be available from
      any part of the homenet, not just the link to which the device is
      attached.

   o  Homenets must address the problem of multiple provisioning
      domains, in the sense that the DNS may give a different answer
      depending on whether caching resolvers at one ISP or another are
      queried.

   An additional requirement from the Homenet Architecture [9] is that
   hosts are not required to implement any homenet-specific capabilities
   in order to discover and access services on the homenet.  This
   architecture may define optional homenet-specific features, but hosts
   that do not implement these features must work on homenets.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 May 2018 12:59:53 -0400

Ted Lemon <[email-masked]> wrote:
    > internet.

I hate to ask this, but it seems like we ought to have a definition for a
managed network... :-(
I think that the section 2.1 provides contrasts, but maybe we should instead
say what aspects of the Managed LAN we care about.

    > forward and one or two reverse domains that are applicable to that

s/forward/forward domain/ ?

    > o  Resolution: a full-service caching DNS resolver

s/caching DNS resolver/caching DNSSEC resolver/ ?

    > long enough to prevent spoofing, but protects end users from

Should the naming architecture consider that some devices are guests?
For instance, should such devices be marked in some way when they publish
names, and how would they be upgraded?  The upgrade must be simple, but
intentional, otherwise well have flashing 12:00 VCR syndrome in most home
networks.

    > discovered on this network."

I'd be curious to know how many printers on corporate/enterprise/campus
environments get TLS certificates?   I suspect that in such environments, the
majority of printing is via a printer server, and the security is via
ActiveDirectory or equivalent.  But I don't know, I haven't lived in such an
environment for a long time, and my printers either don't support TLS,
or they have a self-signed certificate because CUPS doesn't make it easy for
me to care.

In essence, I wonder if you are raising the bar for the Homenet higher than
for real Managed LANs.  I'm okay with that, btw, but I think we should be
clear that we are doing it because it's easy.

    > automatically, without any user intervention or debugging.

I'd like to add some kind of visible auditing here.
I'm thinking about something like multicasted syslog about things that are
occuring automatically. (Still funny that evil rcmd and syslog both live on
port 514...)

    > that do not implement these features must work on homenets.

Is it acceptable that it only works if the host uses the DNS server that DHCP
supplied?
I think it's unacceptable if the host has to rely on search path, and I think
we all agree on that. (But major captive portal suppliers still haven't
figured that out)

-- 
]               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: Fri, 25 May 2018 12:34:03 -0500

Thanks for the review, Michael!

On May 25, 2018, at 11:59 AM, Michael Richardson <[email-masked]> wrote:
> Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:

Good point.  The "including the ability to publish services on the Internet" seems like a reasonable first attempt at specifying that, but I agree that it's insufficient.   Do you have a theory to offer?   What I think I meant by this was:

- Has a globally-scoped delegation for publishing names (a forward tree)
- Optionally with DNSSEC
- Has one or more globally-scoped delegations for publishing records referring to globally-scoped IP addresses on the network (a reverse tree)
- Optionally with DNSSEC
- Ability to specify which services are visible from outside, either manually or automatically (e.g. with mud).
- Ability to acquire ACME certs?   This is probably out of scope-ish, but ACME does interact with the naming system.   This is one of my primary motivations for caring about the advanced naming architecture, TBH—it makes it possible to secure the gateway web UI.

There's probably other stuff I forgot, which is in the old version of the homenet naming architecture.   That said, I don't think this needs to be covered exhaustively here.   The point is "
> s/forward/forward domain/ ?

An X (B, implicitly) and 2 Y Bs is a pretty normal english construction, but maybe it would be better to be explicit, so I'll make this change.

> s/caching DNS resolver/caching DNSSEC resolver/ ?

That would be nice for avoiding cache poisoning, but I don't think it's required.   If you don't validate at the host, you might as well not bother.   That said, this point is worth making clear later on when these bullet points are expanded upon.

> intentional, otherwise well have flashing 12:00 VCR syndrome in most home

Can you articulate a meaningful distinction between a "guest" service and a regular service?   The only thing I can think of is that you might want a shorter default lifetime on the service registration, but I don't think it's actually very important.  Part of the way the DNSSD registration protocol is intended to work is that names are reserved for longer than they are visible as services, so if you come along an hour after a guest device has left the network, you won't see a service record published for it, but you won't be able to claim its name.   Do you think we need to do more than that?

Are guest devices identified on the basis of connecting to a "guest" network?

(This is a good observation, BTW, and I'm not disagreeing that we should consider it, just not sure what to write).

> clear that we are doing it because it's easy.

Yes.  That's precisely what I'm hoping to do.   Active Directory obviously isn't going to work in this situation, and since it's not an IETF standard, there's no reason to attempt to replicate that model.   Although if we can hack a TLS cert into a printer on a homenet by claiming it in an active directory domain somehow, I'm all for doing that as a shim.  Another way that someone from the NIST proposed is to just take a $25 Raspberry Pi-ish device (maybe with better I/O, like the NanoPi Neo Plus2) and just interpose it between the printer and the network to prevent the printer from presenting a non-encrypted API.   But that's definitely out of scope.

> occuring automatically. (Still funny that evil rcmd and syslog both live on

I agree, but I think that's out of scope.

> we all agree on that. (But major captive portal suppliers still haven't

If the host is doing DoH to bypass the local DNS server, it won't be able to access local services.   This is probably the right outcome.   Anything we do to finesse this is going to require changes on the host.   I suspect that this is out of scope for the simple naming architecture, but am eager to hear arguments to the contrary.   :)

---

From: Michael Thomas <[email-masked]>
Date: Fri, 25 May 2018 12:21:10 -0700

On 5/25/18 10:34 AM, Ted Lemon wrote:
> the ability to publish services on the Internet" seems like a 
> reasonable first attempt at specifying that, but I agree that it's 
> insufficient.   Do you have a theory to offer?   What I think I meant 
> by this was:
>
> - Has one or more globally-scoped delegations for publishing records 
> referring to globally-scoped IP addresses on the network (a reverse tree)
> - Optionally with DNSSEC
> - Ability to specify which services are visible from outside, either 
> manually or automatically (e.g. with mud).
> - Ability to acquire ACME certs?   This is probably out of scope-ish, 
> but ACME does interact with the naming system.   This is one of my 
> primary motivations for caring about the advanced naming architecture, 
> TBH—it makes it possible to secure the gateway web UI.
>
>

Optional to implement or optional to deploy?

Mike

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 May 2018 15:43:32 -0400

This is out of scope for simple naming anyway, so I don't think we need to
answer this now.

On Fri, May 25, 2018, 12:24 Michael Thomas <[email-masked]> wrote:

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

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 May 2018 16:06:17 -0400

> Good point.  The "including the ability to publish services on the
    > Internet" seems like a reasonable first attempt at specifying that, but
    > I agree that it's insufficient.   Do you have a theory to offer?   What
    > I think I meant by this was:

A managed network is one that has a (human) manager, or operator.
The operator has authority over the network, and the authority to publish names
in a forward DNS tree, and reverse names in the reverse tree.
The operator has the authority to sign the respective trees with DNSSEC,
and acquire TLS certificates for hosts/servers within the network.

    > An X (B, implicitly) and 2 Y Bs is a pretty normal english
    > construction, but maybe it would be better to be explicit, so I'll make
    > this change.

Yes, but if you change "forward" to "forwarder", then it implies something
about routing. So that's a mistake a reader might make.

    > That would be nice for avoiding cache poisoning, but I don't think it's
    > required.   If you don't validate at the host, you might as well not
    > bother.   That said, this point is worth making clear later on when
    > these bullet points are expanded upon.

"caching DNS(sec) resolver" ?

    > Can you articulate a meaningful distinction between a "guest" service
    > and a regular service?   The only thing I can think of is that you
    > might want a shorter default lifetime on the service registration, but
    > I don't think it's actually very important.  Part of the way the DNSSD
    > registration protocol is intended to work is that names are reserved
    > for longer than they are visible as services, so if you come along an
    > hour after a guest device has left the network, you won't see a service
    > record published for it, but you won't be able to claim its name.   Do
    > you think we need to do more than that?

I visit you.  I find it amusing to name my phone "printer".
When I leave, you unbox your printer, and find that you can't name it "printer".
Is this important?

    > Are guest devices identified on the basis of connecting to a "guest" network?

Yes, quite possibly.

    > (This is a good observation, BTW, and I'm not disagreeing that we
    > should consider it, just not sure what to write).

It would be nice if the network called my phone: "printer.guestnetwork.example.com".

    > Yes.  That's precisely what I'm hoping to do.   Active Directory
    > obviously isn't going to work in this situation, and since it's not an
    > IETF standard, there's no reason to attempt to replicate that model.
    > Although if we can hack a TLS cert into a printer on a homenet by
    > claiming it in an active directory domain somehow, I'm all for doing
    > that as a shim.  Another way that someone from the NIST proposed is to
    > just take a $25 Raspberry Pi-ish device (maybe with better I/O, like
    > the NanoPi Neo Plus2) and just interpose it between the printer and the
    > network to prevent the printer from presenting a non-encrypted API.
    > But that's definitely out of scope.

I wasn't suggesting AD was a solution, but rather than in a *managed*
network, I suspect that the printers people 'discover' aren't the real
printers.  Perhaps someone else will enlighten me.

    > I agree, but I think that's out of scope.

I was responding to "without any user debugging" --- what I think we don't
want to do is create a black box situation which means that debugging is
impossible for even an clueful person to do.

    > If the host is doing DoH to bypass the local DNS server, it won't be
    > able to access local services.   This is probably the right outcome.
    > Anything we do to finesse this is going to require changes on the host.
    > I suspect that this is out of scope for the simple naming architecture,
    > but am eager to hear arguments to the contrary.   :)

But, when a homenet host (a smartphone for instance), is away from the
homenet,  it is expected to be able to use names from the homenet to reach
things.  That's not any different than a host that uses 8.8.8.8 is it?

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 May 2018 08:49:09 +1200

> and acquire TLS certificates for hosts/servers within the network.

This prompts a few thoughts:

(1) There's a strong resemblance between a homenet and a small office
network, in which there's quite likely to be a human who is supposedly
in charge of the network as a minor part of their job. That may well be
a human who has the authority but not the skills. So there's possibly
a category of "badly managed network" to consider.

(2) I note the "(human)". Actually some of the concepts of autonomics
and intent-based networking may spill over from enterprise networks
into SOHO, at some point in the future.

So, the naming system may end up being fully automatic, well or badly
managed by a human, or managed autonomically.

     Brian

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 May 2018 16:02:14 -0700

> managed by a human, or managed autonomically.

The simple naming architecture is fully automatic, but doesn't do as much as we might want.   I think that the advanced architecture can also be automated, but that's terra incognita.   We are not interested in the use case where naming is managed by the human.   It may be possible for the human to intervene, but it has to work if they don't, and that's the nut we are trying to crack.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 May 2018 16:03:00 -0700

> Optional to implement or optional to deploy?

Optional to deploy.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 26 May 2018 14:18:34 +1200

> The simple naming architecture is fully automatic, but doesn't do as much as we might want.   I think that the advanced architecture can also be automated, but that's terra incognita.   We are not…

Understood. However, many of us exposed to certain operating systems deeply hate it when the system thinks it knows what we want better than we do. What I'm suggesting is that dealing with unexpected and/or faulty human intervention is also necessary. So IMHO human override needs to be thought about, both as a risk and as a feature.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 25 May 2018 23:11:09 -0400

> a category of "badly managed network" to consider.

Yes, so there are badly managed small office networks, and unmanaged small
office networks (using homenet technology).

    > into SOHO, at some point in the future.

I think that it's a grey area, but I'm okay with claiming that the autonomic
network had a human operator write the Intent.

    > managed by a human, or managed autonomically.

I realize reading this that the autonomic network is much like the autonomous
vehicle:  Something we aspire to get right, and to do so in order to
avoid/reduce human errors.   (Are the autonomous vehicle people
ahead of the autonomic network people? Not sure)

---

From: Ted Lemon <[email-masked]>
Date: Fri, 25 May 2018 20:18:40 -0700

> Understood. However, many of us exposed to certain operating systems deeply hate it when the system thinks it knows what we want better than we do. What I'm suggesting is that dealing with unexpect…

Yes, for sure.   But e.g. one of the things homenets do right is to deal with humans plugging and unplugging indiscriminately.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 28 May 2018 14:05:39 -0400

Hi,

Thanks for doing this.  Some comments inline.  These may seem a little
picky in a few cases, but I figure it's better to make the corrections
as we go.

>    low-cost homenet routers.

I have never really understood how this could present the complete
architecture when we don't know what would go in a complete
architecture because we don't actually have one :)

>    and service discovery within the home with no operator intervention.

I would just say, "Homenets are intended for use with minimal or no
administration, so homenets automatically configure …."  Then we don't
need to have a boring discussion about what capabilities the user has.

>    network, but does not attempt to provide feature parity with a

As I think I suggested before, we have no evidence that we'll ever
come up with an advanced naming architecture, and I'm not too keen on
writing cheques that might never be negotiable.  Why not just skip
that claim, and say, "This document outlines a simple naming
architecture, which provides a minimal …," and be done with it?

>    Some requirements are not satisfied by the simple architecture

This suggests to me that, in fact, they're not really requirements.
If we have a simple architecture that can leave those use cases out,
they're not actually required at all, are they?

>       forward and one or two reverse domains that are applicable to that

Are we confident that the reverses are really going to be needed?
They're often badly maintained in practice, and the rest of the
document doesn't really seem to indicate why they're so important.

>    o  Resolution: a full-service caching DNS resolver

According to 1123, all full-service resolvers have a cache, so this is
redundant.  

>    that do not implement these features must work on homenets.

What does "work" mean, there?  Work as expected at design time, or
work as the user expects given the homenet deployment?

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Daniel Migault <[email-masked]>
Date: Tue, 29 May 2018 14:13:23 -0400

Hi Andrew,

Thanks you for providing the feed backs. An few comments inline.

> architecture because we don't actually have one :)

I believe that complete architecture here shoudl be read as the set of
functions/properties the naming homenet architecture should provide. The
simple naming architecture defines a best match between the expectation and
what is available. Would something around these lines address your
comments.

This document describes the expected properties and functions a naming
architecture needs to fulfill in a homenet: Names are published, resolved
on homenets, and hosts are configured to use these names to discover
services on homenets.  The document describes how these functions are best
achieved in environments were a single and low cost Homenet Router  (HNR)
is deployed and with minimal or no administration. As a result, the simple
naming architecture may only partially fulfill the initial expected
functions which are expected to be extended in more advanced naming
architectures.

> need to have a boring discussion about what capabilities the user has.

I agree. I also believe that not expecting intervention helps in keeping
description deterministic and simple. I like your text.

> architecture, which provides a minimal …," and be done with it?

I believe that the main reason mentioning the advanced naming architecture
was to state the simple naming architecture is not expected to be complete
and future developments are expected.

> they're not actually required at all, are they?

It seems to me these are more the functionalities one expect from such
architecture. As requirements can be SHOULD ;-) I believe that requirement
is appropriated, but we can relax it with consideration as well - in my
opinion.

> document doesn't really seem to indicate why they're so important.

I would like to make the situation better than worst, so yes we need to
provide motivations. - usability, DNS-SD, ...

> Agree. I think the redundancy wanted to clarify with (stub) resolver, but
I agree we do not need another terminology.

> work as the user expects given the homenet deployment?

I think that is the second option.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 30 May 2018 11:11:44 +1200

On 30/05/2018 06:13, Daniel Migault wrote:
...
> description deterministic and simple. I like your text.

Out of, say, one million homenets, how many do you think *will*
experience human intervention (either helpful, harmful, or
malicious)? I'm guessing several thousand at least. I really think
that not expecting intervention is a basic error.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Wed, 30 May 2018 09:17:10 -0400

> that not expecting intervention is a basic error.

I think you are using the wrong metric to count :-)
Every single homenet will experience human intervention: a human will plug it
together...

The question you want to ask is how many times will a human be required to
configure something which is a normal, every-day activity.  Our goal is zero,
but 0.1% errors on 1,000,000 is 1,000, which is inline with your number
above.  0.1% is only "three" nines.

Then how often will the network need to be interogated for harmful or
malicious activity. At this point, we are not proposing any mechanisms to
deal with attacks, or collect information about current attacks, so let's
make that out of scope for now.

It's that 0.1% situation that we need some kind of accessible audit
information available.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 May 2018 08:32:50 +1200

Well, let me invent something. I throw together my network and it names
the printers as printer1 and printer2. Being a stickler, I decide to
rename them as Printer 1 and Printer 2. I mess around and find a config file
somewhere and manually edit it. My printers no longer work.

All I'm saying is that the design needs to assume that such things will
happen. In the real world, this can't be out of scope.

   Brian

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 May 2018 13:38:31 -0700

> somewhere and manually edit it. My printers no longer work.

It would be good if you could come up with a real example.   This isn't going to happen in practice, because in practice there is no file to edit—printers are discovered using DNSSD.   If we have a successful DNSSD implementation, then printers will work, and nobody will ever even go looking for that nonexistent config file.   If we don't have a successful DNSSD implementation, we have failed.

Does the working group need a walk-through of how this works?   It Can Be Done!   :)

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 30 May 2018 22:53:26 +0200

>     Well, let me invent something. I throw together my network and it
>     names the printers as printer1 and printer2. Being a stickler,
>     I decide to rename them as Printer 1 and Printer 2. I mess around
>     and find a config file somewhere and manually edit it.

Let me rephrase it:

« For her birthday, I bought my girlfriend the nice printer she's been
  wanting.  The network named it "Printer7839cf31".  Since I love my
  girlfriend, I renamed it to "Mathilda's printer".  Now she can no longer
  print. »

> It would be good if you could come up with a real example. This isn't
> going to happen in practice,

(Giggle.)

-- Juliusz

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 May 2018 11:39:25 +1200

>> going to happen in practice,

We'll see. As it says in every good shop: the customer is always right.

    Brian

---

From: "David R. Oran" <[email-masked]>
Date: Thu, 31 May 2018 08:07:59 -0400

> We'll see. As it says in every good shop: the customer is always 
Apple doesn’t think so and it may at least partially account for the 
fact that their products successfully auto-configure way more frequently 
than those of the competition.

If there’s a lesson to be learned from this example it’s that either 
you don’t allow automatically-named things to change their names, or 
if you provide a user-friendly feature to change the name it “just 
works” and doesn’t break the associated function. I guess this means 
that if you rely on DNS to discover and use names, then you provide an 
update API and not allow “write-behind” to config files (if they 
exist in the first place).

Now, if the name-changing auto-configuration functions are broken, then 
either there has to be a way to diagnose it (maybe only by the people 
who sold you the printer) and a way to revert to the prior 
configuration. That diagnostic function does in my view not have to be 
something easily done by the home user.

DaveO

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Jun 2018 09:22:30 +1200

> than those of the competition.

I'm not sure that's as true as it used to be; my recent experiences with
attaching off-the-shelf printers to another o/s have been positive. However,
that's with very simple network topology.

> exist in the first place).

I agree. Without the ability for users to attach names of their choice
(in scripts of their choice) to devices, there will be millions of
unhappy users.

> something easily done by the home user.

Are you sure? The people who sell you printers today operate on very
tight profit margins. In practice, I don't think expert diagnosis is
a realistic expectation.

Regards
    Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 31 May 2018 14:32:15 -0700

In practice, you just change the device's name in its web ui. Then it's
starts advertising the new name, and the old name stops working. If you
have enough of a model of this to change the name, you also know enough to
select the printer under it's new name. Of course it would be nice if we
could have it publish some kind of announcement about the name change.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 31 May 2018 14:41:24 -0700

On 05/31/2018 02:32 PM, Ted Lemon wrote:
> In practice, you just change the device's name in its web ui. Then 
> it's starts advertising the new name, and the old name stops working. 
> If you have enough of a model of this to change the name, you also 
> know enough to select the printer under it's new name. Of course it 
> would be nice if we could have it publish some kind of announcement 
> about the name change.

If we have expectation of somebody configuring their printer with a web 
UI, why should we not expect
the same for routers, or naming services?

IMO, people don't futz around with things unless there's a reason. But 
they will if they want/have to. These things
need to be dumbed down to be certain, but I've never thought we need to 
be hamstrung by the assumption
of zeroconf just because people don't currently have much of a 
relationship with their networking gear.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Thu, 31 May 2018 14:45:04 -0700

We aren't assuming that. Of course in all likelihood it will be present,
but the vast majority of end users never even realize that there is a web
UI available. My point was simply that those users who are aware of that
will be able to cope with adversity.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 31 May 2018 14:54:44 -0700

On 05/31/2018 02:45 PM, Ted Lemon wrote:
> We aren't assuming that. Of course in all likelihood it will be 
> present, but the vast majority of end users never even realize that 
> there is a web UI available. My point was simply that those users who 
> are aware of that will be able to cope with adversity.

Maybe that's the heart of the problem. It sounds like of like what's 
needed is a portal which
knows about all of the other devices/sites around the house and gives a 
click through to them.
That very well could be my router. Or alternatively, maybe my browser 
can figure it out itself and
cons up a web page on its very own and give me a nice shiny "homenet" 
button.

Mike

>
> On Thu, May 31, 2018, 14:41 Michael Thomas <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     [email-masked] <mailto:[email-masked]>

---

From: Daniel Migault <[email-masked]>
Date: Thu, 31 May 2018 18:04:20 -0400

So far the only interaction discussed was to set a specific name. What
other minimal interactions the WG could think of  ?
Yours,
Daniel

---

From: Michael Thomas <[email-masked]>
Date: Thu, 31 May 2018 15:05:58 -0700

> would be nice if we could have it publish some kind of announcement 

On the subject of naming, it's not really necessary to change the name 
to give it a pretty display name in DNS... you can just give it a CNAME 
or something like that. That would at least give me one source of truth 
on naming without having to go to every grotty web interface on low end 
devices (assuming it exists at all).

Mike

---

From: Ted Lemon <[email-masked]>
Date: Thu, 31 May 2018 16:00:10 -0700

That's one way of doing the renaming, sure. It's not that simple though.
You'd probably have to populate both names and mark one of them as
deprecated. The problem is that this creates a bit of a mess.

Regarding specifying a UI, I think that is it of scope, but it's an
interesting problem that would be worth talking about.

---

From: Michael Thomas <[email-masked]>
Date: Thu, 31 May 2018 16:27:34 -0700

On 05/31/2018 04:00 PM, Ted Lemon wrote:
> That's one way of doing the renaming, sure. It's not that simple 
> though. You'd probably have to populate both names and mark one of 
> them as deprecated. The problem is that this creates a bit of a mess.

With a CNAME, you wouldn't need to deprecate the other... it's just an 
alias that you have control of.
 From the UI perspective, whatever is presenting names to the user can 
prefer the human-given name over
the auto-generated name, right? We wouldn't need to standardize anything 
then.

> interesting problem that would be worth talking about.

I'm not an expert on browser plugins, but it seems to me that they could 
probably go a very long
way if one were created to simplify things like naming. And the one 
thing we can take for granted
is that people know how to push bits around using a web browser :)

Mike

>
> On Thu, May 31, 2018, 15:06 Michael Thomas <[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Thu, 31 May 2018 16:36:23 -0700

And a quick search turns up this for Chrome:

https://github.com/GoogleChrome/chrome-app-samples/tree/master/samples/mdns-browser

Apparently writing an extension is as easy as writing html and 
javascript in chrome. I vaguely think that
Firefox is the same, but not for sure.

Mike

On 05/31/2018 04:27 PM, Michael Thomas wrote:
> the auto-generated name, right? We wouldn't need to standardize 
> anything then.
>
>>
> I'm not an expert on browser plugins, but it seems to me that they 
> could probably go a very long

---

From: Ted Lemon <[email-masked]>
Date: Thu, 31 May 2018 17:39:51 -0700

On May 31, 2018, at 4:27 PM, Michael Thomas <[email-masked]> wrote:
> With a CNAME, you wouldn't need to deprecate the other... it's just an alias that you have control of.
> From the UI perspective, whatever is presenting names to the user can prefer the human-given name over
> the auto-generated name, right? We wouldn't need to standardize anything then.

Michael, I don't think you've really understood the issue here.   Let me try and explain it all at once, since the explanation was actually scattered across several messages.

There are two pieces to this.   First, there's the thing that publishes the name.  That's DNSSD.   There's no problem with that end of things.   If you change the name, the device just appears with its new name, and everything is fine.   That's our piece of the puzzle, and it already works.

The problem is that hosts tend to remember names.   On MacOS, for instance, if you configure a printer, the host remembers the printer forevermore.   It's no problem to configure a new printer, but if you change the name that the printer advertises, there will be a stale configuration on the host pointing to the old name, and the user will have to configure a new printer to get access to the old printer.

So what we are talking about here actually breaks DNSSD's good behavior.   We don't want DNSSD to publish two names.   We don't want DNSSD to publish a CNAME.   That would just be extra garbage that would have to be maintained forever.

What we want is a way for the host to notice that the device's name has changed.   We want the device to have some identity other than the name that doesn't change when the name changes.   And we actually have this in the registration protocol, which is another draft being published in the DNSSD working group.   That protocol has the host generating a public/private key pair, and using the public key as an identity.   It uses this identity to claim the name, but it wouldn't be that much work to also specify that hosts should use that identifier to notice that a device has a new name and update the name in the user interface.

When I talk about UI, I'm really talking about the API behind the UI.   Having a management API for homenet would be a good thing.   Possibly it could just be done with HNCP.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 1 Jun 2018 10:57:00 +1000

On the Mac I just press the ‘-‘ button on the list of printers to remove the old entry.

I suspect most devices WILL NOT REMEMBER old printers.  Macs are a exception because their heritage is manually configured printers.  You will get to see the current list and that is just that.  I think this is really a non-issue.  The old printer is gone.  There is a new printer with a different name.

If a device really wants to be known by two names it can register itself twice.

Mark

> On 1 Jun 2018, at 10:39 am, Ted Lemon <[email-masked]> wrote:
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Thu, 31 May 2018 17:59:21 -0700

On 05/31/2018 05:39 PM, Ted Lemon wrote:
> On May 31, 2018, at 4:27 PM, Michael Thomas <[email-masked] 
> Michael, I don't think you've really understood the issue here.   Let 
> me try and explain it all at once, since the explanation was actually 
> scattered across several messages.
>
> There are two pieces to this.   First, there's the thing that 
> publishes the name.  That's DNSSD.   There's no problem with that end 
> of things.   If you change the name, the device just appears with its 
> new name, and everything is fine. That's our piece of the puzzle, and 
> it already works.
>
> The problem is that hosts tend to remember names. On MacOS, for 
> instance, if you configure a printer, the host remembers the printer 
> forevermore.   It's no problem to configure a new printer, but if you 
> change the name that the printer advertises, there will be a stale 
> configuration on the host pointing to the old name, and the user will 
> have to configure a new printer to get access to the old printer.
>
> So what we are talking about here actually /breaks/ DNSSD's good 
> behavior.   We don't want DNSSD to publish two names.   We don't want 
> DNSSD to publish a CNAME.   That would just be extra garbage that 
> would have to be maintained forever.

No, no, no. That's not what i meant. I'm saying that a authoritative 
server can create a CNAME based on the DNSSD name
which is the pretty name. So that when i type pretty-name.myhome.net 
it's really pointing to ugly-name.

>
> What we want is a way for the host to notice that the device's name 
> has changed.   We want the device to have some identity other than the 
> name that doesn't change when the name changes.   And we actually have 
> this in the registration protocol, which is another draft being 
> published in the DNSSD working group.   That protocol has the host 
> generating a public/private key pair, and using the public key as an 
> identity.   It uses this identity to claim the name, but it wouldn't 
> be that much work to also specify that hosts should use that 
> identifier to notice that a device has a new name and update the name 
> in the user interface.

What I'm thinking is that i plug something into my homenet, and i name 
it. I could do that by logging into the device itself,
but creating a CNAME gives me some flexibility in that i don't have to 
deal with its crappy interface, and survives when i throw
it in the trash. If it's normal DNS, it doesn't matter how/why the CNAME 
was created, it just works.

Mike

---

From: Michael Richardson <[email-masked]>
Date: Thu, 31 May 2018 21:33:55 -0400

> could have it publish some kind of announcement about the name change.

That's basically what I'm asking for in the form of diagnostics.