Subject: [Fwd: Re: Requirements for Service Discovery]

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 09 Aug 2002 09:55:00 -0700

Hello Stuart,

I've been passively monitoring the discussion, and it
seems to me that people are taking technical positions
based on preconceptions about SLP that aren't necessary.
My information about SLP is based on my involvement from
some years ago, but I think it is still relevant.

1) It should be possible to write a SLP service
   agent VERY cheaply.  The DA is more complicated,
   but not needed for zeroconf.

2) The harder part would be to make all aspects of the
   service operation user-configurable, but that isn't
   so hard anyway because the schema are machine parsable
   (on purpose) so one could even write a general purpose
   SLP configurator that would work for all devices.
   At least that was the original intention.  I don't
   know how that has carried forward.

3) If SLP isn't simple enough, then it would have been
   very nice for the people who wanted simplicity to
   say so in the working group meeting.  I was among
   those people, and I thought it ended up "pretty
   simple", but I might have been wrong.  Plus, it can
   still be fixed, just like with everything that
   hasn't taken the universe by storm yet.

4) I get the feeling that some people who are not
   enthusiastic about SLP take the position that
   "if it's not DNS, it's broken".  And yet DNS experts
   say that we shouldn't be overloading DNS.  Doesn't
   that mean we shouldn't be adding stuff to DNS for
   which it wasn't designed?

5) To require that the user be the chooser interactively,
   completely disenfranchises non-interactive applications
   and the huge world of embedded computing which should
   be an integral part of zeroconf or else somebody didn't
   tell me that humans have to always be part of the loop.

6) SLP was specifically designed so that the same
   equipment could be moved between home and office
   without reconfiguration, or so that a small office
   could grow into a large office without configuration.
   In other words, it offers a smooth upgrade path without
   requirement for reconfiguring individual devices.
   That does NOT mean that a zeroconf user has to be as
   smart as a network administrator.  Instead, it means
   that SLP was intended to be suitable for both, without
   burdening the users.  This prevents the horrid scenario
   of having to decide whether to build and stock an "office"
   printer or a "home" printer -- and prevents the problem
   of having people having to figure out which variety they
   want to buy.

Your further comments will be appreciated.

Regards,
Charlie P.

---

From: Tim Jansen <[email-masked]>
Date: Fri, 9 Aug 2002 21:21:40 +0200

>    but not needed for zeroconf.

And, BTW, you can get a free and portable implementation with a BSD-like 
license from www.openslp.org. So in most cases you don't even have to 
implement it yourself (unless your device's OS has a API that is very 
different from Posix or Win32). 

bye...

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 09 Aug 2002 15:35:17 -0400

> some years ago, but I think it is still relevant.

SLP is a good idea. But it has yet to see an implementation that isn't too
hard or too obtuse to set up. There are a lot of good ideas that die when
you actually have to set them up. It's also trying to do too much, from what
I've seen. There is a temptation to make things be able to handle every
single situation they might encounter. This is understandable, yet quite
bad. It ends up complicating things into unusabiliity, and they get dumped
in the wastebin.

As an historical reference, read up on the history of the F-111 aircraft.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 09 Aug 2002 13:38:19 -0700

Hello John,

"John C. Welch" wrote:

> you actually have to set them up.

The notes I saw indicated that you were assigning SLP to the wastebin.
Would you prefer an implementation that's simple to use, or would
you prefer to trash SLP and do something else?

Whatever else you choose, you don't have any automatic guarantee
that it will be implemented in a way that's easy to use.   Maybe
it would be better to lobby for SLP implementations that are very
easy to use.

I'm suggesting that SLP as a protocol was designed to offer ease
of use and flexibility across a range of deployment possibilities,
specifically including zeroconf.  People who want to sell other
products will contend otherwise.

>                      It's also trying to do too much, from what

The desirable protocol would allow very simple implementations to work
for very simple scenarios, coexisting with other more fully featured
implementations (i.e., without conflicts that limit usability).

> As an historical reference, read up on the history of the F-111 aircraft.

I get the point (F-111  :=   "bad stuff"), presumably because of
the creeping feature creature.  That's not relevant to this discussion
unless there are ways to pull a string and watch very simple F-111's
fall out.

Regards,
Charlie P.

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 09 Aug 2002 17:00:27 -0400

> you prefer to trash SLP and do something else?

I would have preferred that the problems of implementation and maintenance
of SLP been given equal weight along with the capabilities. From what I have
seen, that wasn't the case.

> it would be better to lobby for SLP implementations that are very

*In general*, the simpler something is, the more reliable it is, and the
easier it is to implement. It is much harder to take something complex and
make it simple. 

> products will contend otherwise.

I'm not selling anything. If I had seen any implementation of SLP that was
easy to install, easy to configure, and worked well across platforms, I'd be
using it everywhere. But I haven't, and I'm not.

> implementations (i.e., without conflicts that limit usability).

And a simple implementation of SLP that I can install today across five
platforms exists where?

> unless there are ways to pull a string and watch very simple F-111's

No, actually. The F-111 was designed to be the one size fits all aircraft.
Robert McNamara and a lot of other very smart people with many smart
initials after their names decided to build one plane that could be all
things to all people. Carrier landings, air superiority, ground attack,
medium range bombing, strategic bombing, making pancakes, washing
dishes...it ended up being a medium range bomber, and an electronic
countermeasures platform, and is generally considered one of the best
examples of what happens when you try to make one thing handle all
conditions. So, in the end, they *did* pull a string, and got a simple F-111
that did one or two things very well.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: John Schnizlein <[email-masked]>
Date: Fri, 09 Aug 2002 17:39:01 -0400

If you thought the F-111 was bad for that reason, 
you must really dislike the Joint Strike Fighter!  
[late Friday - way off topic]

At 05:00 PM 8/9/2002, John C. Welch wrote:

>> the creeping feature creature.  
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 09 Aug 2002 15:30:50 -0700

Hello again John,

Gotta go home soon, but ...

> seen, that wasn't the case.

But, from my perspective when I was involved with some of the
protocol specification, it was a strong consideration.  We tried
to work through a lot of scenarios, especially how an installation
might transition gracefully from "scopeless" to multiple scopes.
I thought we had done a passable job of it.

Regarding the implementation, I guess there are some freeware
things, but I have not kept up with it and have to defer to
others on this point.

> easier it is to implement. It is much harder to take something complex and

Exactly.  Which is why it should be possible to take SLP and
implement a restricted, but simple, subset of it for some service
agents and some user agents where simplicity is the priority.
These simpler implementations are supposed to still be able
to be responsible citizens on the same networks that also
support more complicated SLP implementations, and should still
get the service resolutions they need.

For instance, I believe it is the case that a user agent can
request a printer without any attributes, and it will get a
list of printers.  That information could easily be supplied
to an interactive "chooser" program.

A service agent could be provided with hardcoded attributes
(avoiding configuration requirements) but still by protocol
is quite able to answer user requests.

If you want simplicity, SLP is supposed to be able to provide it.

> And a simple implementation of SLP that I can install today across five

Here, I am totally unable to be of assistance.  I did see that
someone else has something to offer, but maybe it doesn't run
on five platforms.

I should, however, point out the tendency to see the grass as greener
on the other side of the hill.  If SLP doesn't run on 5 platforms,
then you can easily suggest and imagine that XXXFOOprotocol would
of course in the future run on 5 platforms and besides that be
better and more scalable and cheaper than SLP.  By the time the
future rolls around, maybe XXXFOOprotocol would have a few warts
that make it smell bad, and SLP would run on 7 platforms.

You just don't know until you have the results.  Just like you
just don't know that XXXFOOprotocol is better than SLP until
you see the specs.  There are specs on how to instrument DNS
to do part of the job.  It remains to be seen whether those are
better, but for reasons to be skeptical I refer you to my previous
note.

> things to all people.

But that means that every particular plane has to have all the features.
Not every implementation of SLP has to have all the optional features
that are defined in the protocol specification document.  This is
exactly because quite a few people (including myself) did not want
to mandate implementation of all those features.  As I remember, even
the scoping is optional, as would be appropriate for zeroconf
deployments.

>                        Carrier landings, air superiority, ground attack,

I am sure this misperception is why you are disappointed by SLP,
but the fact remains that SLP implementations do not have to
implement all the complex features.  My understanding of the
desirable result is that simple things are simple, complex things
are possible for those units incorporating the desired functionality,
and that all of them should be able to gainfully coexist in a
mutually constructive network environment.

This is better than requiring the units to implement multiple
independent protocols to do almost the same thing.

Regards,
Charlie P.

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 09 Aug 2002 18:42:31 -0400

> you must really dislike the Joint Strike Fighter!

Actually, they had a good idea, but the implementation was garbage, and the
entire concept of commonality got a really bad name because of that bad
implementation.

The JSF seems to be a much better implementation, but then, there are a lot
of differences between the different implementations of the JSF, which shows
flexibility and foresight.

