Subject: Relationship DNS-SD and SLP

From: Tim Jansen <[email-masked]>
Date: Mon, 22 Jul 2002 03:14:16 +0200

Hi...

I wonder why Zeroconf uses DNS-SD and not SLP. Especially as older MacOS X 
versions already supported SLP, and now Rendezvous adds DNS-SD. Does SLP have 
any disadvantages that prevent it from being used for Zeroconf?

bye...

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 21 Jul 2002 18:39:38 -0700 (PDT)

> any disadvantages that prevent it from being used for Zeroconf?

mDNS is not a service discovery protocol, it is a name resolution
protocol. Nowhere in the Zeroconf documents is mDNS described as a service
discovery protocol, and the mDNS document itself
(draft-ietf-dnsext-mdns-10.txt) explicitly states that it is not about
service discovery.

So I'm curious as to how you came to this conclusion.

---

From: Brad Hards <[email-masked]>
Date: Mon, 22 Jul 2002 16:30:44 +1000

On Mon, 22 Jul 2002 11:39, Bernard Aboba wrote:
> > I wonder why Zeroconf uses DNS-SD and not SLP. Especially as older MacOS
> > X versions already supported SLP, and now Rendezvous adds DNS-SD. Does
> > SLP have any disadvantages that prevent it from being used for Zeroconf?
>
Tim's question doesn't mention multicast DNS, AFAICS.
DNS Service Discovery isn't really about multicast DNS, it is kind of a 
complementary peer.

