Subject: Re: On attribute-based queries

From: "John C. Welch" <[email-masked]>
Date: Thu, 01 Aug 2002 01:19:50 -0400

On 08/01/2002 00:00, "Keith Moore" <[email-masked]> wrote:

>> Um...host name conflicts happen all the time if you aren't careful. Wonks
>> things up right nicely
> 
> DNS and hosts idea of their names can be out of sync, and DNS servers can be
> out of sync with one another if they are misconfigured, and these are
> indeed problems sometimes.  but DNS cannot supply conflicting information if
> it is properly configured.  on the other hand, it's perfectly reasonable to
> have two servers on the same LAN with the same properties down to the serial
> number.

Ah...the infamous 'if' clause. That is not the same as intelligent handling
of conflicts. That's just closing your eyes and hoping for good to happen
instead of evil. Intelligent handling of conflicts by the protocol is a far
better idea...works quite well too.

>> No, you use the simplest qualifications to start, then to more complex. You
>> refine the search.
> 
> what is simplest to you may not be simplest to someone else.  one person
> wants to find Chinese food, and another wants to find quick food nearby.
> a single hierarchy will not satisfy both.

I will bet one of my really nasty tacky hawaiian shirts that if you ask one
hundred non-engineers how they find things in a phone book, they look for
the base category first. I've tried to set things up the way you are
advocating, it just does not ever work in the real world, where engineers
aren't the only customer. I've actually found that configuring things the
way engineers like it is a bad thing in far too many cases.

>>> that only works if the attributes you are interested in are exposed in the
>>> name, and if the hierarchy is arranged in the order that *you* need in
>>> order to select a printer, etc.
>> 
>> No, it works when they are not exposed in the name as well.
> 
> NO IT DOES NOT.  If I need a color printer the name of the printer isn't
> going to help me find one unless "color" is somehow exposed in its name.
> Similarly if I need a duplexing printer.  And these are very common
> requirements.

Oh stop yelling. For years I had a set of printers with the following names:

HP Laser 5SI
HP Laser 5SI/MX
HP Laser 4SI
Apple Laserwriter Iig
Tektronix Phaser 740
Tektronix Phaser 550

The phasers were the color printers. I had tell new employees no more than
once which color printer was on their floor. If they asked which printer did
duplexing, I told them once. Since all the printers were set up on their
machines, they would most times just see which printers did what, and move
on. You can yell and scream about it, but simple names work. Why? Because
they only ever normally saw five of those printers. The IIg was a fax server
printer.

Even doing work in fortune 500 companies, I set things up so that no zone
had more than printers. Why? Because IVR experience taught me that no matter
how you name something, people lose track of  list's contents when you give
them more than 4-5 choices. Hell, I wrote IVR systems, and to this day, I
lose track after 4-5 items. Thank god for fingers.

> 
>> And I didn't
>> invent NBP or the Chooser, but I haven't seen anything else that user grock
>> as well. People want simple, but that doesn't mean they are stupid. Again,
>> in a network situation, printers are static devices.
> 
> NOT IN AN AD HOC NETWORK they are not.

You tell me how many hi-speed lasers get shut off and moved around all the
time The things weigh a friggin TON...they don't move at all, therefore,
they never lose their name. As well, they take a dog's age to warm up, so
they never get turned off, therefore, they never lose their name. If the
printers are ad hoc, then you have one, perhaps two, and it's not an issue
so small a number of choices.

> 
>> They don't move. Once
>> you pick one, you can rely on it being there. Even if it changes IP
>> addresses, it *doesn't matter* because you are using the name, not the
>> address. So the printer has to be turned off long enough for something else
>> to claim that name in that zone.
> 
> you mean, like when there's a power failure for several hours, like there
> was yesterday where I live?

UPS's and backup power are just ALL the rage in the 21st century, you should
really try it. In ten+ years of IT, I've had exactly one power outage that
lasted more than two hours. The generation plant next door had a fire. It
was really cool...and we had our UPS's handle it nicely.

>> The humans have to like it and use it, or it's a failure. I doubt mDNS and
>> DNS-SD is overloading DNS anytime soon...it's quite robust.
> 
> They are trying to shove a lookup operation with differnet semantics
> and failure conditions than DNS into the DNS API.  That's overloading.