This is something that I see time and time again in the computer field.
Brilliant idea, but the implementations are so execrably bad that the entire
idea is discredited, and worse yet, the entire concept gets a bad name even
though there is a lot of good in the concept.

example:  The Network Computer. It was and is a good idea for business. But
because some nimrod CEO, <cough>Larry Ellison</cough> through out a
idiotically low, (for the time) price, and no one gave a thought to
infrastructure costs, the entire concept got a really bad name.

example: The Newton. Fantastic idea in so many ways. The initial
implementations were so bad that we are now stuck with *graffiti* which
forces you to write in a different language in an unnatural fashion with a
bit of plastic that a two year old would find small.

You can have the greatest answer to something the world will ever see, and f
the implementations are bad, it won't be used at all.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 09 Aug 2002 18:53:55 -0400

> things, but I have not kept up with it and have to defer to

I've not seen much, and the information is not the easiest thing in the
world to find. (one rule of thumb...if it doesn't have an O'Reilly book, IT
people tend not to want to use it)

> get the service resolutions they need.

But now you're talking about what will become two different things...SLP and
liteSLP...and how do you coordinate one with the other when you don't have
control over which is which? If you go with an implementation that needs
item 'foo', and then you have to integrate something that doesn't, and never
will include item foo...

> If you want simplicity, SLP is supposed to be able to provide it.

That may be...but configuring SLP is still voodoo, and not that many
networking setups use it at all.

> that make it smell bad, and SLP would run on 7 platforms.

DNS runs on everything right now.

> the scoping is optional, as would be appropriate for zeroconf

But when you take something with X number of features, if X is a large
number, then you quickly get into implementation incompatibilities, and the
whole thing goes straight in the toilet. This almost happened with Kerberos.

> mutually constructive network environment.

But then different simple liteSLP implementations end up not working with
each other.

> independent protocols to do almost the same thing.

Well, that works very well...you don't use one single protocol for all your
networking use. You use multiple protocols, because each one does some
things better than others.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 09 Aug 2002 16:08:34 -0700

> item 'foo', and then you have to integrate something that doesn't, and never

Not.  The implementations that implement optional features still
have to be able to interact with implementations that do not
implement those features, or else your protocol design is
broken.  Furthermore, negotiation should not be necessary.

> networking setups use it at all.

It should be the case the SLP can be used without configuration.

> DNS runs on everything right now.

Cool!  No problem! ... but what about configuring the records?
What about making sure that equipments agree on the format of
the data?  Maybe there are some other specification documents?
Doesn't matter about administration?  What about those cool
user interface programs for inserting records when you plug
the equipment in?

I would say that your answer was far from satisfactory, and wasn't
relevant to my example...

> But then different simple liteSLP implementations end up not working with

Not if they follow protocol.

> things better than others.

This is way too glib.  Surely I didn't suggest using a single network
protocol for all uses.  I meant to suggest that having two
protocols for managing service discovery means that implementations
have to have both of them, and then either try them in parallel,
or serialize, or whatever -- plus the user has to be twice as
smart about configuration for protocols that require configuration.

That's it for me!

Regards,
Charlie P.

---

From: Joshua Graessley <[email-masked]>
Date: Fri, 9 Aug 2002 17:56:11 -0700

> broken.  Furthermore, negotiation should not be necessary.

But if the protocol isn't particularly useful without an optional 
feature, then the protocol is broken. The name property is an optional 
feature of SLP, right? If you want to store a service name to resolve 
later in case the IP address of a service changes, it can not be done 
for services that do not support the name property.

-josh

---

From: "John C. Welch" <[email-masked]>
Date: Sat, 10 Aug 2002 00:48:09 -0400

> broken.  Furthermore, negotiation should not be necessary.

Um...I can almost guarantee this will happen...it already has...Microsoft
and Kerberos, Cisco wireless base stations. If you give someone a way to
lock you into their implementation of any standard, they will try to do just
that more often than not.

> Cool!  No problem! ... but what about configuring the records?

Only if you want more than link local. What about configuring different SLP
zones, DAs etc.?

> user interface programs for inserting records when you plug

What about getting people to use SLP at all beyond the limited Apple
implementation, and some HP printers? Where are the books on setting up SLP,
understanding the data formats? What about getting stuff that doesn't use
SLP at all to be advertised along with SLP - enabled apps?

> Not if they follow protocol.

As I learned in basic training..."If ifs and buts were fruits and nuts,
every day would be Christmas". I'm too much of a cynic to buy that a MS or a
Cisco won't pervert a protocol with as much wiggle room as SLP. In MS's
case, on the Windows side at least, that's a part of the mission statement
almost.

> smart about configuration for protocols that require configuration.

And having one overly engineered one almost guarantees that vendors will try
to lock you into their version of it. There's too much money to be made by
doing that to think otherwise.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: Tim Jansen <[email-masked]>
Date: Sat, 10 Aug 2002 12:59:02 +0200

> Only if you want more than link local. What about configuring different SLP

I do not know any other implementations, but OpenSLP is very easy to install 
and works on Linux, BSD, Solaris, Tru64, HPUX, UnixWare and Win32, according 
to the FAQ. In a DA-less network, you just install it (via RPM, for example), 
and it work. Apps that use it should register their services automatically. 
If you need a DA, just edit /etc/slp.conf and set net.slp.isDA = true. Then 
your slp daemon is also a DA. If you need scopes, edit the variable 
net.slp.useScopes. Other implementations should be similar, as the config 
file format is specified in RFC 2614.
You can find the documentation here:
http://www.openslp.org/doc/html/UsersGuide/index.html

bye...

---

From: Robert Elz <[email-masked]>
Date: Sat, 10 Aug 2002 20:30:18 +0700

Date:        Fri, 09 Aug 2002 15:35:17 -0400
    From:        "John C. Welch" <[email-masked]>
    Message-ID:  <[email-masked]>

  | SLP is a good idea. But it has yet to see an implementation that isn't too
  | hard or too obtuse to set up.

Then write one.   That will either produce what's lacking, or provide
some input into what might need to be changed.

  | There are a lot of good ideas that die when
  | you actually have to set them up.

Certainly true.   But "no-one has done this yet, so it must be a bad
idea" doesn't follow.

  | It's also trying to do too much, from what I've seen.

It does more than some people need, and less that what others need.
There's a good chance that puts it about where it ought to be (note:
I had nothing at all to do with SLP when it was being defined, I just
ignored it as "someone else's problem", but having looked at what came
out of that effort, it looks to me to be about right).

  | There is a temptation to make things be able to handle every
  | single situation they might encounter.

There can be, SLP certainly doesn't do that.

  | As an historical reference, read up on the history of the F-111 aircraft.

I know this has already beaten to death, as irrelevant side point, but
Aust actually bought a bunch of those 20-30 years ago, when the US couldn't
figure out what to do with them.   At the time, the huge cost, and buying
cast off US planes that seemed to be wanted by no-one generated lots of
opposition.   Those planes are just being (about to be?) retired now/soon.
Last I heard (this isn't something I follow...) the one big problem was that
there was simply nothing available which could even come close to being an
adequate replacement.   For the US, where having a whole bunch of specialised
planes is possible, and makes sense, the F-111 might have been not as
wonderful as hoped, not being perfect at anything.   For Aust, where a couple
of dozen top class planes (or something, I have no idea) is all the air
force get to own (that is not counting trainers, cargo planes, ...) a
plane like the F-111, with all of its faults, turned out to be just perfect.

Back in the 70's, someone must have known that (it sure wasn't me).

kre

---

From: Robert Elz <[email-masked]>
Date: Sat, 10 Aug 2002 20:37:09 +0700

Date:        Fri, 09 Aug 2002 18:53:55 -0400
    From:        "John C. Welch" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I've not seen much, and the information is not the easiest thing in the
  | world to find. (one rule of thumb...if it doesn't have an O'Reilly book, IT
  | people tend not to want to use it)

In that case, we're not using DNS-SD (NIAS or whatever) - there's no
O'Reilly book on that either.

But be reasonable, books come when the expected readership has reached
large enough proportions that writing and publishing makes sense.   That
takes time after any new technology is invented (except perhaps for those
few that have backing such that success is essentially guaranteed).

  | That may be...but configuring SLP is still voodoo, and not that many
  | networking setups use it at all.

What you mean is that you haven't bothered to figure out how to do it.
And you don't like it, so it's voodoo instead of orthodox religion.

  | DNS runs on everything right now.

Not true.   There's no DNS on my net at home, there's no point configuring
anything so heavyweight for something so small.

I could set it up, but if I was doing that just for service discovery,
I'd prefer SLP I think, it should be easier.

  | Well, that works very well...you don't use one single protocol for all your
  | networking use. You use multiple protocols, because each one does some
  | things better than others.

Yes, you seem to have realised the point.   DNS does name to address 
translation (quite well) - name to anything translation (moderately well),
and discovery (of anything) very badly.