Tim: I asked Stuart Cheshire almost exactly the same question, and he
pointed to http://files.dns-sd.org/draft-cheshire-dnsext-nbp.txt
(I'd point you to section 3, to save time).

> So I'm curious as to how you came to this conclusion.
Bernard: I'm curious why you confused these issues.

Brad
-- 
http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black.

---

From: Tim Jansen <[email-masked]>
Date: Mon, 22 Jul 2002 20:44:14 +0200

> (I'd point you to section 3, to save time).

Thanks, this is what I was looking for. Its arguments did not convince me 
though.

1. If a user-friendly name for a SLP SA is needed, you can put it into an 
attribute
2. You can append those attributes to the URL if you need to display them to 
the user (for example "service:printer:http://169.254.17.202;(name=Epson 
Stylus 900n)")
3. If you need a persistent identifier for a SA or device and the host name or 
IP is not persistent, you can put an identifier in an attribute (for example 
a large random number or a ethernet hardware address).

bye...

---

From: Keith Moore <[email-masked]>
Date: Mon, 22 Jul 2002 18:41:11 -0400

> mDNS is not a service discovery protocol, it is a name resolution protocol. 

perhaps a more relevant question is, why is a name resolution protocol more 
appropriate for ad hoc networks than a service discovery protocol?

I don't think it is.

first because part of the definition of an ad hoc network is that you cannot 
assume a central authority for name assignment.

second, if you want devices to ship and be able to work out of the box then
you can't expect them to have DNS names that are both meaningful to humans
and relative to some DNS tree.  the most they can reasonably expect to do
is advertise their characteristics, and SLP seems like a better fit for that.

third, a lot of the problem with the linklocal proposal is the idea that 
these things should ever appear in DNS - where they can confuse applications
that aren't prepared to deal with limited-scope addresses that can fail to
work at any time.

Keith

---

From: Brad Hards <[email-masked]>
Date: Tue, 23 Jul 2002 10:17:59 +1000

On Tue, 23 Jul 2002 08:41, Keith Moore wrote:
> > > I wonder why Zeroconf uses DNS-SD and not SLP. Especially as older
> > > MacOS X versions already supported SLP, and now Rendezvous adds DNS-SD.
> > > Does SLP have any disadvantages that prevent it from being used for
> > > Zeroconf?
> >
> > protocol.
> first because part of the definition of an ad hoc network is that you
> cannot assume a central authority for name assignment.
Agreed. In fact, you can safely assume that there is not such an authority.

> is advertise their characteristics, and SLP seems like a better fit for
Confusion. I think of DNS as a tool that turns (as if by magic) some kind of
name into some kind of address (that Just Works[tm]), and can turn it back
again as well. Tree is an implementation detail for scalability.

All I want out of a zeroconf naming system is to be able to put a name
in to my GUI, and be able to access the thing with that name. If I have two
identical printers, I'd be happy to be able to change the name on one of them,
especially if someone told me to do so. I don't want printer X to require that
laptop Y is turned on and running though, if I'm trying to print from workstation
Z.

What I want out of a zeroconf service discovery system is to be able to put
in some combination of attributes (possibly none), and be offered a choice of
services on my network. I don't care much about the names or IP addresses,
just what that service can do. For example, I care that it is an colour printer,
and doesn't have much queued work, and is in the west end of the building,
not that it has the name "bolo-meister".

> these things should ever appear in DNS - where they can confuse
> applications that aren't prepared to deal with limited-scope addresses that
> can fail to work at any time.
Some applications can't handle IPv6. That is a bug too.

What worries me is that we don't (AFAICT) have a standard set of
attributes and naming conventions for services. For example, how do
I find a colour printer without much work on my floor. What would that
look like for SLP or DNS-SD or any other sevice discovery system?
Or "who has the network storage with the engineering groups files?"
Or "who has a link to the internet that will cost less than 1c/megabyte?"
Note: I'm not looking for _a_ way to do this, I'm looking for _the_ way
to do this, that will work in general.

Brad

---

From: Joshua Graessley <[email-masked]>
Date: Mon, 22 Jul 2002 17:44:23 -0700

On Monday, July 22, 2002, at 03:41  PM, Keith Moore wrote:

>>> MacOS X

DNS is not just a name resolution protocol. DNS is a distributed 
database. One of the functions it serves is name to address resolution. 
DNS already has a record type for services, it just hasn't been used 
much yet.

> cannot

This is why multicast DNS is used instead of unicast DNS.

> is advertise their characteristics, and SLP seems like a better fit 

The problem with SLP, in my opinion, is that it is overly complicated. 
The complication arises from the goal of advertising all of the 
characteristics of services and supporting very specific queries.

While a DNS host name is limited in the characters that may be used, 
the DNS packet format has no such restrictions. In addition, there is 
no reason that a host name should have anything to do with the service 
that host is advertising. This seems to be something SLP has overlooked.

> applications

What do issues with linklocal address assignment have to do with using 
multicast DNS to discover local services?

-josh

---

From: Keith Moore <[email-masked]>
Date: Mon, 22 Jul 2002 23:31:11 -0400

> again as well. Tree is an implementation detail for scalability.

okay, then you're not talking about DNS names anymore, because apps can't
depend on those names to have the properties that DNS names have such as
global uniqueness.  so you don't want to use the same API to look them
up that you use to make DNS queries, because that will confuse apps that
expect the names and answers returned from that interface to act like DNS. 
and there's no particular reason to use the DNS protocol, because most of
the RR types in DNS implicitly assume some kind of distributed  management
that is not present in an ad hoc system.

> just what that service can do. 

I think you do care about the names and IP addresses because once you've 
identified a service that you want to use then you want to know how to
talk to it.  If you let the user choose which device/service to use then
you want to present the name to the user in a menu.  Just because you 
didn't start your query with a name doesn't mean you don't care about the name.   

Of course if you have a service discovery system (and it seens like you
need one) then you don't need the pseudo-DNS anymore, because you can 
look up the device/service names just as easily using the service
discovery system.

> Some applications can't handle IPv6. That is a bug too.

I don't see what one has to do with the other.  IPv6 doesn't interfere
with apps that don't know about IPv6 - they never see the IPv6 addresses
because they don't ever do AAAA queries.  whereas IPv4 linklocal addresses
do have the potential to interfere with IPv4 apps if those addresses
show up in contexts (like DNS results) where better-behaved IPv4 addresses 
usually appear.   of course with NATs etc IPv4 is pretty much of a
mess anyway, but LLs make it worse, partially because apps end up having
to treat LL addresses differently than other addresses.

> look like for SLP or DNS-SD or any other sevice discovery system?

well we won't solve that problem for an unmanaged network until we
figure out a way for devices to discover their location without help
(not that hard by itself) relative to their physical surroundings
(much harder) so that the searcher can figure out the concept of 
"on my floor" (presumably in the same building) by itself.

> Or "who has the network storage with the engineering groups files?"

same thing - "engineering group" inherently requires management

> Or "who has a link to the internet that will cost less than 1c/megabyte?"

same thing - cost requires management, not to mention the management
needed to authenticate for billing purposes.

so none of the above are problems for zeroconf to tackle.  that said,
having a standard, local, service discovery facility *would* be useful, 
while trying to replicate DNS doesn't seem very useful at all for this
environment.

> to do this, that will work in general.

I don't think there will ever be "the" way of doing service discovery -
there's a fair amount of evidence that you need a variety of service 
discovery methods depending on the nature of your search.

Keith

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 22 Jul 2002 20:21:38 -0700 (PDT)

> global uniqueness.

If application difficulties were as great as you make them seen, then why
is it so easy for applications to work both with an /etc/hosts file and
with DNS?

> so you don't want to use the same API to look them

Given that operating systems have supported multiple name resolution
mechanisms for decades now based on the same APIs with no ill effects,
this concern hardly seems justified.

> that is not present in an ad hoc system.

Nope. RR types in DNS make no such assumptions; it is resolvers that make
the assumptions, and resolvers can change to provide seamless support to
applications, as they have done for decades.

> look up the device/service names just as easily using the service

Not true. How does service discovery enable the resolution of "ping foo"?

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Jul 2002 00:18:43 -0400

> DNS already has a record type for services, it just hasn't been used 

yes, but DNS still only accepts names as queries - even with the SRV
record there is no way to say "tell me about all of the printers within 
this area".  and there never will be.  

> This is why multicast DNS is used instead of unicast DNS.

so what?  the management of the namespace is completely orthogonal 
to the way the queries are transmitted over the network.  using
multicast won't solve the problem that the DNS namespace is
completely incompatible with an ad hoc network.

> characteristics of services and supporting very specific queries.

okay, fine - I'll restate then.  SLP is a far better starting point
than DNS for the kinds of lookups you need to do in an ad hoc network.  

I certainly won't claim that SLP couldn't use improvement.

> the DNS packet format has no such restrictions. 

character set is also irrelevant to this question.  DNS simply doesn't
have any way to say "find the nearest video projectors" and that's really
what you need.  I won't claim that you can't take the DNS protocol
and try to make it look like a service discovery protocol - after all,
you can fit almost anything into a request-response protocol if you 
try hard enough - but the DNS design is already strained enough just
trying to do name lookup, and what you need for this problem isn't
name lookup.  it's really insane to try to make DNS solve this problem,
and trying to won't be good for either this problem or DNS or the
apps that try to use it.

> In addition, there is 

SLP definitely needs fixing.  but it's a better starting point.

> multicast DNS to discover local services?

the point is that LL addresses are much  less likely to cause harm if 
they don't show up in the same contexts that ordinary addresses do.
if they show up in DNS responses, they'll break things.  if the app
thinks its doing a DNS query but the OS tries to be clever an does
an mDNS query that returns LL addresses, it will break apps that
expect an address to be reasonably stable and unambiguous.  (and 
yes, there are other kinds of ill-behaved addresses besides v4 LL;
this is a general problem that needs to be addresed, but part of the
solution is in limiting how LL addresses are used and the contexts
in which they appear)

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Jul 2002 00:37:07 -0400

> is it so easy for applications to work both with an /etc/hosts file and

it's *not* easy to make this work on any scale.  have you ever tried it?

on our local network hosts files are forbidden to have any but a few
'emergency' addresses in them - (if they're enabled at all), and DNS lookups 
have to come first, because otherwise we end up trying to track down 
obscure problems when a host's address changes and the host files don't
change to reflect that. 

for similar reasons we had to completely disable NIS hosts maps and WINS.

from a different angle, one of the reasons that gethostbyname() is 
a lousy interface for DNS queries is that it was designed to read a host 
file (i.e. a local disk file), where (a) you expect a more-or-less
immediate response (so it's okay to block during the call) and (b) you 
simply don't have failure modes like "temporary inability to contact server" 
or "name exists but there are no A records" that applications often
need to handle differently than "no such host".  (no, it's NOT okay to
bounce mail if you get a temp failure on the DNS lookup, but there are
still lots of programs doing this.   and no, it's NOT okay for a web
browser to say "no such server" when the the query on the DNS name fails
for temporary reasons.)

> this concern hardly seems justified.

"no ill effects" is one of the most ridiculous things I've ever seen stated
in IETF.  it's been a disaster for applications and for users.    obviously
you've never tried to make an application work in a wide variety of operating
environments, and you've never tried to administer a heterogeneous network 
of any size.

> applications, as they have done for decades.

wow, you just said something even more ridiculous.    the semantics of
RR types are well defined in their RFCs, and (with the possible exception
of TXT) have global scope - they're the same everywhere in the DNS.
most of those definitions have been stable for a long time.  application 
programmers depend on those semantics.  for "resolvers"  to change those 
semantics on a local basis is a gross and utterly irresponsible protocol 
violation...  it's insanity.

> Not true. How does service discovery enable the resolution of "ping foo"?

why should a name be different than any other service attribute?

just find all nearby systems with name="foo"

but don't expect an application like "ping" to do this unless it's explicitly
coded to do so.

Keith

---

From: Brad Hards <[email-masked]>
Date: Tue, 23 Jul 2002 14:39:38 +1000

On Tue, 23 Jul 2002 13:31, Keith Moore wrote:
> > Confusion. I think of DNS as a tool that turns (as if by magic) some kind
> > of name into some kind of address (that Just Works[tm]), and can turn it
> > back again as well. Tree is an implementation detail for scalability.
>
Maybe.
On my normal managed LAN, I can ask for the address of "gateway", and
get "gateway.cuneata.net.", where "gateway" isn't unique, but 
"gateway.cuneata.net." is unique (or had better be, I don't think I got taken by the
latest scam :).
"gateway.linklocal" isn't that much of a extension. However it 
probably doesn't belong in the same DNS space as my authenticated
name/address pairs, both to stop confusing applications and to prevent
pollution of my DNS.

BTW: is there an example of a major application that will work with NAT,
and not work with LL?

> > What I want out of a zeroconf service discovery system is to be able to
> > put in some combination of attributes (possibly none), and be offered a
> > choice of services on my network. I don't care much about the names or IP
> > addresses, just what that service can do.
>
Agree. At the service discovery step, I want to choose a capability. At the
service usage step, I want to communicate.

> look up the device/service names just as easily using the service
Maybe, maybe not.

Example situation: Tim Jansen and I meet at Linux-Kongress, want to copy
over the latest tarball of zcip. We are both using link-local addresses on 
laptops linked into the main conference network. I have some files available
for rsync, and he has a client. How does get the file?
I can tell him what I call my machine ("leon"), and that the file is available, but
that won't help without some kind of name lookup (which could be DNS).

Or is there a way of phrasing a service discovery query "find me the 
file with zcip in the name"?

> "on my floor" (presumably in the same building) by itself.
I'm happy to configure the printers location when I put it down. But
what do I configure it to so that (in a zeroconf network), I can get
allow people to find it using a "standard" query?

Or a simpler case (which doesn't require management) - I want
to build a zeroconf printer that is a colour bubblejet that can do 
A5, A4 or A3, but not that dodgy American Letter format. What
 are the attributes that I should program into its SLP SA or 
DNS-SD reporting, or whatever?

Brad

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Jul 2002 01:39:19 -0400

> name/address pairs, both to stop confusing applications and to prevent

it's even worse than that, because "gateway.linklocal" doesn't mean the
same thing to you as it does to me, if our contexts are different.
so you can't use that name in a referral from one app to another
and expect it to work.  even ad hoc networks don't necessarily exist as 
disconnected islands. people will be running laptops or palmtops that 
participate in an ad hoc local network around a conference table in
some hotel meeting room at the same time that they're tied via a wireless
link to a VPN to the corporate wireless network, and maybe another VPN to a 
home network.  what does "printer.linklocal" mean then - is it the
printer in the room, or the printer at the office, or the printer at home?
and can I reasonably say "just print to printer.linklocal" to someone across 
the table?  (especially given the assumption that some appliances 
are going to use linklocal as their sole means of addressing...)

and even within the same context there can be multiple hosts that
claim the same name.  in DNS there is only one authority and RRset
for any given name, so DNS query interfaces don't have the possibility
of saying "there are multiple hosts claiming this name, choose 
one of the following..."  

> BTW: is there an example of a major application that will work with NAT,

YES!!!!!!!

First of all, what do you mean by "major application"?  Do you think 
that email and web are the only apps that matter?  "major" apps are the apps 
that *you* need to get work done, or to communicate with others in the way
that works for *you*.  those differ from one kind of user, and from one 
kind of enterprise customer, to another.   there is no typical internet
user anymore.

would you consider SIP a major app?    it doesn't work over NAT, and the
midcom group is making a royal mess trying to figure out how to make it work.

how about multiplayer real-time games?   you don't see them much in the
business world, but there's a fairly big market out there...  some of them
sort-of work with NAT but not in a general fashion - e.g. you have to tunnel
messages through central proxies.  

for the people I work with, cluster computing systems  are essential,
and they don't work over NAT. you might not think of them as "major" but
they are used to implement essential services like large-scale modeling.
essentially all high-performance computing today is cluster computing.

> file with zcip in the name"?

it seems easier to make the service discovery query "find me the nearby
machine that asserts a name of leon".  then if he gets multiple answers
back (some machine names are fairly common), he needs to disambiguate that 
somehow...

the point is that you're as likely to need to do a query for some other
attribute as you are for a name.    and even if you're looking for 
something that matches a name, in an ad hoc network you're going to need
to deal with the possibility of name conflicts that don't exist in DNS.

> allow people to find it using a "standard" query?

well, it sort of seems to me that if you configure the printer at all 
then you're not talking "zeroconf" anymore -  you're talking about
having to have an interface for that printer to allow it to be configured
(impractical for many kinds of appliance) and if you "configure" that 
printer when you "put it down" you can about as easily arrange for
DHCP to give it a stable IP address and a stable DNS name. 

and it also seems to me that "zeroconf" networks are most likely to be
used in ad hoc situations - if the network is going to be up long enough
for the names and locations of devices to be stable then (again) it's worth 
it to start managing that network to some degree.

though I'll accept that a network can be expected to have a mixture of
ad hoc and configured devices.  the printer may be stationary while the
laptops move around, etc.  so in some cases it might be reasonable to 
configure a particular printer to know some of its attributes even if you 
can't expect to configure every device that might appear on the local 
network(s) to which that printer is attached.  that doesn't mean that
name lookup is a good solution in general to the problem of finding
services  on a network.

of course the ability to discover local resources by means other
than name lookups is useful for both zeroconf and managed networks,
and it would be nice if the same mechanism could  work for both cases.

but in the case of a network where everything is managed, things are
in stable locations, etc. name lookup is "good enough" for many
purposes - whereas in ad hoc networks where services and their locations
are probably *not* stable then you need a more versatile service.

> DNS-SD reporting, or whatever?

ask the IPP people - they've been thinking about this stuff for 
awhile, though I don't think it's been heavily targeted at SLP.

Keith

---

From: Brad Hards <[email-masked]>
Date: Tue, 23 Jul 2002 16:56:21 +1000

> same thing to you as it does to me, if our contexts are different.
Clearly this only has meaning *on the same local link*.

> printer in the room, or the printer at the office, or the printer at home?
Clearly, to the 169.254/16 link. I don't know how to handle the case
where someone might be on two 169.254/16 links though.

> and can I reasonably say "just print to printer.linklocal" to someone
> across the table?  (especially given the assumption that some appliances
If you can't, then we've lost. This has to be the outcome of zeroconf.

> of saying "there are multiple hosts claiming this name, choose
Again, either this works, or it doesn't. If you can't handle two hosts
claiming to have the same name, then there is no name lookup in
a zeroconf network. If the current API is broken, then we need to
fix it.

> that email and web are the only apps that matter?  "major" apps are the
> apps that *you* need to get work done, or to communicate with others in the
> way that works for *you*.  those differ from one kind of user, and from one
Concur. Major application is "something I've heard of", for the purposes
of this discussion. Probably I should have used "protocol" rather than
application, because any application can have bugs, and like my
previous assertion that just as applications have to be updated to 
handle IPv6 (and before that, NAT and CIDR maybe), then it is reasonable
to expect people to update applications to handle service discovery,
169.254/16 addresses and "DNS can return non-unique names" 
PROVIDED that those are valid IETF requirements.

> midcom group is making a royal mess trying to figure out how to make it
SIP == "Session Initiation Protocol"? Never heard of it....
That wasn't the question. I asked for an app that  _worked_ with NAT.

> sort-of work with NAT but not in a general fashion - e.g. you have to
> tunnel messages through central proxies.
This is the sort of application that will reasonably work with Link Local, and
not with NAT. That's the reverse question to what I asked.

> essentially all high-performance computing today is cluster computing.
Again, this will work with 169.254/16. It also isn't a representative zeroconf
market.

> back (some machine names are fairly common), he needs to disambiguate that
That would be a naming service. Whether that is different to the service
discovery service is implementation detail. (ie I don't care if it is DNS
a'la Bind, it only has do name to address to name lookups).

> > > > I find a colour printer without much work on my floor. What would
> > > > that look like for SLP or DNS-SD or any other sevice discovery
> > > > system?
> > >
Not so. The whole point of zeroconf isn't that you don't have to 
ever administer things. It is that you can run networks without the
central registry and without reliance on an unrelated box being 
on-line. So I can type in "lounge room" or "basement" into my printer, 
and not have to worry that my DHCP server and DNS server
are available. 
The other thing is that if you assume that everyone has a 
DNS server and can set up a DHCP server, then you
don't need zeroconf. But the world isn't like that. My parents
have no idea about networking - but my Mum could probably
plug colour coded cables into sockets. At that point, she should
be able to print a notice for the gardening group. USB can
do that - the question is whether IP will ever be able to.

> it to start managing that network to some degree.
If it requires management, then you excluded 99% of people.

Home networks for non-networking gurus are very difficult. It isn't
just a matter of temporary - it is a matter of reasonable effort for 
reasonable outcomes. Home networks may not be protected by IPSEC,
not have central registries, may not have DNS servers. But that is
appropriate for some applications. Management should never require
anything more than giving the device a name and plugging it
into a hub.

> name lookup is a good solution in general to the problem of finding
Agree with the point that name lookup isn't everything, but it is
still necessary.
Name is about the only thing that is stable on my laptop. I use
different operating systems, networking devices, etc. Tim still needs
to find my laptop if he wants the _latest_ version of that file.

> and it would be nice if the same mechanism could  work for both cases.
Absolutely. DNS-SD without a specified application API is dead.

> awhile, though I don't think it's been heavily targeted at SLP.
OK - an even easier question. "I'm at a conference, and I want to
print that email from Keith. How do I find a printer on my local link?"

Brad

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 22 Jul 2002 23:26:17 -0700 (PDT)

> this area".  and there never will be.

Yes, and that's a critical distinction between name resolution and service
discovery.

> completely incompatible with an ad hoc network.

There is, for example, no concept of delegation in mDNS. And it is also
true that mDNS is not appropriate for resolution of FQDNs in most cases.
However, few hosts spend all their time connected to adhoc networks, and
names persist while network connections change. Therefore, there is little
intrinsic reason why a host connected to an adhoc network could not have
earlier obtained, and subsequently respond to queries for, an FQDN.

Rather, I would argue that the difficulty of utilizing mDNS to
resolve FQDNs arises largely from the difficulty of implementing
appropriate security mechanisms in the purely adhoc case, rather than
from an intrinsic namespace incompatibility. Were
it possible to use DNS security within adhoc name resolution, the
difficulties in use of the DNS namespace with mDNS would be largely
resolved.

> than DNS for the kinds of lookups you need to do in an ad hoc network.

I think you're overly constraining the kind of interactions that occur in
adhoc networks. Aside from finding a printer or file server, there can
also be a need for directed file transfers or web usage.

How does SLP help with displaying "http://foo/myfolder/"?

> what you need.

I'd claim that the question of the "best" service is a completely
different question than either name resolution or classic service
discovery.

> SLP definitely needs fixing.  but it's a better starting point.

I'm curious as to what exactly needs to be "fixed". SLPv2 has evolved over
a long period in response to deployment experience and critical
evaluations. So I'm curious as to what you believe is still missing.

> apps expect an address to be reasonably stable and unambiguous.

This seems to argue for applications caching the result of name
resolutions. That's a dangerous game, with or without mDNS, if only for
the sake of resilience. In reality, Internet hosts go down on a regular
basis, and well written applications need to deal with that gracefully.

As for the necessity of "unambiguous" naming, I'd remind you that NetBIOS
names exist within a flat hierarchy and have been in widespread use for
decades without causing the application problems you mention.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 22 Jul 2002 23:42:41 -0700 (PDT)

> it's *not* easy to make this work on any scale.  have you ever tried it?

Yup. We run a network with more than 80K hosts, day in and day out.

> for similar reasons we had to completely disable NIS hosts maps and WINS.

I'm sorry that your admins lack the skill to properly maintain NIS or
WINS. But saying that these systems are unworkable strains credibility --
thousands of sites run them successfully.

> browser to say "no such server" when the the query on the DNS name fails

Yes, it's hard for applications to use name resolution correctly. So what?
Well written applications need not exhibit any of these problems.

> in IETF.  it's been a disaster for applications and for users.

One might say the same thing about sockets, yet I don't see you arguing
to avoid changes to TCP :)

> obviously...  you've never tried to administer a heterogeneous network
> of any size.

Hmmm... I guess running a network with more than two million users,
several thousand routers and some of the Internet's most heavily
loaded web servers doesn't qualify, huh?

> violation...  it's insanity.

Yet that is exactly what RFC 1536 did, for example, and the world didn't
end.

---

From: Erik Guttman <[email-masked]>
Date: Tue, 23 Jul 2002 10:02:12 +0200 (MEST)

Keith, Joshua,

Regarding SLP:  Since the SVRLOC WG concluded going on two years ago,
an ad hoc group has formed to work on continuing standardization.  We
have a draft of RFC2608bis which aims at addressing known issues with
the protocol, specifically:

 - reducing the requirements on SAs

 - eliminating complex operations which were hard to implement and
   explain

 - resolving issues which have arisen with the protocol through
   operational experience

The basic goal is to remove features which do not have a solid basis
of interoperability and utility as we have found from three years of
experience as a proposed standard.  We clarify the rest.  We want to
do interoperability testing as soon as the spec is done and advance 
the protocol to draft standard.  All of the changes proposed so far
would retain backwards compatibility - which is to say, existing
SLP implementations would conform to the new spec.  New implementations
will not include some features which were previously in the protocol.

Now, if there are ways suggested to improve the protocol which would 
greatly improve SLP, we *could* consider breaking backward compatib-
ility and creating a new proposed standard 'SLPv3'.  Please consider
what we have already achieved, as I think it goes a long way to 
address shortcomings of SLP.

I invite your comments and participation.  Please see 
  site:  http://www.srvloc.org
  list:  to subscribe:
           http://lists.sourceforge.net/lists/listinfo/srvloc-discuss
         archive:
           http://www.geocrawler.com/lists/3/SourceForge/12970/0
  drafts:

http://www.ietf.org/internet-drafts/draft-guttman-svrloc-rfc2608bis-02.txt
http://www.ietf.org/internet-drafts/draft-guttman-svrloc-serviceid-01.txt
http://www.ietf.org/internet-drafts/draft-kempf-svrloc-rfc2614bis-00.txt
[and more]

RFC2608bis is 40 pages, an improvement over RFC2608 (54 pages) and
RFC2165 (69 pages).  It indicates our progress in simplification
of the protocol.

---

> SLP definitely needs fixing.  but it's a better starting point.

SLP doesn't require any relationship between the host name and the
advertised service.  SLP service advertisements include the following
information, standardized by the service templates registered with
IANA. See http://www.iana.org/assignments/svrloc-templates.htm

   - a 'type of service' string, registered with IANA or vendor specific

   - a 'scope' string, either default or set by a local administration
     to group services

   - a URI, which generally indicates the location of the service, but
     could be used for some other purpose

   - an unordered group of attributes, which could include the name
     of the service, the location of the service, configuration 
     parameters, attributes of the service, etc.

   - digital signatures to allow the recipient of the above information
     to verify that it came from a source which the receiver has been
     configured to trust (at least so far as to be a legitimate source
     of service advertisements).

As far as improving or fixing SLP, your input is extremely welcome and
timely!

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
 E r i k   G u t t m a n            Short email (<140 characters) to 
 Solaris Installation and Deployment       [email-masked] 
 Sun Microsystems                             cell: +49 172 865 5497

---

From: Erik Guttman <[email-masked]>
Date: Tue, 23 Jul 2002 10:25:04 +0200 (MEST)

Brad,

> DNS-SD reporting, or whatever?

Please see:
  http://www.iana.org/assignments/svrloc-templates/printer.2.0.en

According to this, the printer would advertise itself as

  service type =  service:printer:ipp
           URI =  service:printer:ipp://169.254.23.16:631/myqueue
         scope =  default
    attributes =  ...,(printer-media-supported=iso-a4,iso-a5,iso-a3),...

and

  service type =  service:printer:lpr://
           URI =  service:printer:lpr://somehost.example.com:515/myqueue
         scope =  default
    attributes =  ...,(printer-media-supported=iso-a4,iso-a5,iso-a3),...

Notes:
  1) In the IPP case, an address is given instead of a hostname.
     This is OK, but a hostname is preferred.  The host advertising
     the printer is in a zeroconf scenario and has no name assigned
     and only a link local address.  It can still use SLP to advertise
     itself, and be discovered.

  2) The port numbers in both the URLs listed are optional as they
     are the well known port numbers.  Including them doesn't hurt.

A client can request a printer with a SLP service request including

  service type =  service:printer:ipp
         scope =  default
         query =  (printer-media-supported=iso-a4)

It will receive a SLP service reply with:

  service URL =  service:printer:ipp://169.254.23.16:631/myqueue

The entire list of attributes associated with that printer can be
retreived with an Attribute request or in the service reply itself
if RFC 3059 Attribute List Extensions are supported.

The code to do this advertisement is only 3 lines or so of C or Java, 
while the request probably requires about 10 lines - using the SLP API 
(RFC 2614).  

Erik

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Jul 2002 10:01:06 -0400

> Clearly this only has meaning *on the same local link*.

right, but machines can have interfaces on multiple links, and some of those
interfaces might be tunnel endpoints.  (after all, what's the purpose of
a VPN except to give you presence on a remote network so you can access
those resources - and if LLs are used in the way this group seems to
think they will be, those resources might include hosts accessible only 
via a LL address.)
 
> If you can't, then we've lost. This has to be the outcome of zeroconf.

well, it might get easier to disambiguate if you're not restricted to 
matching a single attribute when looking for that printer.

> a zeroconf network. If the current API is broken, then we need to

the DNS API isn't broken (at least, not for this reason) because DNS -
by design - can't have naming conflicts.  applications quite reasonably
depend on DNS not having more than one RRset per name.  but trying to use 
the DNS API to look up names where there might be collisions *is* broken.

> PROVIDED that those are valid IETF requirements.

NO.  as a fundamental part of its design, DNS names *are* unique. 
 
> That wasn't the question. I asked for an app that  _worked_ with NAT.

sorry - I did misread the question.  obviously NATs are a hot button for me...

broad generalization: most apps that only involve two endpoints work with NATs 
as long as the app "inside" the NAT initiates all connections and as long as 
the app or users uses DNS names (and therefore they'll get translated by the
DNS ALG on the NAT) rather than IP addresses.  (But DNS ALG creates problems 
of its own because those addresses leak into other contexts where they're not valid)

so no, I don't think that every app that works with NAT will work with v4 LL
addresses - some of the problems are the same between the two spaces (both 
private addrs and LL address are ambiguous) and some are different
(v4 addrs are subject to being shot down without notice, breaking TCP connections,
and DNS lookups of any kind are a poor mechanism for obtaining v4 LL addresses)
 
> not with NAT. That's the reverse question to what I asked.

it's quite a stretch to assume that all of the participants of a RT game 
are on the same link in the LL case but on different sides of a NAT in the
NAT case...

> discovery service is implementation detail. 

it wouldn't be exclusively a naming service, because it would return other
information than just each machine's name (one machine named leon is an imac,
another is a thinkpad...)

> and not have to worry that my DHCP server and DNS server

my strong impression is that there's more than one "whole point" of zeroconf.

> be able to print a notice for the gardening group. 

is your Mum going to configure a printer to know its location?

> USB can

well for USB the problem is somewhat easier - because you're unlikely
to have a USB connection to a network halfway across the planet
(but you might well have a VPN tunnel to such a location, and want
to access devices on an IP network in such a location).  and chances 
are that you'll *know* what is on your local USB network.  and 
from my limited exposure to USB I don't think they're trying to 
use simple name lookup from a global name space to find devices.

that and with USB there was no expectation that USB appliances would
work with an existing set of applications that was designed to talk 
with IP hosts... whereas there does seem to be an expectation that
existing IP apps can talk to LL devices even though they violate a
number of assumptions that many apps quite reasonably make.

> If it requires management, then you excluded 99% of people.

understood and agreed.  at the same time, if you expect LL networks
to use the same interfaces and applications as existing IP networks,
you need to make LL networks behave like IP networks, and some of
the characteristics of IP networks (like stable, unique addresses
and globally unique host names) are difficult to achieve without some
degree of management.  

> anything more than giving the device a name and plugging it

actually giving the device a name may be too much to ask.

> to find my laptop if he wants the _latest_ version of that file.

I don't know how you can move a laptop around and keep the same DNS name -
in my experience the name has to change even with dynamic DNS (because 
one network that I connect to insists on updating the DNS name that
*it* has assigned to the laptop to reflect the laptop's current IP
address, and so that the address lookup will return *its* name for the
laptop rather than say, the name the laptop has at home).  So if I'm 
going to try to assign a stable name for the laptop that works no matter
where it happens to be connected, that name can't be the DNS name.

> Absolutely. DNS-SD without a specified application API is dead.

it would help to stop calling it anything with DNS in the name, and to 
stop trying to make it look like DNS.  calling it DNS is confusing 
because the service you're talking about doesn't have the same 
characteristics of DNS.  having it look like DNS isn't reasonable 
because you need this service to provide more flexibility than you 
can reasonably shoehorn into the DNS protocol.
 
> print that email from Keith. How do I find a printer on my local link?"

are you asking what is reasonable, or are you asking how to do this in
the context of what zeroconf is trying to define?

as for "what is reasonable" I'd say that the user clicks on network
neighborhood or runs whatever program his OS uses for that purpose,
and maybe it pops up a list of device classes - printers, scanners,
video projectors, hosts - and you select 'printer', and then it
shows a list of printers, along with characteristics and locations,
and you select 'the color printer that is 10m away'. (or lacking
GPS coordinates, you select 'the color printer that thinks its in
room xyz of Hotel Foo')

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Jul 2002 10:34:25 -0400

> earlier obtained, and subsequently respond to queries for, an FQDN.

now that's a disaster waiting to happen.  just because a host might have
once been associated with an FQDN doesn't mean it's *still* associated
with that FQDN.  and if one host does a DNS lookup and gets one result
for an FQDN while another host does an mDNS lookup and gets a different
result, you've just broken DNS.
  
> difficulties in use of the DNS namespace with mDNS would be largely

the problem isn't just security, it's also consistency.  what you're 
essentially saying is that mDNS can be used as a cache for real DNS, 
and with appropriate constraints this might be doable.  but with real 
DNS then there really is an assumption that you can get to an authoritative 
server - one that is controlled or at least chosen by the party that assigned 
the name, and which is generally updated in a timely fashion - and get 
current, authoritative answers from that server.  with mDNS this would 
not be possible - it's as if you're disconnected from the network and
you're stuck with whatever is in the cache of your local resolver.

> How does SLP help with displaying "http://foo/myfolder/"?

it doesn't. but URLs are supposed to have globally consistent meanings, 
and it's not within zeroconf's purview to change that.  

more generally, just because ad hoc networks are useful is not a 
justification for this group trying to change the behavior or meaning
of well-established interfaces and protocols in whatever manner it sees fit.

> different question than either name resolution or classic service

perhaps.  but my point is that trying to overload DNS for this purpose
does harm to DNS and to apps, and doesn't really solve your problem
anyway.

> evaluations. So I'm curious as to what you believe is still missing.

it's been awhile since I reviewed SLP, so I don't really remember details.
but I recall thinking that that service: URI was pretty bogus, and that
it was fairly unreasonable to expect SLP to work beyond a relatively
local portion of the network topology (nothing inherently wrong with that
but some SLP proponents were claiming more generality)

> resolutions. 

not exactly. but at the same time it's completely reasonable for
apps to pass around addresses - for many purposes DNS lookups 
don't work very well.  

> That's a dangerous game, with or without mDNS, if only for

when the host goes down it tends to break existing connections to that
host anyway, and it tends to kill all the apps running on that host anyway,
so having the address be able to change when that happens is probably
not a big deal.  that doens't mean, however, that DNS is the mechanism
that every application should use to find the new address of that host
if and when it happens to reappear on the network.

> decades without causing the application problems you mention.

NetBIOS doesn't try to look like DNS, and people don't try to use NetBIOS
names on an internet-wide scale.  (e.g. I don't give you the NetBIOS name
of my server and expect you to be able to connect to it)

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Jul 2002 10:50:53 -0400

> Yup. We run a network with more than 80K hosts, day in and day out.

and how heterogeneous is it?
 
> WINS. 

they do have the skill. the proper way to maintain NIS host maps is to turn them 
off, because they just get in the way.  sane admins do not try to make their 
lives more complex than they need to be.

> Well written applications need not exhibit any of these problems.

you're missing the point, which is this: when you overload interfaces to
try to do things that they weren't designed to do, you break apps that
use those interface.  you're changing the API (often poorly) without
changing the apps that were designed to use the old API. 
 
> to avoid changes to TCP :)

sockets is a bit klunky, but it works fairly well.  the worst problem I
have with sockets is that there are some performance implications associated
with forcing the programmer to separate (e.g.) connect() and write() and
sending an EOF, and it's hard to extend that interface to do some things 
I want to do with TCP.

but (and this is just a guess at what you might be thinking) it is NOT
a bug that sockets works with IP addresses rather than DNS names.

> loaded web servers doesn't qualify, huh?

not necessarily.  how heterogeneous is it?  how much control do you
have over your users and their machines? 

> Yet that is exactly what RFC 1536 did, for example, and the world didn't

1536 didn't try to change semantics of DNS RRs.

Keith

---

From: Tim Jansen <[email-masked]>
Date: Tue, 23 Jul 2002 19:40:22 +0200

> service usage step, I want to communicate.

Not always. If you have a large number of devices, then you may want to choose 
a capability. But in your home network, where you have an Epson and a Lexmark 
printer, you want to select "the Lexmark" or "the Epson". So here DNS-SD 
works as intended.

> laptops linked into the main conference network. I have some files
> available for rsync, and he has a client. How does get the file?
> I can tell him what I call my machine ("leon"), and that the file is
> available, but that won't help without some kind of name lookup (which
> could be DNS).

The most natural way would be to have an instant messenger that can discover 
persons in the local network, so you would search for my name. Fortunately 
this is quite easy with SIMPLE as IM protocol because it can work 
peer-to-peer, you just need to discover the other person's URL using a 
service discovery protocol.

> DNS-SD reporting, or whatever?

http://www.isi.edu/in-notes/iana/assignments/svrloc-templates/printer.2.0.en

bye...

---

From: Tim Jansen <[email-masked]>
Date: Tue, 23 Jul 2002 19:42:56 +0200

> midcom group is making a royal mess trying to figure out how to make it

Actually it does work as most implementations already support STUN:
http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt

bye...

---

From: Joshua Graessley <[email-masked]>
Date: Tue, 23 Jul 2002 18:38:08 -0700

On Monday, July 22, 2002, at 10:39  PM, Keith Moore wrote:

> across

Ok, so just to try and keep up, you've moved from service discovery to 
name resolution?

It is true that gateway.local. wouldn't mean the same thing to two 
different people on different networks in much the same way that 
10.0.1.12 would would not mean the same thing. Does that mean that 
names that only have a local scope would not be useful? Addresses 
without global scope are very useful and application don't necessarily 
have to be rewritten to make use of them. Throw something nasty like 
NAT in to the picture and things get pretty hairy, but that's a 
separate problem.

> of saying "there are multiple hosts claiming this name, choose

Name collisions can be detected and avoided. This is not a difficult 
problem to solve.

> essentially all high-performance computing today is cluster computing.

All of the examples you have just given do not work with NAT. Brad 
Hards asked if there were any applications that would work with NAT but 
not work with link local addresses.

>>> didn't start your query with a name doesn't mean you don't care 
>>> about the
>>> name.
>> available
>> available, but

I think two different problems are being confused here. Are you arguing 
about name-to-address translation or service discovery? These are two 
totally different things.

Name-to-address resolution is pretty straightforward. Given a name, 
what's the address. The example earlier of gateway.linklocal. to some 
address is name-to-address resolution, not service discovery.

Service discovery is much more involved. A common example of service 
discovery is locating all of the printers on the local link. Most 
service discovery protocols need two phases. The first phase is to 
discovery the actual services on the wire. The second phase is to 
resolve a service name in to the necessary information to make use of 
the service. Going back to the printer samples, we would want to get a 
list of all print services for the first phase. Once a print service 
has been picked, the print service would need to be resolved to the 
specific information required to actually print such as the ip address, 
port number, and perhaps print queue name. By separating the service 
name from the ip address/port number, you can cache service names and 
look them up just before communicating with a service, allowing the 
service to transparently change to a different host or use a different 
address.

Part of every service discovery solution is the ability to detect other 
services with the same name when registering to avoid collisions. This 
is not an impossible problem to solve.

>>>> that

Zero configuration doesn't mean zero options. Zero configuration means 
it can work out of the box without being configured. It makes sense to 
have a printer using zeroconf allow for someone to change settings such 
as the advertised printer name. zeroconf is especially important when 
you first get the printer out of the box and do not have any way to 
interact with it. With zeroconf, you could potentially hook up the 
ethernet jack, use service discovery to find the default name the 
printer has choosen, connect to it, and then set some options such as 
the name it will advertise print services under and perhaps an IP 
address if it would be useful for the printer to be globally accessible.

> it to start managing that network to some degree.

What do you mean by a zeroconf network? Devices supporting zeroconf can 
be plugged in to a network and interact with other devices supporting 
zeroconf without additional configuration. This doesn't mean that every 
device on the network is unconfigured. There is no reason a device 
without a globally accessible address should not be able to communicate 
with a device with a linklocal address if both devices are on the same 
local link. Devices that are not configured with a global address will 
be limited to communicating only with other devices on the local link.

> name lookup is a good solution in general to the problem of finding

No argument here, name-to-address resolution is not service discovery. 
That is not to say that DNS formatted packets cannot be used for 
service discovery.

> and it would be nice if the same mechanism could  work for both cases.

Yes, and SLP so far has failed. Perhaps SLPv2 will have better success. 
I haven't read the draft so I'm not sure if the flaws have been 
addressed. I'll give it a read tonight.

> are probably *not* stable then you need a more versatile service.

No, name lookup is not good enough, anywhere. We need service discovery 
for managed and unmanaged networks alike.

> awhile, though I don't think it's been heavily targeted at SLP.

Find out what the customers you're targeting support. Is there support 
for using SLP to find printers built in to common operating systems out 
there? What about DNS-SD? Can you cover enough of your customers by 
implementing one or the other? If both will work, which one is simpler? 
Which one will give your customers a better user experience?

-josh

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Jul 2002 22:44:46 -0400

> names that only have a local scope would not be useful? 

locally-scoped names are problematic, because they can escape outside
the context in which they are valid.  but we've always had things
like 'localhost'.  many sites also have names for local machines
that aren't advertised to the outside world.  there's an semi-formal
(I think it's documented in some RFC) convention that any name not 
containing a '.' is a local name, and that any name containing a '.' 
is fully-qualified and therefore globally scoped.  many apps have
special-case handling for local names, but many apps also assume that
local names can be changed to FQDNs by appending some string as a suffix.

> Addresses 
> have to be rewritten to make use of them. 

ambiguous addresses are also problematic, for much the same reason that
ambiguous names are problematic.   some apps don't need to be rewritten
to make use of them.  for other apps it's extremely difficult to cope
with them at all.

> Throw something nasty like 

well, if you draw a Venn diagram with circles for the problems caused
by NATs, the problems caused by ambiguous addresses, the problems
caused by ambiguous names, and the problems caused by unstable addresses,
you find that each category causes its unique problems but there's
also a lot of overlap between the categories.

(and then the proponents of one of these use the existence of
the others to justify their doing further damage...)

> Name collisions can be detected and avoided. This is not a difficult 

please explain.  if an app on an ad hoc network is calling gethostbyname() 
to look for a host named "foo" and there are two such hosts, what is
returned?    neither an error indication nor the address of either host
seems reasonable.

> not work with link local addresses.

right, I misread his question.  but the answer is yes - there are apps
that work with NAT but don't work with LL addresses.  for instance,
any app that needs to keep connections open for a long time will be
less reliable on a v4 LL network because of the potential for address 
collisions.  also the topological scope of private addresses used by 
NATs is often considerably larger than a single link, so apps using
private addresses behind a NAT will work when those apps will fail
when trying to use LLs.  this is particularly true for apps that
do address referrals - you could run a cluster computing environment
behind a NAT and it would work fine if all of the nodes were behind
the NAT, but it would fail if LL addresses were used and different nodes 
were on different physical links (as is often the case in dedicated 
clusters).  apps on a host with multiple interfaces will fail more often 
if LL addresses are used on more than one of those interfaces, but NATs 
don't impose this problem.  etc.  

> totally different things.

I'm comparing the effictiveness of the two approaches at solving the
problem where users (via their applications) are trying to find resources 
on an ad hoc network.

> as the advertised printer name. 

yes it does.  however it doesn't necessarily make sense to insist 
(on an ad hoc network) that the device ONLY be able to advertise a name,
and to impose the constraint that the name is expected to be unique.

nor does it necessarily make sense for the effectivness of users at
being able to find resources on an ad hoc network to be dependent 
on someone explicitly configuring those resources to have names
other than their defaults.

> zeroconf is especially important when 

fine, but last I knew zeroconf was being touted as far more than 
a mechanism for initial setup of devices.  

> That is not to say that DNS formatted packets cannot be used for 

you can make any request-response protocol into an RPC if you try hard
enough.  but why try to overload DNS when doing so breaks assumptions
in both DNS and applications?

> addressed. I'll give it a read tonight.

"so far" zeroconf has failed too.   

I would not recommend to adopt SLP wholesale.  But at least they've tried 
to solve the problem of finding resources on a local network without having 
to know their names - which seems like a lot saner approach to finding 
resources on an ad hoc network than to expect people to know the names of 
unfamiliar devices.  It's worth looking at it as a possible starting point.

> for managed and unmanaged networks alike.

I won't argue against that at all.  By "good enough" I meant that people
have so far been able to muddle through.  I just think it's far more 
difficult to muddle through with just names on an ad hoc network 
than to muddle through with names on a stable, managed network that you
use frequently.

> Find out what the customers you're targeting support. 

no, figure out what actually solves your customers' problems with
using LL networks.

Keith

---

From: Brad Hards <[email-masked]>
Date: Wed, 24 Jul 2002 13:18:34 +1000

> returned?    neither an error indication nor the address of either host
gethostbyname_zconf() or equivalent has to return a pointer to an array
of addresses. Otherwise name lookup in a zeroconf network can't work.
Doesn't matter what the backend implementation is (DNS, service discovery 
by name assertion, whatever) - name overlap is an instrinsic property of networks
that don't have central administration.

> don't impose this problem.  etc.
These applications will also fail when DHCP leases expire (think wireless,
roaming, etc).
I think that the cluster argument is bogus, since computing cluster is not a viable
candidate for zeroconf.

> and to impose the constraint that the name is expected to be unique.
I don't think that anyone is making this argument. However names are
important, and people can reasonably expect to use them.

> other than their defaults.
I don't think anyone is making this argument either. But if I do 
choose to change the name (or some other attribute), I'd expect to be
able to distinguish it from other resources.

Brad

---

From: Keith Moore <[email-masked]>
Date: Tue, 23 Jul 2002 23:54:51 -0400

> of addresses. Otherwise name lookup in a zeroconf network can't work.

if you don't try to overload the existing DNS APIs then  I have far fewer
problems with any of this stuff.  though why you would want to reuse any
of DNS for this very different purpose is beyond me.

> that don't have central administration.

agreed.

> These applications will also fail when DHCP leases expire (think wireless,

a DHCP server that fails to renew leases without a good reason is broken,
and DHCP is a really lousy mechanism for mobility.  please don't use one 
kind of brokenness to justify another.
 
> I think that the cluster argument is bogus, since computing cluster is not a viable

are you saying that such apps will never see or have to deal with LL addresses,
and they'll never see or have to deal with ambiguous DNS names?  

from the last LL document it looked as if hosts were going to expose LL 
addresses to apps whether or not the apps could deal with them, and there
was strong objection to NOT exposing apps to such addresses.  unless they 
are taught to special-case LL addresses, apps will treat them as ordinary 
addresses, listening for connections on them, using them in referrals, etc., 
even though those addresses may be unsuitable for their purposes.

> important, and people can reasonably expect to use them.

names are indeed useful as long as you don't try to make them do too
many different things, and as long as you don't confuse one kind of
name for another.  it would certainly be useful to have the ability
to find a host on an ad hoc network by name.  but it would be bad
if these were confused with DNS names, because they don't have the
properties of DNS names.

> able to distinguish it from other resources.

including other resources with the same name that you've chosen? 

Keith

---

From: Brad Hards <[email-masked]>
Date: Wed, 24 Jul 2002 14:50:45 +1000

On Wed, 24 Jul 2002 13:54, Keith Moore wrote:
> > > please explain.  if an app on an ad hoc network is calling
> > > gethostbyname() to look for a host named "foo" and there are two such
> > > hosts, what is returned?    neither an error indication nor the address
> > > of either host seems reasonable.
> >
On a quick review of gethostbyname(), I note that it already returns a pointer
to an array (well **h_addr_list). Note also that gethostbyname() has no
DNS semantics - DNS is but an option.
Reference: Stevens, Unix Network Programming, pg 393.
If you are _really_ worried, the gethostbyname() could return h_addrtype
as somthing new, like AF_ZCONF.

> of DNS for this very different purpose is beyond me.
Running code. All we need now is the rough concensus part :-)

> > These applications will also fail when DHCP leases expire (think
> > wireless, roaming, etc).
>

It is the same kind of brokenness. Networks are now seriously dynamic
things, and assuming long term consistency between names and addresses
is a broken assumption.

What happens if the DHCP server falls over during the night and gets
replaced. Will all be the same tomorrow?

I had a researcher who insisted that zcip (http://zeroconf.sf.net) should be
able to generate random IPs. That was a firm requirement for privacy for
his application - there should be no fixed relationship between hardware
and IP. He was pulling the network interface down at random intervals
and getting another IP (based on the zeroconf linklocal approach)
to prevent long term tracking. If applications cannot cope, then it was
OK to fail (gracefully:).

> including other resources with the same name that you've chosen?
If it is distinct in any way, then I should be able to distinguish it.
Of course, it would be nicer if I could make the name unique, but that
cannot be made a valid assumption in an ad-hoc network.

Brad

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Jul 2002 01:18:28 -0400

> to an array (well **h_addr_list). 

yes, but the expectation is that those addresses are all from the same RRset,
and that they refer to the same host or service, not differnet hosts or services
with the same name.

> Note also that gethostbyname() has no

that's garbage.   programs expect gethostbyname() to provide access to DNS.
even if DNS is sometimes front-ended by other services like host files or
NIS, the reality is that programs break if they can't lookup DNS names with 
that interface or if the gethostbyname() call has significantly different
semantics than a DNS A lookup.

> as somthing new, like AF_ZCONF.

most applications do not bother to check.

> Running code. All we need now is the rough concensus part :-)

DNS certainly isn't running code for this application.  and just because
someone has implemented something doesn't mean it's a good idea to standardize it.

> things, and assuming long term consistency between names and addresses

perhaps.  but neither is it safe to asume that the name is more stably
bound to whatever you want to refer to than the address.  

networks are very dysfunctional these days.  that's not a good excuse for
making them even more dysfunctional.  

what we need to be doing is figuring out ways to make the network behave 
*more* consistently from one place to another, so that we'll increase the
market for new applications by giving them more places where they can
run - NOT adding even more reasons for the network to behave less consistently.

> replaced. Will all be the same tomorrow?

if your DHCP server can't survive the failure (i.e. if the new DHCP
server won't honor the old leases), then many of your apps will break.  
that's a bad design - the DHCP server is a critical component that
doesn't share fate with the endpoints.
 
> OK to fail (gracefully:).

IPv6 has privacy addresses, which are a similar idea.  but it's one thing
to make such addresses available to applications that have no need for stable  
addresses; quite another to insist that all apps should have to use these
things.  it's incredibly naive to think that apps don't need stable addresses.

Keith

---

From: Aidan Williams <[email-masked]>
Date: Wed, 24 Jul 2002 15:40:04 +1000

> result, you've just broken DNS.

"disaster" seems rather too strong a word.

Right now the DNS back end resolver at my ISP may have cached some
RR set associated with a FQDN.  Meanwhile, back at the authoritative
server, the RR set gets updated.  Oops..  now my backend resolver
has inconsistent data!

Does that mean the DNS is broken?  I don't think so -- it just means
that the DNS has a weak cache consistency model.

> you're stuck with whatever is in the cache of your local resolver.

What if the consistency with mDNS was "no worse" than the DNS today?
(ie if you based your caching on DNS TTLs)

> of my server and expect you to be able to connect to it)

Hmm.  So would you be happy with clearly identifiable locally
scoped names?  (e.g. some.thing.local.arpa for all names that
might refer to a non-global name)

-- 

regards
	aidan
____
:wq!

Sydney Network Research Lab             [email-masked]
Motorola Australian Research Centre          phone: +61 2 9666 0649
Locked Bag 5028, Botany NSW 1455              phax: +61 2 9666 0501
Australia                            http://marc.labs.mot.com/snrl/

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 23 Jul 2002 21:54:05 -0700 (PDT)

> of my server and expect you to be able to connect to it)

Type http://foo/ on a Windows system and look at the trace of what issues
from the machine. If the DNS queries do not return a result, you will then
see a NetBIOS name query. The nature of the query will depend on whether
there is a WINS server operating.

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Jul 2002 01:55:12 -0400

> "disaster" seems rather too strong a word.

well, it depends on how this is used.   if hosts start asserting names
for themselves on some networks via mDNS while the real DNS is returning 
different/conflicting information for that name, that's really bad.  

if random hosts start caching DNS informaiton and providing it through mDNS 
(even within the TTL of that information), and other hosts start trusting 
that information, that produces additional potential to propagate stale
DNS data, and to propagate modified DNS data (whether or not there
is any malice, there have certanly been DNS caches that subtly
modified the data that they propagated in a way that broke things)

right now the thing that keeps DNS as "honest"  as it is is that
there's a high probability of being able to contact an authoritative
DNS server for the zone you need.  

> that the DNS has a weak cache consistency model.

right - but now you're introducing additional caches, and each cache
is a potential source of error.
 
> What if the consistency with mDNS was "no worse" than the DNS today?

I'd want to see/do a lot more analysis before coming to a conclusion.

> might refer to a non-global name)

