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

[Ted Lemon]

FWIW, on the particular topic of name stability, it might be worth
consulting https://tools.ietf.org/html/draft-sctl-service-registration-00,
particularly section 5, which talks about first-come, first-served name
registration.   The document is expired because we've been distracted by
implementation recently, but a new version should be coming out shortly.
This is of course an extension to DNSSD, and therefore can't be counted on
to be present in existing devices, so for those devices the security of
names isn't really possible to guarantee in any meaningful way—as you've
both said, neither the MAC address nor the IP address can be used as an
identifier with any confidence.

On Tue, Jun 19, 2018 at 11:50 AM, Andrew Sullivan 
wrote:

> On Mon, Jun 18, 2018 at 06:32:26PM -0400, Michael Richardson wrote:
> > Users need to be able to connect policies (including, but not just
> security
> > policies) to both pretty names ("the office printer"),  and to stable
> > identies.   Neither thing should have anything to do with IP addresses
> > (which get renumbered), nor to MAC addresses (which may be more
> frequently
> > randomized, even for things like printers).
>
> I think this is right, but it seems to me we could be slightly more
> formal.
>
> Over time, a device has one of more MAC address; the MAC address must
> not be treated as a stable identifier because it may change over time.
>
> At a given time, a given MAC address may have 0 or more IP addresses
> assigned.  If any MAC address has an IP address assigned to it, that
> address is expected to be assigned automatically.  It is expected to
> change.  An {IP, MAC} tuple should not be treated as a stable
> identifier because both elements of the identifier may change over
> time.
>
> Each device will have at least one name.
>
> Some names are automatically assigned through the workings of mDNS or
> hybrid multicast DNS (or both).  In particular, when devices are
> available by mDNS they are available by name, but the names are
> checked (and if need be changed) algorithmically in order to prevent
> duplication.  Names are unique within the scope of the homenet, and
> devices will change their names in the event of collision.
>
> Some names are generated by users, and assigned to devices, depnding
> on whether the device supports that functionality.  These names MUST
> NOT be changed algorithmically by devices, and MUST NOT collide with
> automatically-generated names.  These names may be globally-unique, or
> may be unique only in the scope of the homenet.
>
>
> I _think_ that covers all the cases, but I might have missed
> something.
>
> 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] Introduction to draft-ietf-homenet-simple-naming

[Andrew Sullivan]

On Mon, Jun 18, 2018 at 06:32:26PM -0400, Michael Richardson wrote:
> Users need to be able to connect policies (including, but not just security
> policies) to both pretty names ("the office printer"),  and to stable
> identies.   Neither thing should have anything to do with IP addresses
> (which get renumbered), nor to MAC addresses (which may be more frequently
> randomized, even for things like printers).

I think this is right, but it seems to me we could be slightly more
formal.

Over time, a device has one of more MAC address; the MAC address must
not be treated as a stable identifier because it may change over time.

At a given time, a given MAC address may have 0 or more IP addresses
assigned.  If any MAC address has an IP address assigned to it, that
address is expected to be assigned automatically.  It is expected to
change.  An {IP, MAC} tuple should not be treated as a stable
identifier because both elements of the identifier may change over
time.

Each device will have at least one name.

Some names are automatically assigned through the workings of mDNS or
hybrid multicast DNS (or both).  In particular, when devices are
available by mDNS they are available by name, but the names are
checked (and if need be changed) algorithmically in order to prevent
duplication.  Names are unique within the scope of the homenet, and
devices will change their names in the event of collision.

Some names are generated by users, and assigned to devices, depnding
on whether the device supports that functionality.  These names MUST
NOT be changed algorithmically by devices, and MUST NOT collide with
automatically-generated names.  These names may be globally-unique, or
may be unique only in the scope of the homenet.


I _think_ that covers all the cases, but I might have missed
something.

A

-- 
Andrew Sullivan
a...@anvilwalrusden.com

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

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

[Michael Richardson]

STARK, BARBARA H  wrote:
> in which case we can and should re-discuss) is: Some users like to give
> their devices pretty/friendly names. We need to make sure that's
> possible, but not required.  Others will simply accept whatever name
> the device comes with.  These names are visible to users and should not
> be confused with credentials or a stable identity. But they do need to
> be unique.  Stable identity is also needed.

This is essentially correct, but it feels a bit weak to me.

Given that devices wind up with pretty/friendly names, and that those name
can change for a variety of reasons, we REQUIRE stable identity as well as
pretty names.

Users need to be able to connect policies (including, but not just security
policies) to both pretty names ("the office printer"),  and to stable
identies.   Neither thing should have anything to do with IP addresses
(which get renumbered), nor to MAC addresses (which may be more frequently
randomized, even for things like printers).

--
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] Introduction to draft-ietf-homenet-simple-naming

[STARK, BARBARA H]