How? It can't handle a SRV record that reads "4th floor
HP._ipp.tcp.mit.edu"? You mean to say that a system that handles *billions*
of lookups every day is going to fall down because we use it to find
printers...which is just a specific type of host anyway? If that's the case,
then screw mDNS, you should be fixing DNS period.

>>> no, that's not sufficient.  and while you might argue that the user's
>>> computer
>>> can poll every computer in the "user's zone" to see what its capabilities
>>> are
>>> so that it can actually make an intelligent selection when there are more
>>> than a few printers in the "user's zone" - it doesn't scale very well to
>>> zones
>>> of the size contemplated by zeroconf - much less for use on non-ad hoc
>>> networks.
>> 
>> Um, it scales really well actually.
> 
> to networks with 1000 hosts?

Anyone who puts 1000 hosts in a flat hierarchy is an idiot, and will soon be
fired, regardless of browser protocol. You wouldn¹t run that on an ad hoc
network, it would be a bad implementation. DNS-SD isn't restricted to ad
hoc, it just works there very well too.

> 
>> You don't poll for individual
>> capabilities. 
> 
> well, either you get a list of printers and poll for capabilities, or you
> expose
> the capabilities in the names of the printers, or you use a service discovery
> protocol.  which is it?

Service discover...give me a list of printers. If there are too many, the
humans yell at the humans, and the humans fix it. But I'm telling you that
in the world, you search for printers. Printers near you. If they happen to
have good names, great, but you search for printers. DNS-SD doesn't preclude
meaningful names, but they aren't the showstoppers you want them to be.

> 
>> Sheesh, if you want that, then why bother with browsing, let's
>> all just use LPR, it's about as usable as SLP is at the moment, and name
>> every printer 
>> "HP_Laser_5SI_MX_mopier_600DPI_envelope_feeder_1500_sheet_hi_cap_tray_256MB_
>> RAM_9GB_hard_disk_duplexing_with_stapler_and_five_bin_output_tray"
>> 
>> *NO ONE* is going to look at that garbage twice...
> 
> I agree with that but I never said that they would.  I'm just saying that
> the DNS query API is a poor interface for discovering services on an ad hoc
> network.

It's a great way to do it, it does it now. You just aren't seeing that. But
it does. SLP sucks ass to implement. I've tried to. I'd rather go back to
Netware 3, it had better tools.

john

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

---

From: Keith Moore <[email-masked]>
Date: Thu, 01 Aug 2002 02:28:54 -0400

> of conflicts. 

no it's not.  But DNS does what it does, warts and all.  That's not a justification
for screwing it up even further.

> the base category first. 

yes, they'll look for restaurants which in a moderately sized city will have
hundreds of entries.  after that, however, they may look for chinese
restaurants or they might look for restaurants arranged by locality.
they're listed in multiple orders for a reason, you know.

> I've tried to set things up the way you are
> aren't the only customer. 

the only thing I'm strongly advocating in this case is to NOT SCREW UP DNS
or applications that use the DNS query interface.  have you really tried to 
set things up so that applications that query DNS really get DNS and found
that things don't work well that way?  because I find that they do.

> Oh stop yelling. For years I had a set of printers with the following names:

you're thinking a stable network again.  we don't need zeroconf for stable
networks, we need it for ad hoc networks and initial configuration.  

> was really cool...and we had our UPS's handle it nicely.

most organizations don't have UPSes for every system - certainly not for
laser printers (those things *eat* power)