SLP on the other hand is designed for discovery, and name translation
very badly (though you could probably create a "name translation"
service if you were that deranged).

Each protocol does some things better than the other.

kre

---

From: "John C. Welch" <[email-masked]>
Date: Sun, 11 Aug 2002 02:08:25 -0400

> O'Reilly book on that either.

There's better info out there on DNS and its applications than SLP.

> And you don't like it, so it's voodoo instead of orthodox religion.

No, it means I liked the idea, but after six months of looking for a decent
way to implement this across a multiplatform network realized that this was
a good try that had been dumped out there without the people doing the
dumping spending the time to make it easy to implement.

> anything so heavyweight for something so small.

I didn't say in every situation...but if it supports IP, it supports DNS.

> service if you were that deranged).

But I can find all kinds of help and information on working with DNS...and
effectively nothing on SLP. Maybe if the people who create things spent more
time on implementing and maintaining those things, then they would have
created more howtos, effective documentation, and a way to easily implement
it across a network. I already have DNS, so using DNS in a new way is more
familiar, and easier to deal with. Dealing with SLP so far has been too much
of a PITA to be worth the effort, and there are not enough implementations
of it to make it worth the effort to have SLP on some things, and something
else on other things.

Even Apple, who was/is one of the biggest users of SLP has a pretty nasty
setup for it, and it doesn't exist at all in the print architecture. So on
that platform, it's only usable to find file servers. So the implementation
kinda stinks, although it's better than the windows implementation, which is
simply not there at all in 2000. So my majority platforms are only partially
covered. It's not running on my AIX boxen either. It may indeed be cool, and
in truth it is, but I've already seen better support for Zeroconf than I
have for SLP.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: Robert Elz <[email-masked]>
Date: Sun, 11 Aug 2002 14:28:28 +0700

Date:        Sun, 11 Aug 2002 02:08:25 -0400
    From:        "John C. Welch" <[email-masked]>
    Message-ID:  <[email-masked]>

  | There's better info out there on DNS and its applications than SLP.

Sure, but not about abusing the DNS for doing searching.

The only thing that makes the proposed technique work incidentally, is
that this isn't what is being done.

The "searching" is done some other unstated way (one assumes by someone
roaming around with a clipboard, or PDA) the results of the search are
collated, and the answer is stored in the DNS, where it is just more
data.

While one can imagine ways by which new data might make its way into
that answer (the doc, or the version of it that I read, hints at some)
I don't see any sign of a "cleanup" protocol.

When something that is in the list of names returned in that magic PTR
record lookup, and the device (whatever) is summarily removed from the
network (unplugged, crashes, ...) and never returns, what causes its
name to ever be removed from the list?

Note, this isn't the same as just leaving stray old info in the DNS (the
SRV record pointed at, the A or AAAA records, etc) - those just contribute
to a little bit of zone bloat, they aren't used by anything other than if
someone deliberately wants to reference them (because of caching, or for
any other reason).   Getting rid of that old stuff is nice, but not
necessary.

On the other hand, old info (names of printers that haven't existed in
years) in the list of all the current available servers, is telling the users
that there is something out there that they can use, and unless the user
has some other knowledge of what names in the list should be ignored
(if you're going to expect them to have that knowledge, why not instead
just give them the positive knowledge about which they can use?)
then there are going to be constant problems ("The list says that the foobar
printer is available, yet nothing ever prints, why?")

That data really needs to be kept up to date - all the old stuff
(even down to printers that are just switched off, because the user
in the office next door doesn't like the noise).   (NBP managed to
do that adequately enough...)

There's nothing in the doc at all (not the one that was in the I-D
directories) that addresses this problem.   As I recall, it wasn't even
mentioned.

There seem to be two possibilities - human zone management (someone whose
job it is to constantly scan the list and remove anything which shouldn't
be there) in which case it clearly isn't zeroconf in any form.

Or some other system, which discovers which servers exist, and then uses
dynamic DNS to do the DNS updates (the draft hints at that one as one method
by which new entries might be made).

But what's the mechanism by which this other system discovers the servers?

This seems to be an essential ingredient of any zeroconf attempt to make
this proposal actually functional?

Then, once we have that method, why bother interposing some other manager
system and the DNS - why can't the end user applications just use the same
method?

  | No, it means I liked the idea, but after six months of looking for a decent
  | way to implement this across a multiplatform network realized that this was
  | a good try that had been dumped out there without the people doing the
  | dumping spending the time to make it easy to implement.

Did you perhaps consider as possible that it was just that no good
implementations had appeared yet?   Perhaps people are quietly working on
them somewhere?   I suspect that for much of this, the problem isn't
really how to do the SLP part, it is how to integrate that with the
rest of the application in a nice way.   That is, I can easily write an
application that will use SLP to locate printers for me - it just isn't
hard.   But my printing system is still using /etc/printcap, so what
good would it do me?   Seems likely I would need to create a whole new
printing system, and while implementing SLP isn't hard, that is.

The same is true of other services as well of course, I can easily
serach for NFS file servers, but the mount command still expects me
to type the server name (or put it in fstab).

  | I didn't say in every situation...but if it supports IP, it supports DNS.

nonsense.   I have an nice logic analyser, that runs IP (can be commanded
that way, its data files can be uploaded, manipulated, returned, it also
wants to print wave forms, etc - mostly it uses a locallt attached printer,
but it would be nice if it could just find one on the net).

It has never heard of DNS - it has no need for that at all.

I can point you at other systems which also have no need of the DNS, as
they have no need of name translations.

  | But I can find all kinds of help and information on working with DNS...and
  | effectively nothing on SLP.

SLP is newer.   Is this any surprise.   You can find even more information
on working with wood than you can on working with the DNS.   Perhaps you
should be carving a path to your servers???

  | I already have DNS, so using DNS in a new way is more
  | familiar, and easier to deal with.

I already have this plank of wood ...

  | Dealing with SLP so far has been too much
  | of a PITA to be worth the effort, and there are not enough implementations
  | of it to make it worth the effort to have SLP on some things, and something
  | else on other things.

You're right there - if you're an end user today (and perhaps even Apple
wanting to ship something today), then using something new, for which there
isn't much support, today, is probably not the wisest choice.

But that isn't what we are here, what we're doing is designing the method
for tomorrow, for people to be able to use, after it has been well
implemented, documented, etc.  What we want to do is specify what we believe
is technically the best method (solves all the problems that need solving,
has no gaping holes, is implementable, etc).  We're not trying to answer
the question "what do I deploy now".

Try not to get confused here, remember the aim.

kre

ps: it is nice to see at least a proposal of a use for PTR that isn't for
address to name translation - this might encourage its use in other
situiations where it would work)

---

From: Brad Hards <[email-masked]>
Date: Sun, 11 Aug 2002 18:52:16 +1000

> collated, and the answer is stored in the DNS, where it is just more
I assumed that (whatever the implementation) each device "registered" itself 
with the service discovery mechanism (be it a normal DNS server, a specialist 
DNS server, an SLP server, or something else).  If you have to manually find 
all the servers and type them in to some program, then that doesn't count as 
zeroconf to me.

> I don't see any sign of a "cleanup" protocol.
I assumed that there would be a TTL (or equivalent) timeout. 

> name to ever be removed from the list?
Has to be some kind of timeout.'
<snip>
> do that adequately enough...)
Don't know how this was done in NBP (or is done in SLP), but the DNS analog is 
obvious.
<snip>

The main issue that seems to be missing is a standard API for doing the DNS-SD 
update (which is covered by one of the SLP RFCs IIRC - 2614 maybe?). Ideally, 
a common API for both DNS-SD and SLPv2 would be good, then programmers don't 
need to worry about the two systems that _have_ to co-exist in the future.

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

---

From: Tim Jansen <[email-masked]>
Date: Sun, 11 Aug 2002 13:53:55 +0200

> printing system, and while implementing SLP isn't hard, that is.

Or maybe you should give CUPS (www.cups.org) a chance, which is a lpr 
replacement and supports SLP. 

bye...

---

From: Erik Guttman <[email-masked]>
Date: Mon, 12 Aug 2002 10:20:56 +0200 (CEST)

> for services that do not support the name property.

SLP templates define which attributes are required.  If the name
attribute is required for a given service type, it must be included
in service advertisements of this type.  Precisely to address the
possibilities that

  * the service address will change
  * the service has more than one address associated with it
  * the service supports more than one access protocol
  * the service supports more than one transport protocol

there is a usage strategy for SLP called 'serviceid'.  Please see
http://www.ietf.org/internet-drafts/draft-guttman-svrloc-serviceid-01.txt

This addresses the problem of persistent human readable names as
well as persistent unique identifiers for programs, that need to 
find the *same* service instance.  (Note that human readable names 
do not serve that purpose).

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: Robert Elz <[email-masked]>
Date: Sun, 11 Aug 2002 16:16:47 +0700