they might be "clearly" local to you and me, but not "clearly"
local to an application.  local dns-style names seem like the sort 
of thing you want to use very sparingly if at all - they're yet another 
thing that reduces location-independence and the ability of apps to 
run in any part of the internet. 

Keith

---

From: Brad Hards <[email-masked]>
Date: Wed, 24 Jul 2002 15:58:34 +1000

On Wed, 24 Jul 2002 15:18, Keith Moore wrote:
> > On a quick review of gethostbyname(), I note that it already returns a
> > pointer to an array (well **h_addr_list).
>
> yes, but the expectation is that those addresses are all from the same
> RRset, and that they refer to the same host or service, not differnet hosts
> or services with the same name.
I cannot accept the RRset requirement (because of the DNS connotations),
 although I would concede that the main reason for the options with
 AF_INET is to support a single logical entity
(not two distinct, probably unrelated machines).

> that's garbage.   programs expect gethostbyname() to provide access to DNS.
That is a bogus assumption. DNS did not get created at the birth of Arpanet,
and people should not code background implementation into their apps.
gethostbyname() does and should allow you to get the IP addresses
for a given name. 

> semantics than a DNS A lookup.
And that is a bug.

From a local man page (on Linux)
<quote>
       Glibc2 also has a

       struct hostent *gethostbyname2(const char *name, int af);

       that  works  like  gethostbyname(),  but  permits  to specify the address family to which the
       address must belong.

       The Austin draft marks gethostbyaddr() and gethostbyname() legacy, and introduces

       struct hostent *getipnodebyaddr (const void *restrict addr,
         socklen_t len, int type, int *restrict error_num);

       struct hostent *getipnodebyname (const char *name,
         int type, int flags, int *error_num);