Hi homenet,
There was great conversation about homenet-simple-naming a couple of weeks ago. 
I wanted to see if I could summarize where that ended up.

Main points discussed were device (friendly? pretty?) name and/or identity 
(public key?) and basic end user management (like giving devices names).

What I read into the discussion (which may not be what others read -- in which 
case we can and should re-discuss) is:
Some users like to give their devices pretty/friendly names. We need to make 
sure that's possible, but not required.
Others will simply accept whatever name the device comes with.
These names are visible to users and should not be confused with credentials or 
a stable identity. But they do need to be unique.
Stable identity is also needed.

So how did I do? And where does this take us?
Barbara

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

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

[Michael Richardson]

Ted Lemon  wrote:
> 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, there are now "True Names", and "Current Names", and some nebulous
disctinction between them.  TrueNames could be IP addresses or L2 addresses
(except for privacy issues that make them Current names)... 

Let me add additional motivation/use-case to what you say:

Let's say I have a printer called "basement", and after awhile I decide I
want a better printer, and so I get one.  I move the "basement" printer
to the spouse's office, and I want to rename it "houseprinter", because
I want the new printer to be called "basement".

I should be able to rename the printer once, and a whole bunch of places
where there is a link to "basement" should become "houseprinter", because I
see no reason why I should re-install drivers and changes settings, etc.
At the same time, the default printer for my basement desktop should probably
*not* change, but perhaps that's too much to ask.

Contrast this to a case where I get a new phone, and give my old phone to my
kid.  I actually want to *disconnect* all privileges for the old phone when
it is not just renamed, but in fact, factory reset.  My new phone should get
all the privileges of my old phone.

So in fact, when I move the printer I want it to keep the TrueName something,
and when I get a new phone, I want it to adopt the old phone's TrueName
something.

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

Factory reset generates a new keypair, and despite the name change,
that should persist in the printer, so this is perfect.

So what we want the host to remember is the public key of the printer, not
the name.   Is this possible with DNSSD?  I guess we need this additional draft.

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

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



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

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

[Michael Richardson]

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.

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

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



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

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

[Michael Thomas]

On 05/31/2018 05:39 PM, Ted Lemon wrote:
On May 31, 2018, at 4:27 PM, Michael Thomas > 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.


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

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

[Mark Andrews]

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  wrote:
> 
> On May 31, 2018, at 4:27 PM, Michael Thomas  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.
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

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

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

[Ted Lemon]

On May 31, 2018, at 4:27 PM, Michael Thomas  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.

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

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

[Michael Thomas]

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:

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.




Regarding specifying a UI, I think that is it of scope, but it's an 
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  wrote:

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.

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

___
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] Introduction to draft-ietf-homenet-simple-naming

[Michael Thomas]

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.




Regarding specifying a UI, I think that is it of scope, but it's an 
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 > wrote:


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.

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

___
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] Introduction to draft-ietf-homenet-simple-naming

[Ted Lemon]

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.

On Thu, May 31, 2018, 15:06 Michael Thomas  wrote:

> 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.
>
> 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
>
> ___
> 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] Introduction to draft-ietf-homenet-simple-naming

[Michael Thomas]

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.


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

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

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

[Daniel Migault]

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


On Thu, May 31, 2018 at 5:22 PM, Brian E Carpenter <
brian.e.carpen...@gmail.com> wrote:

> On 01/06/2018 00:07, David R. Oran wrote:
> > On 30 May 2018, at 19:39, Brian E Carpenter wrote:
> >
> >> On 31/05/2018 08:53, Juliusz Chroboczek wrote:
>  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.)
> >>
> >> We'll see. As it says in every good shop: the customer is always
> >> right.
> >>
> > 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.
>
> 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.
>
> > 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).
>
> 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.
>
> > 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.
>
> 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
>
> ___
> 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] Introduction to draft-ietf-homenet-simple-naming

[Michael Thomas]

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


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

___
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] Introduction to draft-ietf-homenet-simple-naming

[Ted Lemon]

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.

On Thu, May 31, 2018, 14:41 Michael Thomas  wrote:

> 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
>
> ___
> 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] Introduction to draft-ietf-homenet-simple-naming

[Michael Thomas]

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

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

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

[Ted Lemon]

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.

On Thu, May 31, 2018, 14:22 Brian E Carpenter 
wrote:

> On 01/06/2018 00:07, David R. Oran wrote:
> > On 30 May 2018, at 19:39, Brian E Carpenter wrote:
> >
> >> On 31/05/2018 08:53, Juliusz Chroboczek wrote:
>  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.)
> >>
> >> We'll see. As it says in every good shop: the customer is always
> >> right.
> >>
> > 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.
>
> 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.
>
> > 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).
>
> 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.
>
> > 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.
>
> 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
>
>
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

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

[Brian E Carpenter]