Date:        Sun, 11 Aug 2002 18:52:16 +1000
    From:        Brad Hards <[email-masked]>
    Message-ID:  <[email-masked]>

  | I assumed that (whatever the implementation) each device "registered"
  | itself with the service discovery mechanism (be it a normal DNS server,
  | a specialist DNS server, an SLP server, or something else).

That's the right approach for sure.   But the doc that's been under
discussion doesn't say how that should be done, just briefly mentions
some possibilities.

  | If you have to manually find all the servers and type them in to some
  | program, then that doesn't count as zeroconf to me.

I agree.

  | I assumed that there would be a TTL (or equivalent) timeout.

That would be reasonable, it is the standard approach.   But there's no
way to do that using "standard DNS" - when something is put there, it
remains until something explicitly removes it.

And if (as above) devices are registering themselves, and it is in the DNS
then there isn't going to be anything to do that removal, after the device
has died without warning, is there?

The claimed attractivemess of this approach is that it works with "standard
DNS" - which means to me, by the same reasoning as yours, that it is either
not zeroconf at all, or simply doesn't work.

  | Don't know how this was done in NBP (or is done in SLP), but the
  | DNS analog is obvious.

If you're thinking that the DNS TTL is relevant here, it isn't.  That
just states for how long a cache can retain a record, it has no effect at
all on the lifetimes of records in authoritative servers (which for
these purposes are likely to be the only ones that exist, a DNS cache
would make no difference, one way or the other).

NBP worked by having the device itself answer when someone does a lookup.
Obviously, if it is dead, it doesn't answer.   That's another simple solution
to the problem.

SLP is similar, though a little more complex so it can scale better.

  | The main issue that seems to be missing is a standard API for doing
  | the DNS-SD update

No, the API for doing DNS updates, or at least, the protocol for it, is
well defined now.   The security issues of permitting it to be done are
a whole other question though.

  | (which is covered by one of the SLP RFCs IIRC - 2614 maybe?).

See RFC2136 and RFC3007 for how DNS updates are done.   The SLP RFC2608
for how it works in general (which is nothing like the DNS)

  | Ideally, a common API for both DNS-SD and SLPv2 would be good,

That sounds a like a good idea - an easy and defined way for a service
to make itself known, so server authors (file servers, printers, ...) could
all start coding for that, then the implementation of the API could be
filled in a bit later.

It is a bit tricky to define an API without knowing just what will be
under it, but perhaps something reasonable can be achieved for this.

2614 does that for just SLP, I suspect the DNS version needs extra work,
like which DNS domain this service is to pretend it is in (which is not
necessarily going to be related to the "host" name it has in the DNS).

  | then programmers don't 
  | need to worry about the two systems that _have_ to co-exist in the future.

no, one of them will die away, perhaps both of the current possibilities.
DNS-SD looks to simply have too many problems to survive for long.
SLP, who knows?

kre

---

From: Brad Hards <[email-masked]>
Date: Mon, 12 Aug 2002 21:24:32 +1000

> not zeroconf at all, or simply doesn't work.
Too little evidence to make that assumption yet.

> would make no difference, one way or the other).

I think of it as: the device is the authoritative source, and everyone else is 
just caching (so the DNS server in DNS-SD is really on a cache, not a 
source).

So the service has to keep renewing its records (with the SLP server or the 
DNS-SD) before it times out and the cache dumps any reference.

- --

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 12 Aug 2002 04:08:56 -0700 (PDT)

> discussion doesn't say how that should be done, just briefly mentions

And given the complexities of DNS security, this omission is non-trivial.
For example, is the DNS dynamic update to be protected by TSIG? In SLP
there is the option of the original RFC 2608 security model, as well as an
emerging IPsec-based security model.

While Stuart mentioned that using DNS SRV to find an SLP DA might be
equivalent to using DNS SRV alone, from a security point of view, they are
potentially very different. The IPsec security model for SLP enables the
SLP DA to authenticate the querier, and provides end-to-end security,
where the SLP DA actually knows who the querier is. In a pure DNS-based
model, this is not the case, since queries may come from a DNS server
located far from the original querier, and the original querier is not
known. This makes a difference for things like geographic load balancing.

---

From: Ian Lister <[email-masked]>
Date: Mon, 12 Aug 2002 23:13:32 +1000 (EST)

>discussion doesn't say how that should be done, just briefly mentions

If the document under discussion is draft-cheshire-dnsext-nias-01.txt
(there have been several documents discussed recently), section 7 explains
that how the data gets into DNS is out of scope of the document, and
merely provides pointers to some possibilities (as you pointed out). In
fact most of the suggested possibilities do *not* involve the device
registering itself with a central directory.

>  | program, then that doesn't count as zeroconf to me.

Only one of the suggested mechanisms in section 7 requires manually
finding servers and entering them.

NIAS by itself does not make a zeroconf network. I don't think anybody is
claiming that it does. It allows browsing of a network given existing
(DNS-based) naming infrastructure. It does not attempt to provide zeroconf
naming or addressing; those are provided elsewhere, and NIAS can be used
with or without those.

Zeroconf addressing is provided by IPv4 linklocal addressing
(draft-ietf-zeroconf-ipv4-linklocal-05.txt, implemented in Macs and
Windows for several years now) and IPv6 stateless autoconfiguration.

Zeroconf naming is provided by multicast DNS
(draft-cheshire-dnsext-multicastdns-01.txt).

Zeroconf browsing is provided by NIAS (draft-cheshire-dnsext-nias-01.txt).

To see the whole zeroconf picture you need to look at all three aspects.

>has died without warning, is there?

If you use manual entry as the way to get records into your traditional
unicast DNS server, then it seems reasonable that manual removal is how
you get them out.

If you use multicast DNS to provide the DNS records, then they have TTLs
and when a device is no longer around to claim its presence its records
will soon disappear from any caches.

If you use any of the other techniques suggested in section 7 of the NIAS
draft to add records (or have them added automatically) there will be a
corresponding and appropriate way to delete those records (or have them
deleted automatically).

>not zeroconf at all, or simply doesn't work.

One piece of it by itself provides only a certain amount of benefit.
Similarly, zeroconf addressing and naming do not provide huge benefits by
themselves. They work and provide benefit by themselves, but for the full
`zeroconf experience' you put all three together.

Further, not only do the three zeroconf mechanisms build on each other,
they build on existing protocols and infrastructure. Rather than build an
entire zeroconf protocol that does everything from scratch, the problem
has been divided up and each part of the problem has been solved
separately with a focus not just on working with each other but on working
with existing protocols.

Like to run your home network with assigned addresses but don't want to
(or know how to) run your own DNS server just to get names? Use multicast
DNS.

Already got managed addresses and DNS but would like users to be able to
browse for services on the network? Use NIAS with traditional DNS. Don't
want the hassle of manually keeping each record up to date? Use DNS
update (still with NIAS).

Bump into somebody at a conference/meeting/lunch and want to share some
files? Use linklocal addresses, multicast DNS and NIAS to find your
acquaintance's services.

>would make no difference, one way or the other).

You're right, if you choose to manually add your DNS entries those entries
will need to be manually removed too.

>Obviously, if it is dead, it doesn't answer.   That's another simple solution

When you plug NIAS and multicast DNS together, that's pretty much what you
get (and that's the intent).

[snip]

>  | Ideally, a common API for both DNS-SD and SLPv2 would be good,

[snip]

>necessarily going to be related to the "host" name it has in the DNS).

If your hostname is foo.example.org and an application registers a web
server by the name of `My Webcam', I would expect the resulting DNS
records to be for `My Webcam._http._tcp.example.org' i.e. under the same
domain as the host. The whole point is that it is *not* the hostname, but
reusing the domain name seems like the most sensible idea. If your host is
running in a zeroconf environment and using multicast DNS it will use the
domain local.arpa, resulting in records for `My Webcam._http._tcp.local.arpa'.

I don't see any problems with that. It seems fairly straightforward and
I'm not sure what you think needs extra work here.

>DNS-SD looks to simply have too many problems to survive for long.

I think you think there are more problems than there really are. Check out
the other zeroconf drafts, see the piece of the problem that each is
trying to solve, and see how they fit together to provide some real zero
configuration.

Ian

P.S. it would probably assist in tracking down and referring to the drafts
in question if they were republished :-)

---

From: Tim Jansen <[email-masked]>
Date: Mon, 12 Aug 2002 16:34:52 +0200

> potentially very different. The IPsec security model for SLP enables the

DNS SRV with SLP DAs can also be used for the discovery of remote services:
http://www.potaroo.net/ietf/old-ids/draft-zhao-slp-remote-da-discovery-02.txt

bye...

---

From: "John C. Welch" <[email-masked]>
Date: Mon, 12 Aug 2002 11:07:01 -0400

> Sure, but not about abusing the DNS for doing searching.