</quote>

AF_ZCONF isn't a bad idea to prevent well coded legacy apps from getting
answers they didn't expect.

> most applications do not bother to check.
That is a bug too.

DNS already provides all kinds of lookups that are only locally sensible.
Certainly people shouldn't pollute the Internet DNS system with those
names, but there is little difference to mycompany.west and mycompany.east
vs mymachine.linklocal and myprinter.linklocal.

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Jul 2002 02:19:26 -0400

> gethostbyname() does and should allow you to get the IP addresses

gethostbyname predates DNS - it was originally used to look up names in /etc/hosts.
but gethostbyname() got extended to do DNS lookups in the early 1980s, and 
ever since the mid-to-late 1980s apps have expected that if they feed something
that looks like a DNS name (generally meaning that it has one or more dots) to 
gethostbyname() then it will result in the address records associated with that 
name in DNS being returned.

so despite its origins gethostbyname() is now the de facto standard interface
for querying DNS A records.  there are other, better interfaces, but gethostbyname
is the most portable.

> > semantics than a DNS A lookup.

no, that's a feature.  trying to change functionality that applications have
reasonably expected for 15 years is a bug.

> answers they didn't expect.

if you are talking about gethostbyname2(), then say gethostbyname2.
though I still think it's a bit brain-dead to have multiple addresses 
returned from AF_INET and AF_INET6 queries indicate multiple addresses
for the same host or service, and to have multiple addresses returned
from AF_ZCONF (do you want different versions for v4 and v6?) mean
different hosts or services with the same name.