and for what it's worth, 4-8 hour power failures are fairly common in some
places. (we have lots of trees here, and for the most part, we happen to like 
'em...  but occasionally we also have violent storms and some of the trees 
fall on power lines.  not much we can do about it other than to bury the
power lines, and that's too expensive)

> printers...which is just a specific type of host anyway? 

no I'm saying that you'll be screwing applications because you're expecting
them to do things with the DNS interface that the DNS interface wasn't
designed to do.  now if you make this a separate protocol with a separate
programming interface, I have less problem with it (though I think it's 
still a fairly brain-dead design, but at least it won't screw up other things)

> fired, regardless of browser protocol. 

are you talking DNS hierarchy or IP router hierarchy?  because 1000 hosts
in a subnet can be quite reasonable. 

(fwiw, the 1000 host figure is rounded from the v4 linklocal spec - if we
expect ad hoc networks to support 1000 hosts then it seems reasonable
to make similar expectations of the resource discovery mechanism - either
that or derate the overall expectations for the size of ad hoc networks)

> It's a great way to do it, it does it now. You just aren't seeing that. 

No, I'm seeing people try to break DNS and applications on a large scale.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 01 Aug 2002 03:49:30 -0400

> for screwing it up even further.

This isn't 'screwing it up'. In fact, it's a lot better than creating
multiple complex protocols that require separate tools to manage and deal
with, that use their own methodology, because heaven knows, you can't just
adapt an existing standard...oh no, we have to have a completely different
protcol, and over engineer it so that it's never done, and impossible to
implement sanely across platforms

> they're listed in multiple orders for a reason, you know.

But they all live under restaurants. They don't live under 'buildings, zoned
commercial, with active health permits, that serve food, that is chinese'.
You start simple, and work your way to complex. Proper browsing is the same
way.

> that things don't work well that way?  because I find that they do.

Nope. I've found it works well, but can suck to set up. DNS-SD and mDNS help
with that from what I can tell, and it's NOT going to screw up DNS. DNS is
robust enough to handle telling me the IP address of a printer as well as a
web server. Again, if it's that fragile, then why not replace DNS, since
it's obviously not robust enough to handle any extensions at all.

> networks, we need it for ad hoc networks and initial configuration.

You need it for stable networks too. DHCP sucks to set up and use, so does
manual IPs. Manual IPs suck less than DHCP but not by much. Using DHCP to
get your DNS servers sucks, it never works consistently.

> laser printers (those things *eat* power)

Not in standby mode they don't

> power lines, and that's too expensive)

Massachusetts has trees too.....we also have line crews. In any event,
zeroconf doesn't preclude you from statically assigning things.

> still a fairly brain-dead design, but at least it won't screw up other things)

Oh great...so now I have to reconfigure my routers and wait for how many
years to debug this brand new magical protocol that will make IP work like
APpleTalk...I've been waiting for a long time now...SLP ain't it. What
magical protocol will work like this. And won't require router/firewall/etc
reconfiguration? And won't be waiting forever for clients...I don't see a
lot of SLP clients out there. Hell *Apple* isn't using it for print
browsing, and they helped create the bloody thing! and unless the
Applications are doing funky things with DNS *anyway*, how will allowing for
new features break them?

> in a subnet can be quite reasonable.

1000 hosts in a flat subnet is still quite stupid. At that point, you are
begging for network problems. That's why you then subnet even further, and
use DNS to help you. Using flat DNS hierarchies and 1000 host subnets is
just dumb.

> that or derate the overall expectations for the size of ad hoc networks)

That level of ad hoc is going to be highly uncommon, but even so, I have
more confidence in DNS's ability to scale than I do anything that so far is
a dream.

> No, I'm seeing people try to break DNS and applications on a large scale.

I have yet to see convincing proof that that will happen. So far, every
other attempt at what Stuart is advocating has been feces, so I'm liking the
DNS theory a lot, *especially* as an IT geek.

john

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

---

From: "Philip Nye" <[email-masked]>
Date: Thu, 1 Aug 2002 11:26:16 +0100

This thread is heading into the weeds and seems to me to miss the point almost
entirely.

It is the job of user interface designers to sort, filter, process and
otherwise munge the information they are dealing with before presenting it to
the user. They do so whether they are using SLP or DNS-SD. If they have a rich
set of information they can choose to discard or hide some of it at will. If
they have a sparse set it not so easy to create more and the user can be left
wanting.

If there are only 4 or 5 printers available then the name might be enough. If
there are 40 or 50 then having further information available allows the clever
software designer - not the user - to find ways to partition the choices and
make them more presentable.

If the user habitually uses PrinterA but needs for a special purposes every
few months or years to find one with a stapler then that information should be
available without having to call a human. This doesn't mean that the user
interface has to thrust the fact that the printer has a stapler down the
user's throat all the time. There are plenty of ways user interfaces do this
sort of thing all the time.

There are two extremes of philosophy at work here:
1. Concentrate all the information gathering into a single place where it can
be accessed and processed together. SLP tends to this extreme approach.

2. Put just enough at each level to get you to the next: Having found printers
through DNS-SD, you use a print queueing protocol to find whether it supports
postscript, you then use postscript to find its screen resolution etc. If you
are interested in file servers on the other hand you discover them with DNS-SD
but then use FTP, SMB, NFS etc to find more about them.

The trouble with method 1 is knowing where to draw the line - do you present
all the file names on a server as attributes in SLP? or just its volumes? or
simply its name?. The trouble with method 2 is that a generalised browser such
as the chooser or even the finder has to "know" all those other protocols or
techniques to be able to present more information. In practice of course most
solutions are a compromise between the two.

Philip Nye

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 01 Aug 2002 06:45:45 -0400

> they have a sparse set it not so easy to create more and the user can be left

In general, the more work that has to be done to implement a protocol, the
less likely you will see it implemented at all. TCP/IP is dead simple to
implement...of course, it's also quite stupid at some levels as well, but
the simplicity leads to wider, and faster adoption. There have been a number
of 'rich' protocols for this sort of thing, yet almost none of them are in
use today. That is not a minor point.

> make them more presentable.

But how, without creating an overly complex browser interface? Even with
IPP, all you get is an icon, and a name. That's all most browser interfaces
use. How do you easily and quickly display this information that you are
regarding as critical? Do you gather it all on the initial list build and
then display it in the browser window? That creates a lot of traffic every
time a browser window is opened, since a high end printer can have a rather
large number of characteristics. If you figure on ten potential data fields
at a K per field, then that's 10K per device that's collected, used or not.
If you only collect it when the device is selected in the printer, then you
don't have the large bursts, but now every click is sending requests,
replies, verification, oops a collision, resend the packets...the GUI not
withstanding, if you start dumping that kind of traffic, IT admins are going
to shut your protocol down with prejudice.

As well, the protocol should allow for simple partitioning of presentation,
ala AppleTalk.

> sort of thing all the time.

Um...if you decide to advertise printer capabilities while browsing, you're
advertising them all the time, or none of the time. You can use the name of
the printer, within reason, to do this. But I've found that if treated
intelligently, most users act that way.

> be accessed and processed together. SLP tends to this extreme approach.

And SLP's inability to be anything but an interesting test case in the real
world shows the value in this. It makes implementation harder.

> simply its name?.

The real problem is that OS X may do it one way, OS Y another, and OS Z a
third way, unless you require all information to be displayed as a
compatibility requirement. One way, you can have completely different views
of the same thing, the other way, you can't browse for printers on anything
smaller than a 21" screen.

> The trouble with method 2 is that a generalised browser such

But the 'knowing' is *far* simpler in method 2, and because it is simpler,
you get a much better rate of consistent implementations, which makes the
humans happy.

john

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

---

From: "Philip Nye" <[email-masked]>
Date: Thu, 1 Aug 2002 12:57:02 +0100

> From: "John C. Welch" <[email-masked]>
> >
> But how, without creating an overly complex browser interface?

This is for the GUI designer to decide but if you really need some examples:
- A context menu can give further options when a printer is selected.
- The browser window can have a "View" menu which allows the user to make
selections.
- A "Find" option can be provided with hierarchical options.
- A preferences setting can hide printers which don't have A4 (or whatever)

> Even with

The browser only has to query as much data as it needs to fulfil the user
requirements. If there are only one or two printers out there it just needs
their names. If there are 50 then some further information is needed - but not
all of it.

SLP with its generalised profiles provides one way to do this - it doesn't
force all those attributes on you unless asked - but it is certainly not the
only way.

> intelligently, most users act that way.

You wouldn't say that about file browsing, why should it be so for printers?
Many users choose only to view a filename and icon. Others like to see
file-size, or creation date, or owner, or file type or some combination of
these - but they change their choice according to circumstances. A user will
often choose to see thumbnails of their pictures some of the time and a size
or date sorted list at others.

> you get a much better rate of consistent implementations, which makes the

The "knowing" grows with the problem in method 2. The more kinds of thing to
be discovered, the more completely different protocols and techniques need to
be implemented. Even printers have many alternative protocols available.
Method 1 imposes a higher initial threshold, but once over that the problem
does not grow anything like so fast.

> smaller than a 21" screen.

?? I don't follow this at all. Of course different OSes do things differently.

Personally (and as a great Mac advocate in former times) I always hated the
Chooser - largely because its clunky interface wasn't nearly so good as the
Finder - and I had to perform a mental context switch to go there. It always
felt like a throwback to System-4. Windows' integration of network browsing
with Explorer is much better in principle - though typically badly executed.

There! I never thought I would find myself advocating Windows anything! I
haven't used a Mac much for a few years now though, so things might have
changed there too.

> smaller than a 21" screen.

This is only relevant to Zeroconf because it is a bad thing for the IETF or
Zeroconf to be advocating two solutions which overlap so badly. If they
overlapped completely it would probably be easy to pick one. If they hardly
overlapped at all, it would be easy to pick both.

Philip Nye

---

From: Keith Moore <[email-masked]>
Date: Thu, 01 Aug 2002 09:58:38 -0400

> implement sanely across platforms

on the other hand when you overload an existing protocol you inevitably 
get conflicts between the different uses of that protocol - as they 
try to pull the protocol in different directions.  so for instance we
have SIP people making really poorly thought out extensions to MIME 
headers because SIP decided to use part of MIME and then they decided
it wasn't sufficient for their purposes so they decided they could extend
all of MIME.  similiarly zeroconf wants to make IP addresses and DNS
work differently than they were intended - never mind that this breaks
applications, it's justified because it's easier than doing engineering.
yeah, right.

> You start simple, and work your way to complex. Proper browsing is the same

we've known for decades that there are fundamental limits to hierarchical
tree-walking as a search mechanism.   from what you've said about network
configuration, your solution to the problem of browsing for food sources 
would apparently be to limit the number of chinese restaurants...

> with that from what I can tell, and it's NOT going to screw up DNS. 

not if I can help it, it won't.

> get your DNS servers sucks, it never works consistently.

zeroconf isn't going to get rid of DHCP, because there are large numbers of
apps that you can't run with linklocal addresses.  stateless autoconfiguration
for v6 might help you get rid of DHCP, but that's not a product of zeroconf.

> Not in standby mode they don't

so they're going to stop printing just because there was a power failure
elsewhere?  it makes more sense to shut them down.  it certainly doesn't
make sense to supply each printer with a UPS just so it can keep its name...

> APpleTalk...I've been waiting for a long time now...SLP ain't it. 

well, DNS ain't it either.

> use DNS to help you

DNS doesn't help you subnet.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Thu, 01 Aug 2002 10:53:27 -0400

> applications, it's justified because it's easier than doing engineering.

What's so different? You're making a DNS request for information. It's a
different type of information, but all you want to do is find out if

a)  your host name already exists in your zone. Nothing major there.
b)  if there are any hosts that respond to a ._printer or a .ipp request.
Conceptually, this is not that much different than looking for something to
respond to a www request or an ftp request.