I have yet to see hard proof that this will 'abuse' DNS.

> collated, and the answer is stored in the DNS, where it is just more

You have to get the information in somehow, and even with 'automatic'
discovery, someone is still going to give it a human readable name, if
nothing else, to avoid having ten printers all named "HP LaserJet 5si/MX".
And those names will be how people find the things when they go to find a
printer anyway. 

> name to ever be removed from the list?

Complaints to the maintainers of the records in that case, in the same way
that old server names are removed now.

> any other reason).   Getting rid of that old stuff is nice, but not

Um, yes, it is necessary, to stop the emails and phone calls about server
'foo' being down...it's not *down*, it's gone, and cleaning up DNS records
is good housekeeping, alone with good security.

> printer is available, yet nothing ever prints, why?")

That's the same thing that happens with old computer entries in DNS..."I
keep getting time out errors, is that server down?"
> do that adequately enough...)

Nothing worse than you do now.  If you had a printer set up, it stayed set
up regardless of it's real state. NBP didn't remove it from your list of set
- up printers, it just removed it from the list of printers when you were
browsing for one.

> directories) that addresses this problem.   As I recall, it wasn't even

SLP won't fix that problem either, unless you are telling me that SLP
changes user settings automatically, which would be a *very* bad thing.

> be there) in which case it clearly isn't zeroconf in any form.

If the DNS naming and address assignment are all done automatically, then
that sort of human intervention isn't needed. If you are making manual PTR
entries, then you are bypassing the Zero part of zeroconf anyway.

> them somewhere?  

That's like winking in the dark...you may be quite busy, but no one else
knows you're doing it. It's either in the OS, or it's not going to be used.
This has to be an integrated part of the human experience on a platform, not
some third party utility that may or may not break with every OS update, and
has a separate security model.

> I suspect that for much of this, the problem isn't
> rest of the application in a nice way.

It has to be integrated into the OS...applications shouldn't implement any
printer or resource discovery at all...that's what OS's do.

> That is, I can easily write an

Why not integrate SLP and IPP into the OS?

> to type the server name (or put it in fstab).

Which is one of many reasons why NFS is not the defacto standard for file
sharing...it's a PITA to use, totally insecure, and a banndwidth pig.

> they have no need of name translations.

I didn't say it implements, I said it supports DNS. It can be used with DNS.

> should be carving a path to your servers???

Perhaps the very smart people who think SLP is the answer should do some
documentation instead of letting the schlubs trying to implement it do that
work for them?

> isn't much support, today, is probably not the wisest choice.

If the SLP designers had thought of implementation and documentation in
equal parts with features, we wouldn't need to have this argument.

> Try not to get confused here, remember the aim.

I am remembering the aim. And I'm trying to get the people doing the
designing to remember the inconvenient fact that neither SLP *or* ZeroConf
are breaking new ground here. There are a few efforts that have been made in
this area and none of them are used. I don't care how good, capable, or
ground breaking an idea is, if it can't be implemented quickly, easily, and
transparently, then *NO ONE* is going to use this outside of a test lab.
Zeroconf/Rendevous isn't even a standard, but right now, it has a better
implementation than SLP. Maybe thinking about the deployment/maintenance end
of things more often would result in fewer ideas being thrown into the
wastebin.

Creation is the first 80% here...implementation is the last 20%, and
probably more important in the long run.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: "John C. Welch" <[email-masked]>
Date: Mon, 12 Aug 2002 11:08:26 -0400

> replacement and supports SLP.

It's still not as integrated as it needs to be in enough operating systems.
But it is a really nice implementation, other than that.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: Tim Jansen <[email-masked]>
Date: Mon, 12 Aug 2002 18:24:24 +0200

On Monday 12 August 2002 17:07, John C. Welch wrote:
> implementation than SLP. Maybe thinking about the deployment/maintenance
> end of things more often would result in fewer ideas being thrown into the
> wastebin.

In other words, DNS-SD should be standardized because there is a good 
proprietary implementation for a single platform. 

BTW, better than which SLP implementation? The one in MacOSX, Solaris, Novell 
NetWare, Lexmark printer servers, OpenSLP...

bye...

---

From: "John C. Welch" <[email-masked]>
Date: Mon, 12 Aug 2002 12:53:33 -0400

> proprietary implementation for a single platform.

The only problem is that it's on *one* platform. If it works well, then use
that as a base. 

> NetWare, Lexmark printer servers, OpenSLP...

Mac OS X's, to put a point on it, sucks. Sun's is more complete, and more
unwieldy. I don't use Novell, so no opinion there. The same for Lexmark
printer services. It's not on windows yet, in fact, if you look in
Microsoft's support base, the only mention of SLP is adding it as a DHCP
option for Novell DHCP clients.

So lets see here...out of the platforms I have direct control over daily:

Mac OS X:   File servers only
Sun:        The widest use of SLP, and the worst configuration
            setup...."just write your own C or C++ program..." should NEVER
            be a part of a network service implementation guide for Network
            Admins.
AIX:        SLP doesn't appear to be a part of AIX, and from what I can see,
            IBM is only using it for it's "Host on demand" services, and
            it's SNA gateway products.
Windows:    Doesn't exist

So, we see out of four platforms, one company has limited support, and it's
bad, (Apple), One has more complete support, but a really poorly designed
setup (Sun), one only uses it for a very small set of services, (IBM), and
one is ignoring it completely, (Microsoft).

So SLP, after a few years on the market, has been so poorly implemented that
it's only in slightly wider use than a brand new scheme, Zeroconf.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: Brad Hards <[email-masked]>
Date: Tue, 13 Aug 2002 07:51:49 +1000

> discussion doesn't say how that should be done, just briefly mentions
It finally occurs to me why these ambiguities haven't been resolved by the 
guys who probably have a working system - Apple. Apple has almost certainly 
embargoed people talking about implementation details until after the OS 
10.1.2 release.

Maybe all will be clearer after 24 August (which I think is when apple were 
going to open source the mDNS responder too)

Brad

- --

---

From: Robert Elz <[email-masked]>
Date: Tue, 13 Aug 2002 15:49:26 +0700

Date:        Mon, 12 Aug 2002 21:24:32 +1000
    From:        Brad Hards <[email-masked]>
    Message-ID:  <[email-masked]>

  | I think of it as: the device is the authoritative source, and everyone 
  | else is just caching (so the DNS server in DNS-SD is really on a cache,
  | not a source).

You can think of it that way if you like, but this isn't the DNS, and no
DNS server supplying the data is going to do that for you.

  | So the service has to keep renewing its records (with the SLP server or the 
  | DNS-SD) before it times out and the cache dumps any reference.

With SLP, yes, that's how its designed.   With DNS, no.   Remember DNS-SD
is just a technique of using the existing DNS to perform SD, it isn't
something new of itself.   That's its biggest feature...   To retain that
it must remain the same old DNS we have always had (mDNS alternatives not
being relevant either way here).   That is, the DNS server simply will not
time out and dump any data.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 13 Aug 2002 16:25:28 +0700

Date:        Mon, 12 Aug 2002 23:13:32 +1000 (EST)
    From:        Ian Lister <[email-masked]>
    Message-ID:  <[email-masked]>

  | If the document under discussion is draft-cheshire-dnsext-nias-01.txt

That has been my assumption, except -01 doesn't exist, so -00 is what
I have been looking at.

  | (there have been several documents discussed recently), section 7 explains
  | that how the data gets into DNS is out of scope of the document, and
  | merely provides pointers to some possibilities (as you pointed out). In
  | fact most of the suggested possibilities do *not* involve the device
  | registering itself with a central directory.

Yes.   I agree.

  | Only one of the suggested mechanisms in section 7 requires manually
  | finding servers and entering them.

True.

  | NIAS by itself does not make a zeroconf network.

No, of course not.   Whoever claimed that it should?   The question is
whether it (really) works at all (as distinct from: seems to work in
some environments).

And here (in this WG) zeroconf nets are the ones that matter, how it works
on configured networks is kind of relevant to see whether a good zeroconf
idea will scale, but it has to be a good zeroconf idea first.   (Alternatively
it could be a good idea somewhere else, and this WG could look at it to
see if it is suitable for zeroconf).

  | If you use manual entry as the way to get records into your traditional
  | unicast DNS server, then it seems reasonable that manual removal is how
  | you get them out.

Fine, but that's not zeroconf, so that part isn't relevant here.

  | If you use multicast DNS to provide the DNS records, then they have TTLs
  | and when a device is no longer around to claim its presence its records
  | will soon disappear from any caches.

Yes, that would work OK, though there's another problem with doing that
that I will mention below.

  | If you use any of the other techniques suggested in section 7 of the NIAS
  | draft to add records (or have them added automatically) there will be a
  | corresponding and appropriate way to delete those records (or have them
  | deleted automatically).