overloading an query interface to do something completely different 
accomplishes nothing useful and is just a good way to confuse people.

> > most applications do not bother to check.

so it's a bug.  it will break lots of apps to tickle this bug, and there's
no good reason to do so.

> DNS already provides all kinds of lookups that are only locally sensible.

yes, people misuse DNS.  but then they're responsible for whatever problems
they cause, and they can presumably fix whatever they break or deal with
the consequences.  

if we encourage people to use DNS in a stupid way, then the damage is much
more widespread, and it's very hard for us to undo the damage.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 23 Jul 2002 22:59:25 -0700 (PDT)

> I think my point still holds - just because http://foo/ might produce some
> results for you doesn't mean it will produce the same results for me.

That is also true for the handling of "foo" by DNS resolvers -- depending
on the searchlist, this may resolve to different FQDNs. So this locality
has always existed.

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Jul 2002 03:05:41 -0400

> Do many applications really make use of this?

not many do so explicitly.  I have heard of email MTAs that do this
under some conditions because a significant percentage of email bounces 
are due to DNS misconfiguration (like updating a zone without changing
the serial #).

but what I was getting at is that being able to access the DNS
servers directly makes it at least possible that for whatever reason, 
inconsistencies between caches and authoritative servers will be noticed -
not necessarily by programs, but by humans that notice inconsistent
behavior from one place to another.
 
> Potentially.  And so is every new DNS back-end resolver implementation.
> If however it were done right, it might just work OK.

it might.  though think DNS-SD needs considerably more justification 
than as an ad hoc cache to real DNS.
 
> I see the advantage of having a private namespace is that you
> can keep the global stuff and the non-global stuff separate.
> No site-locals/private-addrs returned along with global addrs.

if you also have a separate API for the two namespaces, this has the 
advantage that apps that can't deal with local stuff won't see it.

> An application (such as a web browser) would happily work with
> either, being less confused, because the user (maybe via a DNS
> search path) explicity used a private DNS domain.

that's assuming that users understand not only the subtle differences 
between a DNS name and a private name, but also which kinds of names
work with which apps.   the app isn't going to get any less confused
unless it has special-case code to deal with private names.
(for instance, don't expect the remote web cache to do useful things
with URIs containing private names...)

> Realistically, people don't want *every* host name to be a globally
> visible and unique one.  I for one think that is unscalable.
> A domain name per house, per car, per bicycle, per human, .. ??

no I don't think we want every name  to be globally unique, but 
I think we want to be able to know when we're using a unique name.
also, we expect predictable behavior from computer programs - but
when we give them ambiguous names for things the results become 
less predictable.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Jul 2002 02:36:27 -0400

I think my point still holds - just because http://foo/ might produce some
results for you doesn't mean it will produce the same results for me.  
the fact that windows tries to do a netbios query is arguably a bug - because
http URLs with two slashes are supposed to have a DNS name or IP address
- not a netbios name.

fortunately, many apps know that "foo" is not a legal DNS name, and that
it cannot therefore be expected to be globally unique.

---

From: Aidan Williams <[email-masked]>
Date: Wed, 24 Jul 2002 16:43:58 +1000

I would expect they would just call gethostbyname() and get
whatever the local back-end resolver happened to pluck out
of its cache.

> run in any part of the internet. 

(actually, I meant "non-global *address*" rather than "name")

Perhaps -- but you appear to be moving to a different argument
just at the point where it gets interesting to me.

-- 

regards
	aidan
____
:wq!

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Jul 2002 03:12:13 -0400

> Please explain how this can happen. mDNS is only used on networks where
> no DNS server is available.

a) apps don't know anything about network topology boundaries.
   there may be some app components that can access DNS which are
   communicating with other app components that can only access mDNS.