On 01/06/2018 00:07, David R. Oran wrote:
> On 30 May 2018, at 19:39, Brian E Carpenter wrote:
> 
>> On 31/05/2018 08:53, Juliusz Chroboczek wrote:
 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.)
>>
>> We'll see. As it says in every good shop: the customer is always 
>> right.
>>
> 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.

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.

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

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.

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

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

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

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

[David R. Oran]

On 30 May 2018, at 19:39, Brian E Carpenter wrote:


On 31/05/2018 08:53, Juliusz Chroboczek wrote:
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.)


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


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


Brian

___
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] Introduction to draft-ietf-homenet-simple-naming

[Brian E Carpenter]

On 31/05/2018 08:53, Juliusz Chroboczek wrote:
>> 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.)

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

Brian

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

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

[Juliusz Chroboczek]

> 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

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

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

[Ted Lemon]

On May 30, 2018, at 1:32 PM, Brian E Carpenter  
wrote:
> 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.

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! 
  :)


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

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

[Brian E Carpenter]

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

On 31/05/2018 01:17, Michael Richardson wrote:
> 
> Brian E Carpenter  wrote:
>  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.
> >>> 
> >>> 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.
> >>> 
> >> 
> >> I agree. I also believe that not expecting intervention helps in 
> keeping
> >> 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.
> 
> 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.
> 

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

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

[Michael Richardson]

Brian E Carpenter  wrote:
 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.
>>> 
>>> 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.
>>> 
>> 
>> I agree. I also believe that not expecting intervention helps in keeping
>> 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.

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.

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








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

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

[Brian E Carpenter]

On 30/05/2018 06:13, Daniel Migault wrote:
...
>>> 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.
>>
>> 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.
>>
> 
> I agree. I also believe that not expecting intervention helps in keeping
> 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

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

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

[Daniel Migault]

Hi Andrew,

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


On Mon, May 28, 2018 at 2:05 PM, Andrew Sullivan 
wrote:

> 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.
>
> On Wed, May 23, 2018 at 04:12:52PM -0400, Ted Lemon wrote:
> >
> > 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.
>
> 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 :)


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.




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

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

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

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.

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

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.

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

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

[Andrew Sullivan]

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.

On Wed, May 23, 2018 at 04:12:52PM -0400, Ted Lemon wrote:
> 
> 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.

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

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

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.

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


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?

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

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?

> 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

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.  

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

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

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

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

[Ted Lemon]

On May 25, 2018, at 7:18 PM, Brian E Carpenter  
wrote:
> 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.

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

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

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

[Michael Richardson]

Brian E Carpenter  wrote:
>> Ted Lemon  wrote:
>> >> 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.
>> 
>> > 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.

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

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

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

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.

> So, the naming system may end up being fully automatic, well or badly
> 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)

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




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

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

[Brian E Carpenter]

On 26/05/2018 11:02, Ted Lemon wrote:
> On May 25, 2018, at 1:49 PM, Brian E Carpenter  
> wrote:
>> So, the naming system may end up being fully automatic, well or badly
>> 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.

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

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

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

[Ted Lemon]

On May 25, 2018, at 12:21 PM, Michael Thomas  wrote:
> Optional to implement or optional to deploy?

Optional to deploy.

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

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

[Ted Lemon]

On May 25, 2018, at 1:49 PM, Brian E Carpenter  
wrote:
> So, the naming system may end up being fully automatic, well or badly
> 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.

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

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

[Brian E Carpenter]

On 26/05/2018 08:06, Michael Richardson wrote:
> 
> Ted Lemon  wrote:
> >> 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.
> 
> > 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.

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

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

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

[Michael Richardson]

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

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

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

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

>>> o  Resolution: a full-service caching DNS resolver
>> 
>> 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.

"caching DNS(sec) resolver" ?

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

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

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

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

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

[Ted Lemon]

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

>
>
> 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 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.
> >
> >
>
> Optional to implement or optional to deploy?
>
> Mike
>
> ___
> 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] Introduction to draft-ietf-homenet-simple-naming

[Michael Thomas]

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





Optional to implement or optional to deploy?

Mike

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

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

[Ted Lemon]

Thanks for the review, Michael!

On May 25, 2018, at 11:59 AM, Michael Richardson  wrote:
> Ted Lemon mailto:mel...@fugue.com>> wrote:
>> 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.
> 
> 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.

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

>> o  Resolution: a full-service caching DNS resolver
> 
> 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.

>> *  manages the lifetime of such information, so that it persists
>> long enough to prevent spoofing, but protects end users from
>> seeing stale information
> 
> 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.

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

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

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 stand

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

[Michael Richardson]

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

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.

> 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

s/forward/forward domain/ ?

> o  Resolution: a full-service caching DNS resolver

s/caching DNS resolver/caching DNSSEC resolver/ ?

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

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.

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

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.

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

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

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

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



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

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

[Ted Lemon]

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