Will there?   What is it?   If the other technique is the "manager"
service, then there should be no great problem, but once again, if
that manager service is able to figure out what servers exist, why can't
the clients all just copy what it does, and thus avoid the need for it
to exist at all?   One less piece required.

Or, if it is the "device registers itself" technique, then what is it that
does the removal when the device is dead?   For this one, I don't see an
answer at all.  Your "there will be" looks like hand waving.

Note that a lookup protocol is just noise unless there's some way access
the data that is to be looked up.   It doesn't help at all to be able to
say "well, this will work fine if we have the data collected ..." - if
data collection is required, then how that happens is every bit as
important as how the lookup is done by the client, and can't just be
swept away as someone else's problem.

  | Further, not only do the three zeroconf mechanisms build on each other,
  | they build on existing protocols and infrastructure.

That's all nice, provided that "build upon" is what they do, and isn't
"tear down and attempt to reconstruct, differently".   No, don't complain,
I'm not claiming that anything I have seen so far (certainly nothing that
is actually in the NIAS draft) is doing that, but remember this when you
read a little below.

  | Bump into somebody at a conference/meeting/lunch and want to share some
  | files? Use linklocal addresses, multicast DNS and NIAS to find your
  | acquaintance's services.

Hmm - remembering the "build on existing protocols" (and for now
assuming that multicast DNS is an existing protocol) how does NIAS
actually work in that scenario?

As I understand it, I do a lookup for _service._tcp.my.domain. (my.domain
might be local.arpa or something here, forget that, it isn't important for
this point).

Who or what can answer that?   Remember, that in the "existing DNS" there
can only be one answer - if there are two different answers, at most one of
them is correct.  It is completely incorrect to merge answers.