b) even on the same host, or for hosts on the same link, DNS accessibility 
   (and presuambly mDNS accessibility) may vary over time - so 
   with just a slight delay different components can have different views
   of the meaning of a DNS name - one from DNS, another from mDNS.

   of course the same could happen if different hosts contacted different
   DNS servers for a zone, but at least the servers are under control of
   that zone.

> > (even within the TTL of that information),
> 
> Again, please explain how this can happen. The mDNS and DNS caches are
> required to be separate, and hosts only respond to queries for which they
> are authoritative.

I must have misunderstood an earlier message then, I thought it was being
proposed that mDNS could be used to return data for a DNS name for which 
the host returning the data would not be an authoritiative source of that data.
 
> You speak as though the use of local names were something new. It isn't.
> This functionality has been present in shipping products for 10 years now,
> and has not produced the "disaster" you speak of.
 
widely shipping products have been taking queries for FQDNs and producing 
results that are inconsistent with DNS lookups?  which ones?

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Jul 2002 03:13:00 -0400

> on the searchlist, this may resolve to different FQDNs. So this locality

yes it has.  and the fact remains that http://foo/ is not valid.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 24 Jul 2002 04:30:06 -0700 (PDT)

>    communicating with other app components that can only access mDNS.

There's a distinction between having a working DNS server, and being
configured with a DNS server. mDNS is only used if no DNS server is
configured -- not just because the DNS server is down, with the possible
exception of unqualified names (e.g. "foo"). With IPv4, the
reason to be without a DNS server is typically because there is no DHCP
server either. With IPv6, the configuration story is not clear yet.