It is also easy to extend poorly, much easier than well. However, from the
administration POV, which is my domain, this is
a) simple 
b) coherent 
c) easy to understand and explain

SLP fails a and c, as do most other over-engineered protocols.

I also have found that simple tends to not break as easy as complex. But
then, I've not found too many engineers that could resist the urge to put
one more thing in to make anything cover every possible situation. OSI is a
*classic* example of this. The OSI protocol was far more capable, had more
features, was designed to handle everything well, and as a result, handled
absolutely nothing well, and was destroyed by a simplistic dinky thing like
TCP/IP.

> would apparently be to limit the number of chinese restaurants...

Nope. Geography takes care of that. Phone books (domains) cover a specific
geographic area. That limits things before you even start. Bigger cities can
even break things down further geographically. That way, you aren't getting
hits from restaurants that are thirty miles or more away, unless you chose
to. So, for things that aren't dynamic, put them in non-dynamic zones.
Vanilla DNS can exist just fine with zeroconf, unless Stuart is having a
complete brain spasm about this, which I highly doubt.

> not if I can help it, it won't.

No, your solution is to do *nothing* until perfection is achieved. That's
unacceptable. To get rid of AppleTalk browsing, you need a replacement.
Forcing people to memorize URLs is unacceptable. Requiring IT departments to
write custom interfaces for stuff is unacceptable. You will *never* achieve
perfection, nor purity, not in this universe anyway. So, you take the
simplest route that gets the job done, preferably using existing tools.
Reinventing the wheel is never the right solution.