So, let's assume there are 4 people and lunch, and three of them have
printers with them (strange lunch...) and I'm the one who doesn't.  I want
to print.   I lookup _printer._tcp.whatever.it.is.   Who answers?
How does that one get the data about the other two to include in the
answer?

  | When you plug NIAS and multicast DNS together, that's pretty much what you
  | get (and that's the intent).

Except NBP specifically merged the answers from multiple replies - each
reply would be just about "me" (the respondent).  DNS very explicitly does
not permit that.   If you want merging, you're using some other protocol.

  | If your hostname is foo.example.org and an application registers a web
  | server by the name of `My Webcam', I would expect the resulting DNS
  | records to be for `My Webcam._http._tcp.example.org' i.e. under the same
  | domain as the host. The whole point is that it is *not* the hostname, but
  | reusing the domain name seems like the most sensible idea. If your host is
  | running in a zeroconf environment and using multicast DNS it will use the
  | domain local.arpa, resulting in records for `My Webcam._http._tcp.local.arpa'.
  | 
  | I don't see any problems with that. It seems fairly straightforward and
  | I'm not sure what you think needs extra work here.

You missed my point.   Sure, if my webcam, on my box, whose name is
foo.example.org registers itself, then "My Webcam._http._tcp.example.org"
would be an obvious possible name, and that would expect to be included
in the "_http._tcp.example.org" PTR RRset.   That much (at least as a
default) isn't very hard to figure out.

The problem is how the user who wants to find the webcam knows that it
should be doing a PTR lookup of "_http._tcp.example.org".   Its domain
name happens to be "bar.example.com".   All of this is at that conference
you mentioned above.   I'm connected to the net, and I want to find the
camera.   I can do a PTR lookup for "_http._tcp.example.com" but all that
can ever find are the cameras back in the office (and maybe one connected
to my system).  That isn't what I'm looking for, I'm looking for the one
covering the session I wanted to attend but couldn't get into the room...

I hope there's no buried assumption in here that there's any relationship
at all between nets and domain names ?   There might be some environments
where you might expect everything to be living in one nice domain, so if
I discover my own domain somehow, I can expect the printers, cameras, file
servers, ... to all be in the same domain.   But it isn't any environment
I've ever lived in.

  | I think you think there are more problems than there really are. Check out
  | the other zeroconf drafts, see the piece of the problem that each is
  | trying to solve, and see how they fit together to provide some real zero
  | configuration.

I have read them.  But solving all of zeroconf isn't what I am concerned
about.   Just "Does NIAS really work for finding servers".   You may (or
perhaps not) have seen that I don't often comment in this WG.  Most of
what goes on here isn't of great interest to me.   But when someone claims
"just use the DNS" as the answer to some problem, then I tend to look
closer.   And I will comment if the approach looks to be unsound (as it
is the vast majority of times someone suggests using the DNS for anything
that isn't a direct hostname lookup).

  | P.S. it would probably assist in tracking down and referring to the drafts
  | in question if they were republished :-)

Yes, I have made that point in private mail.

kre

---

From: Robert Elz <[email-masked]>
Date: Tue, 13 Aug 2002 17:46:41 +0700

Date:        Mon, 12 Aug 2002 11:07:01 -0400
    From:        "John C. Welch" <[email-masked]>
    Message-ID:  <[email-masked]>

  | You have to get the information in somehow, and even with 'automatic'
  | discovery, someone is still going to give it a human readable name, if
  | nothing else, to avoid having ten printers all named "HP LaserJet 5si/MX".
  | And those names will be how people find the things when they go to find a
  | printer anyway. 

That needs to be done - but the people who name printers, and the people
that manage the DNS, are rarely the same group.   So, somehow they need
to communicate, or the printer (after it is named) needs to communicate
with the DNS server, or something.   It is that step that is the data
collection that is being done, to allow DNS-SD to be a straight lookup
that the DNS can cope with, rather than a search, which it cannot.

But the specification on how this necessary step is to be done is lacking.
That's a probloem.

  | Complaints to the maintainers of the records in that case, in the same way
  | that old server names are removed now.

Which maintainers of the records??    Remember that (here at least) we're
looking at this working in a zeroconf environment.   That means, there's
no-one maintaining things.   You can swear at the cabling, or the 802.11
access points, all you like, but they're neither of those will eventually
get sick of your complaints and go edit a DNS zone file for you.  Nor
do they have a boss...

If this protocol is ever to be useful for zeroconf, it has to work in
a network with no administrators - and that includes having old data vanish.

Now, of course, how that happens will depend upon how the data is collected
in the first place - but there's no specification for that either.

  | Um, yes, it is necessary, to stop the emails and phone calls about server
  | 'foo' being down...it's not *down*, it's gone, and cleaning up DNS records
  | is good housekeeping, alone with good security.

Good housekeeping perhaps, it has nothing in the slightest to do with
security.   But in any case, cleaning up specific records (certainly a
nice thing to do) doesn't cause great problems if not done.   Failing to
clean up the magic PTR record would.

So the latter has to have a solution, the other can be left as "someone
will do it, and if not, it doesn't really hurt much anyway".

I don't know if you've ever actually maintained a large DNS server, but
"cleaning out the crap" is the hardest part of that - because it can be
very very hard to figure out what is crap, and should be removed, and what
is just "not there right now".   I think if you look at almost any large
DNS configuration, you'll find all kinds of obsolete stuff still just sitting
there - not being deleted, as there's no-one around who is actually very
confident that it is obsolete.

Again, this doesn't matter for normal DNS records, they consume some space,
occasionally lead someone to believe that some resource is in use (a particular
name, perhaps IP address) but don't cause any serious problems.  Not true of
the NIAS magic PTR record - that has to be kept (relatively) clean to be
useful.

  | That's the same thing that happens with old computer entries in DNS..."I
  | keep getting time out errors, is that server down?"

Sure.   And that's exactly the point.   When that happens, what do you
expect the user to do?   The normal thing would be "well, I'll see if I
can find another one instead".   How do I do that?   Well, if DNS-SD is
the accepted technique, I run my DNS-SD application, and have it fetch the
PTR record value, and I look through that.

All that is fine, normal even - provided the PTR record actually lists
stuff that are available to use now (at least the vast majority) and not
"every server we have seen in the past 10 years".

For that, cleanup is required (it doesn't have to be instant, if a
server has just failed, and hasn't been removed, people will cope).

  | Nothing worse than you do now.  If you had a printer set up, it stayed set
  | up regardless of it's real state. NBP didn't remove it from your list of set
  | - up printers, it just removed it from the list of printers when you were
  | browsing for one.

Once again, exactly.   That's what should be achieved.   We can't ask for
more, that would be asking for too much.   But neither should we accept
less - when browsing, I need to see the printers I can use *now*.

  | SLP won't fix that problem either, unless you are telling me that SLP
  | changes user settings automatically, which would be a *very* bad thing.

Not the problem you just invented as being the one you wanted solved, no.
It does solve the browsing problem though - dead servers will vanish from
the list you get back from SLP (perhaps not instantly, but that's OK, they
won't remain forever).

  | If the DNS naming and address assignment are all done automatically, then
  | that sort of human intervention isn't needed. If you are making manual PTR
  | entries, then you are bypassing the Zero part of zeroconf anyway.

Yes, of course.   That was my point.   But how?   Just assuming it
will happen, somehow, isn't good enough.   What if no-one can ever
find a way that works?   Or what if the way that is found doesn't
work with DNS at all?

  | It has to be integrated into the OS...applications shouldn't implement any
  | printer or resource discovery at all...that's what OS's do.

Whatever.   What OS's should do, and should not do, is a religious
discussion that we don't need to have, as it doesn't matter here.
All that matters is that something does it.   That is, as long as
the application that wants to print can find its printer, we have
success, right?

  | I didn't say it implements, I said it supports DNS. It can be used with DNS.

Then the statement has no meaning.   Anything can be used with the DNS,
even if the method of doing that is just to ignore the DNS...

  | I don't care how good, capable, or
  | ground breaking an idea is, if it can't be implemented quickly, easily, and
  | transparently, then *NO ONE* is going to use this outside of a test lab.

nonsense.   I'll bet you use lots of things every day that weren't
originally implemented quickly easily or transparently.   What's the
CPU in the system that you're using?   How does it meet your criteria?

  | Zeroconf/Rendevous isn't even a standard, but right now, it has a better
  | implementation than SLP.

Whether this is true or not (it is certainly debatable) it is irrelevant.

  | Maybe thinking about the deployment/maintenance end
  | of things more often would result in fewer ideas being thrown into the
  | wastebin.

This I certainly agree with.   But you're jumping to conclusions.
That is, you're looking and not seeing any SLP that you consider acceptable,
and concluding from that that the reason is that it can't be done.  I don't
know how that is supposed to follow.

kre

---

From: "John C. Welch" <[email-masked]>
Date: Tue, 13 Aug 2002 08:25:23 -0400

> time out and dump any data.

Right...but then you are choosing to not have that aspect of Zeroconf
functional on your network, and you have to deal with the fallout. You can
avoid this by using mDNS for things you don't require to exist in a
permanent settings file.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: Aidan Williams <[email-masked]>
Date: Wed, 14 Aug 2002 11:18:54 +1000

> not permit that.   If you want merging, you're using some other protocol.

An interesting set of comments -- thanks.

I think it is fair to say that there are two protocols in operation
here.  One is the standard DNS protocol, deployed today with various
bits of goop added to zone files.  If that were not the case then
DNS-SD would just not work in the case where you were using unicast
DNS and knew a domain name.

The second protocol is the thing that looks like NBP and merges
results.  That thing (according to Stuarts multicast DNS draft)
uses link-local multicast, aggregates the results, and always
uses the domain name "local.arpa" for multicast requests.
Thus discovery of all the "link local lunch line printers"
ought to be possible.

If the problem here is one of naming (ie that multicast DNS
has the acronymn "DNS" in it), that can be fixed pretty simply:
call the thing something different.  LLMNR perhaps.. ;-)

I believe Stuart's NIAS proposal would need tweaking to make it
compatible with the current dnsext LLMNR document..
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-11.txt
In particular, the local.arpa domain name has gone away.
You either have a global domain name, or none and both flavours
of names may be resolved using multicast.

> at all between nets and domain names ?

Yes there is - when you want to discover all the stuff on a local
link using DNS formatted multicast packets (ie the !DNS protocol)
everybody needs to agree on a domain suffix.  Possible suffixes
could be any.old.thing. or nothing at all.  Personally I prefer
nothing at all.  LLMNR allows both.  Stuart's version of mDNS
always uses "local.arpa".

-- 

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: Robert Elz <[email-masked]>
Date: Tue, 13 Aug 2002 23:53:06 +0700

Date:        Tue, 13 Aug 2002 08:25:23 -0400
    From:        "John C. Welch" <[email-masked]>
    Message-ID:  <[email-masked]>

  | Right...but then you are choosing to not have that aspect of Zeroconf
  | functional on your network,

No I'm not.   The exact opposite - I'm refusing to run anything which
doesn't work in a sane fashion.   And not having a method to get rid
of old dead stuff isn't sane...

  | You can
  | avoid this by using mDNS for things you don't require to exist in a
  | permanent settings file.

I'm not sure what the permanent settings file has to do with anything,
but more importantly, mDNS and DNS on the same net was, last I heard,
undefined - it leaves too many possible holes (as well as making it
difficult for the client nodes to figure out what to do).

On a baby net with no real DNS, then mDNS would avoid the cleanup problem,
but still leaves the "there can only be one server of any type" problem to
replace it (remember, no merging of the replies).

kre

---

From: Robert Elz <[email-masked]>
Date: Wed, 14 Aug 2002 14:58:32 +0700

Date:        Wed, 14 Aug 2002 11:18:54 +1000
    From:        Aidan Williams <[email-masked]>
    Message-ID:  <[email-masked]>

  | The second protocol is the thing that looks like NBP and merges
  | results.

That sounds like it would work if you're doing a PTR lookup to find
a service.   If you're doing an A lookup to find an address associated
with a name, is "merges the results" really going to have the
required semantics?

That is, you're hoping there will only be one owner of the name, so the
issue shouldn't arise (as "merging" results in normal DNS is an issue
that should never arise, if everything is operating correctly).

But what if there's not?   Should the mDNS level (whatever it gets
called) just hand you back all of the A records, as if they came in
one answer?

That seems wrong to me.

If that's correct, then is the suggestion that whether merging is done
or not should depend upon the RR type being sought?

That would create difficulties for future types wouldn't it?   How would
software deployed now know whether some future type should be merged or not?

In any case, that doesn't seem adequate anyway - if the PTR lookup is
being done to find an IN-ADDR.ARPA then I don't think I want the results
merged do I?   They're perhaps even less likely to be multiple results,
but no guarantee.

So, it can't be the RR type (relief: no need to worry about the problems
that would cause), but instead it looks as if the merging or not merging
should be decided by the purpose of the lookup.

So, now we have a "kind of like normal DNS" mDNS lookup for normal requests,
and a "different from normal DNS" mDNS lookup for SD type requests.

To me, that looks just like two different protocols, even if the bit formats
on the wire happen to be the same - that is, to make it work, it is bending
the "DNS" concept so much, including the way it is normally used in mDNS,
that keeping pretending they're the same is not worthwhile.  That is, we
claim they're the same so we can convince people that we're just building
on existing infrastructure & protocols - but then we go tell them "but by the
way, we have to make this change, and that change, and ..."

  | Yes there is - when you want to discover all the stuff on a local
  | link using DNS formatted multicast packets (ie the !DNS protocol)
  | everybody needs to agree on a domain suffix.  Possible suffixes
  | could be any.old.thing. or nothing at all.  Personally I prefer
  | nothing at all.  LLMNR allows both.  Stuart's version of mDNS
  | always uses "local.arpa".

The issue here is that we need a protocol that can gracefully work as
the net it is corrected to grows, and changes character.   That doesn't
mean that we have to send only one kind of query packet (mDNS or DNS),
that kind of decision can be made based upon whether there are any DNS
servers answering (or some other way).   That's OK.

What I mean is that the basic method has to work for all sizes of nets.

The domain name issue (as you explain) is probably irrelevant for true
baby nets, the domain name part can just get ignored, or be a fixed
string, or whatever.

But as the net gets bigger, it can't - if you're going to query real
DNS servers, you have to send real DNS queries, and they have to have
real domains in them, or they don't work at all.

How does DNS-SD work in a multi-domain network?   How does the client
discover what domain (or domains) it is supposed to be sending its query
to?   It sounds as if we need a "domain discovery protocol" in order
to allow DNS-SD to work (if DNS-SZ is NBP, then this new one might be ZIP,
or parts of it).

Where's that part?   And please don't tell me it uses DNS, it can't...

kre

---

From: "John C. Welch" <[email-masked]>
Date: Wed, 14 Aug 2002 08:17:02 -0400

> of old dead stuff isn't sane...

By that definition, you aren't running DNS at all, as the only way to get
rid of old stuff is manually, and according to you, that's not sane.

> difficult for the client nodes to figure out what to do).

I read the files on it, and it seems quite defined to me, and I didn't see
any issues with client nodes either.

> replace it (remember, no merging of the replies).

Um...I'm not getting that problem from the way that Zeroconf works, so I'm
going to assume you are getting entirely different ideas from it than I am.

john

-- 
John C. Welch
IT Manager
MIT Police
(617) 253 - 3093 work
(508) 579 - 7380 cell
(617) 253 - 8822 fax

---

From: Joshua Graessley <[email-masked]>
Date: Wed, 14 Aug 2002 10:41:19 -0700

> called) just hand you back all of the A records, as if they came in

Unicast DNS can return multiple answers in one packet regardless of 
record type. The difference with mDNS is the possibility that the 
multiple answers would arrive in different packets.

> or not should depend upon the RR type being sought?

I don't think so. In the case of mDNS the "merging" of answers in 
separate packets should be done for any RRs.

> merged do I?   They're perhaps even less likely to be multiple results,

The mDNS that Stuart Cheshire has proposed would only send queries in 
specific domains to the multicast address. in-addr.arpa is not one of 
those domains although 254.169.in-addr.arpa is for the purpose of 
performing reverse lookups on IPv4 link-local addresses. It is pretty 
obvious there can be no authoritative name server for performing 
reverse lookups for addresses in the 169.254.0.0/16 network.

> and a "different from normal DNS" mDNS lookup for SD type requests.

Not necessarily. If you have two hosts that decide they are logically 
the same so they both respond with A records for the same name, it 
would not be unlike cases where a unicast DNS server contains two A 
records for one name. The difference is that the replies would be in 
separate packets in the mDNS case.

> way, we have to make this change, and that change, and ..."

Yes, a resolver handling mDNS would need to be a bit different from a 
unicast DNS implementation. A resolver handling mDNS would need to join 
the multicast group. In addition, the resolver would probably need to 
have code to send multicast requests on all interfaces as well as code 
to join together answers from multiple packets.

-josh

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 14 Aug 2002 10:41:57 -0700 (PDT)

While it's great to see all the interest in discussion of mDNS, it's worth
noting that mDNS is a work item of the DNSEXT WG, *not* of the Zeroconf
WG. So discussions of mDNS really need to occur on the DNSEXT WG mailing
list.

---

From: Aidan Williams <[email-masked]>
Date: Thu, 15 Aug 2002 11:12:31 +1000

Robert Elz wrote:
 > That is, you're hoping there will only be one owner of the name

Both Stuart's mDNS draft and dnsext's LLMNR check for the uniqueness
of the name.

 > [response aggregation] That seems wrong to me.

Perhaps only if it is a protocol called "*DNS*"?

 > To me, that looks just like two different protocols, [....]

Exactly.  That is what I was trying to point out in my previous
piece of email.

 > even if the bit formats

There is another effect too:  If you call something "*DNS*", you step
on hallowed turf, and all kinds of people come out of the woodwork
and start whacking you over the head.  There are a lot of parochial
gardeners tending that particular piece of turf.

 > What I mean is that the basic method has to work for all sizes of nets.

The "one size fits all" protocol would be nice, but it isn't an
absolute requirement in my opinion.  Both DNS-SD(aka NIAS) and SLP
seem to fit this picture reasonably well.

 > Where's that part?   And please don't tell me it uses DNS, it can't...

There isn't currently a "domain discovery protocol" that I know of,
rather it is assumed that the user knows a useful domain and can type.
A device without a keyboard can be configured with the (only just
recently specified and not yet deployed) domain search list option
for DHCP to find things in other domains, or the (not yet agreed upon)
IPv6 version of the same thing.

It strikes me that the situation is not a whole lot different for SLP.
The up-scaled version requires DNS/SRV SLP DA discovery (and acronymn
expansion to go along with it).

-- 

regards
	aidan
____
:wq!

---

From: Aidan Williams <[email-masked]>
Date: Thu, 15 Aug 2002 11:19:46 +1000

> WG. So discussions of mDNS really need to occur on the DNSEXT WG mailing

Fair point.

Most of the discussion has been about two drafts (Stuart's mDNS and
NIAS drafts) which are not currently wg documents.  Given that LLMNR
*is* a wg document, it would appear to have a reasonable chance of
going forward.  I would like to see DNS-SD/NIAS tweaked so that it
played nice with LLMNR.

The more general discussion about service discovery doesn't appear
to be DNS specific..  Zeroconf seems as reasonable a place as any
right now.

-- 

regards
	aidan
____
:wq!

---

From: Robert Elz <[email-masked]>
Date: Thu, 15 Aug 2002 12:26:00 +0700

Date:        Wed, 14 Aug 2002 10:41:19 -0700
    From:        Joshua Graessley <[email-masked]>
    Message-ID:  <[email-masked]>

  | Not necessarily. If you have two hosts that decide they are logically 
  | the same so they both respond with A records for the same name, it 
  | would not be unlike cases where a unicast DNS server contains two A 
  | records for one name.

I don't think that's true.   If I get a DNS response that says a name
has two A records, what that is telling me is that I can use either one,
and both will get me to the same place (one might be better or worse for
the routing system, but that's not relevant here).   It doesn't matter
for this whether or not the A records reach the same hardware or not,
the existence of two addresses for the same name is a promise that the
two are equivalent.

On the other hand, if I get two systems each of which things it is
called "pc1" on my net, and both return A records, the chances that they'll
be equivalent is vanishingly small.

I believe that merging RRs into an RRSet from different replies is a
bad idea, always, regardless of the method used to elicit the replies.

When I get duplicate A's, I can either just pick one at random (then the
other host will appear not to exist, for now anyway), or most likely
better, complain about the duplicate and return neither (neither host will
be visible until the problem is fixed).

The problem with the better approach is that it means that it is no longer
possible to simply get a reply, and start processing, which is what would
normally be done (and the "random" selection amounts to "the reply that
arrived first").   All queries would need to wait for a timeout just
in case there's another reply waiting to arrive.    That would be required
if merging the results was the desirable outcome.

That's why, in practice here, what is done is application dependent.
If I'm doing a search, I wait, and merge.  If I'm doing what I think is
a specific query, I simply accept the first result, and process that
(which is not merging).

That difference is why I'm suggesting that there really are two different
protocols being describer here.

  | Yes, a resolver handling mDNS would need to be a bit different from a 
  | unicast DNS implementation.

Yes, of course.   I wasn't attempting to suggest that anyone believes
that DNS and mDNS are the same.

  | A resolver handling mDNS would need to join 
  | the multicast group. In addition, the resolver would probably need to 
  | have code to send multicast requests on all interfaces

Yes, though the latter can have some tricky side effects

  | as well as code to join together answers from multiple packets.

This part is what I believe it should not have, normally, and normally
would not have.   The effect would be that every query would need to
wait a while (1 second?) just to see if any more answers were coming.
That's fine for a lookup (find all printers ...) kind of application,
people expect that might take a short while.   It isn't good for a
"ping pc1" or "http://pc1/..." type lookup however.

kre

---

From: Joshua Graessley <[email-masked]>
Date: Mon, 19 Aug 2002 18:31:16 -0700

> be equivalent is vanishingly small.

It is up to the server, not the client to make sure that multiple 
conflicting responses are not sent. In the case of mDNS, an mDNS 
responder should verify that any records it is advertising do not 
conflict with records another responder is advertising. The burden 
should lay on the responders, not the clients.

> bad idea, always, regardless of the method used to elicit the replies.

Is this not already done with unicast DNS? Some DNS clients that want 
to lookup A and AAAA records may send multiple queries. The results of 
the query for A records would be merged with the result for the AAAA 
record query before returning the information to the application 
performing the lookup. Merging for RRsets is already done today, makes 
sense, and is useful.

> be visible until the problem is fixed).

This is true with unicast DNS. If a unicast server has two A entries 
for the same name that point to totally different machines, mayhem will 
ensue. Just as a server administrator would have to ensure they don't 
put conflicting information in their database, an mDNS responder would 
have to ensure that it doesn't generate conflicting information.

> if merging the results was the desirable outcome.

This does make life more challenging. As you noted before, the type of 
query being performed can affect whether or not multiple replies are 
important. In the case of an A record lookup, if a host has two 
interfaces on the same link, and advertises a name on that link, the 
resolver library could return the first response and everything would 
work. On the other hand, when trying to discover services, the first 
response would not be sufficient to locate all of the services out 
there.

In addition, the timeout would not need to be anywhere near as long as 
it is for unicast timeout. It is not unreasonable to expect that any or 
every machine on the local link would be able to respond within a 
second to a multicast query. Unicast can not set such a short timeout 
for a variety of reasons.

> protocols being describer here.

I don't think there are two protocols, but I do think there are two 
APIs required.

> "ping pc1" or "http://pc1/..." type lookup however.

I would argue that a query for a service, from a clients point of view, 
should never really end. Services come and go, so a client ought to sit 
in a loop waiting for notification of services coming and going. This 
has little to do with the on the wire protocol, how the server behaves, 
or the format of the packets. Only the APIs that control how a process 
on a machine would get the results of a query would need to differ.

-josh

---

From: Keith Moore <[email-masked]>
Date: Tue, 27 Aug 2002 16:29:26 -0400

> and start whacking you over the head.  

there's a good reason for that.  there are hundreds of millions of 
computers and tens of thousands of computer programs out there that
were designed to work with DNS as it is currently defined - not some
modified version of DNS with slightly different semantics and 
different failure modes.  

so by calling something *DNS* that doesn't act quite like DNS you're 
doing one (or both) of two things: (1) trying to gain credibility for your
proposal by exploiting the DNS name, or (2) threatening to break a huge
amount of installed software should it ever be expected to interoperate
with your alternation of DNS as if it were *real* DNS.

Keith