Note that it is already possible for one host communicating with another
to not have a DNS server configured, while the other does. This means, for
example, that one side may not be able to do a reverse lookup for the
other side in the conversation.

I'd be curious to understand how mDNS changes the failure modes from not
having a DNS server at all, given the above.

>    of the meaning of a DNS name - one from DNS, another from mDNS.

As noted above, mDNS usage is not determined by DNS accessability, but by
DNS *configuration*.

> the host returning the data would not be an authoritiative source of that data.

That is not what the DNSEXT version of the mDNS spec says (not sure
about the Apple version). Take a look:

http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-10.txt

(draft -11 will be online later this week).

> results that are inconsistent with DNS lookups?  which ones?

I think it's fair to say that every shipping operating system allows
access to non-DNS naming mechanisms (/etc/hosts, NIS, NetBIOS, AppleTalk,
etc.) from resolver API calls.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 23 Jul 2002 22:55:19 -0700 (PDT)

> modified the data that they propagated in a way that broke things)

Again, please explain how this can happen, given that the mDNS and DNS
caches are distinct. One cannot poison the other.

> I'd want to see/do a lot more analysis before coming to a conclusion.

If you are interested in this, you might post the question on the DNSEXT
list where discussion of DNS (and mDNS) occurs.

---

From: Keith Moore <[email-masked]>
Date: Wed, 24 Jul 2002 09:39:03 -0400

> other side in the conversation.

or that one side may not be able to use DNS names in referrals to the 
other side.    (I agree that this is already possible)

> having a DNS server at all, given the above.

I suppose it is similar to the situation where one host uses DNS
and another uses /etc/hosts with missing or stale information.
 
> As noted above, mDNS usage is not determined by DNS accessability, but by

okay.  though it's easy to imagine a configuration option that says
"try DNS first and if that fails try mDNS"  (much as many hosts now
have one that says "try DNS first and if that fails try /etc/hosts"
( or nis, or whatever ).  for nomadic hosts it's nice to avoid having
to explicitly change configuration.

> etc.) from resolver API calls.

okay, I see what you're saying.  and of course they have to have some
non-DNS mechanism for the very case where the host is operating in an
isolated network and cannot use DNS.  

at the same time, if you don't configure your host so that gethostbyname() 
calls DNS (directly or through an intermediary) then a lot of applications 
just don't work - more and more apps expect direct access to DNS.

Keith