> for v6 might help you get rid of DHCP, but that's not a product of zeroconf.

It doesn't have to either. It can coexist with DHCP just fine. That's
another reason why it is an elegant solution...it doesn't require throwing
away what works. It simply fixes what is broken.

> make sense to supply each printer with a UPS just so it can keep its name...

But then, you don't *have* to have dynamic names in that instance. You can
have static names, just like now. Zeroconf will work correctly with them.

> well, DNS ain't it either.

It's either DNS or LDAP. Those are the only two protocols that will handle
this correctly. *Everyone* supports DNS far better than they do LDAP.
Besides, LDAP has to bury Netinfo first.

But since you are rabidly against zeroconf, I eagerly await your complete
solution/alternative to zeroconf.

> DNS doesn't help you subnet.

Obviously. But if you set up your domain hierachy in a real hierachal
fashion rather than the standard flat host.something.com for everything,
then you can use DNS to make your life easier, and simpler via search
domains.

john

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 02 Aug 2002 14:36:06 -0400

> No, your solution is to do *nothing* until perfection is achieved.

you don't even understand how NATs work - don't tell *me* what my solution is.

Proposed standards have to have no technical problems  with respect to 
the requirements placed on them.  This stuff has severe technical 
problems, and so it doesn't meet the requirements.

Keith

---

From: "John C. Welch" <[email-masked]>
Date: Fri, 02 Aug 2002 15:27:13 -0400

> you don't even understand how NATs work - don't tell *me* what my solution is.

Whoa...okay, this is a technical argument. Name calling is not going to do
anything constructive. I meant nothing personal, but what you are talking
about is the "perfect solution". Everyone would love it, but it won't ever
happen. You have to figure out the best solution for the existing problem
that will cause fewer problems than they fix. TCP/IP isn't the perfect
solution, but it works really well. DNS isn't the perfect solution to name
resolution, but it works really well. Zeroconf looks to fit that category.

> problems, and so it doesn't meet the requirements.

You have yet to list concrete example of it failing to work. There are
enough "what if" problems in any solution to any problem that could keep any
solution from ever being implemented for any reason, even the wheel. So you
triage. There are some potential issues, but the spec and information I've
seen  look to have them under control in a logical manner. As well, it can
be explained thoroughly  and clearly in a relatively short amount of time.
That is a huge point in it's favor, as most real-world solutions that work
well can be explained in the same manner.

john

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 02 Aug 2002 16:36:11 -0400

> about is the "perfect solution". 

NO I AM NOT.  I'm just saying that what you are trying to do will cause
harm.  And for you to try to speak on my behalf is *really* offensive.

Keith

---

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

> harm.  And for you to try to speak on my behalf is *really* offensive.

Um..okay, obviously, you are getting angry here, and since I'm not sure why,
I'm ending my participation in this thread. You have yet to clearly
establish the harm that zeroconf will cause, nor have you yet come up with a
clear alternative. Secondly, I'm *not* trying to speak on your behalf. That
would require me to misidentify myself as your representative, which I have
clearly not done. I'm pointing out what it looks, *to me* what you are
saying. 

Again, this is/was a technical argument, not a personal attack.

john

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 02 Aug 2002 17:54:41 -0400

> You have yet to clearly establish the harm that zeroconf will cause, 
> nor have you yet come up with a clear alternative.

zeroconf is many things.

I've spoken out quite extensively on the problems with v4 linklocal
addresses, and recommended some reasonable solutions to those problems.

other things like mdns and dns service discovery need similar attention.

but I agree that this thread isn't accomplishing anything useful, so
I'll stop too.

Keith

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 6 Aug 2002 14:36:28 -0700 (PDT)

> but I agree that this thread isn't accomplishing anything useful, so

Actually, I think some valid points were raised, but it's probably best to
take the discussion to the forums that can actually deal with the issues
in depth.