From owner-zeroconf@merit.edu Thu Aug 1 01:18:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28698 for ; Thu, 1 Aug 2002 01:18:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BA35B91299; Thu, 1 Aug 2002 01:19:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 85B31912FA; Thu, 1 Aug 2002 01:19:54 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3EF0691299 for ; Thu, 1 Aug 2002 01:19:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 20C5F5DDFF; Thu, 1 Aug 2002 01:19:53 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id A8A6B5DDCE for ; Thu, 1 Aug 2002 01:19:52 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id BAA00215 for ; Thu, 1 Aug 2002 01:19:52 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id BAA15419 for ; Thu, 1 Aug 2002 01:19:52 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id BAA26841 for ; Thu, 1 Aug 2002 01:19:51 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Thu, 01 Aug 2002 01:19:50 -0400 Subject: Re: On attribute-based queries From: "John C. Welch" To: Message-ID: In-Reply-To: <200208010400.g7140Bk00501@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA28698 On 08/01/2002 00:00, "Keith Moore" 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 owner-zeroconf@merit.edu Thu Aug 1 02:28:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA08522 for ; Thu, 1 Aug 2002 02:28:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7F2F29129A; Thu, 1 Aug 2002 02:28:57 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4694E912FA; Thu, 1 Aug 2002 02:28:57 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C44D9129A for ; Thu, 1 Aug 2002 02:28:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F03555DE0B; Thu, 1 Aug 2002 02:28:55 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id BBCD35DDF6 for ; Thu, 1 Aug 2002 02:28:55 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g716Ssk00919; Thu, 1 Aug 2002 02:28:54 -0400 (EDT) Message-Id: <200208010628.g716Ssk00919@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: zeroconf@merit.edu Subject: Re: On attribute-based queries In-reply-to: (Your message of "Thu, 01 Aug 2002 01:19:50 EDT.") Date: Thu, 01 Aug 2002 02:28:54 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > >> 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. no it's not. But DNS does what it does, warts and all. That's not a justification for screwing it up even further. > >> 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. 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 > advocating, it just does not ever work in the real world, where engineers > 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. > >>> 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: 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. > >> 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. 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) > >> 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? 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) > > 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. 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) > > 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. No, I'm seeing people try to break DNS and applications on a large scale. Keith From owner-zeroconf@merit.edu Thu Aug 1 03:48:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09475 for ; Thu, 1 Aug 2002 03:48:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6F2D99120A; Thu, 1 Aug 2002 03:49:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3CFAE9121F; Thu, 1 Aug 2002 03:49:34 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0C4219120A for ; Thu, 1 Aug 2002 03:49:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EEC715DE1C; Thu, 1 Aug 2002 03:49:32 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 74E9C5DE0D for ; Thu, 1 Aug 2002 03:49:32 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id DAA27546 for ; Thu, 1 Aug 2002 03:49:32 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id DAA20817 for ; Thu, 1 Aug 2002 03:49:31 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id DAA18588 for ; Thu, 1 Aug 2002 03:49:31 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Thu, 01 Aug 2002 03:49:30 -0400 Subject: Re: On attribute-based queries From: "John C. Welch" To: Message-ID: In-Reply-To: <200208010628.g716Ssk00919@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/01/2002 02:28, "Keith Moore" wrote: > Ah...the infamous 'if' clause. That is not the same as intelligent handling >> 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. 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 > 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. 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. > >> 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. > > 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. 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. >>> 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: > > 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. 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. >> 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. > > most organizations don't have UPSes for every system - certainly not for > laser printers (those things *eat* power) Not in standby mode they don't > > 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) Massachusetts has trees too.....we also have line crews. In any event, zeroconf doesn't preclude you from statically assigning things. >> 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? > > 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) 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? > >>> 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. > > are you talking DNS hierarchy or IP router hierarchy? because 1000 hosts > 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. > > (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) 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. > >>> 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. > > 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 owner-zeroconf@merit.edu Thu Aug 1 06:25:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19476 for ; Thu, 1 Aug 2002 06:25:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 19E9C912FB; Thu, 1 Aug 2002 06:26:25 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DB524912FC; Thu, 1 Aug 2002 06:26:24 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DFEF7912FB for ; Thu, 1 Aug 2002 06:26:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C59B65DE4C; Thu, 1 Aug 2002 06:26:23 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 6FF795DE4B for ; Thu, 1 Aug 2002 06:26:23 -0400 (EDT) Received: from procyon (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 6D5DD59882; Thu, 1 Aug 2002 11:26:19 +0100 (BST) Message-ID: <004d01c23945$de9f3e60$5801a8c0@localdomain> From: "Philip Nye" To: "John C. Welch" , References: Subject: Re: On attribute-based queries Date: Thu, 1 Aug 2002 11:26:16 +0100 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit 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 owner-zeroconf@merit.edu Thu Aug 1 06:45:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21448 for ; Thu, 1 Aug 2002 06:45:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 24C96912FC; Thu, 1 Aug 2002 06:45:50 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E022E912FD; Thu, 1 Aug 2002 06:45:49 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6AECF912FC for ; Thu, 1 Aug 2002 06:45:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 47CFD5DE4E; Thu, 1 Aug 2002 06:45:48 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id DB4405DDC1 for ; Thu, 1 Aug 2002 06:45:47 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id GAA25626 for ; Thu, 1 Aug 2002 06:45:47 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id GAA23416 for ; Thu, 1 Aug 2002 06:45:47 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id GAA08169 for ; Thu, 1 Aug 2002 06:45:46 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Thu, 01 Aug 2002 06:45:45 -0400 Subject: Re: On attribute-based queries From: "John C. Welch" To: Message-ID: In-Reply-To: <004d01c23945$de9f3e60$5801a8c0@localdomain> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/01/2002 06:26, "Philip Nye" wrote: > 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. 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. > > 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. 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. > > 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. 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. > > 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. 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. > > 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 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 > 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. 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 owner-zeroconf@merit.edu Thu Aug 1 07:56:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26498 for ; Thu, 1 Aug 2002 07:56:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E52ED912FD; Thu, 1 Aug 2002 07:57:05 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B4914912FE; Thu, 1 Aug 2002 07:57:05 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 92847912FD for ; Thu, 1 Aug 2002 07:57:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 776D45DE51; Thu, 1 Aug 2002 07:57:04 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from douglas.ukservers.net (douglas.ukservers.net [217.10.138.220]) by segue.merit.edu (Postfix) with ESMTP id 002525DE38 for ; Thu, 1 Aug 2002 07:57:03 -0400 (EDT) Received: from procyon (213-152-45-185.dsl.eclipse.net.uk [213.152.45.185]) by douglas.ukservers.net (Postfix) with ESMTP id 5C5005988B; Thu, 1 Aug 2002 12:57:05 +0100 (BST) Message-ID: <007301c23952$8c7255c0$5801a8c0@localdomain> From: "Philip Nye" To: "John C. Welch" , References: Subject: Re: On attribute-based queries Date: Thu, 1 Aug 2002 12:57:02 +0100 Organization: Engineering Arts MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit > From: "John C. Welch" > > > > 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. > > 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 > 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. 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. > > 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. > > 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. 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. > > 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. > > 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. 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. > 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. ?? 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. > 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. 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 owner-zeroconf@merit.edu Thu Aug 1 09:57:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01132 for ; Thu, 1 Aug 2002 09:57:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3F56891280; Thu, 1 Aug 2002 09:58:41 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 06C4491281; Thu, 1 Aug 2002 09:58:40 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D8F3F91280 for ; Thu, 1 Aug 2002 09:58:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B786B5DE62; Thu, 1 Aug 2002 09:58:39 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 817135DE5C for ; Thu, 1 Aug 2002 09:58:39 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g71Dwck25093; Thu, 1 Aug 2002 09:58:38 -0400 (EDT) Message-Id: <200208011358.g71Dwck25093@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: zeroconf@merit.edu Subject: Re: On attribute-based queries In-reply-to: (Your message of "Thu, 01 Aug 2002 03:49:30 EDT.") Date: Thu, 01 Aug 2002 09:58:38 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > 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 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. > > 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. > > 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. 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... > > 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. > > 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. not if I can help it, it won't. > >>> 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: > > > > 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. > > 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. 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. > >> 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. > > > > most organizations don't have UPSes for every system - certainly not for > > laser printers (those things *eat* power) > > 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... > >> 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? > > > > 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) > > 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. well, DNS ain't it either. > >>> 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. > > > > are you talking DNS hierarchy or IP router hierarchy? because 1000 hosts > > 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 DNS doesn't help you subnet. Keith From owner-zeroconf@merit.edu Thu Aug 1 11:09:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03421 for ; Thu, 1 Aug 2002 11:09:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 853F091218; Thu, 1 Aug 2002 11:10:24 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 571509122A; Thu, 1 Aug 2002 11:10:24 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5514091218 for ; Thu, 1 Aug 2002 11:10:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3E05A5DE77; Thu, 1 Aug 2002 11:10:23 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from zsc3s004.nortelnetworks.com (h65s138a81n47.user.nortelnetworks.com [47.81.138.65]) by segue.merit.edu (Postfix) with ESMTP id 9C8655DDB7 for ; Thu, 1 Aug 2002 11:10:22 -0400 (EDT) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zsc3s004.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g71FAK125378 for ; Thu, 1 Aug 2002 08:10:20 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Thu, 1 Aug 2002 08:10:20 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C034FD468@zsc3c032.us.nortel.com> From: "Venkatesh Raju" To: zeroconf@merit.edu Subject: RE: On attribute-based queries Date: Thu, 1 Aug 2002 08:10:20 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2396D.8D419860" Sender: owner-zeroconf@merit.edu Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2396D.8D419860 Content-Type: text/plain; charset="iso-8859-1" It appears that for some people the universe is "Appletalk-replacement" and "Printers". In this confined universe it will be difficult to argue the merits of anything over DNS. You have to expand your horizon and keep-it-simple is not an excuse. ------_=_NextPart_001_01C2396D.8D419860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: On attribute-based queries

It appears that for some people the universe is = "Appletalk-replacement" and "Printers".  In = this confined universe it will be difficult to argue the merits of = anything over DNS.  You have to expand your horizon and = keep-it-simple is not an excuse.

------_=_NextPart_001_01C2396D.8D419860-- From owner-zeroconf@merit.edu Thu Aug 1 11:14:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03499 for ; Thu, 1 Aug 2002 11:14:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0FB9491210; Thu, 1 Aug 2002 11:03:24 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5BAF91218; Thu, 1 Aug 2002 11:03:23 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C16C391210 for ; Thu, 1 Aug 2002 11:03:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AEC8D5DE77; Thu, 1 Aug 2002 11:03:22 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 4B1E95DDB7 for ; Thu, 1 Aug 2002 11:03:22 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA19587 for ; Thu, 1 Aug 2002 11:03:21 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA21335 for ; Thu, 1 Aug 2002 10:58:22 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA25260 for ; Thu, 1 Aug 2002 10:53:28 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Thu, 01 Aug 2002 10:53:27 -0400 Subject: Re: On attribute-based queries From: "John C. Welch" To: Message-ID: In-Reply-To: <200208011358.g71Dwck25093@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/01/2002 09:58, "Keith Moore" wrote: > 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. 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. >> 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. > > 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... 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. >> 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. > > 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. > >> 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. > > 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. 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. >>> most organizations don't have UPSes for every system - certainly not for >>> laser printers (those things *eat* power) >> >> 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... 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. >> 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. > > 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. >> 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 > > 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 owner-zeroconf@merit.edu Thu Aug 1 11:23:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03690 for ; Thu, 1 Aug 2002 11:23:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C63A29122A; Thu, 1 Aug 2002 11:24:04 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 91F9091250; Thu, 1 Aug 2002 11:24:04 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7593A9122A for ; Thu, 1 Aug 2002 11:24:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5F7825DE77; Thu, 1 Aug 2002 11:24:03 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id F2BEB5DDB7 for ; Thu, 1 Aug 2002 11:24:02 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA22437 for ; Thu, 1 Aug 2002 11:24:02 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA27133 for ; Thu, 1 Aug 2002 11:24:02 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id LAA10457 for ; Thu, 1 Aug 2002 11:24:01 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Thu, 01 Aug 2002 11:24:01 -0400 Subject: Re: On attribute-based queries From: "John C. Welch" To: Message-ID: In-Reply-To: <7B802811BE77D51189910002A55CFD2C034FD468@zsc3c032.us.nortel.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/01/2002 11:10, "Venkatesh Raju" wrote: > It appears that for some people the universe is "Appletalk-replacement" and > "Printers". In this confined universe it will be difficult to argue the > merits of anything over DNS. You have to expand your horizon and > keep-it-simple is not an excuse. I've yet to see any protocol implement AppleTalk's services as elegantly. AppleTalk 'just worked'. None of the so-called replacements 'just work'. They 'eventually work with a lot of support'. Zeroconf is the first thing that I've seen that looks to 'just work'. "Just working" is one of, if not *the* major requirements for what we are talking about. If you have to do more than activate a wireless link, or plug in an ethernet cable to get basic services, It's too complex for what it needs to do. Secondly, "Keep It Simple, Silly" is a very good rule to follow in anything. I have yet to hear anyone explain SLP and the like completely and coherently in under 30 minutes. I've seen zeroconf done in 10-15...simple is FAR harder to do well than complex. john -- John C. Welch IT Manager MIT Police (617) 253 - 3093 work (508) 579 - 7380 cell (617) 253 - 8822 fax From owner-zeroconf@merit.edu Fri Aug 2 14:08:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29194 for ; Fri, 2 Aug 2002 14:08:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 76D7691217; Fri, 2 Aug 2002 14:08:13 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3E96891218; Fri, 2 Aug 2002 14:08:13 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2A40E91217 for ; Fri, 2 Aug 2002 14:08:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 116675DF3B; Fri, 2 Aug 2002 14:08:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id A16F15DE52 for ; Fri, 2 Aug 2002 14:08:11 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA08635 for ; Fri, 2 Aug 2002 14:08:11 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA11736 for ; Fri, 2 Aug 2002 14:08:10 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA03099 for ; Fri, 2 Aug 2002 14:04:38 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Fri, 02 Aug 2002 14:04:37 -0400 Subject: Other print vendors From: "John C. Welch" To: Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Just curious if anyone has heard from Xerox supporting Zeroconf directly? john -- John C. Welch IT Manager MIT Police (617) 253 - 3093 work (508) 579 - 7380 cell (617) 253 - 8822 fax From owner-zeroconf@merit.edu Fri Aug 2 14:35:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00246 for ; Fri, 2 Aug 2002 14:35:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1897C91218; Fri, 2 Aug 2002 14:36:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D67A59121A; Fri, 2 Aug 2002 14:36:10 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ADE1E91218 for ; Fri, 2 Aug 2002 14:36:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8ACE45DE60; Fri, 2 Aug 2002 14:36:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 042205DE09 for ; Fri, 2 Aug 2002 14:36:08 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g72Ia6k23030; Fri, 2 Aug 2002 14:36:06 -0400 (EDT) Message-Id: <200208021836.g72Ia6k23030@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: zeroconf@merit.edu Subject: Re: On attribute-based queries In-reply-to: (Your message of "Thu, 01 Aug 2002 10:53:27 EDT.") Date: Fri, 02 Aug 2002 14:36:06 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > 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 owner-zeroconf@merit.edu Fri Aug 2 15:26:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02716 for ; Fri, 2 Aug 2002 15:26:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 83C0B9121E; Fri, 2 Aug 2002 15:27:17 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 59ADC91226; Fri, 2 Aug 2002 15:27:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5190D9121E for ; Fri, 2 Aug 2002 15:27:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3EE555DF41; Fri, 2 Aug 2002 15:27:16 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id D27B35DE89 for ; Fri, 2 Aug 2002 15:27:15 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA17490 for ; Fri, 2 Aug 2002 15:27:15 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA23062 for ; Fri, 2 Aug 2002 15:27:14 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA06645 for ; Fri, 2 Aug 2002 15:27:14 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Fri, 02 Aug 2002 15:27:13 -0400 Subject: Re: On attribute-based queries From: "John C. Welch" To: Message-ID: In-Reply-To: <200208021836.g72Ia6k23030@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/02/2002 14:36, "Keith Moore" wrote: >> 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. 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. > > 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. 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 owner-zeroconf@merit.edu Fri Aug 2 16:35:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05392 for ; Fri, 2 Aug 2002 16:35:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F1A0B91220; Fri, 2 Aug 2002 16:36:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF75D91226; Fri, 2 Aug 2002 16:36:14 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9EF2591220 for ; Fri, 2 Aug 2002 16:36:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 85E835DEED; Fri, 2 Aug 2002 16:36:13 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 1F1BD5DDF3 for ; Fri, 2 Aug 2002 16:36:13 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g72KaBk24699; Fri, 2 Aug 2002 16:36:11 -0400 (EDT) Message-Id: <200208022036.g72KaBk24699@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: zeroconf@merit.edu Subject: Re: On attribute-based queries In-reply-to: (Your message of "Fri, 02 Aug 2002 15:27:13 EDT.") Date: Fri, 02 Aug 2002 16:36:11 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > >> 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. > > 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". 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 owner-zeroconf@merit.edu Fri Aug 2 17:07:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06512 for ; Fri, 2 Aug 2002 17:07:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6703491239; Fri, 2 Aug 2002 17:08:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 34E6A91235; Fri, 2 Aug 2002 17:08:18 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1C74191239 for ; Fri, 2 Aug 2002 17:08:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0685D5DF46; Fri, 2 Aug 2002 17:08:17 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 92F0D5DF3F for ; Fri, 2 Aug 2002 17:08:16 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA22210 for ; Fri, 2 Aug 2002 17:08:16 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA08182 for ; Fri, 2 Aug 2002 17:08:16 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA13264 for ; Fri, 2 Aug 2002 17:05:11 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Fri, 02 Aug 2002 17:05:09 -0400 Subject: Re: On attribute-based queries From: "John C. Welch" To: Message-ID: In-Reply-To: <200208022036.g72KaBk24699@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/02/2002 16:36, "Keith Moore" wrote: >> 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". > > 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. 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 owner-zeroconf@merit.edu Fri Aug 2 17:53:45 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08511 for ; Fri, 2 Aug 2002 17:53:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B7D459123A; Fri, 2 Aug 2002 17:54:44 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 839A79123C; Fri, 2 Aug 2002 17:54:44 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6321B9123A for ; Fri, 2 Aug 2002 17:54:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 44D525DEF1; Fri, 2 Aug 2002 17:54:43 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id D2F1F5DDF3 for ; Fri, 2 Aug 2002 17:54:42 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g72Lsfk25356; Fri, 2 Aug 2002 17:54:41 -0400 (EDT) Message-Id: <200208022154.g72Lsfk25356@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: zeroconf@merit.edu Subject: Re: On attribute-based queries In-reply-to: (Your message of "Fri, 02 Aug 2002 17:05:09 EDT.") Date: Fri, 02 Aug 2002 17:54:41 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > 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 owner-zeroconf@merit.edu Tue Aug 6 13:00:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18594 for ; Tue, 6 Aug 2002 13:00:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7935991252; Tue, 6 Aug 2002 13:01:41 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6B1A591253; Tue, 6 Aug 2002 13:01:34 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AEE2591252 for ; Tue, 6 Aug 2002 13:01:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7CDAD5DDA9; Tue, 6 Aug 2002 13:01:32 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.2]) by segue.merit.edu (Postfix) with ESMTP id CF7615DD8C for ; Tue, 6 Aug 2002 13:01:30 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g76H1GG10839; Wed, 7 Aug 2002 00:01:17 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g76H0bH27512; Wed, 7 Aug 2002 00:00:37 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: List of Service Types In-Reply-To: <200207310557.g6V5vKl09083@scv1.apple.com> References: <200207310557.g6V5vKl09083@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Aug 2002 00:00:37 +0700 Message-ID: <27510.1028653237@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 30 Jul 2002 22:57:25 -0700 From: Stuart Cheshire Message-ID: <200207310557.g6V5vKl09083@scv1.apple.com> | This means that a telnet client can automatically find and display a list | of entities on the network that are advertising that they will accept | telnet connections Maybe I'm missing something obvious, but using the DNS, how exactly is that intended to be accomplished? The DNS is a truly lousy searching protocol, in fact, it is hard to imagine one worse. If you know the exact name that you want, it works just fine. If you don't, it is completely useless. So, if there are 4 or 5 telnet servers (or printers to move towards the more common example that has been being used), we know how to create the name "_telnet._tcp" (or "_printer._tcp" or whatever) - that's defined by the protocol in use. We may know what domain that we're in (in some environments - but assume we do), we may even know of some other domains we might like to look in to find things. Call this "example.com" just for the purposes of argument here. So, I need to find X such that "_telnet._tcp.X.example.com" exists. What's the DNS method to achieve that? I must have missed that sometime. | If you make some future "foobar" product, with which the user can | communicate over an ssh connection, then my ssh client software doesn't | need to know what a "foobar" is, it just needs to know that it can talk | ssh to it. I (as a human being) may know what a "foobar" is, but my ssh | client doesn't need to know. For ssh that might be true. For printers, I'm not sure that it is. I know we get constant queries like "why did that printer print all my postscript file looking like gibberish (which examined is the postscript program to generate the printing) ? Answer: well, that printer doesn't support postscipt, you need to convert it to xxx (or use a printer driver to convert it to xxx) first. Similarly if I'm about to print a photograph, dumping it onto a line printer (even offering me the choice to print it on "printer number 3") isn't exactly useful. The list I'm offered should be just those printers that are capable of printing the data that I want to print. The software can (should be able to) do that kind of filtering before a human gets near the list of choices. | There is precedent for this. Every time a new PostScript network printer | comes out, users don't need a new driver for it (at least this is true on | the Mac). As long as the printer speaks PostScript over AppleTalk | properly, the Apple LaserWriter driver can find it and print on it, even | though this particular printer model may not have even existed when the | Apple LaserWriter driver was written. Yes, this is fine. But on 98% of the printers like that that we have installed, my photo will come out in B&W (greytone). Only one or two of the printers will actually print colour. How does the laserwriter driver do on avoiding letting me (unintentionally anyway) send my nice colour image to a printer that simply cannot cope? kre ps: Stuart, in the IETF we generally don't want to know "Apple's position" we want to know yours. It is fine (if you're able) to tell us "Apple is shipping a product which ..." or even "Apple is about to ship a product which does ...", but corporate positions don't belong. From owner-zeroconf@merit.edu Tue Aug 6 13:11:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19029 for ; Tue, 6 Aug 2002 13:11:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E19D091254; Tue, 6 Aug 2002 13:12:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A50EF91256; Tue, 6 Aug 2002 13:12:28 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A543D91254 for ; Tue, 6 Aug 2002 13:12:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8601C5DDA9; Tue, 6 Aug 2002 13:12:27 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.2]) by segue.merit.edu (Postfix) with ESMTP id 0A9095DDA7 for ; Tue, 6 Aug 2002 13:12:26 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g76HCHG19371; Wed, 7 Aug 2002 00:12:18 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g76HBeH27532; Wed, 7 Aug 2002 00:11:40 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "John C. Welch" Cc: zeroconf@merit.edu Subject: Re: On attribute-based queries In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Aug 2002 00:11:40 +0700 Message-ID: <27530.1028653900@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 01 Aug 2002 11:24:01 -0400 From: "John C. Welch" Message-ID: | I've yet to see any protocol implement AppleTalk's services as elegantly. | AppleTalk 'just worked'. None of the so-called replacements 'just work'. What this means is that no-one has done a good implementation of anything else yet. Once upon a time vinyl LP's "just worked" and there was nothing better that anyone had demonstrated (though there were lots of attempts). Now, vinyl LP's ??? Everything eventually gets replaced by something better. Refusing to countenance that anything could be better is just foolish. | Secondly, "Keep It Simple, Silly" is a very good rule to follow in anything. | I have yet to hear anyone explain SLP and the like completely and coherently | in under 30 minutes. I've seen zeroconf done in 10-15...simple is FAR harder | to do well than complex. "completely" for SLP (as for NBP in appletalk) is hard to do quickly. But for enough to understand how it works, "you ask on the net for any devices that can service your request, which can be simple, or can include extra requirements - anything out there which can handle your request replies, and tells you what it can do, if there's more than one, you pick (however you like, including popping up a "chooser" box if you are actually going to have a human user to select), if there's exactly one, well ... if there's less than one, then you either try for lesser requirements, if possible, or give up." That's it. The rest is all boring detail that you don't need to know to actually understand how it works. Sound rather line NBP? Aside from NBP being only able to locate names of a given type (which actually is a truly lousy human interface to finding things, as soon as there are more than just a couple), there really is no difference. kre From owner-zeroconf@merit.edu Tue Aug 6 14:35:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22884 for ; Tue, 6 Aug 2002 14:35:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D071791298; Tue, 6 Aug 2002 14:36:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A415391299; Tue, 6 Aug 2002 14:36:03 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7DCB791298 for ; Tue, 6 Aug 2002 14:36:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5D4995DD99; Tue, 6 Aug 2002 14:36:02 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id EBC1E5DD96 for ; Tue, 6 Aug 2002 14:36:01 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA04174 for ; Tue, 6 Aug 2002 14:36:01 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA28848 for ; Tue, 6 Aug 2002 14:36:01 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id OAA02853 for ; Tue, 6 Aug 2002 14:36:00 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 06 Aug 2002 14:36:00 -0400 Subject: Re: On attribute-based queries From: "John C. Welch" To: Message-ID: In-Reply-To: <27530.1028653900@munnari.OZ.AU> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/06/2002 13:11, "Robert Elz" wrote: > | I've yet to see any protocol implement AppleTalk's services as elegantly. > | AppleTalk 'just worked'. None of the so-called replacements 'just work'. > > What this means is that no-one has done a good implementation of anything > else yet. From the user standpoint, no they haven't. > > Once upon a time vinyl LP's "just worked" and there was nothing better > that anyone had demonstrated (though there were lots of attempts). > Now, vinyl LP's ??? It took until the convenience of CDs to get people to move off of vinyl, even though CD sound reproduction is just horrid compared to vinyl. > > Everything eventually gets replaced by something better. Refusing to > countenance that anything could be better is just foolish. I'm not at all. But, it has to be easy to use, easy to implement, easy to maintain, and easy to integrate. So far, I haven't seen anything that matches all three. AppleTalk is not perfect on the last test, but only if you hate non-IP protocols. > > | Secondly, "Keep It Simple, Silly" is a very good rule to follow in anything. > | I have yet to hear anyone explain SLP and the like completely and coherently > | in under 30 minutes. I've seen zeroconf done in 10-15...simple is FAR harder > | to do well than complex. > > "completely" for SLP (as for NBP in appletalk) is hard to do quickly. > > But for enough to understand how it works, "you ask on the net for > any devices that can service your request, which can be simple, or > can include extra requirements - anything out there which can handle > your request replies, and tells you what it can do, if there's more than > one, you pick (however you like, including popping up a "chooser" box > if you are actually going to have a human user to select), if there's > exactly one, well ... if there's less than one, then you either > try for lesser requirements, if possible, or give up." You aren't going to get anyone to implement a standard with that much variation in the browser protocols. The average person will ignore most of the options, and complain that it makes it too hard to use. Implementing the more complex ones is a PITA from the other side, and jacks up network traffic. > > That's it. The rest is all boring detail that you don't need to know > to actually understand how it works. > > Sound rather line NBP? Aside from NBP being only able to locate names > of a given type (which actually is a truly lousy human interface to finding > things, as soon as there are more than just a couple), there really is no > difference. You know what? In my experience, people like names. We use names rather well. "Stuart Cheshire" is hardly descriptive at all, and for someone who doesn't know Stuart, absolutely meaningless. But for the people who deal with Stuart, or have talked with him, then "Stuart Cheshire" is all you need. You don't use the name to perfectly describe what you are looking for. In our printer example, you find out which printer is the duplexing color laser, "Oh, it's the one named 'HP third floor color' Great, you add it to your list of printers. Now, when you need to print color, the name gives you the start point, and your brain says, "Ah, that's the one that also does duplexing". Seriously, names are what humans use. You don't go out to the movies with a (for example) human female, 5'11", 140lbs, black hair 18" in length with a light wave, green eyes, non-smoker, has a porsche, likes Wesley Snipes movies, lives at x address with y phone number, and is allergic to sushi. You go out with Janet. There's what, 175 million women in the united states, but someone men keep straight the ones they are dating/living with/friends with/married to, etc., just fine, and they do it pretty much by name alone. They remember the physical/emotional/mental characteristics, but when it comes down to it, we use names, and well. So there's nothing wrong with a list of printer names. They work. There's also no requirement that you list all the printers in your organization in a flat hierarchy. john -- John C. Welch IT Manager MIT Police (617) 253 - 3093 work (508) 579 - 7380 cell (617) 253 - 8822 fax From owner-zeroconf@merit.edu Tue Aug 6 15:22:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25140 for ; Tue, 6 Aug 2002 15:22:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 478D1912A4; Tue, 6 Aug 2002 15:23:51 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 19280912A6; Tue, 6 Aug 2002 15:23:51 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E6FD8912A4 for ; Tue, 6 Aug 2002 15:23:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C9E625DDAA; Tue, 6 Aug 2002 15:23:49 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 5E7895DD8F for ; Tue, 6 Aug 2002 15:23:49 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g76JNlf01035; Tue, 6 Aug 2002 15:23:48 -0400 (EDT) Message-Id: <200208061923.g76JNlf01035@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: zeroconf@merit.edu Subject: Re: On attribute-based queries In-reply-to: (Your message of "Tue, 06 Aug 2002 14:36:00 EDT.") Date: Tue, 06 Aug 2002 15:23:47 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > You don't go out to the movies with a > (for example) human female, 5'11", 140lbs, black hair 18" in length with a > light wave, green eyes, non-smoker, has a porsche, likes Wesley Snipes > movies, lives at x address with y phone number, and is allergic to sushi. > You go out with Janet. *You* might not care which Janet you go out with, but personally I prefer the Janet who is 5'4", 110 lbs, blond hair, blue eyes, and drives a Honda. AND YOU ARE TO STAY AWAY FROM HER!!! :) > There's what, 175 million women in the united states, > but someone men keep straight the ones they are dating/living with/friends > with/married to, etc., just fine, and they do it pretty much by name alone. There are some awfully confused men out there then, if the cannot tell (or do not care about) the difference between one Janet and another. > They remember the physical/emotional/mental characteristics, but when it > comes down to it, we use names, and well. I know dozens of dance partners whom I recognize (and ask to dance) based on what they look like and how they dance. If I remember their names, so much the better. ("why didn't you ask her to dance?" "I didn't know her name!") Keith From owner-zeroconf@merit.edu Tue Aug 6 16:17:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27494 for ; Tue, 6 Aug 2002 16:17:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 18D49912AF; Tue, 6 Aug 2002 16:18:24 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC861912B1; Tue, 6 Aug 2002 16:18:23 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7C29C912AF for ; Tue, 6 Aug 2002 16:18:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 639515DDB2; Tue, 6 Aug 2002 16:18:21 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id ED53F5DD8F for ; Tue, 6 Aug 2002 16:18:20 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA19263 for ; Tue, 6 Aug 2002 16:18:20 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA17838 for ; Tue, 6 Aug 2002 16:18:20 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA20766 for ; Tue, 6 Aug 2002 16:18:19 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 06 Aug 2002 16:18:19 -0400 Subject: Re: On attribute-based queries From: "John C. Welch" To: Message-ID: In-Reply-To: <200208061923.g76JNlf01035@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/06/2002 15:23, "Keith Moore" wrote: >> You don't go out to the movies with a >> (for example) human female, 5'11", 140lbs, black hair 18" in length with a >> light wave, green eyes, non-smoker, has a porsche, likes Wesley Snipes >> movies, lives at x address with y phone number, and is allergic to sushi. >> You go out with Janet. > > *You* might not care which Janet you go out with, but personally I prefer > the Janet who is 5'4", 110 lbs, blond hair, blue eyes, and drives a Honda. But when you look her up, I'll be it's by name, and I'll bet you call her Janet not "human woman, 5'4"..." The important thing is that because humans deal with the fuzzy logic behind the name, the name doesn't *have* to be so detailed. And it works. Even if you know multiple Janets, I doubt you get them confused. (you better not ;-) > > AND YOU ARE TO STAY AWAY FROM HER!!! :) Heh...she's a bit on the short side for my tastes, no worries mate ;-) > >> There's what, 175 million women in the united states, >> but someone men keep straight the ones they are dating/living with/friends >> with/married to, etc., just fine, and they do it pretty much by name alone. > > There are some awfully confused men out there then, if the cannot tell > (or do not care about) the difference between one Janet and another. Exactly. > >> They remember the physical/emotional/mental characteristics, but when it >> comes down to it, we use names, and well. > > I know dozens of dance partners whom I recognize (and ask to dance) > based on what they look like and how they dance. If I remember their > names, so much the better. Even then, you still (most likely) do it based on a very few conscious parameters. > > ("why didn't you ask her to dance?" "I didn't know her name!") Hee...I know that routine ;-) john -- John C. Welch IT Manager MIT Police (617) 253 - 3093 work (508) 579 - 7380 cell (617) 253 - 8822 fax From owner-zeroconf@merit.edu Tue Aug 6 18:08:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01471 for ; Tue, 6 Aug 2002 18:08:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4B5F2912B0; Tue, 6 Aug 2002 18:09:42 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1AF27912B1; Tue, 6 Aug 2002 18:09:42 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F2E3A912B0 for ; Tue, 6 Aug 2002 18:09:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DC0715DDBF; Tue, 6 Aug 2002 18:09:40 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 5D4FF5DDA8 for ; Tue, 6 Aug 2002 18:09:40 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g76M9dA23288 for ; Tue, 6 Aug 2002 15:09:39 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Aug 2002 15:08:59 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id g76M9dl20046 for ; Tue, 6 Aug 2002 15:09:39 -0700 (PDT) Message-Id: <200208062209.g76M9dl20046@scv1.apple.com> Subject: Re: Requirements for Service Discovery Date: Fri, 2 Aug 2002 11:10:34 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Erik Nordmark (by way of Stuart Cheshire, ) Reply-To: "Erik Nordmark" To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk > Host names can be organized into domains and subdomains > (e.g. host.sales.apple.com., host.eng.apple.com., etc., > or host.building1.apple.com., host.building2.apple.com., etc., > as the organization chooses). This brings up an interesting issue. Today we have one DNS search list for host names. But as a user, if I use DNS for discovering services, it isn't clear that I want the same search list for each service. For instance, when looking for a printer I probably want a searchlist based on physical location e.g. floor1.building2.example.com floor2.building2.example.com but when looking for a file server I might only care about organizational aspects i.e. have a searchlist of myorg.eng.example.com Doesn't this imply a different search list per service? One could of course say that such complexity indicates that the network is "large" hence administered hence a different mechanism (web pages listing printers etc) should be used. But I think assuming such a discountinuity as architecturally desired is a bad idea; even large companies with administrators want to minimize the cost of administering the network. Forcing a large discountinuity when going from a "small" to a "large" network seems counter to this. Compare this with the SLP approach where a "large" network implies introducing DAs but not doing service discovery in a completely different fashion - that discontinuity is much much smaller. The discontinuity issue is IMHO an indication that we don't yet agree on the constraints for the problem we are trying to solve for service discovery. Erik From owner-zeroconf@merit.edu Tue Aug 6 18:30:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01901 for ; Tue, 6 Aug 2002 18:30:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 67B88912B2; Tue, 6 Aug 2002 18:31:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2F2BF912B5; Tue, 6 Aug 2002 18:31:30 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4BE00912B2 for ; Tue, 6 Aug 2002 18:31:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3BBD85DDC3; Tue, 6 Aug 2002 18:31:29 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id CFF095DDC1 for ; Tue, 6 Aug 2002 18:31:28 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g76LaSw16437; Tue, 6 Aug 2002 14:36:28 -0700 Date: Tue, 6 Aug 2002 14:36:28 -0700 (PDT) From: Bernard Aboba To: Keith Moore Cc: "John C. Welch" , Subject: Re: On attribute-based queries In-Reply-To: <200208022154.g72Lsfk25356@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > but I agree that this thread isn't accomplishing anything useful, so > I'll stop too. 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. From owner-zeroconf@merit.edu Tue Aug 6 19:58:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04233 for ; Tue, 6 Aug 2002 19:58:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EF1ED912BB; Tue, 6 Aug 2002 19:59:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BEBA8912BC; Tue, 6 Aug 2002 19:59:34 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A8A28912BB for ; Tue, 6 Aug 2002 19:59:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8E0305DDCC; Tue, 6 Aug 2002 19:59:33 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 434835DDCA for ; Tue, 6 Aug 2002 19:59:33 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id QAA01594; Tue, 6 Aug 2002 16:59:24 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id QAA17097; Tue, 6 Aug 2002 16:57:39 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g76NxJBG013002; Wed, 7 Aug 2002 09:59:20 +1000 (EST) Message-ID: <3D5062D6.1090105@motorola.com> Date: Wed, 07 Aug 2002 09:59:18 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Elz Cc: Stuart Cheshire , zeroconf@merit.edu Subject: Re: List of Service Types References: <200207310557.g6V5vKl09083@scv1.apple.com> <27510.1028653237@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > Date: Tue, 30 Jul 2002 22:57:25 -0700 > From: Stuart Cheshire > Message-ID: <200207310557.g6V5vKl09083@scv1.apple.com> > > | This means that a telnet client can automatically find and display a list > | of entities on the network that are advertising that they will accept > | telnet connections > > Maybe I'm missing something obvious, but using the DNS, how exactly is > that intended to be accomplished? > ... > > So, I need to find X such that "_telnet._tcp.X.example.com" exists. > > What's the DNS method to achieve that? I must have missed that sometime. > The X is actually in a surprising position in the domain name: X._telnet._tcp.example.com Creative use of PTR records allows the set of Xes to be discovered. Multiple PTRs are returned for _service._proto.domain.name and displayed in a box. The user chooses something, a query is then made for a SRV and the connection established. http://files.dns-sd.org/draft-cheshire-dnsext-nias.txt, Section 10 has an example. -- regards aidan ____ :wq! Sydney Network Research Lab aidan.williams@motorola.com 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 owner-zeroconf@merit.edu Tue Aug 6 22:11:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07785 for ; Tue, 6 Aug 2002 22:11:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1A35B912BF; Tue, 6 Aug 2002 22:12:12 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DDEE5912C0; Tue, 6 Aug 2002 22:12:11 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA222912BF for ; Tue, 6 Aug 2002 22:12:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A6EB45DDDD; Tue, 6 Aug 2002 22:12:10 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.2]) by segue.merit.edu (Postfix) with ESMTP id 05BE55DDB5 for ; Tue, 6 Aug 2002 22:12:09 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g772Bpo01888; Wed, 7 Aug 2002 09:11:51 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g76JMhH28377; Wed, 7 Aug 2002 02:22:43 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "John C. Welch" Cc: zeroconf@merit.edu Subject: Re: On attribute-based queries In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 07 Aug 2002 02:22:43 +0700 Message-ID: <28375.1028661763@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 06 Aug 2002 14:36:00 -0400 From: "John C. Welch" Message-ID: | I'm not at all. But, it has to be easy to use, easy to implement, easy to | maintain, and easy to integrate. So far, I haven't seen anything that | matches all three. AppleTalk is not perfect on the last test, but only if | you hate non-IP protocols. I have done a lot of work with appletalk (including implementing all the bits that are relevant here). It isn't too hard to implement (localtalk aside, but that's not relevant) it is horrible to maintain (ever tried to change a zone name?). But none of that really matters, what's easy to implement or maintain has little effect on what becomes popular (believe that web browsers are easy ??) | You aren't going to get anyone to implement a standard with that much | variation in the browser protocols. The average person will ignore most of | the options, and complain that it makes it too hard to use. Implementing the | more complex ones is a PITA from the other side, and jacks up network | traffic. I think that you're putting too many assumptions on the user interface and the protocol being closely linked. They need not be. Take a trivial example - if you just looked at SMTP, and told people that's how e-mail was to be sent, most of them wouldn't want to know. And they needn't, their mailer takes care of all of the detail, all the user needs to know is how to stick in a To address, type the message, and send it. The same is true here. If you believe that a browser that simply lists the names of available printers is the user interface that people want, then I can trivially see how to make that work using SLP, I can't even begin to imagine how to do it using (conventional) DNS. (On the other hand, if I already know the name of the printer I want, then DNS is clearly the superior way to find out its address to talk to it). On the other hand, if you want the browser to be smarter - when you're in your graphics application, and select "print" (or "page setup" or something) you get to see only the list of printers that can actually be used by that application, as when it did its query, it was more selective than just any printer - then it sounds much more like SLP to me. Just because appletalk doesn't allow applications to assist like that, and windows has no rational interface at all, so users aren't used to this kind of help, doesn't mean that they're not going to like it when it can be implemented. | You know what? In my experience, people like names. We use names rather | well. "Stuart Cheshire" is hardly descriptive at all, and for someone who | doesn't know Stuart, absolutely meaningless. But for the people who deal | with Stuart, or have talked with him, then "Stuart Cheshire" is all you | need. Sure, once you know who/what you want to talk to, names (labels) as a reference work just fine. But then we're beyond service location, the service has already been located sometime in the past. No objections at all to remembering the name that resulted from a previous activation of service location, and then using the DNS to find its address, over and over again. But somehow, we have to find Stuart initially, and when I start, all I know is that I'm looking for a WG chair, who happens to be involved with the zeroconf WG ... | You don't use the name to perfectly describe what you are looking for. | In our printer example, you find out which printer is the duplexing color | laser, How? In the answer, don't assume there are necessarily any humans involved. In much of this, there will be zero of those arcane animals. Just nice clean silicon life forms... | Seriously, names are what humans use. The protocols designed here have to work for humans, they also have to work without humans. They have to work for small networks, but they have to also keep working (or somehow know how to transition) when they're on large networks (my laptop sometimes connects to my home net, which is pretty small, and sometimes to the internet, which is pretty large, and sometimes even to both at once... the software in it doesn't change when that happens, the same set has to cope with all possibilities). | So there's nothing wrong with a list of printer names. They work. Not very well. That's the environment I am used to, and I can never figure out just which printer is which - yet they have names that people believe will help - a few of them are obvious, most might mean something to some people, I suppose, but they mean nothing to me. I know which printer I normally use, that's fine - but when that's not working, I have to pick another one, and at that point it really starts getting hard. Our list of names supposedly tells me where to go to find the printer, that helps, assuming I know the geography and number scheme of the building (which I don't, despite having occupied it since it was built, nearly a decade ago). It doesn't tell me which are inside rooms that have been locked, and I can't get to (nor would SLP of course...). It tells me nothing about which printer will do what. It all boils down to guesswork. I suppose I could call the support staff - but then I'd end up talking to myself. I might find someone who actually knows what some of the printers can do, but I doubt I can find anyone who knows about all of them. If only I could just ask the printers... | There's also no requirement that you list all the printers in your | organization in a flat hierarchy. No, of course not, and we don't, and printers in other departments are all nicely hidden in general. But hierarchy for no better reason than making the list smaller is hopeless, it makes things harder, not easier. kre From owner-zeroconf@merit.edu Tue Aug 6 22:46:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09077 for ; Tue, 6 Aug 2002 22:46:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7EBC491229; Tue, 6 Aug 2002 22:45:46 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3243B91231; Tue, 6 Aug 2002 22:45:46 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3637291229 for ; Tue, 6 Aug 2002 22:45:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1A2445DDE4; Tue, 6 Aug 2002 22:45:45 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id BBA1B5DDB5 for ; Tue, 6 Aug 2002 22:45:44 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g772jhk19808 for ; Tue, 6 Aug 2002 19:45:43 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Aug 2002 19:45:03 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id g772jhT01784 for ; Tue, 6 Aug 2002 19:45:43 -0700 (PDT) Message-Id: <200208070245.g772jhT01784@scv3.apple.com> Subject: Re: On attribute-based queries Date: Tue, 6 Aug 2002 19:45:47 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >I am surprised that Apple of all people might suggest that because >a query appears on the wire in an arcane form, that the user >should see this. > >Of course the chooser software has to filter >"service:printer:http://169.254.17.202;(name=Epson Stylus 900n)" >to present the user with something more friendly - like showing >"Epson Stylus 900n" in its printer selection (assuming that the >user hasn't even changed the manufacturers default name to >something more useful). But is every printer *required* to have a "name=xxx" attribute? Is every printer required to check that its name is unique, and take some action if it is not? It is fine to talk about what things can be done with this or that protocol, but it is hard to write a client that takes advantage of a feature unless you know that *ALL* implementers of that protocol will implement the feature you are depending upon. The recipe for an interoperable protocol is a small list of mandatory features, and an even smaller list of optional features. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Aug 6 22:52:08 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09172 for ; Tue, 6 Aug 2002 22:52:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2950191231; Tue, 6 Aug 2002 22:53:12 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E3332912C2; Tue, 6 Aug 2002 22:53:11 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EB42991231 for ; Tue, 6 Aug 2002 22:53:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C95A75DDE3; Tue, 6 Aug 2002 22:53:10 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 7AD675DDB5 for ; Tue, 6 Aug 2002 22:53:10 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g772r9k20831 for ; Tue, 6 Aug 2002 19:53:09 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Aug 2002 19:52:29 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id g772r9l26710 for ; Tue, 6 Aug 2002 19:53:09 -0700 (PDT) Message-Id: <200208070253.g772r9l26710@scv1.apple.com> Subject: Re: On attribute-based queries Date: Tue, 6 Aug 2002 19:53:13 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >I work in a field (entertainment technology) where networks >with several thousand devices came over the horizon >a while ago and are now knocking on the door. Really? Several thousand devices? Can you back this up with a real example? I can imagine owning ten or twenty hi-fi components, but not several thousand. I use X10 light switches in my house, but I don't have more than twenty or thirty of those. The cheapest object I think I own is a pencil, but even for something that cheap I can't see any reason to own several thousand pencils. I have a hard time thinking of any object of which I own several thousand. If I do need to own several thousand network devices, that seems like a strong argument to make them as cheap and simple as possible. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Aug 6 23:05:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09530 for ; Tue, 6 Aug 2002 23:05:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EFE7C912AD; Tue, 6 Aug 2002 23:06:47 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1937912C2; Tue, 6 Aug 2002 23:06:46 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C3CF7912AD for ; Tue, 6 Aug 2002 23:06:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A9FB45DDB5; Tue, 6 Aug 2002 23:06:45 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 2DAA15DD9E for ; Tue, 6 Aug 2002 23:06:45 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g7736ik23380 for ; Tue, 6 Aug 2002 20:06:44 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Aug 2002 20:06:44 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id g7736hT22670 for ; Tue, 6 Aug 2002 20:06:44 -0700 (PDT) Message-Id: <200208070306.g7736hT22670@scv2.apple.com> Subject: Re: Relationship DNS-SD and SLP Date: Tue, 6 Aug 2002 20:06:47 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >> This does not satisfy: >> >> 2.1 Name-to-Address Mapping > >Sure it does. Search for the printer which has the name attribute >equal to the name of the printer you are seeking. Get its address. Only if the application developer can safely assume that every printer has a unique name. As long as the name is allowed to be optional (or 'unknown') the application developer has to think of some other way to reliably record the identity of the user's chosen default printer. >> 2.7 "Name Space Management -or- Name Conflict Detection". > >Sure it does. Search for the printer which has the name X. If a >printer replies, do not use the name X. Are all printers *required* to do this? If not, then an application developer can't assume that all printers have unique names, so it's not much use. >> 2.5 User-Friendly Names > >No, you can display a user friendly name attribute or even a binary >image attribute icon, etc. in a human interface. Sure, anyone *could* do anything, but *do* all printers have friendly name attributes and binary image attributes? If I'm trying to write printing software that works will all printers (the whole point of open standards, after all) what can I rely on to be implemented by *every* printer? Anything optional can't be safely assumed, so for practial purposes it may as well not be in the spec at all. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Aug 6 23:17:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09752 for ; Tue, 6 Aug 2002 23:17:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BE48D91232; Tue, 6 Aug 2002 23:18:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 870229125D; Tue, 6 Aug 2002 23:18:45 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9527A91232 for ; Tue, 6 Aug 2002 23:18:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 81F7B5DDB5; Tue, 6 Aug 2002 23:18:44 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 040A95DD9E for ; Tue, 6 Aug 2002 23:18:44 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g773IgA20809 for ; Tue, 6 Aug 2002 20:18:42 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Aug 2002 20:18:03 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id g773Igl03368 for ; Tue, 6 Aug 2002 20:18:43 -0700 (PDT) Message-Id: <200208070318.g773Igl03368@scv1.apple.com> Subject: Re: List of Service Types Date: Tue, 6 Aug 2002 20:18:46 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >So in the file search example I raised earlier, you might do DNS queries >for >_cifs._tcp >_rsync._tcp >_ftp._tcp >_http._tcp >_nfs._tcp Right. And if you are worrying that doing queries for five different protocols like this is horribly inefficient, I should let you know that Apple's Rendezvous software packs all five queries into a single UDP packet. Those of you on this list who already have OS X 10.2 will be able to see this using a packet sniffer. >Then you can map whatever services are offered, and search through the >various drives for a certain name (or size, whatever the user wants). > >Is this the intended approach? Right. For example, the AFP protocol allows server-side searching. When you press Cmd-F in the Finder and search for files by name, size, date, etc., the search is not performed locally. A query description is sent to the server, executed on the server, and then the results are sent back. My belief is that complex queries like this will always be protocol-specific. The kinds of queries a file server has to answer are different to the kinds of queries a printer has to answer, and different to the kinds of queries a database engine has to answer. It is reasonable to expect each application protocol to support the appropriate query sematics for that application. I believe that it is unreasonable to expect a generic service discovery protocol to implement sufficient query sematics to cover all those cases -- especially when you also want a $49 ink-jet printer to implement that service discovery protocol. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Aug 6 23:19:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA09789 for ; Tue, 6 Aug 2002 23:19:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C58E89125D; Tue, 6 Aug 2002 23:20:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 974C2912C2; Tue, 6 Aug 2002 23:20:29 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A18FD9125D for ; Tue, 6 Aug 2002 23:20:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 90A9E5DDE4; Tue, 6 Aug 2002 23:20:28 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 343085DDB5 for ; Tue, 6 Aug 2002 23:20:28 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g773KRk24591 for ; Tue, 6 Aug 2002 20:20:27 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Aug 2002 20:20:27 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id g773KRT10220 for ; Tue, 6 Aug 2002 20:20:27 -0700 (PDT) Message-Id: <200208070320.g773KRT10220@scv3.apple.com> Subject: Re: On Scaling of DNS-SD Date: Tue, 6 Aug 2002 20:20:30 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >the problem is in the notion of "where a mini-DNS server is present" - >it can be present for some nodes in an application and absent for others. Can we delete the word "mini" from all this discussion? A DNS server is a DNS server. I used the term "mini-DNS server" in my original posting to refer to code size and complexity, not protocol and behaviour. Now everyone is acting as if a mini-DNS server behaves differently than a normal DNS server. It doesn't. The only difference is that the DNS server embedded in your $99 home gateway doesn't have to be as sophisticated as BIND 9, because no one is expecting to buy a $99 home gateway and use it as the authoritative server for -- to pick an example -- the entire "com." domain. In all past and future references to "mini-DNS", please ignore the word "mini". Any assertions that, "Mini-DNS doesn't work because of x," should be read as saying equally that, "DNS doesn't work because of x." They are the same thing, and I'm sorry I caused this confusion. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Aug 6 23:37:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10063 for ; Tue, 6 Aug 2002 23:37:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 78725912C4; Tue, 6 Aug 2002 23:36:41 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47E16912C7; Tue, 6 Aug 2002 23:36:41 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1F48E912C4 for ; Tue, 6 Aug 2002 23:36:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 103A95DD9E; Tue, 6 Aug 2002 23:36:37 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 2C5515DDE3 for ; Tue, 6 Aug 2002 23:36:32 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g773aVA23980 for ; Tue, 6 Aug 2002 20:36:31 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Aug 2002 20:35:47 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id g773aRl06840 for ; Tue, 6 Aug 2002 20:36:27 -0700 (PDT) Message-Id: <200208070336.g773aRl06840@scv1.apple.com> Subject: RE: On attribute-based queries Date: Tue, 6 Aug 2002 20:36:31 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >You're again bringing this back to the human aspect of "choosing" >things. For software agents to search and select services attribute >-based searching is a necessity. I never said that attributes weren't important. What I questioned is whether you want to ship some generic query description over the network and have every device interpret the query itself, or whether you want get all the information from the devices, and then perform your evaluation locally to determine which one (or ones) meet your needs. Those who are old enough will remember the battle between ISDN-to-the-desktop and Ethernet. The ISDN proponents said that the network should be very carefully managed, and should never lose a single byte of data. Of course that made ISDN switching hardware very slow and expensive compared to an Ethernet hub. The Ethernet vendors said, "Forget call setup. Forget reservations. Forget virtual circuits. Just make the hardware so cheap and fast that no one cares." The market spoke. People would rather have fast and cheap. People would rather have an uncertain share of 10Mb/s (or 100Mb/s, or Gb/s) than a guaranteed 100% of 64kb/s (that's 0.06Mb/s, for anyone who's counting). I take the same approach here -- I'd rather focus my efforts on making the network fast and cheap, and fill it with cheap simple devices, than focus my efforts on making complicated devices that have to execute generic queries locally in order to preserve the precious bandwidth of my slow network. To state it even more plainly: If a device vendor selling a $50 device has a limited budget to spend on either a faster network interface, or on a faster processor to execute a more complicated protocol, I'd rather have a simple device with a 10Mb/s interface, instead of a more powerful device with only a 1Mb/s interface. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Aug 6 23:43:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10234 for ; Tue, 6 Aug 2002 23:43:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 53039912C3; Tue, 6 Aug 2002 23:44:48 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1E477912C5; Tue, 6 Aug 2002 23:44:48 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2F056912C3 for ; Tue, 6 Aug 2002 23:44:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1A38C5DDE3; Tue, 6 Aug 2002 23:44:47 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id C06555DD9E for ; Tue, 6 Aug 2002 23:44:46 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g773ijk27220 for ; Tue, 6 Aug 2002 20:44:45 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Aug 2002 20:44:45 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id g773ijT00114 for ; Tue, 6 Aug 2002 20:44:45 -0700 (PDT) Message-Id: <200208070344.g773ijT00114@scv2.apple.com> Subject: Re: On attribute-based queries Date: Tue, 6 Aug 2002 20:44:49 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >Each desktop sharing service announces its availability using SLP, >together with the user's full name and user id. This allows an >administrator to search for the user by name or id. Sometimes the >administrator may only know the first or last name, so he can >query for all Johns or all Millers. Or when the admin does not >know how to spell the name he can enter a part of the name. Err. Did I miss something here? The SLP protocol now requires every device to implement the Soundex name matching algorithm to find variant spellings of names? If SLP *does* require Soundex name matching, then that's pretty good evidence for my claim that SLP is too much burden to impose on every device. If SLP does *not* require Soundex name matching, then that's pretty good evidence for my claim that SLP's query language is not sufficiently general to meet the needs of every application. Either way, the conclusion is the same -- one size does not fit all. Let's strip the discovery protocol to the lowest practical common denominator, and let each application implement the attribute matching technique appropriate to that application. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Aug 6 23:47:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10402 for ; Tue, 6 Aug 2002 23:47:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 394F9912C6; Tue, 6 Aug 2002 23:48:44 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4AD4B912C7; Tue, 6 Aug 2002 23:48:18 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D7571912C6 for ; Tue, 6 Aug 2002 23:47:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BB26A5DDE3; Tue, 6 Aug 2002 23:47:19 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 6D79D5DD9E for ; Tue, 6 Aug 2002 23:47:19 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g773lIk27587 for ; Tue, 6 Aug 2002 20:47:18 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Aug 2002 20:47:18 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id g773lHT00784 for ; Tue, 6 Aug 2002 20:47:18 -0700 (PDT) Message-Id: <200208070347.g773lHT00784@scv2.apple.com> Subject: Re: On Scaling of DNS-SD Date: Tue, 6 Aug 2002 20:47:21 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >So the problem will right itself, though the timescale on which >this occurs might be an issue (I've not found 5 minutes to be a >satisfactory time between attempts to find a home gateway, in my >experience). Agreed. I've thought of proposing a DHCP announcement packet that is sent when a DHCP server comes on-line, which would let the clients reconfigure immediately and reduce this delay, but we have so much struggle getting agreement on even the simplest things that I don't have the energy to be taking on more work right now. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Aug 7 00:04:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10812 for ; Wed, 7 Aug 2002 00:04:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0170D912C8; Wed, 7 Aug 2002 00:05:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30450912CB; Wed, 7 Aug 2002 00:05:35 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E4F3D912C9 for ; Wed, 7 Aug 2002 00:03:27 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B1F8B5DDE7; Wed, 7 Aug 2002 00:03:27 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 3315A5DD9E for ; Wed, 7 Aug 2002 00:03:27 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g7743Qk29359 for ; Tue, 6 Aug 2002 21:03:26 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Aug 2002 21:02:46 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id g7743Ql12373 for ; Tue, 6 Aug 2002 21:03:26 -0700 (PDT) Message-Id: <200208070403.g7743Ql12373@scv1.apple.com> Subject: Re: Requirements for Service Discovery Date: Tue, 6 Aug 2002 21:03:29 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >This brings up an interesting issue. >Today we have one DNS search list for host names. > >But as a user, if I use DNS for discovering services, it isn't >clear that I want the same search list for each service. That is true. We could implement multiple different domains of services. For any protocol I think we can think of ways to make it arbitrarily complicated and configurable, but we have to exercise judgement in deciding when all the complication serves enough purpose to justify the cost. If it is so complicated that it is never implemented, then it is hard to argue that the benefit was worth it. >Forcing a large discountinuity when going from a "small" to a >"large" network seems counter to this. Compare this with the SLP >approach where a "large" network implies introducing DAs but not >doing service discovery in a completely different fashion - that >discontinuity is much much smaller. I disagree. SLP has one discontinuity when going from a small LAN with no scopes (i.e. scope "DEFAULT") to a medium-sized network with multiple scopes. How does the user find out in which scope they should be looking for printers? What I proposed with mDNS-SD is no different. SLP has another discontinuity when going from a medium-sized network (e.g. one corporation) to a larger network (e.g. the whole Internet). It just stops working. How would you, Erik Nordmark at Sun, use SLP (not DNS) to find the list of public time servers provided by some other company, say Apple? In contrast, the example I gave before, to enumerate my printers using DNS-SD, will work from anywhere on this planet that has working Internet connectivity: nslookup -q=ptr _printer._tcp.stuartcheshire.org. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Aug 7 00:06:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10854 for ; Wed, 7 Aug 2002 00:06:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 18AFC912C7; Wed, 7 Aug 2002 00:07:13 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DE278912C9; Wed, 7 Aug 2002 00:07:12 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E70D4912C7 for ; Wed, 7 Aug 2002 00:07:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C3D0C5DDE8; Wed, 7 Aug 2002 00:07:11 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 74EB25DDE7 for ; Wed, 7 Aug 2002 00:07:11 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g7747AA27250 for ; Tue, 6 Aug 2002 21:07:10 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Aug 2002 21:07:10 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id g7747AT04658 for ; Tue, 6 Aug 2002 21:07:10 -0700 (PDT) Message-Id: <200208070407.g7747AT04658@scv2.apple.com> Subject: Re: List of Service Types Date: Tue, 6 Aug 2002 21:07:14 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >>This means that a telnet client can automatically find and display >>a list of entities on the network that are advertising that they >>will accept telnet connections > >Maybe I'm missing something obvious, but using the DNS, how exactly is >that intended to be accomplished? Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Aug 7 00:23:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11368 for ; Wed, 7 Aug 2002 00:23:04 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C00F7912CA; Wed, 7 Aug 2002 00:24:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D543912CB; Wed, 7 Aug 2002 00:24:07 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9024B912CA for ; Wed, 7 Aug 2002 00:24:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 60E155DD9E; Wed, 7 Aug 2002 00:24:06 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id CC4D05DDEC for ; Wed, 7 Aug 2002 00:24:05 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g774O4A00405 for ; Tue, 6 Aug 2002 21:24:04 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Aug 2002 21:24:04 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id g774O4T07903 for ; Tue, 6 Aug 2002 21:24:04 -0700 (PDT) Message-Id: <200208070424.g774O4T07903@scv2.apple.com> Subject: Re: List of Service Types Date: Tue, 6 Aug 2002 21:24:07 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >Yes, this is fine. But on 98% of the printers like that that we have >installed, my photo will come out in B&W (greytone). Only one or two >of the printers will actually print colour. How does the laserwriter >driver do on avoiding letting me (unintentionally anyway) send my nice >colour image to a printer that simply cannot cope? Are you asking about AppleTalk or DNS-SD? Over AppleTalk, once the printer has been discovered using NBP, the driver talks to it using PostScript queries over PAP (the AppleTalk Printer Access Protocol) to find out more about its capabilities. Using DNS-SD, the printer's TXT record contains some rudimentary information to identify simple capabilities, like whether it can print colour. This can save a subsequent connection to the printer to interrogate it directly. However, and I have said this before, no attribute list can meet every application's requirements. Sure, the printer can print colour, but is it four-colour or six-colour? What is the ink chemistry? What is the gamut? What is the colour matching profile? This is not a contrived example. At Stanford we had a high-speed black-and-white Xerox printer that could also overlay red toner. It was good for doing titles in red, and figures like pie charts, but useless for printing a full-colour photograph. If you are looking for a list of printers on the network that can print colour, should this printer show up or not? It's not a binary yes-or-no answer is it? It depends on what the user wants to print on it. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Aug 7 00:24:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11688 for ; Wed, 7 Aug 2002 00:24:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3340D912CB; Wed, 7 Aug 2002 00:25:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D5F29912CC; Wed, 7 Aug 2002 00:25:26 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E0916912CB for ; Wed, 7 Aug 2002 00:25:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C6D6E5DDEA; Wed, 7 Aug 2002 00:25:25 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 78F035DD9E for ; Wed, 7 Aug 2002 00:25:25 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g774POk02206 for ; Tue, 6 Aug 2002 21:25:24 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 6 Aug 2002 21:24:44 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id g774POl16710 for ; Tue, 6 Aug 2002 21:25:24 -0700 (PDT) Message-Id: <200208070425.g774POl16710@scv1.apple.com> Subject: Re: List of Service Types Date: Tue, 6 Aug 2002 21:25:27 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >ps: Stuart, in the IETF we generally don't want to know "Apple's >position" we want to know yours. It is fine (if you're able) to tell >us "Apple is shipping a product which ..." or even "Apple is about to >ship a product which does ...", but corporate positions don't belong. Fair point. I have endeavoured in this latest round of responses to express personal opinions about protocol design, not corporate positions. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Aug 7 00:27:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11804 for ; Wed, 7 Aug 2002 00:27:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 60EAE912CC; Wed, 7 Aug 2002 00:28:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C319912CD; Wed, 7 Aug 2002 00:28:45 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C9CE1912CC for ; Wed, 7 Aug 2002 00:28:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9EBEE5DDEA; Wed, 7 Aug 2002 00:28:43 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 3CADD5DD9E for ; Wed, 7 Aug 2002 00:28:43 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA24081 for ; Wed, 7 Aug 2002 00:28:42 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA20530 for ; Wed, 7 Aug 2002 00:28:42 -0400 (EDT) Received: from [10.0.0.2] (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id AAA09669 for ; Wed, 7 Aug 2002 00:28:41 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 07 Aug 2002 00:28:42 -0400 Subject: Re: On attribute-based queries From: "John C. Welch" To: Message-ID: In-Reply-To: <28375.1028661763@munnari.OZ.AU> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/06/2002 15:22, "Robert Elz" wrote: > I have done a lot of work with appletalk (including implementing all the > bits that are relevant here). It isn't too hard to implement (localtalk > aside, but that's not relevant) it is horrible to maintain (ever tried to > change a zone name?). Far easier than changing a windows domain name, and I have yet to feel confident that I have read any sort of SLP manual correctly...it seems to work anyway, but I don't want that type of result. Knowing it worked because I did the right things, that is what I want > > But none of that really matters, what's easy to implement or maintain > has little effect on what becomes popular (believe that web browsers are > easy ??) Compared to other things, yes, from the human view. > I think that you're putting too many assumptions on the user interface and > the protocol being closely linked. They need not be. Take a trivial > example - if you just looked at SMTP, and told people that's how e-mail > was to be sent, most of them wouldn't want to know. And they needn't, > their mailer takes care of all of the detail, all the user needs to know > is how to stick in a To address, type the message, and send it. Right...but email does a lot more than what we are talking about. I'm talking about getting a list of a specific type of thing. > > The same is true here. If you believe that a browser that simply lists > the names of available printers is the user interface that people want, > then I can trivially see how to make that work using SLP, I can't even > begin to imagine how to do it using (conventional) DNS. (On the other > hand, if I already know the name of the printer I want, then DNS is > clearly the superior way to find out its address to talk to it). Maybe you can, but since there are no good SLP tools out there, from the IT viewpoint, SLP is just a big PITA. DNS has good tools, and is well understood. > > On the other hand, if you want the browser to be smarter - when you're in > your graphics application, and select "print" (or "page setup" or something) > you get to see only the list of printers that can actually be used by > that application, as when it did its query, it was more selective than > just any printer - then it sounds much more like SLP to me. But that can be accomplished via the printer information on the local machine. That's what PPDs, and intelligent print protocols are for. That way, all the 'intelligent settings' are done locally. I don't want a network full of packets fully describing the complete capabilities of a Xerox 1235DX. Just tell me the name of the printer, give my Mac the data it needs to auto select the right ppd, or tell me I need the right ppd, and be done with it. There is no need to query the printer for that information. > > Just because appletalk doesn't allow applications to assist like that, > and windows has no rational interface at all, so users aren't used to > this kind of help, doesn't mean that they're not going to like it when > it can be implemented. In my experience, people using computers are inundated with information. They want less information to deal with. If I have to wade through a list of options just to pick a printer, then why bother with SLP, or IPP? Just go back to LPR, and manually set everything. > Sure, once you know who/what you want to talk to, names (labels) as a > reference work just fine. But then we're beyond service location, the > service has already been located sometime in the past. No objections at > all to remembering the name that resulted from a previous activation of > service location, and then using the DNS to find its address, over and > over again. > > But somehow, we have to find Stuart initially, and when I start, all I > know is that I'm looking for a WG chair, who happens to be involved > with the zeroconf WG ... Right. So then you just want a list of WG chairs in the zeroconf zone. > > | You don't use the name to perfectly describe what you are looking for. > | In our printer example, you find out which printer is the duplexing color > | laser, > > How? The best way that people know how...you ask the people who set up the printers. > > In the answer, don't assume there are necessarily any humans involved. > In much of this, there will be zero of those arcane animals. Just nice > clean silicon life forms... See...that's your prime error. Let's design a protocol without considering the humans. Well, you *can't* assume there are no humans. In fact, it's one of the few things you can count on, that there will be humans. Because if the humans can't use and implement your protocol easily, they won't use it. > > | Seriously, names are what humans use. > > The protocols designed here have to work for humans, they also have to > work without humans. They have to work for small networks, but they > have to also keep working (or somehow know how to transition) when they're > on large networks (my laptop sometimes connects to my home net, which is > pretty small, and sometimes to the internet, which is pretty large, and > sometimes even to both at once... the software in it doesn't change > when that happens, the same set has to cope with all possibilities). Right...but the simpler you keep things, the better they will work. That's the closest thing to a universal truth I know. > > | So there's nothing wrong with a list of printer names. They work. > > Not very well. That's the environment I am used to, and I can never > figure out just which printer is which - yet they have names that people > believe will help - a few of them are obvious, most might mean something > to some people, I suppose, but they mean nothing to me. I know which > printer I normally use, that's fine - but when that's not working, I have > to pick another one, and at that point it really starts getting hard. > Our list of names supposedly tells me where to go to find the printer, > that helps, assuming I know the geography and number scheme of the building > (which I don't, despite having occupied it since it was built, nearly a > decade ago). It doesn't tell me which are inside rooms that have been > locked, and I can't get to (nor would SLP of course...). It tells me > nothing about which printer will do what. It all boils down to guesswork. But in your example, there is no amount of complex device queries that would help you either. Sometimes, the humans need to use better names, but that can get out of hand as well. In any case, the traffic generated by what is not an outrageous possible device feature browser query would get really large, really quick. That's a bad thing. > > I suppose I could call the support staff - but then I'd end up talking to > myself. I might find someone who actually knows what some of the printers > can do, but I doubt I can find anyone who knows about all of them. If only > I could just ask the printers... But then you just admitted you really don't know where they all are...so what good will knowing the features do you if you don't know where the paper is coming out at? So your really large amount of network traffic to receive every feature from every printer in the building still won't do you much good. You'd be better off knowing that the printers on your list are all near you, and them looking at the ppd options for that printer to see if it's the one you want. You don't need a complex protocol for that. > No, of course not, and we don't, and printers in other departments are > all nicely hidden in general. But hierarchy for no better reason than > making the list smaller is hopeless, it makes things harder, not easier. In my experience, it's a driving reason to use a proper hierarchy. To reduce useless input. john -- John C. Welch IT Manager MIT Police (617) 253 - 3093 work (508) 579 - 7380 cell (617) 253 - 8822 fax From owner-zeroconf@merit.edu Wed Aug 7 00:28:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA11828 for ; Wed, 7 Aug 2002 00:28:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ABDA7912CD; Wed, 7 Aug 2002 00:29:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77270912CE; Wed, 7 Aug 2002 00:29:15 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6DBA2912CD for ; Wed, 7 Aug 2002 00:29:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 480155DDEA; Wed, 7 Aug 2002 00:29:14 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id A55BD5DD9E for ; Wed, 7 Aug 2002 00:29:13 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id VAA12443; Tue, 6 Aug 2002 21:29:06 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id VAA21165; Tue, 6 Aug 2002 21:29:25 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g774T2BG007063; Wed, 7 Aug 2002 14:29:02 +1000 (EST) Message-ID: <3D50A20D.60504@motorola.com> Date: Wed, 07 Aug 2002 14:29:01 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: List of Service Types References: <200208070424.g774O4T07903@scv2.apple.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Stuart Cheshire wrote: > Using DNS-SD, the printer's TXT record contains some rudimentary > information to identify simple capabilities, like whether it can print > colour. This can save a subsequent connection to the printer to > interrogate it directly. > Soo... seems to me that a complete specification would need to have templates for the TXT records along the lines that SLP has schemas. Or do you have something else in mind? -- regards aidan ____ :wq! Sydney Network Research Lab aidan.williams@motorola.com 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 owner-zeroconf@merit.edu Wed Aug 7 01:30:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA13130 for ; Wed, 7 Aug 2002 01:30:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 97C98912D0; Wed, 7 Aug 2002 01:30:52 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F0E7912D1; Wed, 7 Aug 2002 01:30:52 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6FC03912D0 for ; Wed, 7 Aug 2002 01:30:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4B91E5DDF4; Wed, 7 Aug 2002 01:30:51 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 6C2D15DD9E for ; Wed, 7 Aug 2002 01:30:45 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g774ZNQ20305; Tue, 6 Aug 2002 21:35:24 -0700 Date: Tue, 6 Aug 2002 21:35:22 -0700 (PDT) From: Bernard Aboba To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Requirements for Service Discovery In-Reply-To: <200208070403.g7743Ql12373@scv1.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > SLP has another discontinuity when going from a medium-sized network > (e.g. one corporation) to a larger network (e.g. the whole Internet). It > just stops working. How would you, Erik Nordmark at Sun, use SLP (not > DNS) to find the list of public time servers provided by some other > company, say Apple? You just root the SLP DAs within the DNS, so that you can reach the SLP DAs for a given domain. This is described in the following draft: http://www.ietf.org/internet-drafts/draft-zhao-slp-remote-da-discovery-03.txt From owner-zeroconf@merit.edu Wed Aug 7 04:45:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10290 for ; Wed, 7 Aug 2002 04:45:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E5BC791233; Wed, 7 Aug 2002 04:46:53 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E187912D1; Wed, 7 Aug 2002 04:46:50 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0783791233 for ; Wed, 7 Aug 2002 04:46:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E23D55DDF9; Wed, 7 Aug 2002 04:46:23 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from msweeper.seri.co.uk (mailhost2.seri.co.uk [194.133.18.172]) by segue.merit.edu (Postfix) with ESMTP id 4F87A5DDF7 for ; Wed, 7 Aug 2002 04:46:23 -0400 (EDT) Received: from ex1.seri.co.uk (ex1.seri.co.uk) by msweeper.seri.co.uk (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Wed, 7 Aug 2002 09:44:58 +0100 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Subject: RE: On attribute-based queries X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Date: Wed, 7 Aug 2002 09:45:31 +0100 Message-ID: <341710540F08E34498A057DEE04DAAD7279D6D@ex1.seri.co.uk> Thread-Topic: On attribute-based queries Thread-Index: AcI9vXxoj/d/SUCKRQmExasO8a2fQAALohng From: "Martin Layley" To: Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA10290 Stuart, I can't remember who wrote the original note you are replying to, but I sometimes stagecrew for amateur theatre groups. We often have only a few hours on a Sunday afternoon to completely rig a theatre for a show (let in at 12, with a rehearsal at 6 or 7pm). In that time, as well as all of the scenery having to be placed, an entire lighting rig needs to be installed and positioned. Currently, only part of the rig is networked - usually using DMX, but increasingly 10base-T is appearing for the more complex effects units. A typical rig for a show in a 150 seat theatre will probably involve about 80 lamps, each with colour scrollers. To avoid ladder or tower climbing, remote positioners would be nice (we can't afford to hire them yet....). This comes to 240 devices which have to be installed, configured and tested in 6 hours. When you start to look at the scale of the large touring rigs for rock bands, several thousand devices in one venue is not unthinkable. Martin Layley Samsung-SERI -----Original Message----- From: Stuart Cheshire [mailto:cheshire@apple.com] Sent: 07 August 2002 03:53 To: zeroconf@merit.edu Subject: Re: On attribute-based queries >I work in a field (entertainment technology) where networks >with several thousand devices came over the horizon >a while ago and are now knocking on the door. Really? Several thousand devices? Can you back this up with a real example? I can imagine owning ten or twenty hi-fi components, but not several thousand. I use X10 light switches in my house, but I don't have more than twenty or thirty of those. The cheapest object I think I own is a pencil, but even for something that cheap I can't see any reason to own several thousand pencils. I have a hard time thinking of any object of which I own several thousand. If I do need to own several thousand network devices, that seems like a strong argument to make them as cheap and simple as possible. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Aug 7 09:23:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16881 for ; Wed, 7 Aug 2002 09:23:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A23A2912D1; Wed, 7 Aug 2002 09:24:33 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5F40D912D4; Wed, 7 Aug 2002 09:24:33 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4D869912D1 for ; Wed, 7 Aug 2002 09:24:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 285DC5DE0D; Wed, 7 Aug 2002 09:24:32 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by segue.merit.edu (Postfix) with ESMTP id EACF25DD94 for ; Wed, 7 Aug 2002 09:24:31 -0400 (EDT) Received: from fwd01.sul.t-online.de by mailout02.sul.t-online.com with smtp id 17cQne-0004bS-04; Wed, 07 Aug 2002 15:24:30 +0200 Received: from cookie.tjansen.de (520059241914-0001@[80.132.184.20]) by fmrl01.sul.t-online.com with esmtp id 17cQnV-069OpkC; Wed, 7 Aug 2002 15:24:21 +0200 From: Tim Jansen Reply-To: tim@tjansen.de To: Subject: Re: On attribute-based queries Date: Wed, 7 Aug 2002 15:45:01 +0200 User-Agent: KMail/1.4.5 References: <200208070245.g772jhT01784@scv3.apple.com> In-Reply-To: <200208070245.g772jhT01784@scv3.apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200208071545.01902.ml@tjansen.de> X-Sender: 520059241914-0001@t-dialin.net Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Wednesday 07 August 2002 04:45, Stuart Cheshire wrote: > >Of course the chooser software has to filter > >"service:printer:http://169.254.17.202;(name=Epson Stylus 900n)" > >to present the user with something more friendly - like showing > But is every printer *required* to have a "name=xxx" attribute? Yes, if you require this in the service template. And only a service template allows you to use a service type like "service:printer". > Is every printer required to check that its name is unique, and take some > action if it is not? No. You may be able to require this in the service template, but the check+register action will not be atomic. But I dont think that it is good idea: You don't make things easier when one printer is called "Epson Stylus 900n" and the other one "Epson Stylus 900n #2". And if you turn both off and on again they may even swap their names, so the names are not even stable. Saving the printer's name in persistent memory will create other problems, so people could wonder why one model is called Epson Stylus 900n #3" even though there is only one printer in the network. And what happens if you put a printer that has previously been number #2 in a network that already has two printers of the type? A better solution is to add a unique/serial/random number to the URL or attributes so you get a persistent identifier for the printers, e.g. "service:printer:http://169.254.17.202;(name=Epson Stylus 900n),(serialno=65465421)". bye... From owner-zeroconf@merit.edu Wed Aug 7 10:41:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21046 for ; Wed, 7 Aug 2002 10:41:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3823E912D6; Wed, 7 Aug 2002 10:42:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1445912D7; Wed, 7 Aug 2002 10:42:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A10CA912D6 for ; Wed, 7 Aug 2002 10:42:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 77D895DDE9; Wed, 7 Aug 2002 10:42:36 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailout01.sul.t-online.com (mailout01.sul.t-online.com [194.25.134.80]) by segue.merit.edu (Postfix) with ESMTP id 43FDC5DDD0 for ; Wed, 7 Aug 2002 10:42:36 -0400 (EDT) Received: from fwd09.sul.t-online.de by mailout01.sul.t-online.com with smtp id 17cR6X-0000Ng-0A; Wed, 07 Aug 2002 15:44:01 +0200 Received: from cookie.tjansen.de (520059241914-0001@[80.132.184.20]) by fmrl09.sul.t-online.com with esmtp id 17cR6J-20Z9c0C; Wed, 7 Aug 2002 15:43:47 +0200 From: Tim Jansen Reply-To: tim@tjansen.de To: Subject: Re: On attribute-based queries Date: Wed, 7 Aug 2002 16:04:28 +0200 User-Agent: KMail/1.4.5 References: <200208070344.g773ijT00114@scv2.apple.com> In-Reply-To: <200208070344.g773ijT00114@scv2.apple.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200208071604.28036.ml@tjansen.de> X-Sender: 520059241914-0001@t-dialin.net Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Wednesday 07 August 2002 05:44, Stuart Cheshire wrote: > Err. Did I miss something here? The SLP protocol now requires every > device to implement the Soundex name matching algorithm to find variant > spellings of names? No, but it allows wildcards. So if I dont know how to spell your name I could search for "Stuar*" or "Ches*". It would be easy to use Soundex with SLP though: just store the Soundex code in the attribute. > Either way, the conclusion is the same -- one size does not fit all. > Let's strip the discovery protocol to the lowest practical common > denominator, and let each application implement the attribute matching > technique appropriate to that application. No one said that SLP's attribute queries are sufficient for all applications. But they should be sufficient for most, and help you to get a much better performance in large networks. bye... From owner-zeroconf@merit.edu Wed Aug 7 10:47:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21302 for ; Wed, 7 Aug 2002 10:47:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2D67A912D9; Wed, 7 Aug 2002 10:48:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F3057912D7; Wed, 7 Aug 2002 10:48:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E3591912DC for ; Wed, 7 Aug 2002 10:47:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C61535DDE9; Wed, 7 Aug 2002 10:47:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by segue.merit.edu (Postfix) with ESMTP id 67CF15DDD0 for ; Wed, 7 Aug 2002 10:47:58 -0400 (EDT) Received: from srvmail.cablelabs.com (srvmail.cablelabs.com [10.5.0.15]) by ondar.cablelabs.com (8.12.5/8.12.5) with ESMTP id g77EluYI022739 for ; Wed, 7 Aug 2002 08:47:56 -0600 (MDT) Received: by srvmail.cablelabs.com with Internet Mail Service (5.5.2653.19) id <30SSWRQX>; Wed, 7 Aug 2002 08:47:56 -0600 Message-ID: <4DF5E8A771ECD21187020008C7B1C5AF02D8825F@srvmail.cablelabs.com> From: Kevin Luehrs To: "'zeroconf@merit.edu'" Subject: DNS-SRV Date: Wed, 7 Aug 2002 08:47:52 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Approved: ondar Sender: owner-zeroconf@merit.edu Precedence: bulk I am new to this list so forgive the newby question, but I would like to know if DNS-SRV [RFC2782] is under consideration as the service discovery mechanism for the Zeroconf initiative. Kevin Luehrs ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Kevin Luehrs Project Director, CableHome Engineering CableLabs 400 Centennial Parkway Louisville, CO 80027 303 661 9100 fax 303 661 9199 k.luehrs@cablelabs.com From owner-zeroconf@merit.edu Wed Aug 7 11:33:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23774 for ; Wed, 7 Aug 2002 11:33:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7C579912DB; Wed, 7 Aug 2002 11:34:58 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 47A47912DC; Wed, 7 Aug 2002 11:34:58 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2394D912DB for ; Wed, 7 Aug 2002 11:34:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F1C645DDD0; Wed, 7 Aug 2002 11:34:56 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from smtpout.mac.com (unknown [204.179.120.87]) by segue.merit.edu (Postfix) with ESMTP id 79F645DD94 for ; Wed, 7 Aug 2002 11:34:56 -0400 (EDT) Received: from smtp-relay03.mac.com (smtp-relay03-en1 [10.13.10.222]) by smtpout.mac.com (8.12.1/8.10.2/1.0) with ESMTP id g77FZ0fY001879 for ; Wed, 7 Aug 2002 08:35:00 -0700 (PDT) Received: from asmtp01.mac.com (asmtp01-qfe3 [10.13.10.65]) by smtp-relay03.mac.com (8.12.1/8.12.1/1.0) with ESMTP id g77FYsKN007194 for ; Wed, 7 Aug 2002 08:34:54 -0700 (PDT) Received: from [10.1.1.168] ([209.204.163.150]) by asmtp01.mac.com (Netscape Messaging Server 4.15) with ESMTP id H0HCM500.7PJ for ; Wed, 7 Aug 2002 08:34:53 -0700 User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 07 Aug 2002 08:37:15 -0700 Subject: Re: On attribute-based queries From: Tony de Rijk To: Message-ID: In-Reply-To: <341710540F08E34498A057DEE04DAAD7279D6D@ex1.seri.co.uk> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Martin, I can back up your story for Stuart since I have done many large scale entertainment projects, mostly using Ethernet to provide communications using our Ethernet control units between consoles and lighting equipment. I have done projects with up to 10000 lighting channels, however this doesn't mean you need 10000 IP addresses. Lighting channels are normally bundled in dimmer packs and moving lights etc. So the real demand in terms of addressing capabilities is probably closer to less than 2000 in my example. Using AppleTalk over Ethernet we had systems like this set up in a very short time with virtually no network configuration time. Fortunately, zeroconf will allow us to do similar things based on IP. On 8/7/02 1:45 AM, "Martin Layley" wrote: > Stuart, > I can't remember who wrote the original note you are replying to, but I > sometimes stagecrew for amateur theatre groups. We often have only a few > hours on a Sunday afternoon to completely rig a theatre for a show (let in at > 12, with a rehearsal at 6 or 7pm). In that time, as well as all of the > scenery having to be placed, an entire lighting rig needs to be installed and > positioned. Currently, only part of the rig is networked - usually using DMX, > but increasingly 10base-T is appearing for the more complex effects units. > > A typical rig for a show in a 150 seat theatre will probably involve about 80 > lamps, each with colour scrollers. To avoid ladder or tower climbing, remote > positioners would be nice (we can't afford to hire them yet....). This comes > to 240 devices which have to be installed, configured and tested in 6 hours. > When you start to look at the scale of the large touring rigs for rock bands, > several thousand devices in one venue is not unthinkable. > > Martin Layley > Samsung-SERI > > -----Original Message----- > From: Stuart Cheshire [mailto:cheshire@apple.com] > Sent: 07 August 2002 03:53 > To: zeroconf@merit.edu > Subject: Re: On attribute-based queries > > >> I work in a field (entertainment technology) where networks >> with several thousand devices came over the horizon >> a while ago and are now knocking on the door. > > Really? > > Several thousand devices? > > Can you back this up with a real example? > > I can imagine owning ten or twenty hi-fi components, but not several > thousand. > > I use X10 light switches in my house, but I don't have more than twenty > or thirty of those. > > The cheapest object I think I own is a pencil, but even for something > that cheap I can't see any reason to own several thousand pencils. I have > a hard time thinking of any object of which I own several thousand. If I > do need to own several thousand network devices, that seems like a strong > argument to make them as cheap and simple as possible. > > Stuart Cheshire > * Wizard Without Portfolio, Apple Computer > * Chairman, IETF ZEROCONF > * www.stuartcheshire.org > > From owner-zeroconf@merit.edu Wed Aug 7 12:07:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25767 for ; Wed, 7 Aug 2002 12:07:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 67236912DE; Wed, 7 Aug 2002 12:08:23 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 347DD912E0; Wed, 7 Aug 2002 12:08:23 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 53658912DE for ; Wed, 7 Aug 2002 12:08:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3CBDD5DDED; Wed, 7 Aug 2002 12:08:22 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by segue.merit.edu (Postfix) with ESMTP id CDA105DDCE for ; Wed, 7 Aug 2002 12:08:21 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA04647; Wed, 7 Aug 2002 10:08:20 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g77G8Ib08593; Wed, 7 Aug 2002 18:08:18 +0200 (MEST) Date: Wed, 7 Aug 2002 18:07:35 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: Kevin Luehrs Cc: "'zeroconf@merit.edu'" Subject: Re: DNS-SRV In-Reply-To: <4DF5E8A771ECD21187020008C7B1C5AF02D8825F@srvmail.cablelabs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Wed, 7 Aug 2002, Kevin Luehrs wrote: > I am new to this list so forgive the newby question, but I would > like to know if DNS-SRV [RFC2782] is under consideration as the > service discovery mechanism for the Zeroconf initiative. There is no 'zeroconf initiative.' The zeroconf working group is chartered to produce two documents. One is on the requirements for zeroconf networking, the other is on IPv4 link local address autoconfiguration. Once these documents are published, the working group will have fulfilled its charter, I believe. Erik ZEROCONF WG cochair From owner-zeroconf@merit.edu Wed Aug 7 17:42:26 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10564 for ; Wed, 7 Aug 2002 17:42:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6518B91235; Wed, 7 Aug 2002 17:43:32 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 30D1D912BF; Wed, 7 Aug 2002 17:43:32 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1881091235 for ; Wed, 7 Aug 2002 17:43:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F28365DE1C; Wed, 7 Aug 2002 17:43:30 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id A6D6B5DDCE for ; Wed, 7 Aug 2002 17:43:30 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g77LhUJ07227 for ; Wed, 7 Aug 2002 14:43:30 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 7 Aug 2002 14:43:29 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id g77LhTT17862 for ; Wed, 7 Aug 2002 14:43:29 -0700 (PDT) Message-Id: <200208072143.g77LhTT17862@scv2.apple.com> Subject: Point of Order Date: Wed, 7 Aug 2002 14:43:35 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk > I have done a lot of work with appletalk (including implementing > all the bits that are relevant here). It isn't too hard to > implement (localtalk aside, but that's not relevant) it is > horrible to maintain (ever tried to change a zone name?). The charter of this working group is to work on the problem of: * making IP networking work... * with zero user configuration and... * zero dependence on external infrastructure to provide configuration. If someone wishes to make a brief observation that achieving this goal would allow us to retire AppleTalk (and that would be a good thing), then that is acceptable. However, protracted in-depth arguments about how easy (or hard) it may be (or may not be) to run a large AppleTalk network are out of scope for this list. This is not the "Bash AppleTalk Working Group" (or the "Support AppleTalk Working Group"). This Working Group has nothing to do with AppleTalk, except inasmuch as if we are successful, then people may not need to keep using AppleTalk much longer. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Aug 7 17:51:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10802 for ; Wed, 7 Aug 2002 17:51:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EDCCC912BF; Wed, 7 Aug 2002 17:52:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B951A912C4; Wed, 7 Aug 2002 17:52:07 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA0C0912BF for ; Wed, 7 Aug 2002 17:52:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BE8AF5DE1C; Wed, 7 Aug 2002 17:52:06 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 731A35DE1B for ; Wed, 7 Aug 2002 17:52:06 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g77Lq5A21600 for ; Wed, 7 Aug 2002 14:52:05 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 7 Aug 2002 14:52:05 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id g77Lq5T23454 for ; Wed, 7 Aug 2002 14:52:05 -0700 (PDT) Message-Id: <200208072152.g77Lq5T23454@scv2.apple.com> Subject: Re: List of Service Types Date: Wed, 7 Aug 2002 14:52:11 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >Soo... seems to me that a complete specification would need >to have templates for the TXT records along the lines that >SLP has schemas. Or do you have something else in mind? Percisely. This is what I wrote in "Discovering Named Instances of Abstract Services using DNS": Some services discovered via Service Instance Enumeration may need more than just an IP address and port number ... In these cases, the necessary additional data is stored in a TXT record with the same name as the SRV record. The specific nature of that additional data, and how it is to be used, is service-dependent. And, in section 6 "Selective Queries": The list of possible subtypes, if any, and the additional data stored in TXT records, if any, are defined separately for each basic service type. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Aug 7 18:43:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12460 for ; Wed, 7 Aug 2002 18:43:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CEECD91235; Wed, 7 Aug 2002 18:44:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7A174912D6; Wed, 7 Aug 2002 18:44:09 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3C60391235 for ; Wed, 7 Aug 2002 18:44:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2C9A45DE23; Wed, 7 Aug 2002 18:44:06 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id CE10A5DDBC for ; Wed, 7 Aug 2002 18:44:05 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g77Mi5J20359 for ; Wed, 7 Aug 2002 15:44:05 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 7 Aug 2002 15:44:04 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id g77Mi4T25092 for ; Wed, 7 Aug 2002 15:44:04 -0700 (PDT) Message-Id: <200208072244.g77Mi4T25092@scv2.apple.com> Subject: Re: Requirements for Service Discovery Date: Wed, 7 Aug 2002 15:44:10 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >You just root the SLP DAs within the DNS, so that you can reach the >SLP DAs for a given domain. This is described in the following draft: > >draft-zhao-slp-remote-da-discovery-03.txt Forgive me if I laugh, but let me quote from the introduction of that document: 1. Introduction DNS SRV [2] provides a convenient way for a UA to discover the SLP service Isn't that what I've been arguing all along? DNS SRV (as described in NIAS) provides a convenient way to discover any service. If you need to use DNS SRV to discover the service discovery server, why not just skip the middleman and use DNS SRV to discover the service you're actually looking for? Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Aug 7 19:05:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12908 for ; Wed, 7 Aug 2002 19:05:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A192F912DE; Wed, 7 Aug 2002 19:05:47 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7501B912DB; Wed, 7 Aug 2002 19:05:47 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A6D6A912C6 for ; Wed, 7 Aug 2002 19:05:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 90B8A5DDE9; Wed, 7 Aug 2002 19:05:43 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 142F65DDBC for ; Wed, 7 Aug 2002 19:05:43 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g77N5fA06273 for ; Wed, 7 Aug 2002 16:05:41 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 7 Aug 2002 16:05:42 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id g77N5fT06977 for ; Wed, 7 Aug 2002 16:05:41 -0700 (PDT) Message-Id: <200208072305.g77N5fT06977@scv2.apple.com> Subject: RE: On attribute-based queries Date: Wed, 7 Aug 2002 16:05:47 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk This is a good real-world example: >A typical rig for a show in a 150 seat theatre will probably >involve about 80 lamps, each with colour scrollers. To avoid >ladder or tower climbing, remote positioners would be nice (we >can't afford to hire them yet....). This comes to 240 devices >which have to be installed, configured and tested in 6 hours. The crux of the debate between SLP and DNS-SD is the assertion that you need a complicated attribute-query-based service discovery protocol, because a simple protocol couldn't work in a network this large. So, the question is this: Could a simple protocol work on a network with 240 devices, or more? Perhaps we can find existing operational experience by looking at what people did using the old AppleTalk Name Binding Protocol, a very simple-minded protocol. Over to you, Tony: >I have done projects with up to 10000 lighting channels, however >this doesn't mean you need 10000 IP addresses. Lighting channels >are normally bundled in dimmer packs and moving lights etc. So the >real demand in terms of addressing capabilities is probably closer >to less than 2000 in my example. > >Using AppleTalk over Ethernet we had systems like this set up in >a very short time with virtually no network configuration time. If something as exceedingly simple-minded and inefficient as AppleTalk NBP worked for Tony de Rijk in this environment, we need to look elsewhere for evidence that a complicated attribute-query-based service discovery protocol is worth the cost. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Aug 7 19:15:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13160 for ; Wed, 7 Aug 2002 19:15:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 42A0E912C6; Wed, 7 Aug 2002 19:15:51 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0FB32912CB; Wed, 7 Aug 2002 19:15:50 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 28885912C6 for ; Wed, 7 Aug 2002 19:15:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0F68B5DE18; Wed, 7 Aug 2002 19:15:50 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id B725D5DDBC for ; Wed, 7 Aug 2002 19:15:49 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g77NFnJ26441 for ; Wed, 7 Aug 2002 16:15:49 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 7 Aug 2002 16:15:48 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id g77NFmT12301 for ; Wed, 7 Aug 2002 16:15:48 -0700 (PDT) Message-Id: <200208072315.g77NFmT12301@scv2.apple.com> Subject: Re: DNS-SRV Date: Wed, 7 Aug 2002 16:15:54 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >I am new to this list so forgive the newby question, but I would >like to know if DNS-SRV [RFC2782] is under consideration as the >service discovery mechanism for the Zeroconf initiative. The IETF is an organization populated by individuals who come together to work on protocol design. This members of this Working Group, Zeroconf, working together, identified "discovery of services available on the network" as one of the basic requirements for Zeroconf networking. In my capacity as an individual contributor, not as co-chairman of the group, I made an individual submission proposing what I believe is the best way to meet that requirement: At the present time this document is an individual submission, not a product of the Working Group as a whole. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Wed Aug 7 23:30:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA19422 for ; Wed, 7 Aug 2002 23:30:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ADB4C912E5; Wed, 7 Aug 2002 23:30:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79017912E6; Wed, 7 Aug 2002 23:30:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8DC78912E5 for ; Wed, 7 Aug 2002 23:30:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 565665DE37; Wed, 7 Aug 2002 23:30:37 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id BB3C25DE20 for ; Wed, 7 Aug 2002 23:30:36 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g783UaJ09287 for ; Wed, 7 Aug 2002 20:30:36 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 7 Aug 2002 20:29:55 -0700 Received: from [206.111.147.156] (vpn-gh-63.apple.com [17.254.136.62]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id g783UZl06691 for ; Wed, 7 Aug 2002 20:30:35 -0700 (PDT) Message-Id: <200208080330.g783UZl06691@scv1.apple.com> Subject: Discovering Named Instances of Abstract Services using DNS Date: Wed, 7 Aug 2002 20:30:38 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk While we're talking about DNS-SD, this is a good opportunity to correct a misconception that some people seem to have. Some people seem to believe that Apple is not allowed to ship products using DNS-SD until the IETF has approved it. This is false. Apple, or any other company, is allowed to ship products using whatever networking protocols they choose. AppleTalk is an example of a protocol that Apple shipped and continues to ship without seeking any outside permission or approval. The AppleShare IP file sharing protocol is another protocol that Apple shipped and continues to ship without seeking any outside permission or approval. Microsoft and other companies do the same all the time. What is different in this case is that Apple is willing to share this protocol with the IETF. Of course Apple has patents to protect its intellectual property, but I am working with Apple's lawyers on getting an IPR statement offering a royalty-free license to those patents for the purpose of implementing this specification. If members of the IETF want to contribute to make this an open protocol, then Apple is willing to do that. If no one in the IETF cares about this, then Apple will continue to ship it, and it will be just like UPnP or FireWire or Bluetooth or USB or any of a countless list of other protocols that companies ship without any IETF involvement whatsoever. I'd like to take this opportunity to conduct a little survey. How many people have read the draft and think it is a good idea? How many people have read the draft and think it is a bad idea? At this stage let's hold off on the arguments why -- right now I'm just looking for a one-line answer: "I've read NIAS and I think it is good," or, "I've read NIAS and I think it is bad." Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Thu Aug 8 03:49:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03920 for ; Thu, 8 Aug 2002 03:49:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1202C912EB; Thu, 8 Aug 2002 03:49:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 68BEF912EC; Thu, 8 Aug 2002 03:49:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EC287912EB for ; Thu, 8 Aug 2002 03:49:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DABBD5DDDD; Thu, 8 Aug 2002 03:49:13 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 46B525DE44 for ; Thu, 8 Aug 2002 03:49:13 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g787nCJ06379 for ; Thu, 8 Aug 2002 00:49:12 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 8 Aug 2002 00:49:12 -0700 Received: from adsl-64-171-18-123.dsl.sntc01.pacbell.net (vpn-gh-62.apple.com [17.254.136.61]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g787nBT26797 for ; Thu, 8 Aug 2002 00:49:11 -0700 (PDT) Date: Thu, 8 Aug 2002 00:49:10 -0700 Subject: Re: Discovering Named Instances of Abstract Services using DNS Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: Joshua Graessley To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <200208080330.g783UZl06691@scv1.apple.com> Message-Id: <53163942-AAA3-11D6-9F11-000393760260@apple.com> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I've read NIAS and I think it is good -josh From owner-zeroconf@merit.edu Thu Aug 8 04:45:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05289 for ; Thu, 8 Aug 2002 04:45:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C8E54912F0; Thu, 8 Aug 2002 04:46:48 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C9EB0912F3; Thu, 8 Aug 2002 04:46:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C88A2912F0 for ; Thu, 8 Aug 2002 04:46:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4FEFF5DDDD; Thu, 8 Aug 2002 04:46:34 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from orgs.ecs.soton.ac.uk (orgs.ecs.soton.ac.uk [152.78.191.129]) by segue.merit.edu (Postfix) with ESMTP id ACCE45DD99 for ; Thu, 8 Aug 2002 04:46:33 -0400 (EDT) Received: (from stripes@localhost) by orgs.ecs.soton.ac.uk (8.9.3/8.9.3) id JAA06460; Thu, 8 Aug 2002 09:47:24 +0100 Date: Thu, 8 Aug 2002 09:47:23 +0100 From: Mark Thompson To: zeroconf@merit.edu Subject: Re: Requirements for Service Discovery Message-ID: <20020808084723.GA1074@orgs.ecs.soton.ac.uk> References: <200208072244.g77Mi4T25092@scv2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200208072244.g77Mi4T25092@scv2.apple.com> User-Agent: Mutt/1.3.28i Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On 15:44(GMT) 07-08-02, Stuart Cheshire wrote: > > Isn't that what I've been arguing all along? DNS SRV (as described in > NIAS) provides a convenient way to discover any service. > > If you need to use DNS SRV to discover the service discovery server, why > not just skip the middleman and use DNS SRV to discover the service > you're actually looking for? I think I agree in principle, but disagree with choice of implementation: NIAS promotes abuse of the TXT RR, which has been accepted (abused?) by many as having no semantic definition and therefore used in non-standard ways across many installations. If you're lucky then at least people might adopt style similar to that suggested in experimental RFC1464 (i.e. lots of 'IN TXT "attr=val"' entries for a single domain name), but then we're back to the game of "which ontology for attribute names does this definition belong to?" Just because an RR exists and its use accepted as being non-standardised doesn't mean that a later standard can come along and blat all over everyone else's (legitimate) use of the RR. *blush* - we abuse it by tieing registrar/warranty information etc. against domain names - stuff that isn't sensitive and therefore no problem if its public, but stuff for which there is no schema or ontology defining a syntax of use and no more convenient location to store it. Without creating yet another RR for service attributes within the DNS (and I'm not suggesting this!), I don't see how NIAS can reliably scale across sites. Maybe I've missed this being covered in an earlier thread. If so, shout at me and direct me to the nearest archive. Thanks ;-) Mark/ -- equator÷ irc .. .- -- university of southampton, uk From owner-zeroconf@merit.edu Thu Aug 8 07:07:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07824 for ; Thu, 8 Aug 2002 07:07:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4DD90912F4; Thu, 8 Aug 2002 07:08:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1F438912F6; Thu, 8 Aug 2002 07:08:15 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 34023912F4 for ; Thu, 8 Aug 2002 07:08:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 157275DE51; Thu, 8 Aug 2002 07:08:14 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id A58765DE34 for ; Thu, 8 Aug 2002 07:08:13 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA01820; Thu, 8 Aug 2002 05:08:12 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g78B8Ab15507; Thu, 8 Aug 2002 13:08:10 +0200 (MEST) Date: Thu, 8 Aug 2002 13:07:27 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Requirements for Service Discovery In-Reply-To: <200208072244.g77Mi4T25092@scv2.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Wed, 7 Aug 2002, Stuart Cheshire wrote: > > DNS SRV [2] provides a convenient way for a UA > to discover the SLP service > > Isn't that what I've been arguing all along? DNS SRV (as described in > NIAS) provides a convenient way to discover any service. It provides a way to discover some services with various limitations. > If you need to use DNS SRV to discover the service discovery server, why > not just skip the middleman and use DNS SRV to discover the service > you're actually looking for? Finding the service discovery service allows you to send complex queries. We are at loggerheads here, Stuart. Some argue for the utility of complex queries, others argue against their importance. I suggest we discontinue this largely esthetic debate. Erik From owner-zeroconf@merit.edu Thu Aug 8 07:11:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07955 for ; Thu, 8 Aug 2002 07:11:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 49AB6912F6; Thu, 8 Aug 2002 07:12:20 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14FE7912F7; Thu, 8 Aug 2002 07:12:20 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 23A6F912F6 for ; Thu, 8 Aug 2002 07:12:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EF9045DE53; Thu, 8 Aug 2002 07:12:18 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 8B8415DE34 for ; Thu, 8 Aug 2002 07:12:18 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA04340; Thu, 8 Aug 2002 05:12:17 -0600 (MDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g78BCFb15682; Thu, 8 Aug 2002 13:12:15 +0200 (MEST) Date: Thu, 8 Aug 2002 13:11:32 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: RE: On attribute-based queries In-Reply-To: <200208072305.g77N5fT06977@scv2.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Wed, 7 Aug 2002, Stuart Cheshire wrote: > The crux of the debate between SLP and DNS-SD is the assertion that you > need a complicated attribute-query-based service discovery protocol, I disagree that the SLP protocol is complicated. We're back to esthetics. > because a simple protocol couldn't work in a network this large. There is more to it than this. If you do not have attribute based queries, each service has to handle server feature discovery. So, by making the service discovery simpler you make applications more complex. Erik From owner-zeroconf@merit.edu Thu Aug 8 12:34:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18641 for ; Thu, 8 Aug 2002 12:34:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 511969122C; Thu, 8 Aug 2002 12:35:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 250D991303; Thu, 8 Aug 2002 12:35:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 457839122C for ; Thu, 8 Aug 2002 12:35:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 330D95DE5D; Thu, 8 Aug 2002 12:35:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ariel.eastgw.xerox.com (ariel.xerox.com [208.140.33.25]) by segue.merit.edu (Postfix) with ESMTP id 99B355DE5C for ; Thu, 8 Aug 2002 12:35:53 -0400 (EDT) Received: from "Firewall" (mswitch2.cinops.xerox.com [13.250.20.172]) by ariel.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id MAA14000; Thu, 8 Aug 2002 12:35:48 -0400 (EDT) Received: from CONVERSION-DAEMON.mgate.usa.xerox.com by mgate.usa.xerox.com (PMDF V6.1 #39864) id <0H0J00K019JZ8J@mgate.usa.xerox.com>; Thu, 08 Aug 2002 12:23:59 -0400 (EDT) Received: from usaxeroxbh1.USA.XEROX.COM (usaxeroxbh1.usa.xerox.com [13.250.20.25]) by mgate.usa.xerox.com (PMDF V6.1 #39864) with ESMTP id <0H0J00J5Z9JZWK@mgate.usa.xerox.com>; Thu, 08 Aug 2002 12:23:59 -0400 (EDT) Received: by usaxeroxbh1.usa.xerox.com with Internet Mail Service (5.5.2653.19) id ; Thu, 08 Aug 2002 12:35:49 -0400 Content-return: allowed Date: Thu, 08 Aug 2002 12:35:40 -0400 From: "Nicolae, Dan" Subject: RE: Discovering Named Instances of Abstract Services using DNS To: "'Stuart Cheshire'" , zeroconf@merit.edu Message-id: <3820E1EF15CCD411B4E600508BAED1F45BCF85@usa0111ms2.eng.mc.xerox.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain Sender: owner-zeroconf@merit.edu Precedence: bulk Stuart, I read it (fast) and I think the idea of using DNS for discovery in ad-hoc networks is good. I've argued for that two years ago on the UPnP mailing list. Back then it was about SSDP vs. mDNS. It is useful for simple devices in simple networks to talk a single protocol for both name resolution and service discovery. About how the document suggests DNS can be used for discovery, at this time I can only say that it may be a good start for discussion. Holding off the arguments, I will only mention that the idea of defining labels for services attributes (e.g. _postscript) I don't think it's going to fly. If we are to use DNS for service discovery I think we should give up the hope of doing queries by attributes (other than the service name itself). Dan > > I'd like to take this opportunity to conduct a little survey. > > > > How many people have read the draft and think it is a good idea? > > How many people have read the draft and think it is a bad idea? > > At this stage let's hold off on the arguments why -- > right now I'm just looking for a one-line answer: > "I've read NIAS and I think it is good," or, > "I've read NIAS and I think it is bad." > From owner-zeroconf@merit.edu Thu Aug 8 18:07:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28901 for ; Thu, 8 Aug 2002 18:07:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8FFA491314; Thu, 8 Aug 2002 18:08:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5928391315; Thu, 8 Aug 2002 18:08:36 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7C3E891314 for ; Thu, 8 Aug 2002 18:08:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5D1585DE56; Thu, 8 Aug 2002 18:08:35 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 10A015DD99 for ; Thu, 8 Aug 2002 18:08:35 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g78M8YR21538 for ; Thu, 8 Aug 2002 15:08:34 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 8 Aug 2002 15:07:54 -0700 Received: from [17.202.45.150] (il0204a-dhcp22.apple.com [17.202.45.150]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id g78M8Xl01005 for ; Thu, 8 Aug 2002 15:08:33 -0700 (PDT) Message-Id: <200208082208.g78M8Xl01005@scv1.apple.com> Subject: Re: Requirements for Service Discovery Date: Thu, 8 Aug 2002 15:08:37 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >I think I agree in principle, but disagree with choice of implementation: > >NIAS promotes abuse of the TXT RR, which has been accepted >(abused?) by many as having no semantic definition I agree that an explicit "attribute list" RR type would be good, but there is such opposition to creating any new DNS RR types that if you want to ship a product this decade, the only way to do it is with an existing type. I am willing to be proved wrong on this. If NIAS were to be adopted as an IETF document, and DNSEXT were to prove willing to create a new RR type to better support it, then Apple would find a way to do a backwards-compatible migration over to the new standard. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Aug 9 10:36:22 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA28390 for ; Fri, 9 Aug 2002 10:36:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BF93C91323; Fri, 9 Aug 2002 10:35:41 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0AD8491324; Fri, 9 Aug 2002 10:35:40 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5D68F91323 for ; Fri, 9 Aug 2002 10:35:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4405B5DEF5; Fri, 9 Aug 2002 10:35:35 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id B7DA15DEEF for ; Fri, 9 Aug 2002 10:35:34 -0400 (EDT) Received: from bebop.France.Sun.COM ([129.157.174.15]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25956; Fri, 9 Aug 2002 07:35:33 -0700 (PDT) Received: from lillen (lillen [129.157.212.23]) by bebop.France.Sun.COM (8.11.6+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g79EZWg19341; Fri, 9 Aug 2002 16:35:32 +0200 (MEST) Date: Fri, 9 Aug 2002 16:33:32 +0200 (CEST) From: Erik Nordmark Reply-To: Erik Nordmark Subject: RE: Discovering Named Instances of Abstract Services using DNS To: "Nicolae, Dan" Cc: "'Stuart Cheshire'" , zeroconf@merit.edu In-Reply-To: "Your message with ID" <3820E1EF15CCD411B4E600508BAED1F45BCF85@usa0111ms2.eng.mc.xerox.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > About how the document suggests DNS can be used for discovery, at this time > I can only say that it may be a good start for discussion. Holding off the > arguments, I will only mention that the idea of defining labels for services > attributes (e.g. _postscript) I don't think it's going to fly. If we are to > use DNS for service discovery I think we should give up the hope of doing > queries by attributes (other than the service name itself). So what is a "service name"? Is it "printer" or something more specific like "lpr" or "ipp" (which actually name the the protocol used to communicate to the service?) I think this is fundamentally different shades of grey. You could have _printer._tcp. and an adjunct protocol for discovering the capabilities of the printer (including the protocols used to send print jobs). A slightly different shade of grey is to use _slp._udp. and use the SLP protocol for discovering the capabilities of the printer (including the protocols used to send print jobs). In this case the "printer" specific protocol is replaced by an SLP service template, which describes the attributes. The difference between "define a service template per service" or "define a service capability protocol per service" doesn't seem significant to me - the hard part is figuring out what the standard and optional capabilities are for a given service. A different shade (in the other direction) is to use _lpr._tcp. and _ipp._tcp. and use lpr/ipp specific ways to discover the capabilities (but not the protocol used to send the print jobs since that's implicit in the tag). If there services which support many different protocols this seems like more work than the above to shades of grey. Erik From owner-zeroconf@merit.edu Fri Aug 9 12:03:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01462 for ; Fri, 9 Aug 2002 12:03:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7CC1391324; Fri, 9 Aug 2002 12:04:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A06891321; Fri, 9 Aug 2002 12:04:14 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BEDCB91324 for ; Fri, 9 Aug 2002 12:03:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A86EB5DED0; Fri, 9 Aug 2002 12:03:34 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ariel.eastgw.xerox.com (ariel.xerox.com [208.140.33.25]) by segue.merit.edu (Postfix) with ESMTP id 1C1615DDFE for ; Fri, 9 Aug 2002 12:03:34 -0400 (EDT) Received: from "Firewall" (mswitch2.cinops.xerox.com [13.250.20.172]) by ariel.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id MAA27652; Fri, 9 Aug 2002 12:03:31 -0400 (EDT) Received: from CONVERSION-DAEMON.mgate.usa.xerox.com by mgate.usa.xerox.com (PMDF V6.1 #39864) id <0H0L004012Q6A0@mgate.usa.xerox.com>; Fri, 09 Aug 2002 11:51:42 -0400 (EDT) Received: from usaxeroxbh1.USA.XEROX.COM (usaxeroxbh1.usa.xerox.com [13.250.20.25]) by mgate.usa.xerox.com (PMDF V6.1 #39864) with ESMTP id <0H0L003AX2Q6VL@mgate.usa.xerox.com>; Fri, 09 Aug 2002 11:51:42 -0400 (EDT) Received: by usaxeroxbh1.usa.xerox.com with Internet Mail Service (5.5.2653.19) id ; Fri, 09 Aug 2002 12:03:32 -0400 Content-return: allowed Date: Fri, 09 Aug 2002 12:03:26 -0400 From: "Nicolae, Dan" Subject: RE: Discovering Named Instances of Abstract Services using DNS To: "'Erik Nordmark'" Cc: zeroconf@merit.edu Message-id: <3820E1EF15CCD411B4E600508BAED1F45BCF8E@usa0111ms2.eng.mc.xerox.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-type: text/plain Sender: owner-zeroconf@merit.edu Precedence: bulk I am about to leave for vacation so I only have time for a few fast thoughts: > > So what is a "service name"? Is it "printer" or something > more specific > like "lpr" or "ipp" (which actually name the the protocol > used to communicate > to the service?) > > I think this is fundamentally different shades of grey. I agree. That's exactly why I said that we can only start talking about that at this time; we must decide where to stop. That would depend on the zeroconf requirements for service discovery; which I don't think provide that level of detail yet. If zeroconf is nothing more than a migration of AppleTalk and NetBIOS (including the MS Browser), than "printer" is enough. If zeroconf needs to take into account the IETF-documented printing protocols, then "ipp"/"lpr" is enough. If zeroconf does not imply losing any capabilities available in managed networks (i.e. what SLP can do) then we need SLP. From what I've heard so far, my impression is that zeroconf means more than the possibility to function when there is no centralized configuration. Besides that, it seems that we're also looking for a suite of protocols that can be easily implemented by simple devices. > > You could have > _printer._tcp. > and an adjunct protocol for discovering the capabilities of > the printer > (including the protocols used to send print jobs). > > A slightly different shade of grey is to use > _slp._udp. > and use the SLP protocol for discovering the capabilities of > the printer > (including the protocols used to send print jobs). > In this case the "printer" specific protocol is replaced by > an SLP service > template, which describes the attributes. > The difference between "define a service template per service" > or "define a service capability protocol per service" doesn't seem > significant to me - the hard part is figuring out what the > standard and > optional capabilities are for a given service. > > > A different shade (in the other direction) is to use > _lpr._tcp. > and > _ipp._tcp. > and use lpr/ipp specific ways to discover the capabilities (but not > the protocol used to send the print jobs since that's > implicit in the tag). > If there services which support many different protocols this seems > like more work than the above to shades of grey. > Yes, all these are possible. It seems like nobody here wants to start from the scratch with the user requirements. Everybody has one protocol in mind that they've used, they liked it and now think we should simply mimic it. In UPnP's case, when I proposed to use mDNS instead of SSDP, it wasn't because DNS is appropriate for service discovery in general. It was only because the UPnP service discovery requirements could have been easily achieved with DNS (already required for name resolution). So what are the zeroconf requirements for service discovery? Nothing more than AppleTalk/MS Browser, a lot more (like SLP/LDAP) or somewhere in between? Once we know that it will be easy to decide if DNS is appropriate or not. > > Erik > From owner-zeroconf@merit.edu Fri Aug 9 12:56:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03192 for ; Fri, 9 Aug 2002 12:56:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CC7B391237; Fri, 9 Aug 2002 12:57:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A67A9123B; Fri, 9 Aug 2002 12:57:09 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A268091237 for ; Fri, 9 Aug 2002 12:57:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7FD2B5DDFE; Fri, 9 Aug 2002 12:57:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by segue.merit.edu (Postfix) with ESMTP id E89C65DEFF for ; Fri, 9 Aug 2002 12:57:07 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA00955; Fri, 9 Aug 2002 09:57:06 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g79Gv5m14458; Fri, 9 Aug 2002 09:57:05 -0700 X-mProtect: <200208091657> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpd2riBnC; Fri, 09 Aug 2002 09:55:14 PDT Message-ID: <3D53F3E4.AA9DD1E0@iprg.nokia.com> Date: Fri, 09 Aug 2002 09:55:00 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Stuart Cheshire Cc: Zeroconf Working Group Mailing List Subject: [Fwd: Re: Requirements for Service Discovery] Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit 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 owner-zeroconf@merit.edu Fri Aug 9 14:38:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06697 for ; Fri, 9 Aug 2002 14:38:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D1B5991323; Fri, 9 Aug 2002 14:39:06 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9AE2E91324; Fri, 9 Aug 2002 14:39:06 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ABB0391323 for ; Fri, 9 Aug 2002 14:39:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 97B0F5DEFA; Fri, 9 Aug 2002 14:39:05 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 10AD55DEEF for ; Fri, 9 Aug 2002 14:39:05 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g79Id4R25151 for ; Fri, 9 Aug 2002 11:39:04 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 9 Aug 2002 11:38:23 -0700 Received: from graejo.apple.com (graejo.apple.com [17.202.40.111]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id g79Id4l10039 for ; Fri, 9 Aug 2002 11:39:04 -0700 (PDT) Date: Fri, 9 Aug 2002 11:39:00 -0700 Subject: Re: Discovering Named Instances of Abstract Services using DNS Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: Joshua Graessley To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <45699AFC-ABC7-11D6-BC38-000393760260@apple.com> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, August 9, 2002, at 07:33 AM, Erik Nordmark wrote: >> About how the document suggests DNS can be used for discovery, at >> this time >> I can only say that it may be a good start for discussion. Holding >> off the >> arguments, I will only mention that the idea of defining labels for >> services >> attributes (e.g. _postscript) I don't think it's going to fly. If we >> are to >> use DNS for service discovery I think we should give up the hope of >> doing >> queries by attributes (other than the service name itself). > > So what is a "service name"? Is it "printer" or something more specific > like "lpr" or "ipp" (which actually name the the protocol used to > communicate > to the service?) I believe the intent is to use the service names IANA uses in their list of assigned ports. lpr's service name is printer. ipp's serivce name is ipp. So a printer supporting both ipp and lpr would register _printer._tcp.. and _ipp._tcp... Registering as just _printer._tcp.. would not work because there are actually two protocols running on two different ports. Part of the information returned about a service is the port it is running on. In cases where the port is not enough to distinguish between two services on the same machine, such as the case of lpr where a print queue is also necessary, the TXT record is used to specify the additional information. As noted before, such information would be protocol specific. Most protocols do not need additional information. -josh From owner-zeroconf@merit.edu Fri Aug 9 14:59:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07357 for ; Fri, 9 Aug 2002 14:59:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0575091324; Fri, 9 Aug 2002 15:00:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 770E391325; Fri, 9 Aug 2002 15:00:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4141D91324 for ; Fri, 9 Aug 2002 15:00:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 528035DF04; Fri, 9 Aug 2002 15:00:13 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by segue.merit.edu (Postfix) with ESMTP id 8D0105DDA5 for ; Fri, 9 Aug 2002 15:00:12 -0400 (EDT) Received: from fwd01.sul.t-online.de by mailout08.sul.t-online.com with smtp id 17dEzQ-0005zM-0E; Fri, 09 Aug 2002 21:00:00 +0200 Received: from cookie.tjansen.de (520059241914-0001@[217.226.28.40]) by fmrl01.sul.t-online.com with esmtp id 17dEzL-1g9gXYC; Fri, 9 Aug 2002 20:59:55 +0200 From: Tim Jansen Reply-To: tim@tjansen.de To: "Charles E. Perkins" Subject: Re: [Fwd: Re: Requirements for Service Discovery] Date: Fri, 9 Aug 2002 21:21:40 +0200 User-Agent: KMail/1.4.5 References: <3D53F3E4.AA9DD1E0@iprg.nokia.com> In-Reply-To: <3D53F3E4.AA9DD1E0@iprg.nokia.com> Cc: Zeroconf Working Group Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200208092121.41100.ml@tjansen.de> X-Sender: 520059241914-0001@t-dialin.net Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Friday 09 August 2002 18:55, Charles E. Perkins wrote: > 1) It should be possible to write a SLP service > agent VERY cheaply. The DA is more complicated, > 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 owner-zeroconf@merit.edu Fri Aug 9 15:34:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08384 for ; Fri, 9 Aug 2002 15:34:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 53FB691325; Fri, 9 Aug 2002 15:35:22 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1D28F91326; Fri, 9 Aug 2002 15:35:22 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 19A9A91325 for ; Fri, 9 Aug 2002 15:35:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0010F5DF06; Fri, 9 Aug 2002 15:35:20 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 93A9D5DF05 for ; Fri, 9 Aug 2002 15:35:20 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA22833 for ; Fri, 9 Aug 2002 15:35:20 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA22192 for ; Fri, 9 Aug 2002 15:35:19 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA24870 for ; Fri, 9 Aug 2002 15:35:19 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Fri, 09 Aug 2002 15:35:17 -0400 Subject: Re: [Fwd: Re: Requirements for Service Discovery] From: "John C. Welch" To: Zeroconf Working Group Mailing List Message-ID: In-Reply-To: <3D53F3E4.AA9DD1E0@iprg.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/09/2002 12:55, "Charles E. Perkins" wrote: > 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. 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 owner-zeroconf@merit.edu Fri Aug 9 16:37:20 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09898 for ; Fri, 9 Aug 2002 16:37:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EEE3791329; Fri, 9 Aug 2002 16:38:25 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B80949132A; Fri, 9 Aug 2002 16:38:24 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BAA9F91329 for ; Fri, 9 Aug 2002 16:38:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A24BD5DF0E; Fri, 9 Aug 2002 16:38:23 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by segue.merit.edu (Postfix) with ESMTP id 211695DF0D for ; Fri, 9 Aug 2002 16:38:23 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id NAA15082; Fri, 9 Aug 2002 13:38:22 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g79KcLW05287; Fri, 9 Aug 2002 13:38:21 -0700 X-mProtect: <200208092038> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdqwWyF7; Fri, 09 Aug 2002 13:38:18 PDT Message-ID: <3D54283B.3EF3E527@iprg.nokia.com> Date: Fri, 09 Aug 2002 13:38:19 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "John C. Welch" Cc: Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello John, "John C. Welch" wrote: > 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. 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 > 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. 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 owner-zeroconf@merit.edu Fri Aug 9 17:08:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11239 for ; Fri, 9 Aug 2002 17:08:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4406B9132B; Fri, 9 Aug 2002 17:09:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1132C9132C; Fri, 9 Aug 2002 17:09:15 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E57E79132B for ; Fri, 9 Aug 2002 17:09:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C850B5DF11; Fri, 9 Aug 2002 17:09:14 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 5B6475DED5 for ; Fri, 9 Aug 2002 17:09:14 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA28585 for ; Fri, 9 Aug 2002 17:09:13 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA23737 for ; Fri, 9 Aug 2002 17:09:13 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA02758 for ; Fri, 9 Aug 2002 17:00:29 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Fri, 09 Aug 2002 17:00:27 -0400 Subject: Re: [Fwd: Re: Requirements for Service Discovery] From: "John C. Welch" To: Zeroconf Working Group Mailing List Message-ID: In-Reply-To: <3D54283B.3EF3E527@iprg.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/09/2002 16:38, "Charles E. Perkins" wrote: >> 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. > > 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? 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. > > 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. *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. > > 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. 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. > 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). And a simple implementation of SLP that I can install today across five platforms exists where? > >> 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. 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 owner-zeroconf@merit.edu Fri Aug 9 17:42:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12426 for ; Fri, 9 Aug 2002 17:42:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C4919132E; Fri, 9 Aug 2002 17:43:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3575791332; Fri, 9 Aug 2002 17:43:39 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 484E49132E for ; Fri, 9 Aug 2002 17:43:38 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 35AAD5DF1A; Fri, 9 Aug 2002 17:43:38 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.54]) by segue.merit.edu (Postfix) with ESMTP id EC4BF5DED5 for ; Fri, 9 Aug 2002 17:43:37 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id g79Lhb6I013404; Fri, 9 Aug 2002 14:43:37 -0700 (PDT) Received: from JSCHNIZL-W2K1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g79LhYiU004785; Fri, 9 Aug 2002 14:43:36 -0700 (PDT) Message-Id: <4.3.2.7.2.20020809173632.018a71e8@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 09 Aug 2002 17:39:01 -0400 To: "John C. Welch" From: John Schnizlein Subject: Re: [Fwd: Re: Requirements for Service Discovery] Cc: Zeroconf Working Group Mailing List In-Reply-To: References: <3D54283B.3EF3E527@iprg.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk 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: >>> 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. > >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. From owner-zeroconf@merit.edu Fri Aug 9 18:33:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA13799 for ; Fri, 9 Aug 2002 18:33:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2AB7091334; Fri, 9 Aug 2002 18:31:20 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id F1B9E91335; Fri, 9 Aug 2002 18:31:16 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6DCF491334 for ; Fri, 9 Aug 2002 18:30:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5ADBE5DE37; Fri, 9 Aug 2002 18:30:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by segue.merit.edu (Postfix) with ESMTP id C8CFA5DDB7 for ; Fri, 9 Aug 2002 18:30:53 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA22362; Fri, 9 Aug 2002 15:30:52 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g79MUpn15311; Fri, 9 Aug 2002 15:30:51 -0700 X-mProtect: <200208092230> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdenKC2f; Fri, 09 Aug 2002 15:30:49 PDT Message-ID: <3D54429A.C0FA272E@iprg.nokia.com> Date: Fri, 09 Aug 2002 15:30:50 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "John C. Welch" Cc: Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello again John, Gotta go home soon, but ... "John C. Welch" wrote: > 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. 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. >> 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. > > *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. 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 > platforms exists where? 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. > 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. 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, > 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. 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 owner-zeroconf@merit.edu Fri Aug 9 18:41:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14008 for ; Fri, 9 Aug 2002 18:41:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 816E891335; Fri, 9 Aug 2002 18:42:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 54C2791336; Fri, 9 Aug 2002 18:42:36 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4516B91335 for ; Fri, 9 Aug 2002 18:42:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2A05B5DF1F; Fri, 9 Aug 2002 18:42:35 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id BDA615DDB7 for ; Fri, 9 Aug 2002 18:42:34 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA26741 for ; Fri, 9 Aug 2002 18:42:34 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA11648 for ; Fri, 9 Aug 2002 18:42:34 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id SAA26454 for ; Fri, 9 Aug 2002 18:42:33 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Fri, 09 Aug 2002 18:42:31 -0400 Subject: Re: [Fwd: Re: Requirements for Service Discovery] From: "John C. Welch" To: Zeroconf Working Group Mailing List Message-ID: In-Reply-To: <4.3.2.7.2.20020809173632.018a71e8@wells.cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/09/2002 17:39, "John Schnizlein" wrote: > If you thought the F-111 was bad for that reason, > 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, Larry Ellison 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 owner-zeroconf@merit.edu Fri Aug 9 18:53:04 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14289 for ; Fri, 9 Aug 2002 18:53:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2E06A91338; Fri, 9 Aug 2002 18:54:01 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED5F191339; Fri, 9 Aug 2002 18:54:00 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 10AEE91338 for ; Fri, 9 Aug 2002 18:53:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E8CF05DE85; Fri, 9 Aug 2002 18:53:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 86EF35DDB7 for ; Fri, 9 Aug 2002 18:53:58 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA28859 for ; Fri, 9 Aug 2002 18:53:58 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id SAA12107 for ; Fri, 9 Aug 2002 18:53:57 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id SAA28595 for ; Fri, 9 Aug 2002 18:53:57 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Fri, 09 Aug 2002 18:53:55 -0400 Subject: Re: [Fwd: Re: Requirements for Service Discovery] From: "John C. Welch" To: Zeroconf Working Group Mailing List Message-ID: In-Reply-To: <3D54429A.C0FA272E@iprg.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/09/2002 18:30, "Charles E. Perkins" wrote: >> 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. > > 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. 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 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. > > 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. 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... > > 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. That may be...but configuring SLP is still voodoo, and not that many networking setups use it at all. > >> And a simple implementation of SLP that I can install today across five >> platforms exists where? > > 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. DNS runs on everything right now. > >> 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. > > 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. 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. > >> 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. > > 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. But then different simple liteSLP implementations end up not working with each other. > > This is better than requiring the units to implement multiple > 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 owner-zeroconf@merit.edu Fri Aug 9 19:07:43 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA14531 for ; Fri, 9 Aug 2002 19:07:43 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 38F0791337; Fri, 9 Aug 2002 19:08:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0A34891339; Fri, 9 Aug 2002 19:08:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EAA4991337 for ; Fri, 9 Aug 2002 19:08:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CEBD85DF1F; Fri, 9 Aug 2002 19:08:37 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by segue.merit.edu (Postfix) with ESMTP id 4BABE5DE85 for ; Fri, 9 Aug 2002 19:08:37 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id QAA23866; Fri, 9 Aug 2002 16:08:36 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g79N8ZX19936; Fri, 9 Aug 2002 16:08:35 -0700 X-mProtect: <200208092308> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdorR3NP; Fri, 09 Aug 2002 16:08:33 PDT Message-ID: <3D544B72.ABEF187E@iprg.nokia.com> Date: Fri, 09 Aug 2002 16:08:34 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "John C. Welch" Cc: Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit "John C. Welch" wrote: > >> *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. > > > > 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. > > 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... 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. > > 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. It should be the case the SLP can be used without configuration. > > 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. > > 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... > > 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. > > But then different simple liteSLP implementations end up not working with > each other. Not if they follow protocol. >> This is better than requiring the units to implement multiple >> 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. 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 owner-zeroconf@merit.edu Fri Aug 9 20:55:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16498 for ; Fri, 9 Aug 2002 20:55:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 521919121E; Fri, 9 Aug 2002 20:56:25 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2406391237; Fri, 9 Aug 2002 20:56:25 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 322DC9121E for ; Fri, 9 Aug 2002 20:56:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1C3305DF1F; Fri, 9 Aug 2002 20:56:24 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id B9FCD5DDB7 for ; Fri, 9 Aug 2002 20:56:23 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g7A0uNR06085 for ; Fri, 9 Aug 2002 17:56:23 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 9 Aug 2002 17:56:22 -0700 Received: from graejo.apple.com (graejo.apple.com [17.202.40.111]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g7A0uMT02899 for ; Fri, 9 Aug 2002 17:56:22 -0700 (PDT) Date: Fri, 9 Aug 2002 17:56:11 -0700 Subject: Re: [Fwd: Re: Requirements for Service Discovery] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: Joshua Graessley To: Zeroconf Working Group Mailing List Content-Transfer-Encoding: 7bit In-Reply-To: <3D544B72.ABEF187E@iprg.nokia.com> Message-Id: X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, August 9, 2002, at 04:08 PM, Charles E. Perkins wrote: > "John C. Welch" wrote: > >> 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... > > 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. 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 owner-zeroconf@merit.edu Sat Aug 10 00:48:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20651 for ; Sat, 10 Aug 2002 00:48:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4FE9591213; Sat, 10 Aug 2002 00:49:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7DDEF91218; Sat, 10 Aug 2002 00:49:06 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3087E91213 for ; Sat, 10 Aug 2002 00:48:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 001D15DF3D; Sat, 10 Aug 2002 00:48:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 952145DF3C for ; Sat, 10 Aug 2002 00:48:12 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id AAA17104 for ; Sat, 10 Aug 2002 00:48:12 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA21037 for ; Sat, 10 Aug 2002 00:48:11 -0400 (EDT) Received: from [10.0.0.2] (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id AAA17110 for ; Sat, 10 Aug 2002 00:48:10 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Sat, 10 Aug 2002 00:48:09 -0400 Subject: Re: [Fwd: Re: Requirements for Service Discovery] From: "John C. Welch" To: Zeroconf Working Group Mailing List Message-ID: In-Reply-To: <3D544B72.ABEF187E@iprg.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/09/2002 19:08, "Charles E. Perkins" wrote: >> 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... > > 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. 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. >>> 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. >> >> DNS runs on everything right now. > > 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.? > 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? 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? >> But then different simple liteSLP implementations end up not working with >> each other. > > 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. >> 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. > > 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. 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 owner-zeroconf@merit.edu Sat Aug 10 06:35:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA06235 for ; Sat, 10 Aug 2002 06:35:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 756C99120F; Sat, 10 Aug 2002 06:36:49 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4151991236; Sat, 10 Aug 2002 06:36:49 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 30F479120F for ; Sat, 10 Aug 2002 06:36:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1052C5DF50; Sat, 10 Aug 2002 06:36:48 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by segue.merit.edu (Postfix) with ESMTP id D37B05DF0D for ; Sat, 10 Aug 2002 06:36:47 -0400 (EDT) Received: from fwd09.sul.t-online.de by mailout04.sul.t-online.com with smtp id 17dTby-0006eB-05; Sat, 10 Aug 2002 12:36:46 +0200 Received: from cookie.tjansen.de (520059241914-0001@[80.132.181.215]) by fmrl09.sul.t-online.com with esmtp id 17dTbv-2CITyKC; Sat, 10 Aug 2002 12:36:43 +0200 From: Tim Jansen Reply-To: tim@tjansen.de To: Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] Date: Sat, 10 Aug 2002 12:59:02 +0200 User-Agent: KMail/1.4.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200208101259.02625.ml@tjansen.de> X-Sender: 520059241914-0001@t-dialin.net Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Saturday 10 August 2002 06:48, John C. Welch wrote: > >>> 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, > Only if you want more than link local. What about configuring different SLP > zones, DAs etc.? 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 owner-zeroconf@merit.edu Sun Aug 11 00:43:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25840 for ; Sun, 11 Aug 2002 00:43:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 11D3291238; Sun, 11 Aug 2002 00:44:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C9B259124D; Sun, 11 Aug 2002 00:44:14 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DA1EA91238 for ; Sun, 11 Aug 2002 00:44:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B62D15DFB1; Sun, 11 Aug 2002 00:44:13 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.2]) by segue.merit.edu (Postfix) with ESMTP id 38FE55DE2E for ; Sun, 11 Aug 2002 00:44:12 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7B4i6o20819; Sun, 11 Aug 2002 11:44:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7ADLlq20459; Sat, 10 Aug 2002 20:21:47 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Erik Guttman Cc: Kevin Luehrs , "'zeroconf@merit.edu'" Subject: Re: DNS-SRV In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 Aug 2002 20:21:47 +0700 Message-ID: <20457.1028985707@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 7 Aug 2002 18:07:35 +0200 (CEST) From: Erik Guttman Message-ID: | The zeroconf working group is | chartered to produce two documents. One is on the requirements | for zeroconf networking, the other is on IPv4 link local address | autoconfiguration. Once these documents are published, the working | group will have fulfilled its charter, I believe. That is possible - I kind of suspect however that if the requirements doc says that, apart from link local addresses for V4, we also need X, Y and Z, then either this WG, or perhaps several continuation WG's (depending upon just what X Y and Z are) will be chartered to work on those. I would kind of suspect that some form or service/server discovery mechanism might be a useful requirement to have, as is likely to be some non DS kind of name lookup mechanism (a zeroconf type of lookup). kre From owner-zeroconf@merit.edu Sun Aug 11 00:43:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25858 for ; Sun, 11 Aug 2002 00:43:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0B17391255; Sun, 11 Aug 2002 00:44:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 422039125A; Sun, 11 Aug 2002 00:44:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id ED3EA91255 for ; Sun, 11 Aug 2002 00:44:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DBE915DE2E; Sun, 11 Aug 2002 00:44:15 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.2]) by segue.merit.edu (Postfix) with ESMTP id 41C505DFB1 for ; Sun, 11 Aug 2002 00:44:14 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7B4i8o20828; Sun, 11 Aug 2002 11:44:08 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7ADUIq20529; Sat, 10 Aug 2002 20:30:18 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "John C. Welch" Cc: Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 Aug 2002 20:30:18 +0700 Message-ID: <20527.1028986218@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 09 Aug 2002 15:35:17 -0400 From: "John C. Welch" Message-ID: | 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 owner-zeroconf@merit.edu Sun Aug 11 00:43:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25875 for ; Sun, 11 Aug 2002 00:43:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DEDEF9125A; Sun, 11 Aug 2002 00:44:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 03A4D9124D; Sun, 11 Aug 2002 00:44:18 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA3199124D for ; Sun, 11 Aug 2002 00:44:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA5BE5DE2E; Sun, 11 Aug 2002 00:44:16 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.2]) by segue.merit.edu (Postfix) with ESMTP id 321075DFB2 for ; Sun, 11 Aug 2002 00:44:15 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7B4i4o20816; Sun, 11 Aug 2002 11:44:04 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7ADJEq20432; Sat, 10 Aug 2002 20:19:14 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Discovering Named Instances of Abstract Services using DNS In-Reply-To: <200208080330.g783UZl06691@scv1.apple.com> References: <200208080330.g783UZl06691@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 Aug 2002 20:19:14 +0700 Message-ID: <20430.1028985554@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 7 Aug 2002 20:30:38 -0700 From: Stuart Cheshire Message-ID: <200208080330.g783UZl06691@scv1.apple.com> | I haven't read that draft, I find it too hard to keep up with ones that are in the I-D directories. I read what might be an earlier version in the I-D directories. If you seriously expect the WG to consider this, you really should take the effort to keep it current (which means perhaps resubmitting it once every 6 months if there are no changes happening). | How many people have read the draft and think it is a bad idea? Assuming that nothing substantive has changed, that's me. I sent private mail in response to a private message saying why already... Others here are also covering many of the same points, and more my reply didn't get down to smaller details like abuse of TXT records, or name space pollution). kre From owner-zeroconf@merit.edu Sun Aug 11 00:44:03 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25888 for ; Sun, 11 Aug 2002 00:44:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B8D9B9124E; Sun, 11 Aug 2002 00:44:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2D4DA9125F; Sun, 11 Aug 2002 00:44:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D2DEA9124E for ; Sun, 11 Aug 2002 00:44:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C14D85DFB3; Sun, 11 Aug 2002 00:44:15 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.2]) by segue.merit.edu (Postfix) with ESMTP id 3C0255DE2E for ; Sun, 11 Aug 2002 00:44:14 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7B4i8o20825; Sun, 11 Aug 2002 11:44:08 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7ADb9q20582; Sat, 10 Aug 2002 20:37:09 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "John C. Welch" Cc: Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 10 Aug 2002 20:37:09 +0700 Message-ID: <20580.1028986629@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 09 Aug 2002 18:53:55 -0400 From: "John C. Welch" Message-ID: | 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 owner-zeroconf@merit.edu Sun Aug 11 02:07:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06377 for ; Sun, 11 Aug 2002 02:07:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 077579124D; Sun, 11 Aug 2002 02:08:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD63A9125F; Sun, 11 Aug 2002 02:08:29 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A4DA39124D for ; Sun, 11 Aug 2002 02:08:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 83BE25DFB7; Sun, 11 Aug 2002 02:08:28 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 1E5B65DE2E for ; Sun, 11 Aug 2002 02:08:28 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id CAA08063 for ; Sun, 11 Aug 2002 02:08:27 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id CAA21697 for ; Sun, 11 Aug 2002 02:08:27 -0400 (EDT) Received: from [10.0.0.2] (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id CAA02735 for ; Sun, 11 Aug 2002 02:08:26 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Sun, 11 Aug 2002 02:08:25 -0400 Subject: Re: [Fwd: Re: Requirements for Service Discovery] From: "John C. Welch" To: Zeroconf Working Group Mailing List Message-ID: In-Reply-To: <20580.1028986629@munnari.OZ.AU> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/10/2002 09:37, "Robert Elz" wrote: > | 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. There's better info out there on DNS and its applications than SLP. > | 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. 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. > > | 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 didn't say in every situation...but if it supports IP, it supports DNS. > 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). 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 owner-zeroconf@merit.edu Sun Aug 11 03:28:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07633 for ; Sun, 11 Aug 2002 03:28:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6D80D9125F; Sun, 11 Aug 2002 03:29:17 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2CE8A91262; Sun, 11 Aug 2002 03:29:17 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 18CB09125F for ; Sun, 11 Aug 2002 03:29:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DD22C5DFC0; Sun, 11 Aug 2002 03:29:15 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.2]) by segue.merit.edu (Postfix) with ESMTP id 5138C5DE2E for ; Sun, 11 Aug 2002 03:29:14 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7B7T8o25070; Sun, 11 Aug 2002 14:29:08 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7B7SS104032; Sun, 11 Aug 2002 14:28:28 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "John C. Welch" Cc: Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Aug 2002 14:28:28 +0700 Message-ID: <4030.1029050908@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 11 Aug 2002 02:08:25 -0400 From: "John C. Welch" Message-ID: | 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 owner-zeroconf@merit.edu Sun Aug 11 04:56:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA09141 for ; Sun, 11 Aug 2002 04:56:20 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D3A9D91262; Sun, 11 Aug 2002 04:57:25 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9B49091263; Sun, 11 Aug 2002 04:57:25 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7AE9191262 for ; Sun, 11 Aug 2002 04:57:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 555505DFC9; Sun, 11 Aug 2002 04:57:24 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mta05ps.bigpond.com (mta05ps.bigpond.com [144.135.25.137]) by segue.merit.edu (Postfix) with ESMTP id 487C45DFC8 for ; Sun, 11 Aug 2002 04:57:23 -0400 (EDT) Received: from 192.168.1.242 ([144.135.25.87]) by mta05ps.bigpond.com (Netscape Messaging Server 4.15 mta05ps May 23 2002 23:53:28) with SMTP id H0O8VK00.C14; Sun, 11 Aug 2002 18:57:20 +1000 Received: from CPE-203-51-35-244.nsw.bigpond.net.au ([203.51.35.244]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0n 119/38633949); 11 Aug 2002 18:57:20 From: Brad Hards To: Robert Elz , "John C. Welch" Subject: Re: [Fwd: Re: Requirements for Service Discovery] Date: Sun, 11 Aug 2002 18:52:16 +1000 User-Agent: KMail/1.4.5 Cc: Zeroconf Working Group Mailing List References: <4030.1029050908@munnari.OZ.AU> In-Reply-To: <4030.1029050908@munnari.OZ.AU> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200208111852.16290.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 11 Aug 2002 17:28, Robert Elz wrote: > 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. 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. > 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. I assumed that there would be a TTL (or equivalent) timeout. > 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? Has to be some kind of timeout.' > 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...) Don't know how this was done in NBP (or is done in SLP), but the DNS analog is obvious. 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9ViXAW6pHgIdAuOMRAlLtAJ0TfwUWSWuvl352dVsjg52jSNA+DACgsfIy km9kH9sKDD2JARfDn/nl2U8= =TAvT -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Sun Aug 11 07:32:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11284 for ; Sun, 11 Aug 2002 07:32:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0D6F691248; Sun, 11 Aug 2002 07:34:00 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CF5299123B; Sun, 11 Aug 2002 07:33:59 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 78DCE91248 for ; Sun, 11 Aug 2002 07:31:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5AEEF5DFBA; Sun, 11 Aug 2002 07:31:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailout11.sul.t-online.com (mailout11.sul.t-online.com [194.25.134.85]) by segue.merit.edu (Postfix) with ESMTP id 29B985DE2E for ; Sun, 11 Aug 2002 07:31:58 -0400 (EDT) Received: from fwd06.sul.t-online.de by mailout11.sul.t-online.com with smtp id 17dqw3-0008CA-03; Sun, 11 Aug 2002 13:31:03 +0200 Received: from cookie.tjansen.de (520059241914-0001@[217.226.22.143]) by fmrl06.sul.t-online.com with esmtp id 17dqw0-1TpEZsC; Sun, 11 Aug 2002 13:31:00 +0200 From: Tim Jansen Reply-To: tim@tjansen.de To: Robert Elz Subject: Re: [Fwd: Re: Requirements for Service Discovery] Date: Sun, 11 Aug 2002 13:53:55 +0200 User-Agent: KMail/1.4.5 References: <4030.1029050908@munnari.OZ.AU> In-Reply-To: <4030.1029050908@munnari.OZ.AU> Cc: Zeroconf Working Group Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200208111353.55019.ml@tjansen.de> X-Sender: 520059241914-0001@t-dialin.net Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Sunday 11 August 2002 09:28, Robert Elz wrote: > 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. Or maybe you should give CUPS (www.cups.org) a chance, which is a lpr replacement and supports SLP. bye... From owner-zeroconf@merit.edu Sun Aug 11 21:04:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26072 for ; Sun, 11 Aug 2002 21:04:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ECB3E91253; Sun, 11 Aug 2002 21:03:57 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5E9A91250; Sun, 11 Aug 2002 21:03:57 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D8B4D9124F for ; Sun, 11 Aug 2002 21:03:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ACA8A5DDD3; Sun, 11 Aug 2002 21:03:39 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sigmabravo.com.au (CPE-203-51-35-185.nsw.bigpond.net.au [203.51.35.185]) by segue.merit.edu (Postfix) with SMTP id 4F1D65DDD1 for ; Sun, 11 Aug 2002 21:03:38 -0400 (EDT) Received: (qmail 3680 invoked by uid 8); 12 Aug 2002 00:58:20 -0000 Received: from pc-00081 (192.168.0.81) by gateway.sigmabravo.com.au with SMTP id smtpdNYHRvi; Sun, 11 Aug 2002 20:58:11 EDT From: Brad Hards To: Zeroconf Working Group Mailing List Subject: [OT] Autoconfiguration BoF at Linux-Kongress (4-6 Sep, Cologne) Date: Mon, 12 Aug 2002 10:58:20 +1000 User-Agent: KMail/1.4.5 MIME-Version: 1.0 Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200208121057.22100.bhards@bigpond.net.au> Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'll be at Linux-Kongress 2002 (aka 9th International Linux System Technology Conference), which will be held in Cologne (Koln) from 4-6 September 2002. See http://www.linux-kongress.org/2002/index.html for details. If there are people with interest in implementing zeroconf technologies and other networking "ease of use" ideas, eg SLP, that could be used in simple networking scenarios), who will be at that conference, please let me know - I will try to organise a Birds of a Feather session if there is any interest. Sorry for the partly off-topic nature of this post. Brad -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9VwgtW6pHgIdAuOMRAgbkAKC+G+qpfNkwgLYmMMZ0bY2xZlJlgACgtNJ6 bHmU6UFvuhUNp8R7DYAcgbM= =OEoH -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Mon Aug 12 04:20:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12903 for ; Mon, 12 Aug 2002 04:20:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4114B91257; Mon, 12 Aug 2002 04:21:44 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0CC3491258; Mon, 12 Aug 2002 04:21:43 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 12F0791257 for ; Mon, 12 Aug 2002 04:21:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E9D4D5DFE6; Mon, 12 Aug 2002 04:21:42 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by segue.merit.edu (Postfix) with ESMTP id 62EDB5DDFD for ; Mon, 12 Aug 2002 04:21:42 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA11880; Mon, 12 Aug 2002 01:21:40 -0700 (PDT) Received: from field (field [129.157.142.146]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id g7C8Lcb23875; Mon, 12 Aug 2002 10:21:38 +0200 (MEST) Date: Mon, 12 Aug 2002 10:20:56 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: Joshua Graessley Cc: Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Fri, 9 Aug 2002, Joshua Graessley wrote: > > 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. > > 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. 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 01728655497@d2-message.de Sun Microsystems cell: +49 172 865 5497 From owner-zeroconf@merit.edu Mon Aug 12 06:59:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15706 for ; Mon, 12 Aug 2002 06:59:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D3D829125B; Mon, 12 Aug 2002 06:59:52 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9968E9125C; Mon, 12 Aug 2002 06:59:52 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7D1E69125B for ; Mon, 12 Aug 2002 06:59:51 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 599855DDE4; Mon, 12 Aug 2002 06:59:51 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.2]) by segue.merit.edu (Postfix) with ESMTP id CDF675DDAB for ; Mon, 12 Aug 2002 06:59:49 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7CAxgo23907; Mon, 12 Aug 2002 17:59:42 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7B9Gl106906; Sun, 11 Aug 2002 16:16:47 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Brad Hards Cc: "John C. Welch" , Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-Reply-To: <200208111852.16290.bhards@bigpond.net.au> References: <200208111852.16290.bhards@bigpond.net.au> <4030.1029050908@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 11 Aug 2002 16:16:47 +0700 Message-ID: <6904.1029057407@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Sun, 11 Aug 2002 18:52:16 +1000 From: Brad Hards Message-ID: <200208111852.16290.bhards@bigpond.net.au> | 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 owner-zeroconf@merit.edu Mon Aug 12 07:28:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16763 for ; Mon, 12 Aug 2002 07:28:50 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1734B91207; Mon, 12 Aug 2002 07:29:56 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DD4DE9125C; Mon, 12 Aug 2002 07:29:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C0D2C91207 for ; Mon, 12 Aug 2002 07:29:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AAA9F5DDAB; Mon, 12 Aug 2002 07:29:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mta06bw.bigpond.com (mta06bw.bigpond.com [139.134.6.96]) by segue.merit.edu (Postfix) with ESMTP id 991F05DDFA for ; Mon, 12 Aug 2002 07:29:53 -0400 (EDT) Received: from 192.168.1.244 ([144.135.24.84]) by mta06bw.bigpond.com (Netscape Messaging Server 4.15 mta06bw May 23 2002 23:53:28) with SMTP id H0QALP00.074; Mon, 12 Aug 2002 21:29:49 +1000 Received: from CPE-203-51-35-244.nsw.bigpond.net.au ([203.51.35.244]) by bwmam06.mailsvc.email.bigpond.com(MailRouter V3.0n 47/15354772); 12 Aug 2002 21:29:49 From: Brad Hards To: Robert Elz Subject: Re: [Fwd: Re: Requirements for Service Discovery] Date: Mon, 12 Aug 2002 21:24:32 +1000 User-Agent: KMail/1.4.5 Cc: "John C. Welch" , Zeroconf Working Group Mailing List References: <200208111852.16290.bhards@bigpond.net.au> <4030.1029050908@munnari.OZ.AU> <6904.1029057407@munnari.OZ.AU> In-Reply-To: <6904.1029057407@munnari.OZ.AU> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200208122124.36663.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 11 Aug 2002 19:16, Robert Elz wrote: > | 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. Too little evidence to make that assumption yet. > | 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). 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. - -- http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9V5r0W6pHgIdAuOMRAkEOAKCA1aNLY2rciz8ms9BEaGHF8RPhVQCbBoZV fRm3s1TT/y4FW4rz0l9kI24= =OQX4 -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Mon Aug 12 08:04:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17791 for ; Mon, 12 Aug 2002 08:04:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 69AEC9125E; Mon, 12 Aug 2002 08:05:13 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3B84591260; Mon, 12 Aug 2002 08:05:13 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4DD099125E for ; Mon, 12 Aug 2002 08:05:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 35D365DDAB; Mon, 12 Aug 2002 08:05:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id BA78E5DDE6 for ; Mon, 12 Aug 2002 08:05:11 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g7CB8vh27151; Mon, 12 Aug 2002 04:08:57 -0700 Date: Mon, 12 Aug 2002 04:08:56 -0700 (PDT) From: Bernard Aboba To: Robert Elz Cc: Brad Hards , "John C. Welch" , Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-Reply-To: <6904.1029057407@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > 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. 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 owner-zeroconf@merit.edu Mon Aug 12 09:12:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20454 for ; Mon, 12 Aug 2002 09:12:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6DC4291260; Mon, 12 Aug 2002 09:13:47 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 355CF91261; Mon, 12 Aug 2002 09:13:47 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F2D1791260 for ; Mon, 12 Aug 2002 09:13:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D02BB5DDFF; Mon, 12 Aug 2002 09:13:45 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from piglet.dstc.edu.au (piglet.dstc.edu.au [130.102.176.1]) by segue.merit.edu (Postfix) with ESMTP id CA6E55DDBE for ; Mon, 12 Aug 2002 09:13:44 -0400 (EDT) Received: from ilister.dialup.dstc.edu.au (ilister.dialup.dstc.edu.au [130.102.182.103]) by piglet.dstc.edu.au (8.12.3/8.12.3) with ESMTP id g7CDDYh7003633; Mon, 12 Aug 2002 23:13:36 +1000 (EST) Received: from localhost (ilister@localhost) by ilister.dialup.dstc.edu.au (8.11.1/8.11.1) with ESMTP id g7CDDWA08288; Mon, 12 Aug 2002 23:13:32 +1000 (EST) (envelope-from list-zeroconf@lister.dnsalias.net) Date: Mon, 12 Aug 2002 23:13:32 +1000 (EST) From: Ian Lister X-X-Sender: To: Robert Elz Cc: Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-Reply-To: <6904.1029057407@munnari.OZ.AU> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checked: SPAMASSASSIN: This message probably not SPAM X-Spam-Score: -4.3, Required: 5 X-Virus-Scanned: Message: ok X-Scanned-By: MIMEDefang 2.9 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-zeroconf@merit.edu Precedence: bulk On Sun, 11 Aug 2002, Robert Elz wrote: > From: Brad Hards > | 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 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. > | 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. 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. > | 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? 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). >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. 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. > | 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). You're right, if you choose to manually add your DNS entries those entries will need to be manually removed too. >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. 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] >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). 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. > | 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? 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 owner-zeroconf@merit.edu Mon Aug 12 10:11:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23293 for ; Mon, 12 Aug 2002 10:11:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 01F8491209; Mon, 12 Aug 2002 10:12:06 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1F9391267; Mon, 12 Aug 2002 10:12:05 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B5B4D91209 for ; Mon, 12 Aug 2002 10:12:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9CFCC5DE07; Mon, 12 Aug 2002 10:12:04 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailout03.sul.t-online.com (mailout03.sul.t-online.com [194.25.134.81]) by segue.merit.edu (Postfix) with ESMTP id 00DB75DDE0 for ; Mon, 12 Aug 2002 10:11:59 -0400 (EDT) Received: from fwd09.sul.t-online.de by mailout03.sul.t-online.com with smtp id 17eFuz-0008Bw-0A; Mon, 12 Aug 2002 16:11:37 +0200 Received: from cookie.tjansen.de (520059241914-0001@[217.226.20.109]) by fmrl09.sul.t-online.com with esmtp id 17eFum-1v0KHYC; Mon, 12 Aug 2002 16:11:24 +0200 From: Tim Jansen Reply-To: tim@tjansen.de To: Bernard Aboba Subject: Re: [Fwd: Re: Requirements for Service Discovery] Date: Mon, 12 Aug 2002 16:34:52 +0200 User-Agent: KMail/1.4.5 References: In-Reply-To: Cc: Zeroconf Working Group Mailing List MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200208121634.52707.ml@tjansen.de> X-Sender: 520059241914-0001@t-dialin.net Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Monday 12 August 2002 13:08, Bernard Aboba wrote: > 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 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 owner-zeroconf@merit.edu Mon Aug 12 11:10:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25490 for ; Mon, 12 Aug 2002 11:10:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 65BCE91213; Mon, 12 Aug 2002 11:11:47 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 253EF91253; Mon, 12 Aug 2002 11:11:46 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CA4C691213 for ; Mon, 12 Aug 2002 11:11:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BA0B75DE0D; Mon, 12 Aug 2002 11:11:45 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 87B045DE0C for ; Mon, 12 Aug 2002 11:11:45 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA09916 for ; Mon, 12 Aug 2002 11:11:44 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA25885 for ; Mon, 12 Aug 2002 11:09:16 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id LAA07904 for ; Mon, 12 Aug 2002 11:07:00 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 12 Aug 2002 11:07:01 -0400 Subject: Re: [Fwd: Re: Requirements for Service Discovery] From: "John C. Welch" To: Zeroconf Working Group Mailing List Message-ID: In-Reply-To: <4030.1029050908@munnari.OZ.AU> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/11/2002 03:28, "Robert Elz" wrote: > | There's better info out there on DNS and its applications than SLP. > > Sure, but not about abusing the DNS for doing searching. I have yet to see hard proof that this will 'abuse' DNS. > > 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. 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. > 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? Complaints to the maintainers of the records in that case, in the same way that old server names are removed now. > > 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. 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. > > 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's the same thing that happens with old computer entries in DNS..."I keep getting time out errors, is that server down?" > > 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...) 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. > 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. 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. > > 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. 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. > | 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? 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 > really how to do the SLP part, it is how to integrate that with the > 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 > 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. Why not integrate SLP and IPP into the OS? > > 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). 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. > > | 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. I didn't say it implements, I said it supports DNS. It can be used with DNS. > > | 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??? 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? > | 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. If the SLP designers had thought of implementation and documentation in equal parts with features, we wouldn't need to have this argument. > > 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. 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 owner-zeroconf@merit.edu Mon Aug 12 11:18:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25718 for ; Mon, 12 Aug 2002 11:18:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B78D891253; Mon, 12 Aug 2002 11:19:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8D6FA91248; Mon, 12 Aug 2002 11:19:15 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 99C5791255 for ; Mon, 12 Aug 2002 11:18:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 60DEC5DE14; Mon, 12 Aug 2002 11:18:50 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id E3D865DE10 for ; Mon, 12 Aug 2002 11:18:49 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA15135 for ; Mon, 12 Aug 2002 11:18:49 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA16709 for ; Mon, 12 Aug 2002 11:14:02 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id LAA08411 for ; Mon, 12 Aug 2002 11:08:25 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 12 Aug 2002 11:08:26 -0400 Subject: Re: [Fwd: Re: Requirements for Service Discovery] From: "John C. Welch" To: Zeroconf Working Group Mailing List Message-ID: In-Reply-To: <200208111353.55019.ml@tjansen.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/11/2002 07:53, "Tim Jansen" wrote: >> 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. > > Or maybe you should give CUPS (www.cups.org) a chance, which is a lpr > 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 owner-zeroconf@merit.edu Mon Aug 12 12:00:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27487 for ; Mon, 12 Aug 2002 12:00:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B9A7D91238; Mon, 12 Aug 2002 12:01:05 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 733029124E; Mon, 12 Aug 2002 12:01:05 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3788D91238 for ; Mon, 12 Aug 2002 12:01:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 189A75DF1D; Mon, 12 Aug 2002 12:01:04 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by segue.merit.edu (Postfix) with ESMTP id D971C5DDE4 for ; Mon, 12 Aug 2002 12:01:03 -0400 (EDT) Received: from fwd11.sul.t-online.de by mailout10.sul.t-online.com with smtp id 17eHcr-0005WT-0H; Mon, 12 Aug 2002 18:01:01 +0200 Received: from cookie.tjansen.de (520059241914-0001@[217.226.20.109]) by fmrl11.sul.t-online.com with esmtp id 17eHcm-0wtURMC; Mon, 12 Aug 2002 18:00:56 +0200 From: Tim Jansen Reply-To: tim@tjansen.de To: Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] Date: Mon, 12 Aug 2002 18:24:24 +0200 User-Agent: KMail/1.4.5 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200208121824.24525.ml@tjansen.de> X-Sender: 520059241914-0001@t-dialin.net Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Monday 12 August 2002 17:07, John C. Welch wrote: > 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. 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 owner-zeroconf@merit.edu Mon Aug 12 12:53:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29665 for ; Mon, 12 Aug 2002 12:53:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 263349125B; Mon, 12 Aug 2002 12:54:50 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA1D191229; Mon, 12 Aug 2002 12:54:49 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E6DB99125B for ; Mon, 12 Aug 2002 12:53:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C6F2F5DF41; Mon, 12 Aug 2002 12:53:33 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 64FBA5DE22 for ; Mon, 12 Aug 2002 12:53:33 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA25862 for ; Mon, 12 Aug 2002 12:53:32 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA05187 for ; Mon, 12 Aug 2002 12:53:32 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA28509 for ; Mon, 12 Aug 2002 12:53:32 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Mon, 12 Aug 2002 12:53:33 -0400 Subject: Re: [Fwd: Re: Requirements for Service Discovery] From: "John C. Welch" To: Zeroconf Working Group Mailing List Message-ID: In-Reply-To: <200208121824.24525.ml@tjansen.de> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/12/2002 12:24, "Tim Jansen" wrote: >> 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. > > In other words, DNS-SD should be standardized because there is a good > 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. > > BTW, better than which SLP implementation? The one in MacOSX, Solaris, Novell > 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 owner-zeroconf@merit.edu Mon Aug 12 17:56:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA13028 for ; Mon, 12 Aug 2002 17:56:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A20A791214; Mon, 12 Aug 2002 17:57:08 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67CFF91226; Mon, 12 Aug 2002 17:57:08 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4F5E591214 for ; Mon, 12 Aug 2002 17:57:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3252E5E013; Mon, 12 Aug 2002 17:57:07 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mta03bw.bigpond.com (mta03bw.bigpond.com [139.134.6.86]) by segue.merit.edu (Postfix) with ESMTP id E81445E012 for ; Mon, 12 Aug 2002 17:57:05 -0400 (EDT) Received: from 192.168.1.244 ([144.135.24.84]) by mta03bw.bigpond.com (Netscape Messaging Server 4.15 mta03bw May 23 2002 23:53:28) with SMTP id H0R3N300.FLW; Tue, 13 Aug 2002 07:57:03 +1000 Received: from CPE-203-51-35-244.nsw.bigpond.net.au ([203.51.35.244]) by bwmam06.mailsvc.email.bigpond.com(MailRouter V3.0n 47/16379598); 13 Aug 2002 07:57:03 From: Brad Hards To: Robert Elz Subject: Re: [Fwd: Re: Requirements for Service Discovery] Date: Tue, 13 Aug 2002 07:51:49 +1000 User-Agent: KMail/1.4.5 Cc: "John C. Welch" , Zeroconf Working Group Mailing List References: <200208111852.16290.bhards@bigpond.net.au> <4030.1029050908@munnari.OZ.AU> <6904.1029057407@munnari.OZ.AU> In-Reply-To: <6904.1029057407@munnari.OZ.AU> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200208130751.49192.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sun, 11 Aug 2002 19:16, Robert Elz wrote: > Date: Sun, 11 Aug 2002 18:52:16 +1000 > From: Brad Hards > Message-ID: <200208111852.16290.bhards@bigpond.net.au> > > | 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. 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 - -- http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9WC31W6pHgIdAuOMRAjVtAKDDSN/v66uVNIyeU3iYJH4aACov7gCfZMHP 6gtP72EecDOX+MMChsH7T6c= =hiZt -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Tue Aug 13 07:17:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07229 for ; Tue, 13 Aug 2002 07:17:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7A98B91212; Tue, 13 Aug 2002 07:16:01 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C02A91214; Tue, 13 Aug 2002 07:16:01 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 13A1591212 for ; Tue, 13 Aug 2002 07:16:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E2C9D5DE4C; Tue, 13 Aug 2002 07:15:59 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.6]) by segue.merit.edu (Postfix) with ESMTP id 5F02B5DDCC for ; Tue, 13 Aug 2002 07:15:58 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7DBFio11335; Tue, 13 Aug 2002 18:15:44 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7D8nQW22220; Tue, 13 Aug 2002 15:49:26 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Brad Hards Cc: "John C. Welch" , Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-Reply-To: <200208122124.36663.bhards@bigpond.net.au> References: <200208122124.36663.bhards@bigpond.net.au> <200208111852.16290.bhards@bigpond.net.au> <4030.1029050908@munnari.OZ.AU> <6904.1029057407@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Aug 2002 15:49:26 +0700 Message-ID: <22218.1029228566@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 12 Aug 2002 21:24:32 +1000 From: Brad Hards Message-ID: <200208122124.36663.bhards@bigpond.net.au> | 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 owner-zeroconf@merit.edu Tue Aug 13 07:17:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07244 for ; Tue, 13 Aug 2002 07:17:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D64D291244; Tue, 13 Aug 2002 07:16:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EEC7F91214; Tue, 13 Aug 2002 07:16:06 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8B3B191235 for ; Tue, 13 Aug 2002 07:16:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 749DD5DDCC; Tue, 13 Aug 2002 07:16:04 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.6]) by segue.merit.edu (Postfix) with ESMTP id 119165DE4C for ; Tue, 13 Aug 2002 07:16:03 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7DBFso11402; Tue, 13 Aug 2002 18:15:54 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7D9PSW22265; Tue, 13 Aug 2002 16:25:28 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Ian Lister Cc: Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Aug 2002 16:25:28 +0700 Message-ID: <22263.1029230728@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 12 Aug 2002 23:13:32 +1000 (EST) From: Ian Lister Message-ID: | 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 owner-zeroconf@merit.edu Tue Aug 13 07:17:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07259 for ; Tue, 13 Aug 2002 07:17:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C8B4891235; Tue, 13 Aug 2002 07:16:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77B7991243; Tue, 13 Aug 2002 07:16:06 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2DD7391214 for ; Tue, 13 Aug 2002 07:16:04 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1752B5DE4D; Tue, 13 Aug 2002 07:16:04 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.6]) by segue.merit.edu (Postfix) with ESMTP id B85585DDCC for ; Tue, 13 Aug 2002 07:16:02 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7DBFno11381; Tue, 13 Aug 2002 18:15:49 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7DAkfW22343; Tue, 13 Aug 2002 17:46:41 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "John C. Welch" Cc: Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Aug 2002 17:46:41 +0700 Message-ID: <22341.1029235601@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 12 Aug 2002 11:07:01 -0400 From: "John C. Welch" Message-ID: | 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 owner-zeroconf@merit.edu Tue Aug 13 08:24:22 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA09474 for ; Tue, 13 Aug 2002 08:24:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8EE079126C; Tue, 13 Aug 2002 08:25:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECF179126D; Tue, 13 Aug 2002 08:25:26 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E8FA99126C for ; Tue, 13 Aug 2002 08:25:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D06C75DFEE; Tue, 13 Aug 2002 08:25:25 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 6788E5DFEC for ; Tue, 13 Aug 2002 08:25:25 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id IAA04636 for ; Tue, 13 Aug 2002 08:25:24 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA01442 for ; Tue, 13 Aug 2002 08:25:24 -0400 (EDT) Received: from [10.0.0.2] (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id IAA11218 for ; Tue, 13 Aug 2002 08:25:24 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 13 Aug 2002 08:25:23 -0400 Subject: Re: [Fwd: Re: Requirements for Service Discovery] From: "John C. Welch" To: Zeroconf Working Group Mailing List Message-ID: In-Reply-To: <22218.1029228566@munnari.OZ.AU> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/13/2002 04:49, "Robert Elz" wrote: > | 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. 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 owner-zeroconf@merit.edu Tue Aug 13 10:09:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12808 for ; Tue, 13 Aug 2002 10:09:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2B30591235; Tue, 13 Aug 2002 10:11:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E0FCB91244; Tue, 13 Aug 2002 10:11:06 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0121191235 for ; Tue, 13 Aug 2002 10:11:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D0A545E021; Tue, 13 Aug 2002 10:11:05 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pheriche.sun.com (pheriche.sun.com [192.18.98.34]) by segue.merit.edu (Postfix) with ESMTP id 6E72D5DFF8 for ; Tue, 13 Aug 2002 10:11:05 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by pheriche.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA21146 for ; Tue, 13 Aug 2002 08:11:04 -0600 (MDT) Received: from sun.com (vpn-129-159-0-97.EMEA.Sun.COM [129.159.0.97]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id g7DEB1b28014 for ; Tue, 13 Aug 2002 16:11:02 +0200 (MEST) Message-ID: <3D591324.8222BD18@sun.com> Date: Tue, 13 Aug 2002 16:09:40 +0200 From: Erik Guttman Reply-To: erik.guttman@sun.com Organization: Sun Microsystems, GmbH X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: draft-ietf-zeroconf-ipv4-linklocal-06.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I have submitted a document to the internet draft editor which includes all comments which were agreed to during the working group action. http://www.merit.edu/mail.archives/zeroconf/2002-05/msg00027.html This means that all outstanding issues from the IETF last call on this document have been properly dealt with. The document will now be put in the hands of the IESG, with the request to advance the document to proposed standard. Erik ZEROCONF WG cochair From owner-zeroconf@merit.edu Tue Aug 13 19:07:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25067 for ; Tue, 13 Aug 2002 19:07:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A147191273; Tue, 13 Aug 2002 19:09:04 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6AE8291275; Tue, 13 Aug 2002 19:09:04 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6D0C791273 for ; Tue, 13 Aug 2002 19:09:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 516A85DE6D; Tue, 13 Aug 2002 19:09:03 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mta04ps.bigpond.com (mta04ps.bigpond.com [144.135.25.136]) by segue.merit.edu (Postfix) with ESMTP id 13BA85DD99 for ; Tue, 13 Aug 2002 19:09:02 -0400 (EDT) Received: from 192.168.1.246 ([144.135.25.87]) by mta04ps.bigpond.com (Netscape Messaging Server 4.15 mta04ps May 23 2002 23:53:28) with SMTP id H0T1MY00.6CP; Wed, 14 Aug 2002 09:08:58 +1000 Received: from CPE-203-51-35-244.nsw.bigpond.net.au ([203.51.35.244]) by psmam07.mailsvc.email.bigpond.com(MailRouter V3.0n 119/41840910); 14 Aug 2002 09:08:57 From: Brad Hards To: openslp-devel@lists.sourceforge.net, zeroconf@merit.edu, srvloc-discuss@lists.sourceforge.net Subject: [OT] zeroconf and SLP BoF at Linux-Kongress Date: Wed, 14 Aug 2002 09:03:48 +1000 User-Agent: KMail/1.4.5 Cc: Erik Guttman MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Content-Description: clearsigned data Content-Disposition: inline Message-Id: <200208140903.48429.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have arranged a BoF session for Linux-Kongress 2002 on automatic networking technology implementation. A full description of what is planned is on line at http://www.linux-kongress.org/2002/bofs/index.html#zeroconf The BoF will be held Thursday 5-September-2002, in Cologne (Koln), Germany. The BoF will officially start at 1430, and run until 1600 (local time). However I will try to be at the room from about 1400 to welcome people and have informal discussions. We may have to vacate the room after (depends on other BoFs that are still to be scheduled) and find a pub or coffee house if it runs a bit long. Erik Guttman and I (well, mostly Erik, I guess) will be moderating it. I already have some expressions of interest from CUPS developers who will be at the conference, but if anyone else with an interest in this area can make, it'd be great to see you there. Full conference details are on their web-site (see above). I strongly encourage you to register (even if only for the day), although it is not absolutely mandatory if you only want to attend the BoF. If you don't register, you can't go to the official talks and wont get any coffee in the breaks etc. and no printed proceedings. You can attend the exhibition though. Sorry if this is too off-topic, but a get-together for a few hours can often overcome weeks of emails, so this might be a good chance to progress things. Brad - -- http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE9WZBUW6pHgIdAuOMRAmypAJ9iamNZoKOr/SVrKTTD6YDnodh7PwCgrBcc RZ1Yo1s+UCIImE6YHJkE/fM= =Fa+r -----END PGP SIGNATURE----- From owner-zeroconf@merit.edu Tue Aug 13 21:18:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA28086 for ; Tue, 13 Aug 2002 21:18:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5D4D49127A; Tue, 13 Aug 2002 21:19:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 26FCB9127D; Tue, 13 Aug 2002 21:19:09 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 007A09127A for ; Tue, 13 Aug 2002 21:19:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D35F55DE87; Tue, 13 Aug 2002 21:19:07 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by segue.merit.edu (Postfix) with ESMTP id 87AC65DE3C for ; Tue, 13 Aug 2002 21:19:07 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id SAA04408; Tue, 13 Aug 2002 18:19:03 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id SAA02486; Tue, 13 Aug 2002 18:19:23 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g7E1IsBG014697; Wed, 14 Aug 2002 11:18:56 +1000 (EST) Message-ID: <3D59AFFE.9080006@motorola.com> Date: Wed, 14 Aug 2002 11:18:54 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Elz Cc: Ian Lister , Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] References: <22263.1029230728@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Robert Elz wrote: > | 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. > 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. > I hope there's no buried assumption in here that there's any relationship > 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 aidan.williams@motorola.com 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 owner-zeroconf@merit.edu Wed Aug 14 01:19:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04053 for ; Wed, 14 Aug 2002 01:19:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B39DC9127F; Wed, 14 Aug 2002 01:20:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 815BF91280; Wed, 14 Aug 2002 01:20:07 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 95B929127F for ; Wed, 14 Aug 2002 01:20:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 807475DE6F; Wed, 14 Aug 2002 01:20:06 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.6]) by segue.merit.edu (Postfix) with ESMTP id 04F475DE53 for ; Wed, 14 Aug 2002 01:20:05 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7E5Jp101824; Wed, 14 Aug 2002 12:19:51 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7DGr6W24153; Tue, 13 Aug 2002 23:53:06 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: "John C. Welch" Cc: Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 13 Aug 2002 23:53:06 +0700 Message-ID: <24151.1029257586@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 13 Aug 2002 08:25:23 -0400 From: "John C. Welch" Message-ID: | 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 owner-zeroconf@merit.edu Wed Aug 14 03:59:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA29757 for ; Wed, 14 Aug 2002 03:59:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DEA8A9121B; Wed, 14 Aug 2002 04:00:06 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4B7CF91280; Wed, 14 Aug 2002 04:00:05 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 054319121B for ; Wed, 14 Aug 2002 04:00:02 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 267435DEAB; Wed, 14 Aug 2002 04:00:02 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.6]) by segue.merit.edu (Postfix) with ESMTP id 200D65DDA6 for ; Wed, 14 Aug 2002 04:00:00 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7E7xT106174; Wed, 14 Aug 2002 14:59:29 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7E7wWW29207; Wed, 14 Aug 2002 14:58:32 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Aidan Williams Cc: Ian Lister , Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-Reply-To: <3D59AFFE.9080006@motorola.com> References: <3D59AFFE.9080006@motorola.com> <22263.1029230728@munnari.OZ.AU> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 14 Aug 2002 14:58:32 +0700 Message-ID: <29205.1029311912@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 14 Aug 2002 11:18:54 +1000 From: Aidan Williams Message-ID: <3D59AFFE.9080006@motorola.com> | 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 owner-zeroconf@merit.edu Wed Aug 14 08:16:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06288 for ; Wed, 14 Aug 2002 08:16:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9154F9120E; Wed, 14 Aug 2002 08:17:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A1F991225; Wed, 14 Aug 2002 08:17:22 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5AA0B9120E for ; Wed, 14 Aug 2002 08:17:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 36F3A5DEC8; Wed, 14 Aug 2002 08:17:03 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id C99FE5DEC4 for ; Wed, 14 Aug 2002 08:17:02 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id IAA03464 for ; Wed, 14 Aug 2002 08:17:02 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA01174 for ; Wed, 14 Aug 2002 08:17:01 -0400 (EDT) Received: from [10.0.0.2] (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id IAA24018 for ; Wed, 14 Aug 2002 08:17:01 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 14 Aug 2002 08:17:02 -0400 Subject: Re: [Fwd: Re: Requirements for Service Discovery] From: "John C. Welch" To: Zeroconf Working Group Mailing List Message-ID: In-Reply-To: <24151.1029257586@munnari.OZ.AU> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/13/2002 12:53, "Robert Elz" wrote: > | 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... 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. > > | 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). I read the files on it, and it seems quite defined to me, and I didn't see any issues with client nodes either. > > 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). 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 owner-zeroconf@merit.edu Wed Aug 14 13:40:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18628 for ; Wed, 14 Aug 2002 13:40:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8F2491230; Wed, 14 Aug 2002 13:41:32 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6CB089127A; Wed, 14 Aug 2002 13:41:32 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5235291230 for ; Wed, 14 Aug 2002 13:41:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 300AC5DED7; Wed, 14 Aug 2002 13:41:31 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id CDFBB5DEA9 for ; Wed, 14 Aug 2002 13:41:30 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g7EHfUF18061 for ; Wed, 14 Aug 2002 10:41:30 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 14 Aug 2002 10:41:28 -0700 Received: from adsl-64-171-18-123.dsl.sntc01.pacbell.net (vpn-gh-71.apple.com [17.254.136.70]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g7EHfSV21526 for ; Wed, 14 Aug 2002 10:41:28 -0700 (PDT) Date: Wed, 14 Aug 2002 10:41:19 -0700 Subject: Re: [Fwd: Re: Requirements for Service Discovery] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: Joshua Graessley To: Zeroconf Working Group Mailing List Content-Transfer-Encoding: 7bit In-Reply-To: <29205.1029311912@munnari.OZ.AU> Message-Id: <0A7288A3-AFAD-11D6-B707-000393760260@apple.com> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, August 14, 2002, at 12:58 AM, Robert Elz wrote: > 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. 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. > If that's correct, then is the suggestion that whether merging is done > 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. > 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. 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. > 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. 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. > 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, 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 owner-zeroconf@merit.edu Wed Aug 14 14:36:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20669 for ; Wed, 14 Aug 2002 14:36:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D2A5391282; Wed, 14 Aug 2002 14:37:43 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9823591283; Wed, 14 Aug 2002 14:37:43 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BCDE591282 for ; Wed, 14 Aug 2002 14:37:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9B9D95DED2; Wed, 14 Aug 2002 14:37:42 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 3B9D95DE9E for ; Wed, 14 Aug 2002 14:37:42 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g7EHfva12054; Wed, 14 Aug 2002 10:41:57 -0700 Date: Wed, 14 Aug 2002 10:41:57 -0700 (PDT) From: Bernard Aboba To: Joshua Graessley Cc: Zeroconf Working Group Mailing List Subject: Discussion of mDNS In-Reply-To: <0A7288A3-AFAD-11D6-B707-000393760260@apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk 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 owner-zeroconf@merit.edu Wed Aug 14 21:11:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29517 for ; Wed, 14 Aug 2002 21:11:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9A0FE91211; Wed, 14 Aug 2002 21:12:49 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BBB39128F; Wed, 14 Aug 2002 21:12:49 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4922691211 for ; Wed, 14 Aug 2002 21:12:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 168675DEF8; Wed, 14 Aug 2002 21:12:47 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id B795E5DEB6 for ; Wed, 14 Aug 2002 21:12:46 -0400 (EDT) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id SAA28674; Wed, 14 Aug 2002 18:12:46 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id SAA15087; Wed, 14 Aug 2002 18:10:49 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g7F1CVBG007969; Thu, 15 Aug 2002 11:12:33 +1000 (EST) Message-ID: <3D5AFFFF.5040806@motorola.com> Date: Thu, 15 Aug 2002 11:12:31 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Elz Cc: Ian Lister , Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] References: <3D59AFFE.9080006@motorola.com> <22263.1029230728@munnari.OZ.AU> <29205.1029311912@munnari.OZ.AU> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit 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*"? > 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, [....] Exactly. That is what I was trying to point out in my previous piece of email. > 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 ..." > 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. > 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... > 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! Sydney Network Research Lab aidan.williams@motorola.com 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 owner-zeroconf@merit.edu Wed Aug 14 21:18:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29597 for ; Wed, 14 Aug 2002 21:18:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id EA6989128F; Wed, 14 Aug 2002 21:19:58 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7F4F91290; Wed, 14 Aug 2002 21:19:58 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A1E299128F for ; Wed, 14 Aug 2002 21:19:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 81DAB5DEFB; Wed, 14 Aug 2002 21:19:57 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id 2A9825DEB6 for ; Wed, 14 Aug 2002 21:19:57 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id SAA02408 for ; Wed, 14 Aug 2002 18:19:56 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id SAA09132 for ; Wed, 14 Aug 2002 18:19:54 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g7F1JlBG008549; Thu, 15 Aug 2002 11:19:49 +1000 (EST) Message-ID: <3D5B01B2.6090101@motorola.com> Date: Thu, 15 Aug 2002 11:19:46 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bernard Aboba Cc: Zeroconf Working Group Mailing List Subject: Re: Discussion of mDNS References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > 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. 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! Sydney Network Research Lab aidan.williams@motorola.com 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 owner-zeroconf@merit.edu Wed Aug 14 21:27:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29739 for ; Wed, 14 Aug 2002 21:27:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 70E1491290; Wed, 14 Aug 2002 21:28:48 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3C6D691291; Wed, 14 Aug 2002 21:28:48 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3AD8191290 for ; Wed, 14 Aug 2002 21:28:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 18DD45DEFF; Wed, 14 Aug 2002 21:28:47 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by segue.merit.edu (Postfix) with ESMTP id C1F575DEFE for ; Wed, 14 Aug 2002 21:28:46 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id SAA07638 for ; Wed, 14 Aug 2002 18:28:46 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id SAA22789 for ; Wed, 14 Aug 2002 18:29:08 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g7F1SYBG009250 for ; Thu, 15 Aug 2002 11:28:34 +1000 (EST) Message-ID: <3D5B03C1.90205@motorola.com> Date: Thu, 15 Aug 2002 11:28:33 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Zeroconf Working Group Mailing List Subject: DNS-SD/NIAS TXT record templates Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all, One of the things that bugs me about the DNS-SD/NIAS proposal is the use of TXT records to return the "other stuff" that is needed to use a discovered service. One example given is the lpr print queue name.. Are we really happy to do this? What if the printer has two queues? Do we end up putting lumps of XML, or RDF, or comma seperated thingies into the TXT record? Surely we don't want to go there... To have interoperability the contents and parsing of these TXT records needs to be specified somewhere. This would be pretty much the same as creating an SLP service template. Creating yet another one of these doesn't appear to me as an obvious win. Are there any other options? -- regards aidan ____ :wq! Sydney Network Research Lab aidan.williams@motorola.com 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 owner-zeroconf@merit.edu Thu Aug 15 01:44:05 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04970 for ; Thu, 15 Aug 2002 01:44:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 915C391295; Thu, 15 Aug 2002 01:45:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1842C91296; Thu, 15 Aug 2002 01:45:08 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E1E5E91295 for ; Thu, 15 Aug 2002 01:45:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 660075DF05; Thu, 15 Aug 2002 01:45:06 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.6]) by segue.merit.edu (Postfix) with ESMTP id 7F1185DDB7 for ; Thu, 15 Aug 2002 01:45:04 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7F5io110873; Thu, 15 Aug 2002 12:44:50 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7F5Q0W03907; Thu, 15 Aug 2002 12:26:00 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Joshua Graessley Cc: Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-Reply-To: <0A7288A3-AFAD-11D6-B707-000393760260@apple.com> References: <0A7288A3-AFAD-11D6-B707-000393760260@apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 15 Aug 2002 12:26:00 +0700 Message-ID: <3905.1029389160@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 14 Aug 2002 10:41:19 -0700 From: Joshua Graessley Message-ID: <0A7288A3-AFAD-11D6-B707-000393760260@apple.com> | 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 owner-zeroconf@merit.edu Mon Aug 19 21:30:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19915 for ; Mon, 19 Aug 2002 21:30:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AC1DC9128E; Mon, 19 Aug 2002 21:31:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 68480912DB; Mon, 19 Aug 2002 21:31:34 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 31BC39128E for ; Mon, 19 Aug 2002 21:31:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AD17C5DE3B; Mon, 19 Aug 2002 21:31:32 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 1BF115DDA5 for ; Mon, 19 Aug 2002 21:31:32 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g7K1VVf24409 for ; Mon, 19 Aug 2002 18:31:31 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 19 Aug 2002 18:30:49 -0700 Received: from graejo.apple.com (graejo.apple.com [17.202.40.111]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g7K1VU308068 for ; Mon, 19 Aug 2002 18:31:30 -0700 (PDT) Date: Mon, 19 Aug 2002 18:31:16 -0700 Subject: Re: [Fwd: Re: Requirements for Service Discovery] Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: Joshua Graessley To: Zeroconf Working Group Mailing List Content-Transfer-Encoding: 7bit In-Reply-To: <3905.1029389160@munnari.OZ.AU> Message-Id: <85501BBC-B3DC-11D6-BAC1-000393760260@apple.com> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, August 14, 2002, at 10:26 PM, Robert Elz wrote: > Date: Wed, 14 Aug 2002 10:41:19 -0700 > From: Joshua Graessley > Message-ID: <0A7288A3-AFAD-11D6-B707-000393760260@apple.com> > > | 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. 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. > 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. 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. > 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). 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. > 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. 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. > 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. I don't think there are two protocols, but I do think there are two APIs required. > | 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. 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 owner-zeroconf@merit.edu Mon Aug 19 21:41:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20334 for ; Mon, 19 Aug 2002 21:41:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9E8B391291; Mon, 19 Aug 2002 21:42:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 354A8912DB; Mon, 19 Aug 2002 21:42:27 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F2D8D91291 for ; Mon, 19 Aug 2002 21:42:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D327B5DE5A; Mon, 19 Aug 2002 21:42:25 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id BDCAD5DDA5 for ; Mon, 19 Aug 2002 21:42:20 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g7K1g8U12713 for ; Mon, 19 Aug 2002 18:42:08 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 19 Aug 2002 18:41:26 -0700 Received: from [17.202.45.251] (il0204a-dhcp123.apple.com [17.202.45.251]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id g7K1g7b24231 for ; Mon, 19 Aug 2002 18:42:07 -0700 (PDT) Message-Id: <200208200142.g7K1g7b24231@scv1.apple.com> Subject: RE: Discovering Named Instances of Abstract Services using DNS Date: Mon, 19 Aug 2002 18:42:08 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Erik Nordmark asked: >So what is a "service name"? Is it "printer" or something more >specific like "lpr" or "ipp" (which actually name the the protocol >used to communicate to the service?) My philosophy here is very deliberately a behavioural model of networking -- I believe the only sensible question in this context is not, "What are you?", but, "What protocol do you speak?" If you walk like a duck and quack like a duck, then I'll treat you as a duck. If I'm writing an IPP client, then I want to find other things on the network that speak IPP. It doesn't matter if they archive the documents onto CDR instead of printing them on paper -- if they speak IPP, then my IPP client will talk to them. Conversely, finding "a thing that prints on paper" (whatever that means, in a precise sense) and then asking what protocols it speaks doesn't help me, if the answer is that it speaks only PSPAPATUDPIP (Postscript-over-Printer-Access-protocol-over-AppleTalk-tunneled-over-UDP-o ver-IP). That's no use at all to a client that implements only IPP. What an IPP client wants to know is, "Who can I talk to?" >A different shade (in the other direction) is to use > _lpr._tcp. >and > _ipp._tcp. >and use lpr/ipp specific ways to discover the capabilities (but not the >protocol used to send the print jobs since that's implicit in the tag). Right, but you mean, "_printer._tcp." The IANA protocol name for LPR is "printer", not "lpr". (Search for "515" in .) I made this same mistake in my draft a year ago, and I need to fix it. A client that implements LPR looks for "_printer._tcp." A client that implements IPP looks for "_ipp._tcp." A client that implements both looks for both. >If there services which support many different protocols this seems >like more work than the above to shades of grey. If there are devices that support many different protocols, then that itself is the problem, not the discovery step of the process. If there are n printing protocols, then Apple (and any other client vendor) has to support n different ways of printing, each with their own features, bugs, and deficiencies. Printer vendors each have to support n different ways of printing. That is the big burden. I'd like to see a world where there's one and only one accepted way of printing over IP, and that way of printing works really well. In the meantime, there are currently a small number of different ways of printing, and we do have to support that, but lets recognise that as a problem to be reduced over time, not a desirable thing to be proliferated. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Mon Aug 19 21:50:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20439 for ; Mon, 19 Aug 2002 21:50:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 486019128E; Mon, 19 Aug 2002 21:51:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09B70912DB; Mon, 19 Aug 2002 21:51:29 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1424F9128E for ; Mon, 19 Aug 2002 21:51:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E90EB5DE8F; Mon, 19 Aug 2002 21:51:28 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 5840B5DDA5 for ; Mon, 19 Aug 2002 21:51:28 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g7K1pRf27538 for ; Mon, 19 Aug 2002 18:51:27 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 19 Aug 2002 18:50:46 -0700 Received: from [17.202.45.251] (il0204a-dhcp123.apple.com [17.202.45.251]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id g7K1pRb27717 for ; Mon, 19 Aug 2002 18:51:27 -0700 (PDT) Message-Id: <200208200151.g7K1pRb27717@scv1.apple.com> Subject: Re: [Fwd: Re: Requirements for Service Discovery] Date: Mon, 19 Aug 2002 18:51:28 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Zeroconf Working Group Mailing List" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Robert Elz wrote: >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? A question for Robert: DNS UPDATE currently specifies no time-out, refresh period, or other garbage collection mechanism to purge old records created by long-dead clients. Do you see this as: (a) a wonderful feature of the DNS UPDATE mechanism, to be cherished, or (b) an oversight in the DNS UPDATE mechanism, which should be fixed I'm not looking for a protracted digression here; I'm not looking for qualifications and caveats, just a clear unambiguous "yes/no" statement of your opinion, if possible. Thanks. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Mon Aug 19 22:00:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20564 for ; Mon, 19 Aug 2002 22:00:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A7D93912E0; Mon, 19 Aug 2002 22:01:01 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 752D5912E1; Mon, 19 Aug 2002 22:01:01 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7FCD0912E0 for ; Mon, 19 Aug 2002 22:01:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6854A5DE51; Mon, 19 Aug 2002 22:01:00 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 5262F5DDA5 for ; Mon, 19 Aug 2002 22:00:55 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g7K20pf28603 for ; Mon, 19 Aug 2002 19:00:51 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Mon, 19 Aug 2002 19:00:09 -0700 Received: from [17.202.45.251] (il0204a-dhcp123.apple.com [17.202.45.251]) by scv1.apple.com (8.11.3/8.11.3) with SMTP id g7K20ob01337 for ; Mon, 19 Aug 2002 19:00:50 -0700 (PDT) Message-Id: <200208200200.g7K20ob01337@scv1.apple.com> Subject: Re: Discovering Named Instances of Abstract Services using DNS Date: Mon, 19 Aug 2002 19:00:51 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk Two weeks ago I asked: > >How many people have read the draft and think it is a good idea? >How many people have read the draft and think it is a bad idea? Here is a summary of the responses I received: Brad Hards: "I think it is good" is closer to my opinion. Alex Karahalios: I've read NIAS and I think it is good. Joshua Graessley: I've read NIAS and I think it is good. Mark Thompson: I've read NIAS and I think it is good, - but flawed. John C. Welch: I've read NIAS and I think it is good. Varuni Witana: I've read NIAS and I think it is bad. Dan Nicolae: I read it (fast) and I think the idea of using DNS for discovery in ad-hoc networks is good. Robert Elz: If you seriously expect the WG to consider this, you really should take the effort to keep it current (Robert didn't like it.) This is a small sample (though not too different to the response you get when asking about any Internet Draft), but the results appear to be: Generally Positive: 6 Generally Negative: 2 So, there appears to be some limited interest in this. There are two ways to proceed now: 1. The IETF community would like to take charge of this work and help evolve it in a sensible direction. 2. The IETF community has no interest in this, and Apple should just publish it as an Informational RFC. Thoughts? Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Aug 20 09:28:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13741 for ; Tue, 20 Aug 2002 09:28:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 92E62912E1; Tue, 20 Aug 2002 09:17:50 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44452912E5; Tue, 20 Aug 2002 09:17:47 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3C10C912E1 for ; Tue, 20 Aug 2002 09:17:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 29ED25DEEC; Tue, 20 Aug 2002 09:17:45 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.6]) by segue.merit.edu (Postfix) with ESMTP id 1FAEC5DDA4 for ; Tue, 20 Aug 2002 09:17:42 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7KDG7128406; Tue, 20 Aug 2002 20:16:08 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7KDFnW29347; Tue, 20 Aug 2002 20:15:49 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Stuart Cheshire Cc: "Zeroconf Working Group Mailing List" Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-Reply-To: <200208200151.g7K1pRb27717@scv1.apple.com> References: <200208200151.g7K1pRb27717@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 20 Aug 2002 20:15:49 +0700 Message-ID: <29345.1029849349@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Mon, 19 Aug 2002 18:51:28 -0700 From: Stuart Cheshire Message-ID: <200208200151.g7K1pRb27717@scv1.apple.com> | DNS UPDATE currently specifies no time-out, refresh period, or other | garbage collection mechanism to purge old records created by long-dead | clients. Correct. | Do you see this as: | (a) a wonderful feature of the DNS UPDATE mechanism, to be cherished, or | (b) an oversight in the DNS UPDATE mechanism, which should be fixed Neither of those. (b) is easy to handle - this certainly wasn't an oversight, when dynamic updates were being designed there was a lot of work spent on attempting to achieve exactly what you're suggesting should be done, records that get inserted for a time, and if they're not refreshed, vanish (or something else more or less equivalent to that) So "an oversight" it certainly isn't. (a) it isn't either - no-one believes that it is great that there's no way to add something to the DNS for a limited period, and then have it go away all by itself. | I'm not looking for a protracted digression here; I'm not looking for | qualifications and caveats, just a clear unambiguous "yes/no" statement | of your opinion, if possible. The problem is that it is essentially impossible to make work. The principle problem is not how one would manage to tell the primary server that the data was supposed to vanish, but how that server would pass along that information to secondary servers. AXFR (sometimes now IXFR, but that makes no difference) is the most common way that the servers for a zone communicate, and AXFR transfers the RRs and only the RRs, no additional data. There's nowhere in there where "this record should vanish after a day" can be shoehorned in. One might think that the primary server could do all the work, make the data vanish, increment the serial number, then notify the secondary servers of the zone change - at which point the secondary servers would refresh their copies of the zone, and the data would be gone. But even this has two problems - first, up to the point of the notify, while the primary server could have been answering queries with progressively shorter TTLs so that caches won't be keeping the data beyond its validity date - but secondary servers know nothing of this, and would be answering queries with the initial TTL of the RR up to the instant it is deleted. Whether this is a serious problem or not depends upon why you're wanting the record to be deleted - if it is just cleaning up old cruft, then it doesn't matter at all - but those aren't all of the reasons that people wanted this ability. More seriously, something has to deal with the possibility that the primary server might no longer be functioning at the time the deletion is supposed to happen - another server might have replaced it. In any case, all of this means that any kind of automated RR deletion doesn't work, and really can't be made to work reliably in the DNS as we know it (some different protocol set might have different outcomes, but aren't relevant). Because of that, if records are to be deleted, there really needs to be something else that is going to take on the responsibility of making sure that it actually happens, because even if the DNS is attempting to do it, it isn't always going to be successful. Then, once you accept the need for such an agent, any argument for having the DNS do any of it simply vanishes - if the agent is able to clean up in the hard cases, it can do so in the easy ones as well. This has been a (very brief) summary of my recollection of the discussions that took place in the DNSIND working group (the predecessor to dnsext) when dynamic updates was being designed. I think I have it more or less complete - but do feel free to go back and check ancient namedroppers archives (sometime mid 90's this would have been I think, look a year or two before the date of the dynamic updates doc - maybe a bit more, that doc was done and sat for ages waiting for a security mechanism to appear to make it safe enough for anyone to use). Namedroppers has been the list for DNS development since before I was involved (that is, a very long time now). Just about everything should be in its archives... kre From owner-zeroconf@merit.edu Tue Aug 20 21:48:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA03298 for ; Tue, 20 Aug 2002 21:48:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D07249124B; Tue, 20 Aug 2002 21:49:42 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9C0A591282; Tue, 20 Aug 2002 21:49:42 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id B28AD9124B for ; Tue, 20 Aug 2002 21:49:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A02C55DDCF; Tue, 20 Aug 2002 21:49:41 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 6A2EA5DDB0 for ; Tue, 20 Aug 2002 21:49:36 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g7L1nVL07716 for ; Tue, 20 Aug 2002 18:49:31 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Tue, 20 Aug 2002 18:48:50 -0700 Received: from [17.202.45.251] (il0204a-dhcp123.apple.com [17.202.45.251]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id g7L1nV312908 for ; Tue, 20 Aug 2002 18:49:31 -0700 (PDT) Message-Id: <200208210149.g7L1nV312908@scv3.apple.com> Subject: Re: [Fwd: Re: Requirements for Service Discovery] Date: Tue, 20 Aug 2002 18:49:34 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Zeroconf Working Group Mailing List" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk A short question, and a long answer from Robert Elz, which I will refrain from repeating in its entirety here. I think this is the crux of the matter: >The principle problem is not how one would manage to tell the >primary server that the data was supposed to vanish, but how >that server would pass along that information to secondary servers. If I understand this correctly, Robert is saying that he believes: (c) a garbage collection mechanism to purge old records would be nice, but it is simply not possible. I would submit that the definition of "simply not possible" is merely a matter of where you choose to set your horizons. If the usefulness of DNS UPDATE is fundamentally undermined by the lack of a garbage collection mechanism to purge old records, then we (the IETF community) should take on the challenge to solve that problem, not simply declare it impossible and give up. Just as DNS migrated from AXFR to IXFR over time, I see no reason it couldn't migrate from IXFR to some new thing ("IXFR2"?) which does provide the necessary garbage collection support to make DNS UPDATE a useful technology. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Tue Aug 20 22:33:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA04163 for ; Tue, 20 Aug 2002 22:33:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 87BA091297; Tue, 20 Aug 2002 22:34:49 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 573F791298; Tue, 20 Aug 2002 22:34:49 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 82BB291297 for ; Tue, 20 Aug 2002 22:34:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EF07F5DE59; Tue, 20 Aug 2002 22:34:47 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 906DB5DDB0 for ; Tue, 20 Aug 2002 22:34:47 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g7L1cNv28707; Tue, 20 Aug 2002 18:38:23 -0700 Date: Tue, 20 Aug 2002 18:38:23 -0700 (PDT) From: Bernard Aboba To: Stuart Cheshire Cc: Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-Reply-To: <200208210149.g7L1nV312908@scv3.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > If the usefulness of DNS UPDATE is fundamentally undermined by the lack > of a garbage collection mechanism to purge old records, then we (the IETF > community) should take on the challenge to solve that problem See: http://www.ietf.org/internet-drafts/draft-janardhan-dnsext-aging-01.txt From owner-zeroconf@merit.edu Wed Aug 21 03:22:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02916 for ; Wed, 21 Aug 2002 03:22:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3418891297; Wed, 21 Aug 2002 03:24:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 018E19129D; Wed, 21 Aug 2002 03:24:08 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EBE0F91297 for ; Wed, 21 Aug 2002 03:24:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CCED75DE93; Wed, 21 Aug 2002 03:24:07 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.6]) by segue.merit.edu (Postfix) with ESMTP id 3C60F5DDC3 for ; Wed, 21 Aug 2002 03:24:06 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7L7Npl03564; Wed, 21 Aug 2002 14:23:52 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7L6atW07808; Wed, 21 Aug 2002 13:36:55 +0700 (ICT) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Stuart Cheshire Cc: "Zeroconf Working Group Mailing List" Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-Reply-To: <200208210149.g7L1nV312908@scv3.apple.com> References: <200208210149.g7L1nV312908@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 21 Aug 2002 13:36:55 +0700 Message-ID: <7806.1029911815@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Tue, 20 Aug 2002 18:49:34 -0700 From: Stuart Cheshire Message-ID: <200208210149.g7L1nV312908@scv3.apple.com> | I would submit that the definition of "simply not possible" is merely a | matter of where you choose to set your horizons. That's true, but ... | If the usefulness of DNS UPDATE is fundamentally undermined by the lack | of a garbage collection mechanism to purge old records, this isn't. DNS UPDATE works just fine as it is, there are applications that manage it just fine, and the lack of any internal mechanism in the DNS to make old stuff go away doesn't bother those in the least. However, of course, a false premise doesn't imply a false conslusion, so: | then we (the IETF community) should take on the challenge to solve that | problem, not simply declare it impossible and give up. isn't necessarily false - just nothing above on its own would drive us to this state. What you really mean is that you have a use for DNS update, which doesn't work well without a cleanup mechanism. Of course, here, we all know that I don't think much of that proposed use... I have no doubt but that this could be made to work, with sufficient effort. But do remember that when dnsind was looking at this, a lot of effort was expended in exactly that direction, with precisely zero results. Also, note that there is a considerable swell of background feeling that it is getting close to the time to simply scrap the DNS, and invent DNS2. Any proposal that starts to make major changes to how the DNS functions is going to (I suspect) get pushback both from the people who simply don't see the need, and from the people who agree to the need, but who don't want to bother with yet another hack to the current DNS. But whatever your feeling on this is, this WG is most certainly not the place to be discussing this kind of DNS change - take to to the dnsext WG (namedroppers@ops.ietf.org) where you will get a whole stack of DNS people to comment. kre ps: I do know about the draft that Bernard mentioned, as best I can tell, it is going precisely nowhere. From owner-zeroconf@merit.edu Wed Aug 21 10:11:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10729 for ; Wed, 21 Aug 2002 10:11:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CFD569121F; Wed, 21 Aug 2002 10:12:28 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 958C4912A4; Wed, 21 Aug 2002 10:12:28 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E8819121F for ; Wed, 21 Aug 2002 10:12:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0EAEE5DF01; Wed, 21 Aug 2002 10:12:26 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id A07635DDDD for ; Wed, 21 Aug 2002 10:12:25 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA15726 for ; Wed, 21 Aug 2002 10:12:25 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA00294 for ; Wed, 21 Aug 2002 10:12:24 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA07919 for ; Wed, 21 Aug 2002 10:12:24 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 21 Aug 2002 10:11:31 -0400 Subject: Re: [Fwd: Re: Requirements for Service Discovery] From: "John C. Welch" To: Zeroconf Working Group Mailing List Message-ID: In-Reply-To: <7806.1029911815@munnari.OZ.AU> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/21/2002 02:36, "Robert Elz" wrote: > | If the usefulness of DNS UPDATE is fundamentally undermined by the lack > | of a garbage collection mechanism to purge old records, > > this isn't. > > DNS UPDATE works just fine as it is, there are applications that manage > it just fine, and the lack of any internal mechanism in the DNS to make > old stuff go away doesn't bother those in the least. Well, it doesn't do much for the humans who have to clean up after this. > > However, of course, a false premise doesn't imply a false conslusion, so: > > | then we (the IETF community) should take on the challenge to solve that > | problem, not simply declare it impossible and give up. > > isn't necessarily false - just nothing above on its own would drive us to > this state. > > What you really mean is that you have a use for DNS update, which doesn't > work well without a cleanup mechanism. Of course, here, we all know that > I don't think much of that proposed use... > > I have no doubt but that this could be made to work, with sufficient effort. > But do remember that when dnsind was looking at this, a lot of effort was > expended in exactly that direction, with precisely zero results. Well, then maybe it's time to look at it again. The Internet is a rather dynamic place, and what wasn't a good idea last year doesn't guarantee that it's a bad idea this year > > Also, note that there is a considerable swell of background feeling that > it is getting close to the time to simply scrap the DNS, and invent DNS2. > Any proposal that starts to make major changes to how the DNS functions > is going to (I suspect) get pushback both from the people who simply > don't see the need, and from the people who agree to the need, but who > don't want to bother with yet another hack to the current DNS. Oh great...just what we need, moratorium on improving DNS because "The Exciting New World of DNS2 Will Make It All Better" Pardon my cynicism, but we need both. IPv6 hasn't yet replaced IPv4, but it would have been foolish to not do anything to improve IPv4 while waiting for IPv6. Get started on DNS2, but let's not sit on our hands in the meantime. > > But whatever your feeling on this is, this WG is most certainly not the > place to be discussing this kind of DNS change - take to to the dnsext WG > (namedroppers@ops.ietf.org) where you will get a whole stack of DNS > people to comment. Well, actually, since DNS is central to Zeroconf, yes it is, if you think about it. Besides, it's always better to propose a change that fixes a real world problem, as opposed to a theoretical one. john -- John C. Welch IT Manager MIT Police (617) 253 - 3093 work (508) 579 - 7380 cell (617) 253 - 8822 fax From owner-zeroconf@merit.edu Wed Aug 21 20:02:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00110 for ; Wed, 21 Aug 2002 20:02:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D5EFE913A9; Wed, 21 Aug 2002 20:02:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA6989135E; Wed, 21 Aug 2002 20:02:54 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 50E37913A9 for ; Wed, 21 Aug 2002 20:01:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 373215DEA6; Wed, 21 Aug 2002 20:01:17 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id BF40B5DEA3 for ; Wed, 21 Aug 2002 20:01:16 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id RAA03918; Wed, 21 Aug 2002 17:01:15 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by mothost.mot.com (MOT-pobox 2.0) with ESMTP id RAA03039; Wed, 21 Aug 2002 17:01:38 -0700 (MST)] Received: from motorola.com (aidanw.arc.corp.mot.com [10.238.80.63]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g7M0157C022618; Thu, 22 Aug 2002 10:01:07 +1000 (EST) Message-ID: <3D6429C1.9050509@motorola.com> Date: Thu, 22 Aug 2002 10:01:05 +1000 From: Aidan Williams User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.0) Gecko/20020530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "John C. Welch" Cc: Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit John C. Welch wrote: [ comments about not being able to "fix" the DNS ] > Well, actually, since DNS is central to Zeroconf, > yes it is, if you think about it. As an alternative, perhaps we should be working on making "DNS" less central to zeroconf. It is certainly a possibility, if you think about it. -- regards aidan ____ :wq! Sydney Network Research Lab aidan.williams@motorola.com 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 owner-zeroconf@merit.edu Thu Aug 22 08:52:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23982 for ; Thu, 22 Aug 2002 08:52:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5000F9134D; Thu, 22 Aug 2002 08:49:48 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C24E09134F; Thu, 22 Aug 2002 08:49:44 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 966F99134D for ; Thu, 22 Aug 2002 08:48:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7AACC5DE50; Thu, 22 Aug 2002 08:48:03 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.6]) by segue.merit.edu (Postfix) with ESMTP id DECE75DD98 for ; Thu, 22 Aug 2002 08:48:01 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7MClol02290; Thu, 22 Aug 2002 19:47:50 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7MCatW13400; Thu, 22 Aug 2002 19:36:55 +0700 (ICT) From: Robert Elz To: "John C. Welch" Cc: Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 22 Aug 2002 19:36:55 +0700 Message-ID: <13398.1030019815@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Wed, 21 Aug 2002 10:11:31 -0400 From: "John C. Welch" Message-ID: | Well, it doesn't do much for the humans who have to clean up after this. DNS Update is mostly used by DHCP servers, which manage the cleaning up pretty well by themselves... | Well, then maybe it's time to look at it again. The Internet is a rather | dynamic place, and what wasn't a good idea last year doesn't guarantee that | it's a bad idea this year Nothing was said about "bad ideas", what was said was that a suitable method to make it work hadn't been found. By all means, go ahead and propose a solution to the problem. If it works, lots of people will be very happy. Just don't expect people who already spend a lot of time on this to do it for you - nor for them to be very sympathetic to ideas that won't work (propose something unworkable and expect a very brusque response). | Pardon my cynicism, but we need both. IPv6 hasn't yet replaced IPv4, but it | would have been foolish to not do anything to improve IPv4 while waiting for | IPv6. Get started on DNS2, but let's not sit on our hands in the meantime. That's fine - and incremental improvements are continually being made to the DNS (as they are to IPv4). But no-one rational would suggest making a sweeping change that would involve upgrading everyone's IPv4 stack at this stage of the game. Improvements to the DNS will happen, and do happen - major changes are starting to look less likely (but who can tell). kre From owner-zeroconf@merit.edu Sat Aug 24 11:48:35 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13022 for ; Sat, 24 Aug 2002 11:48:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 308E191234; Sat, 24 Aug 2002 11:46:07 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 488FF91235; Sat, 24 Aug 2002 11:46:05 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 144B991234 for ; Sat, 24 Aug 2002 11:45:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E04F55DF39; Sat, 24 Aug 2002 11:45:36 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from imo-r05.mx.aol.com (imo-r05.mx.aol.com [152.163.225.101]) by segue.merit.edu (Postfix) with ESMTP id 776AC5DDA2 for ; Sat, 24 Aug 2002 11:45:36 -0400 (EDT) Received: from Ndenete@aol.com by imo-r05.mx.aol.com (mail_out_v33.5.) id m.60.24e80063 (30950) for ; Sat, 24 Aug 2002 11:45:31 -0400 (EDT) From: Ndenete@aol.com Message-ID: <60.24e80063.2a99041b@aol.com> Date: Sat, 24 Aug 2002 11:45:31 EDT Subject: Jaguar and mDNS Responder Source To: zeroconf@merit.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_60.24e80063.2a99041b_boundary" X-Mailer: AOL For Mac OS X sub 16 Sender: owner-zeroconf@merit.edu Precedence: bulk --part1_60.24e80063.2a99041b_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Greetings, Now that OS X version 10.2 has shipped, does anyone know the link to get the source to their mDNS responder? Noel Enete --part1_60.24e80063.2a99041b_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit Greetings,

Now that OS X version 10.2 has shipped, does anyone know the link to get the source to their mDNS responder?

Noel Enete
 --part1_60.24e80063.2a99041b_boundary-- From owner-zeroconf@merit.edu Tue Aug 27 16:32:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11483 for ; Tue, 27 Aug 2002 16:32:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D96579129A; Tue, 27 Aug 2002 16:33:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 99F2B9121E; Tue, 27 Aug 2002 16:33:18 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D48699129B for ; Tue, 27 Aug 2002 16:33:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B66835DDF7; Tue, 27 Aug 2002 16:33:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 4C4A55DD94 for ; Tue, 27 Aug 2002 16:33:08 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7RKX4015089; Tue, 27 Aug 2002 16:33:05 -0400 (EDT) Message-Id: <200208272033.g7RKX4015089@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: zeroconf@merit.edu Subject: Re: Discovering Named Instances of Abstract Services using DNS In-reply-to: (Your message of "Mon, 19 Aug 2002 19:00:51 PDT.") <200208200200.g7K20ob01337@scv1.apple.com> Date: Tue, 27 Aug 2002 16:33:04 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > So, there appears to be some limited interest in this. > There are two ways to proceed now: > > 1. The IETF community would like to take charge of this work > and help evolve it in a sensible direction. > > 2. The IETF community has no interest in this, > and Apple should just publish it as an Informational RFC. > 3. A much wider community needs to carefully examine this before any decision about IETF investment or RFC publication is made. Keith From owner-zeroconf@merit.edu Tue Aug 27 16:33:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11505 for ; Tue, 27 Aug 2002 16:33:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 116619129F; Tue, 27 Aug 2002 16:33:49 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CD4BB912A1; Tue, 27 Aug 2002 16:33:48 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DFA9B9129F for ; Tue, 27 Aug 2002 16:33:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CE7B15DDF7; Tue, 27 Aug 2002 16:33:43 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 641695DD94 for ; Tue, 27 Aug 2002 16:33:43 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7RKTQ015043; Tue, 27 Aug 2002 16:29:26 -0400 (EDT) Message-Id: <200208272029.g7RKTQ015043@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Aidan Williams Cc: Robert Elz , Ian Lister , Zeroconf Working Group Mailing List Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-reply-to: (Your message of "Thu, 15 Aug 2002 11:12:31 +1000.") <3D5AFFFF.5040806@motorola.com> Date: Tue, 27 Aug 2002 16:29:26 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > 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'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 From owner-zeroconf@merit.edu Tue Aug 27 16:35:13 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11570 for ; Tue, 27 Aug 2002 16:35:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 64F249120D; Tue, 27 Aug 2002 16:36:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 44D919120F; Tue, 27 Aug 2002 16:36:26 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id EC0CF9120D for ; Tue, 27 Aug 2002 16:34:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D07AB5DDF7; Tue, 27 Aug 2002 16:34:47 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 685955DD94 for ; Tue, 27 Aug 2002 16:34:47 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7RKYi015113; Tue, 27 Aug 2002 16:34:44 -0400 (EDT) Message-Id: <200208272034.g7RKYi015113@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Stuart Cheshire Cc: "Zeroconf Working Group Mailing List" Subject: Re: [Fwd: Re: Requirements for Service Discovery] In-reply-to: (Your message of "Tue, 20 Aug 2002 18:49:34 PDT.") <200208210149.g7L1nV312908@scv3.apple.com> Date: Tue, 27 Aug 2002 16:34:44 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > >The principle problem is not how one would manage to tell the > >primary server that the data was supposed to vanish, but how > >that server would pass along that information to secondary servers. > > If I understand this correctly, Robert is saying that he believes: > > (c) a garbage collection mechanism to purge old records would be nice, > but it is simply not possible. (c') DNS wasn't designed to do this, and it's very difficult to retro-fit it into DNS in a way that allows incremental upgrading of DNS servers. Keith From owner-zeroconf@merit.edu Tue Aug 27 16:37:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11653 for ; Tue, 27 Aug 2002 16:37:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0AE029120F; Tue, 27 Aug 2002 16:39:00 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0A839121E; Tue, 27 Aug 2002 16:38:59 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D09B69120F for ; Tue, 27 Aug 2002 16:38:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9CB385DE19; Tue, 27 Aug 2002 16:38:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-relay.mobilestar.com (unknown [208.54.109.197]) by segue.merit.edu (Postfix) with ESMTP id 0D3785DD94 for ; Tue, 27 Aug 2002 16:38:58 -0400 (EDT) Received: from james-mcmurrys-Computer.local. ([208.54.20.2]) by mail-relay.mobilestar.com (8.11.0/8.11.0) with ESMTP id g7RJQc122876; Tue, 27 Aug 2002 14:26:39 -0500 Date: Tue, 27 Aug 2002 13:38:52 -0700 Subject: Re: Discovering Named Instances of Abstract Services using DNS Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: Stuart Cheshire , zeroconf@merit.edu To: Keith Moore From: james mcmurry In-Reply-To: <200208272033.g7RKX4015089@astro.cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit How wide of a "community" should look into this? Should there be a group of people elected to review this? (other than the people on this list as a whole) Jim On Tuesday, August 27, 2002, at 01:33 PM, Keith Moore wrote: >> So, there appears to be some limited interest in this. >> There are two ways to proceed now: >> >> 1. The IETF community would like to take charge of this work >> and help evolve it in a sensible direction. >> >> 2. The IETF community has no interest in this, >> and Apple should just publish it as an Informational RFC. >> > > 3. A much wider community needs to carefully examine this before any > decision about IETF investment or RFC publication is made. > > Keith > From owner-zeroconf@merit.edu Tue Aug 27 16:40:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11764 for ; Tue, 27 Aug 2002 16:40:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 778869121E; Tue, 27 Aug 2002 16:41:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D8B791299; Tue, 27 Aug 2002 16:41:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4144B9121E for ; Tue, 27 Aug 2002 16:41:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 24E605DDBE; Tue, 27 Aug 2002 16:41:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id AE09F5DD94 for ; Tue, 27 Aug 2002 16:41:53 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7RKfh015252; Tue, 27 Aug 2002 16:41:43 -0400 (EDT) Message-Id: <200208272041.g7RKfh015252@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: james mcmurry Cc: Keith Moore , Stuart Cheshire , zeroconf@merit.edu Subject: Re: Discovering Named Instances of Abstract Services using DNS In-reply-to: (Your message of "Tue, 27 Aug 2002 13:38:52 PDT.") Date: Tue, 27 Aug 2002 16:41:43 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > How wide of a "community" should look into this? well, when you start talking about changing DNS, you're threatening to break every host and every application on the Internet. it's certainly not something within zeroconf's purview, and IMHO even the *dns* groups should solicit wide review from apps area groups before tampering with such things. fortunately, the *dns* groups have traditionally taken their responsibilities to avoid harm fairly seriously. I can't say the same for zeroconf. Keith From owner-zeroconf@merit.edu Tue Aug 27 17:54:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14073 for ; Tue, 27 Aug 2002 17:54:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 54A6291238; Tue, 27 Aug 2002 17:55:33 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 207C591248; Tue, 27 Aug 2002 17:55:33 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1647C91238 for ; Tue, 27 Aug 2002 17:55:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DFD5E5DDF7; Tue, 27 Aug 2002 17:55:31 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 7B0EC5DD94 for ; Tue, 27 Aug 2002 17:55:31 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id RAA19309 for ; Tue, 27 Aug 2002 17:55:30 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id RAA04634 for ; Tue, 27 Aug 2002 17:55:30 -0400 (EDT) Received: from [18.174.0.40] (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id RAA00607 for ; Tue, 27 Aug 2002 17:55:29 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Tue, 27 Aug 2002 17:55:26 -0400 Subject: Re: Discovering Named Instances of Abstract Services using DNS From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200208272041.g7RKfh015252@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/27/2002 16:41, "Keith Moore" wrote: > fortunately, the *dns* groups have traditionally taken their > responsibilities to avoid harm fairly seriously. I can't say the > same for zeroconf. Um...it's real irresponsible to make the zeroconf group out to be a bunch of yahoos bent on destroying DNS. From everything I've read in the mDNS and other papers, they've bent over backwards to avoid causing harm to DNS. Are they updating it? Yes. Causing harm? Well, that's what things like the WG and this mailing list are trying to deal with. Luckily, as of August 24th, you're shortly going to have what is, without a doubt, the best, and in the end, the only way to see if something really works: Real - world testing on a large scale. I'm in the middle of setting up a domain that will, among other things start implementing Zeroconf/Rendezvous along with conventional DNS, so I'll be able to see in a reasonably real - world setting what works and what doesn't. John -- John C. Welch IT Manager MIT Police (617) 253 - 3093 work (508) 579 - 7380 cell (617) 253 - 8822 fax From owner-zeroconf@merit.edu Tue Aug 27 22:41:47 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21003 for ; Tue, 27 Aug 2002 22:41:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 403869129F; Tue, 27 Aug 2002 22:42:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 038E3912A9; Tue, 27 Aug 2002 22:42:10 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3EE339129F for ; Tue, 27 Aug 2002 22:42:06 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 23B925DDBF; Tue, 27 Aug 2002 22:42:06 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id A74135DDBE for ; Tue, 27 Aug 2002 22:42:05 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7S2g4017149; Tue, 27 Aug 2002 22:42:04 -0400 (EDT) Message-Id: <200208280242.g7S2g4017149@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: Zeroconf Subject: Re: Discovering Named Instances of Abstract Services using DNS In-reply-to: (Your message of "Tue, 27 Aug 2002 17:55:26 EDT.") Date: Tue, 27 Aug 2002 22:42:04 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > fortunately, the *dns* groups have traditionally taken their > > responsibilities to avoid harm fairly seriously. I can't say the > > same for zeroconf. > > Um...it's real irresponsible to make the zeroconf group out to be a bunch of > yahoos bent on destroying DNS. hey, it's not just DNS - it's IP also :) of course zeroconf isn't trying to destroy DNS, or IP. but neither does it seem to be very concerned about compatibility issues. as for your supposed real-world testing, I don't think MIT can even approach the diversity that exists in the internet. So I'd consider it useless. Keith From owner-zeroconf@merit.edu Wed Aug 28 00:27:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23523 for ; Wed, 28 Aug 2002 00:27:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B1A3A912AA; Wed, 28 Aug 2002 00:28:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7AF61912AB; Wed, 28 Aug 2002 00:28:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 61086912AA for ; Wed, 28 Aug 2002 00:28:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 327C95DDE0; Wed, 28 Aug 2002 00:28:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id C52A75DDCF for ; Wed, 28 Aug 2002 00:28:53 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id AAA20967 for ; Wed, 28 Aug 2002 00:28:53 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA09304 for ; Wed, 28 Aug 2002 00:28:52 -0400 (EDT) Received: from [10.0.0.12] (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id AAA21212 for ; Wed, 28 Aug 2002 00:28:52 -0400 (EDT) User-Agent: Microsoft-Entourage/10.1.0.2006 Date: Wed, 28 Aug 2002 00:28:48 -0400 Subject: Re: Discovering Named Instances of Abstract Services using DNS From: "John C. Welch" To: Zeroconf Message-ID: In-Reply-To: <200208280242.g7S2g4017149@astro.cs.utk.edu> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On 08/27/2002 22:42, "Keith Moore" wrote: >> Um...it's real irresponsible to make the zeroconf group out to be a bunch of >> yahoos bent on destroying DNS. > > hey, it's not just DNS - it's IP also :) IP has been serviceless for too long, and been the bane of the non-technical users existance for just as long. If people really want to see things like appliances on a network, then things like zeroconf are going to be a requirement. > > of course zeroconf isn't trying to destroy DNS, or IP. > but neither does it seem to be very concerned about compatibility issues. Have you read the specs? There's yards of verbiage that deals with compatibility. > > as for your supposed real-world testing, I don't think MIT can even > approach the diversity that exists in the internet. So I'd consider > it useless. Well, okay, so I *only* have: Solaris 8 AIX 4.3 AIX 5L Linux Windows 2000 Windows NT Mac OS X 10.2 OS/400 Yep, you're absolutely right, no diversity at all. I still need a mainframe, and OS/2 box, an SGI, two crays, an amiga, and a TRS-80 model III on dial up. But since at least I'm trying to contribute something besides deconstructive criticism, I'm pretty happy with it over all. john -- John C. Welch IT Manager MIT Police (617) 253 - 3093 work (508) 579 - 7380 cell (617) 253 - 8822 fax From owner-zeroconf@merit.edu Wed Aug 28 08:28:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27007 for ; Wed, 28 Aug 2002 08:28:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5A1BC912B4; Wed, 28 Aug 2002 08:29:41 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1B8A0912B5; Wed, 28 Aug 2002 08:29:41 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BCA6A912B4 for ; Wed, 28 Aug 2002 08:29:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 906D55DE0C; Wed, 28 Aug 2002 08:29:39 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 665075DDFF for ; Wed, 28 Aug 2002 08:29:34 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7SCSC012118; Wed, 28 Aug 2002 08:28:13 -0400 (EDT) Message-Id: <200208281228.g7SCSC012118@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: itojun@iijlab.net Cc: moore@cs.utk.edu, zeroconf@merit.edu Subject: Re: non-DNS name services In-reply-to: (Your message of "Wed, 28 Aug 2002 15:01:31 +0900.") <20020828060131.5871E4B22@coconut.itojun.org> Date: Wed, 28 Aug 2002 08:28:12 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk YP (later NIS) did indeed break applications, and is one of the things that demonstrated to me that overloading of new services on existing interfaces was a dubious idea. There are lots of examples: - YP could return inconsistent results from DNS both in obvious ways (different name-to-address bindings) and subtle ways (canonical name for an address might be an FQDN in one case and not in another). this could result in different hosts in a conversation having different views of "DNS" (i.e. host name<>address mapping) and causing things to break in subtle ways. - failure modes were different: a host could wait indefinitely on YP binding when a DNS query would have timed out - this could cause failures for applications that were time-critical. (to some degree this was a result of overloading the gethostbyname interface to do DNS queries rather than local-file lookup - hence the clunky h_errno hack - which was at first only supported for DNS queries) - capabilities were different: originally YP tried to completely substitute for DNS, which meant that essential services like MX lookup were not available. For many years Sun distributed two version of sendmail - one with DNS/MX support and one which used only YP - the latter would simply bounce mail for any domain that didn't have an A record (even if it had an MX record). of course, YP was deployed a long time ago, and at a time when the Internet was much smaller than it is now - so the impact was much less than it would be now. and both applications and host implementations have adjusted since YP was initially deployed. for many years it was necessary to explicitly link -lresolv to your applications in order to get the version of gethostbyname() that did DNS lookups. nowdays -lresolv might not actually redefine gethostbyname() to use DNS but the chances are good that the sysadmin has included "dns" in the nss switch file. but to be sure you might have to call the res_* routines explicitly if you really need DNS lookup. and modern implementations of NIS are probably better at setting h_errno to return similar error codes for similar conditions across different services. but even now, NIS is a potential source of DNS inconsistency from one host to another (producing problems similar to those produced by multi-faced DNS) and it's still possible for applications to get bitten by it. one other important difference - NIS was never standardized. we can't stop vendors from putting dubious features in products, but we shouldn't bless such practices. and yes, even though many of the problems have been sorted out (if memory serves it took about 10 years for this to happen) using NIS for hostname lookup is *still* a dubious idea. it mostly serves to increase the potential for errors, while adding very little additional functionality - the chief benefit seems to be that it provides a way to do the equivalent of two-faced DNS (which is also known to cause problems) in a more complex and error-prone fashion. you have been arguing that multicast DNS (or LLMNR) is bad as it mimics DNS behavior and breaks applications. i would like to hear your comment about NIS and NIS+. they are widely deployed, integrated into name resolution functionality of systems (gethostbyname), and certainly overrides DNS in NIS-configured network. from my experience, all NIS, NIS+ and multicast DNS work just fine, no problem observed. if you are okay with NIS/NIS+, you should be okay with multicast DNS. From owner-zeroconf@merit.edu Wed Aug 28 09:24:50 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28917 for ; Wed, 28 Aug 2002 09:24:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DA00F912B9; Wed, 28 Aug 2002 09:26:04 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A58D6912BA; Wed, 28 Aug 2002 09:26:04 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8B64E912B9 for ; Wed, 28 Aug 2002 09:26:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 759EC5DD96; Wed, 28 Aug 2002 09:26:03 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 0D1475DD90 for ; Wed, 28 Aug 2002 09:26:03 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7SDQ1012943; Wed, 28 Aug 2002 09:26:02 -0400 (EDT) Message-Id: <200208281326.g7SDQ1012943@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: Zeroconf Subject: Re: Discovering Named Instances of Abstract Services using DNS In-reply-to: (Your message of "Wed, 28 Aug 2002 00:28:48 EDT.") Date: Wed, 28 Aug 2002 09:26:01 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > >> Um...it's real irresponsible to make the zeroconf group out to be a bunch of > >> yahoos bent on destroying DNS. > > > > hey, it's not just DNS - it's IP also :) > > IP has been serviceless for too long, and been the bane of the non-technical > users existance for just as long. If people really want to see things like > appliances on a network, then things like zeroconf are going to be a > requirement. I don't disagree, I just think that considerably more attention to compatibility issues is warranted. > > as for your supposed real-world testing, I don't think MIT can even > > approach the diversity that exists in the internet. So I'd consider > > it useless. > > Well, okay, so I *only* have: I'm *so* impressed :) But I was talking about diversity of users. > But since at least I'm trying to contribute something besides deconstructive > criticism, I'm pretty happy with it over all. I'm hoping to find time to contribute more constructively (i.e. in more detail) Unfortunately our process places the burden of doing detailed analysis on the people who raise objections, not (as normal engineering discipline would dictate) on the people who make proposals. Keith From owner-zeroconf@merit.edu Wed Aug 28 09:26:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28993 for ; Wed, 28 Aug 2002 09:26:12 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A5A69912BA; Wed, 28 Aug 2002 09:27:32 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D0C9912BB; Wed, 28 Aug 2002 09:27:32 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E16E912BA for ; Wed, 28 Aug 2002 09:27:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 74B0C5DDB1; Wed, 28 Aug 2002 09:27:31 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 102415DD90 for ; Wed, 28 Aug 2002 09:27:31 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g7SCUOD05962; Wed, 28 Aug 2002 05:30:24 -0700 Date: Wed, 28 Aug 2002 05:30:23 -0700 (PDT) From: Bernard Aboba To: Keith Moore Cc: itojun@iijlab.net, Subject: Re: non-DNS name services In-Reply-To: <200208281228.g7SCSC012118@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Wed, 28 Aug 2002, Keith Moore wrote: > - YP could return inconsistent results from DNS > - failure modes were different: > - capabilities were different: > NIS was never standardized. > many of the problems have been sorted out This reads like an argument for careful review of mDNS/LLMNR to make sure that the problems you cite are minimized. I'd note that mDNS and LLMNR do have some important differences along these dimensions. From owner-zeroconf@merit.edu Wed Aug 28 09:35:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29308 for ; Wed, 28 Aug 2002 09:35:13 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 89BC5912BB; Wed, 28 Aug 2002 09:36:31 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 53419912BC; Wed, 28 Aug 2002 09:36:31 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 67C70912BB for ; Wed, 28 Aug 2002 09:36:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3CEE65DD96; Wed, 28 Aug 2002 09:36:30 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id CBE545DD90 for ; Wed, 28 Aug 2002 09:36:29 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g7SCdOo06388; Wed, 28 Aug 2002 05:39:24 -0700 Date: Wed, 28 Aug 2002 05:39:24 -0700 (PDT) From: Bernard Aboba To: Keith Moore Cc: "John C. Welch" , Zeroconf Subject: Re: Discovering Named Instances of Abstract Services using DNS In-Reply-To: <200208280242.g7S2g4017149@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > > Um...it's real irresponsible to make the zeroconf group out to be a bunch of > > yahoos bent on destroying DNS. Actually, it matters little whether the members of Zeroconf WG are yahoos bent on destroying DNS, or angels sent from heaven to save DNS -- because Zeroconf has no charter items relating to DNS. DNSEXT WG has the responsibility of destroying (or saving) DNS. > hey, it's not just DNS - it's IP also :) There is indeed a work item relating to IP (IPv4 linklocal), but not DNS. Bernard "It doesn't have to finish - but it must stop." -- Mike O'Dell From owner-zeroconf@merit.edu Wed Aug 28 09:38:15 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29521 for ; Wed, 28 Aug 2002 09:38:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1FDC7912BC; Wed, 28 Aug 2002 09:39:33 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D96ED912BD; Wed, 28 Aug 2002 09:39:32 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C35A3912BC for ; Wed, 28 Aug 2002 09:39:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A28235DD96; Wed, 28 Aug 2002 09:39:31 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 390E55DD90 for ; Wed, 28 Aug 2002 09:39:31 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7SDc9013044; Wed, 28 Aug 2002 09:38:09 -0400 (EDT) Message-Id: <200208281338.g7SDc9013044@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bernard Aboba Cc: Keith Moore , itojun@iijlab.net, zeroconf@merit.edu Subject: Re: non-DNS name services In-reply-to: (Your message of "Wed, 28 Aug 2002 05:30:23 PDT.") Date: Wed, 28 Aug 2002 09:38:09 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > This reads like an argument for careful review of mDNS/LLMNR to make sure > that the problems you cite are minimized. yes, that's what I expect should be done - while also considering the possibility that it might be better to abandon the approach altogether. From owner-zeroconf@merit.edu Wed Aug 28 09:38:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29537 for ; Wed, 28 Aug 2002 09:38:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B425D912BD; Wed, 28 Aug 2002 09:39:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 737D9912BE; Wed, 28 Aug 2002 09:39:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 81F6A912BD for ; Wed, 28 Aug 2002 09:39:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 70E855DD96; Wed, 28 Aug 2002 09:39:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id CCAE55DD90 for ; Wed, 28 Aug 2002 09:39:53 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g7SCgqa06569 for ; Wed, 28 Aug 2002 05:42:52 -0700 Date: Wed, 28 Aug 2002 05:42:51 -0700 (PDT) From: Bernard Aboba To: zeroconf@merit.edu Subject: I-D ACTION: draft-ietf-dnsext-mdns-12.txt (fwd) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk To: IETF-Announce: ; Subject: I-D ACTION:draft-ietf-dnsext-mdns-12.txt From: Internet-Drafts@ietf.org Date: Wed, 28 Aug 2002 07:55:19 -0400 Cc: namedroppers@ops.ietf.org Reply-to: Internet-Drafts@ietf.org Sender: nsyracus@cnri.reston.va.us -------------------------------------------------------------------------------- A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DNS Extensions Working Group of the IETF. Title : Linklocal Multicast Name Resolution (LLMNR) Author(s) : L. Esibov, B. Aboba, D. Thaler Filename : draft-ietf-dnsext-mdns-12.txt Pages : 20 Date : 2002-8-27 Today, with the rise of home networking, there are an increasing number of ad-hoc networks operating without a DNS server. In order to allow name resolution in such environments, Link-Local Multicast Name Resolution (LLMNR) is proposed. LLMNR supports all current and future DNS formats, types and classes, while operating on a separate port from DNS, and with a distinct resolver cache. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-mdns-12.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dnsext-mdns-12.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dnsext-mdns-12.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. From owner-zeroconf@merit.edu Wed Aug 28 09:38:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29554 for ; Wed, 28 Aug 2002 09:38:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3E20B912BE; Wed, 28 Aug 2002 09:40:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 09B44912BF; Wed, 28 Aug 2002 09:40:13 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C534F912BE for ; Wed, 28 Aug 2002 09:40:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AF4DB5DD96; Wed, 28 Aug 2002 09:40:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 47C345DD90 for ; Wed, 28 Aug 2002 09:40:12 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7SDe8013076; Wed, 28 Aug 2002 09:40:08 -0400 (EDT) Message-Id: <200208281340.g7SDe8013076@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bernard Aboba Cc: Keith Moore , "John C. Welch" , Zeroconf Subject: Re: Discovering Named Instances of Abstract Services using DNS In-reply-to: (Your message of "Wed, 28 Aug 2002 05:39:24 PDT.") Date: Wed, 28 Aug 2002 09:40:08 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > Actually, it matters little whether the members of Zeroconf WG are > yahoos bent on destroying DNS, or angels sent from heaven to > save DNS -- because Zeroconf has no charter items relating to DNS. true, but some of the proposals originated here, and this group seems to have the assumption that changing how DNS works is part of the solution space for what this group is trying to achieve - even if someone else has to do it. From owner-zeroconf@merit.edu Wed Aug 28 09:45:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29831 for ; Wed, 28 Aug 2002 09:45:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A18A4912BF; Wed, 28 Aug 2002 09:46:49 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 58C32912C0; Wed, 28 Aug 2002 09:46:49 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6F99D912BF for ; Wed, 28 Aug 2002 09:46:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 576E35DDCC; Wed, 28 Aug 2002 09:46:48 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id D07C95DDB1 for ; Wed, 28 Aug 2002 09:46:47 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g7SCngT07003; Wed, 28 Aug 2002 05:49:42 -0700 Date: Wed, 28 Aug 2002 05:49:41 -0700 (PDT) From: Bernard Aboba To: Keith Moore Cc: "John C. Welch" , Zeroconf Subject: Re: Discovering Named Instances of Abstract Services using DNS In-Reply-To: <200208281340.g7SDe8013076@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > true, but some of the proposals originated here, and this group seems > to have the assumption that changing how DNS works is part of the > solution space for what this group is trying to achieve - even if someone > else has to do it. Some in this group may be operating under that assumption -- but the IESG in its wisdom did not vest that power in the Zeroconf WG. Instead, they vested it in the WG that owns responsibility for DNS - namely DNSEXT WG. The DNSEXT WG reviewed the mDNS proposals that originated here -- and so far has chosen not to grant them standards track status. They did however, originate their own proposal, and put it on the standards track in DNSEXT WG. This is the LLMNR draft. From owner-zeroconf@merit.edu Wed Aug 28 11:45:21 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05124 for ; Wed, 28 Aug 2002 11:45:21 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B35AF912C8; Wed, 28 Aug 2002 11:46:08 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5B17C912C9; Wed, 28 Aug 2002 11:46:08 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 10779912C8 for ; Wed, 28 Aug 2002 11:46:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E52A45DDF5; Wed, 28 Aug 2002 11:46:06 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id A67845DDA9 for ; Wed, 28 Aug 2002 11:46:06 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7SFil013723; Wed, 28 Aug 2002 11:44:47 -0400 (EDT) Message-Id: <200208281544.g7SFil013723@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: itojun@iijlab.net Cc: Keith Moore , zeroconf@merit.edu Subject: Re: non-DNS name services In-reply-to: (Your message of "Thu, 29 Aug 2002 00:20:57 +0900.") <20020828152057.796104B23@coconut.itojun.org> Date: Wed, 28 Aug 2002 11:44:47 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > >- YP could return inconsistent results from DNS both in obvious ways > >(different name-to-address bindings) and subtle ways (canonical name > >for an address might be an FQDN in one case and not in another). > >this could result in different hosts in a conversation having > >different views of "DNS" (i.e. host name<>address mapping) and > >causing things to break in subtle ways. > > this is no different from having entry different from DNS in /etc/hosts. > i don't see the point. the existence of one source of error does not justify introducing another. > >- failure modes were different: a host could wait indefinitely on YP > >binding when a DNS query would have timed out - this could cause > >failures for applications that were time-critical. (to some degree > >this was a result of overloading the gethostbyname interface to do > >DNS queries rather than local-file lookup - hence the clunky h_errno > >hack - which was at first only supported for DNS queries) > > timeout behavior is different between NIS and DNS, that's all. > i can't say that DNS timeout behavior is *the* right behavior, > nor NIS. it wasn't just a difference in the delay before timing out, it was a difference in the way errors were reported. and under some conditions (ypbind failure) YP lookups would not time out at all. > from my experience, i have to disagree. NIS worked just fine. > maybe your NIS configuration was incorrect/corrupted. after lots of pulling our hair out we decided that "correct" configuration of NIS was to completely disable it for hostname lookups (even when that meant patching libc.so). we've had very few problems with it since then :) (though not zero - I remember one problem that resulted from getservbyname ("smtp", "tcp") returning NULL due to a ypbind failure. it makes *zero* sense to use a network-based service to look up a well-known constant. I replaced that line with htons(25) and it's worked fine ever since :) Keith From owner-zeroconf@merit.edu Wed Aug 28 12:21:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07444 for ; Wed, 28 Aug 2002 12:21:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CEE789120C; Wed, 28 Aug 2002 12:22:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0C53912C9; Wed, 28 Aug 2002 12:22:38 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 76B049120C for ; Wed, 28 Aug 2002 12:22:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5FD605DE14; Wed, 28 Aug 2002 12:22:36 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by segue.merit.edu (Postfix) with ESMTP id CF3FC5DE16 for ; Wed, 28 Aug 2002 12:22:35 -0400 (EDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g7SGMYnO062002; Wed, 28 Aug 2002 12:22:34 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g7SGMXlE169932; Wed, 28 Aug 2002 10:22:33 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g7SGJVR02506; Wed, 28 Aug 2002 12:19:31 -0400 Message-Id: <200208281619.g7SGJVR02506@rotala.raleigh.ibm.com> To: erik.guttman@sun.com Cc: zeroconf@merit.edu Subject: Re: draft-ietf-zeroconf-ipv4-linklocal-06.txt In-Reply-To: Message from "Tue, 13 Aug 2002 16:09:40 +0200." <3D591324.8222BD18@sun.com> Date: Wed, 28 Aug 2002 12:19:30 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk I was all set to put this before the IESG when I realized that the IETF Last Call was run all the way back in July of last year. Given the length of time that has elapsed, I opted to run the LC again. Once the LC has completed, I will formally put the document before the IESG as a whole. In re-reviewing the document, I had the following comments: Most are nits. The one substantive comment is: If the destination address is in the 169.254/16 prefix (including the 169.254.255.255 broadcast address), the host SHOULD use its link- local source address, if it has one. If the host does not have a link-local source address, then it MAY choose to ARP for the destination address and then send its packet, with a routable source IP address and a link-local destination IP address, directly to its destination on the same physical link. The host MUST NOT send the packet to any router for forwarding. The above wording suggests that if host has no LL address, it is not required to use its global address to talk to a device that only has a LL address. This seems broken (i.e, will result in communication failure that is hard to diagnose). Seems to me that SHOULD->MUST and the MAY should also be a MUST. nits: The Security considerations should mention the trivial DOS attack whereby an attacker can force a node to give up its address. This is discussed in the document, so the security considerations could just point to that text. Perhaps Change title to "Usage of and Dynamic Configuration of IPv4 LL Addresses"? > addresses in the source or destination address. With respects to s/respects/respect/ A host probes to see if an address is already in use by broadcasting an ARP request for the desired address. The client MUST fill in the why not use the previously defined term "ARP Probe" rather than "ARP Request"? being probed. An ARP request constructed this way with an all-zero 'sender IP address' is referred to as an "ARP probe". term was already defined earlier. From owner-zeroconf@merit.edu Wed Aug 28 12:23:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA07513 for ; Wed, 28 Aug 2002 12:23:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 26DA7912C9; Wed, 28 Aug 2002 12:24:25 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E23A7912CA; Wed, 28 Aug 2002 12:24:24 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A9DFB912C9 for ; Wed, 28 Aug 2002 12:24:23 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 848305DE19; Wed, 28 Aug 2002 12:24:23 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 399165DE14 for ; Wed, 28 Aug 2002 12:24:23 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7SGN1013949; Wed, 28 Aug 2002 12:23:01 -0400 (EDT) Message-Id: <200208281623.g7SGN1013949@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: itojun@iijlab.net Cc: Keith Moore , zeroconf@merit.edu Subject: Re: non-DNS name services In-reply-to: (Your message of "Thu, 29 Aug 2002 01:00:05 +0900.") <20020828160005.9B3EE4B22@coconut.itojun.org> Date: Wed, 28 Aug 2002 12:23:01 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > >> this is no different from having entry different from DNS in > >> /etc/hosts. > >> i don't see the point. > >the existence of one source of error does not justify introducing another. > > then why DNS is the only one true mechanism for host-to-address lookup? actually I wouldn't claim that at all - quite the opposite. I think we need lots of mechanisms for host-to-address lookup, service-to-address lookup, resource-to-address lookup. but DNS *is* the one true mechanism for lookup of DNS names :) because it is what defines the meanings of those names. > >> >- failure modes were different: a host could wait indefinitely on YP > >> >binding when a DNS query would have timed out - this could cause > >> >failures for applications that were time-critical. (to some degree > >> >this was a result of overloading the gethostbyname interface to do > >> >DNS queries rather than local-file lookup - hence the clunky h_errno > >> >hack - which was at first only supported for DNS queries) > >> > >> timeout behavior is different between NIS and DNS, that's all. > >> i can't say that DNS timeout behavior is *the* right behavior, > >> nor NIS. > > > >it wasn't just a difference in the delay before timing out, it was > >a difference in the way errors were reported. and under some conditions > >(ypbind failure) YP lookups would not time out at all. > > i don't think we are talking. you have been arguing that DNS is the > only one true mechanism for host-to-address lookup. you need to prove > that DNS timeout vaulue as well as the behavior is *the* right one. no, all I need to prove is that we have an installed base that is dependent on the APIs that are used to do DNS lookup having DNS semantics. whether those semantics are right or wrong is immaterial if changing them will break applications. Keith From owner-zeroconf@merit.edu Wed Aug 28 12:50:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08730 for ; Wed, 28 Aug 2002 12:50:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A40959121A; Wed, 28 Aug 2002 12:51:40 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5CBDF9127C; Wed, 28 Aug 2002 12:51:40 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1227D9121A for ; Wed, 28 Aug 2002 12:51:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E8FC85DE1B; Wed, 28 Aug 2002 12:51:38 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 7132F5DE1A for ; Wed, 28 Aug 2002 12:51:38 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7SGoJ014163; Wed, 28 Aug 2002 12:50:20 -0400 (EDT) Message-Id: <200208281650.g7SGoJ014163@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: itojun@iijlab.net Cc: Keith Moore , zeroconf@merit.edu Subject: Re: non-DNS name services In-reply-to: (Your message of "Thu, 29 Aug 2002 01:37:07 +0900.") <20020828163707.166204B22@coconut.itojun.org> Date: Wed, 28 Aug 2002 12:50:19 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk >no, all I need to prove is that we have an installed base that is dependent >on the APIs that are used to do DNS lookup having DNS semantics. whether >those semantics are right or wrong is immaterial if changing them will break >applications. as i have wrote repeatedly, use of multicast DNS did not break any applications for me. if you have evidence that it actually broke your applications, you have to tell us the details so that we can fix things. if you are making discussion based on armchair theory, i suggest you to speak up again only after trying it out for real. that's just completely wrong. you analyze the design *before* you deploy it widely. experience with implementation and early deployment tells you whether the specification was precise enough, and whether you have any unforseen problems (or benefits). it does NOT tell you a number of other things - such as the impact on operations of existing applications or networks, the degree to which it scales, or whether it affects security. for any new technology that affects an existing service, this idea of "you have to prove it's broken to stop it" is broken. the burden needs to be on the proposers to demonstrate - certainly by analysis, perhaps also by operational testing - that the proposal will not have a disruptive effect. Keith From owner-zeroconf@merit.edu Wed Aug 28 13:02:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09314 for ; Wed, 28 Aug 2002 13:02:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BCD7F9127B; Wed, 28 Aug 2002 13:03:51 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 90AD991226; Wed, 28 Aug 2002 13:03:51 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A71029127B for ; Wed, 28 Aug 2002 13:03:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8ED9C5DE23; Wed, 28 Aug 2002 13:03:19 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by segue.merit.edu (Postfix) with ESMTP id 685395DE1E for ; Wed, 28 Aug 2002 13:03:19 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.104]) by gnat.inet.org (Postfix) with ESMTP id E9ADC67103; Wed, 28 Aug 2002 09:17:31 -0400 (EDT) Date: Wed, 28 Aug 2002 13:03:16 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: zeroconf@merit.edu, itojun@iijlab.net To: Keith Moore From: RJ Atkinson In-Reply-To: <200208281650.g7SGoJ014163@astro.cs.utk.edu> Message-Id: <0B862DBF-BAA8-11D6-AC38-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, Aug 28, 2002, at 12:50 America/Montreal, Keith Moore wrote: > for any new technology that affects an existing service, this idea > of "you have to prove it's broken to stop it" is broken. the burden > needs to be on the proposers to demonstrate - certainly by analysis, > perhaps also by operational testing - that the proposal will not have > a disruptive effect. Keith, I understand that you believe the above. However, the IETF process does NOT require that the burden is 100% on the proposers. As this is an IETF WG, your preferred approach is not the same as the actual ground rules in place here. Moreover, as Bernard has pointed out, you're raising your issue in the wrong WG anyway. Ran From owner-zeroconf@merit.edu Wed Aug 28 13:08:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09510 for ; Wed, 28 Aug 2002 13:08:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3A6DB91226; Wed, 28 Aug 2002 13:10:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 024389127C; Wed, 28 Aug 2002 13:10:10 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D3C5391226 for ; Wed, 28 Aug 2002 13:10:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B17B45DE1A; Wed, 28 Aug 2002 13:10:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id B30AC5DDC5 for ; Wed, 28 Aug 2002 13:10:04 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7SH9u014266; Wed, 28 Aug 2002 13:09:57 -0400 (EDT) Message-Id: <200208281709.g7SH9u014266@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: RJ Atkinson Cc: Keith Moore , zeroconf@merit.edu, itojun@iijlab.net Subject: Re: non-DNS name services In-reply-to: (Your message of "Wed, 28 Aug 2002 13:03:16 EDT.") <0B862DBF-BAA8-11D6-AC38-00039357A82A@extremenetworks.com> Date: Wed, 28 Aug 2002 13:09:56 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > I understand that you believe the above. However, the IETF process > does NOT require that the burden is 100% on the proposers. understood. IMHO it's a change that is badly needed. of course, this isn't the right group to discuss *that* either. I noticed that dnsext has just revised the mdns draft so I'll comment on that draft to the dnsext mailing list. Keith From owner-zeroconf@merit.edu Wed Aug 28 16:09:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16766 for ; Wed, 28 Aug 2002 16:09:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3B559912BF; Wed, 28 Aug 2002 16:11:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 0AE94912C1; Wed, 28 Aug 2002 16:11:10 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F1188912BF for ; Wed, 28 Aug 2002 16:11:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D9F6E5DE22; Wed, 28 Aug 2002 16:11:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 7209C5DD92 for ; Wed, 28 Aug 2002 16:11:09 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA25107 for ; Wed, 28 Aug 2002 16:11:09 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA04045 for ; Wed, 28 Aug 2002 16:11:08 -0400 (EDT) Received: from HUSTLER.MIT.EDU (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA14145 for ; Wed, 28 Aug 2002 16:11:08 -0400 (EDT) Date: Wed, 28 Aug 2002 16:11:05 -0400 Subject: Re: Discovering Named Instances of Abstract Services using DNS Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208281326.g7SDQ1012943@astro.cs.utk.edu> Message-Id: <48683C79-BAC2-11D6-ABA2-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, August 28, 2002, at 09:26 AM, Keith Moore wrote: >> Well, okay, so I *only* have: > > I'm *so* impressed :) But I was talking about diversity of users. It's a bunch of people using their network, not students. We are going to be testing student labs as well. *Obviously* any test isn't going to perfectly mirror the internet. But testing in a real world situation, as opposed to an artificially created lab is a good way to find odd things that could go wrong. > >> But since at least I'm trying to contribute something besides >> deconstructive >> criticism, I'm pretty happy with it over all. > > I'm hoping to find time to contribute more constructively (i.e. in > more detail) > Unfortunately our process places the burden of doing detailed analysis > on > the people who raise objections, not (as normal engineering discipline > would > dictate) on the people who make proposals. well, at least someone's testing something somewhere. It's the best way to find real, as opposed to perceived problems. john From owner-zeroconf@merit.edu Wed Aug 28 16:15:57 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16968 for ; Wed, 28 Aug 2002 16:15:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ECEDD912CA; Wed, 28 Aug 2002 16:14:00 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B45A2912CE; Wed, 28 Aug 2002 16:13:59 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3DA41912CA for ; Wed, 28 Aug 2002 16:12:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 215045DE2F; Wed, 28 Aug 2002 16:12:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id B22F05DE22 for ; Wed, 28 Aug 2002 16:12:53 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA25850 for ; Wed, 28 Aug 2002 16:12:53 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA04456 for ; Wed, 28 Aug 2002 16:12:53 -0400 (EDT) Received: from HUSTLER.MIT.EDU (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA14964 for ; Wed, 28 Aug 2002 16:12:52 -0400 (EDT) Date: Wed, 28 Aug 2002 16:12:49 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208281338.g7SDc9013044@astro.cs.utk.edu> Message-Id: <86A1DDDC-BAC2-11D6-ABA2-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, August 28, 2002, at 09:38 AM, Keith Moore wrote: >> This reads like an argument for careful review of mDNS/LLMNR to make >> sure >> that the problems you cite are minimized. > > yes, that's what I expect should be done - while also considering the > possibility that it might be better to abandon the approach altogether. two questions: 1) Have you done a careful review? 2) What do you propose in Zeroconf's place? john From owner-zeroconf@merit.edu Wed Aug 28 16:19:58 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17048 for ; Wed, 28 Aug 2002 16:19:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2B15D912D6; Wed, 28 Aug 2002 16:20:31 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ECE94912DD; Wed, 28 Aug 2002 16:20:30 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1CF1F912D6 for ; Wed, 28 Aug 2002 16:17:49 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 014CB5DE22; Wed, 28 Aug 2002 16:17:49 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 932375DD92 for ; Wed, 28 Aug 2002 16:17:48 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA28138 for ; Wed, 28 Aug 2002 16:17:48 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA05938 for ; Wed, 28 Aug 2002 16:17:47 -0400 (EDT) Received: from HUSTLER.MIT.EDU (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA17059 for ; Wed, 28 Aug 2002 16:17:47 -0400 (EDT) Date: Wed, 28 Aug 2002 16:17:44 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208281623.g7SGN1013949@astro.cs.utk.edu> Message-Id: <365CF2B2-BAC3-11D6-ABA2-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, August 28, 2002, at 12:23 PM, Keith Moore wrote: >> i don't think we are talking. you have been arguing that DNS >> is the >> only one true mechanism for host-to-address lookup. you need >> to prove >> that DNS timeout vaulue as well as the behavior is *the* >> right one. > > no, all I need to prove is that we have an installed base that is > dependent > on the APIs that are used to do DNS lookup having DNS semantics. > whether > those semantics are right or wrong is immaterial if changing them will > break > applications. ...which is why we need to TEST this, and get real data that can be verified, and duplicated. Otherwise, all of this is just arguing about angels doing the gavotte on sewing hardware. john From owner-zeroconf@merit.edu Wed Aug 28 16:23:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA17194 for ; Wed, 28 Aug 2002 16:23:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0BCB2912CD; Wed, 28 Aug 2002 16:24:10 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B2C51912E7; Wed, 28 Aug 2002 16:24:09 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C6F2B912CD for ; Wed, 28 Aug 2002 16:22:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A37C55DE22; Wed, 28 Aug 2002 16:22:47 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 4132F5DD92 for ; Wed, 28 Aug 2002 16:22:47 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA00303 for ; Wed, 28 Aug 2002 16:22:46 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA07503 for ; Wed, 28 Aug 2002 16:22:46 -0400 (EDT) Received: from HUSTLER.MIT.EDU (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA19585 for ; Wed, 28 Aug 2002 16:22:46 -0400 (EDT) Date: Wed, 28 Aug 2002 16:22:43 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208281650.g7SGoJ014163@astro.cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, August 28, 2002, at 12:50 PM, Keith Moore wrote: >> no, all I need to prove is that we have an installed base that is >> dependent >> on the APIs that are used to do DNS lookup having DNS semantics. >> whether >> those semantics are right or wrong is immaterial if changing them >> will break >> applications. > > as i have wrote repeatedly, use of multicast DNS did not break > any > applications for me. if you have evidence that it actually > broke > your applications, you have to tell us the details so that we > can fix > things. if you are making discussion based on armchair theory, > i suggest you to speak up again only after trying it out for > real. > > > that's just completely wrong. you analyze the design *before* you > deploy it widely. experience with implementation and early deployment > tells you whether the specification was precise enough, and whether > you have any unforseen problems (or benefits). it does NOT tell you > a number of other things - such as the impact on operations of existing > applications or networks, the degree to which it scales, or whether it > affects security. Actually, test deployments are part of testing. You cannot get a thorough or reliable analysis without real-world testing. That does NOT mean you deploy it across 50,000 machines on tuesday and see what happens. But you aren't going to get squat for reliable data on scaling, security, operational impact until you actually try it. Because paper can be wrong...which is why the C-124 was the bumblebee of cargo planes. > > for any new technology that affects an existing service, this idea > of "you have to prove it's broken to stop it" is broken. the burden > needs to be on the proposers to demonstrate - certainly by analysis, > perhaps also by operational testing - that the proposal will not have > a disruptive effect. > Analysis alone is never enough. On paper, lots of things look good. But you *need* operational testing to look at silly things like implementation details. Theoretical analysis can only go so far. At some point, someone's got to fire it up. john From owner-zeroconf@merit.edu Wed Aug 28 18:17:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22120 for ; Wed, 28 Aug 2002 18:17:15 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D9DDA9129E; Wed, 28 Aug 2002 18:18:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6D06912C8; Wed, 28 Aug 2002 18:17:22 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E8F99129E for ; Wed, 28 Aug 2002 18:17:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 407425DE40; Wed, 28 Aug 2002 18:17:17 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id CD7725DE32 for ; Wed, 28 Aug 2002 18:17:16 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7SMHF016266; Wed, 28 Aug 2002 18:17:15 -0400 (EDT) Message-Id: <200208282217.g7SMHF016266@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: Zeroconf Subject: Re: non-DNS name services In-reply-to: (Your message of "Wed, 28 Aug 2002 16:12:49 EDT.") <86A1DDDC-BAC2-11D6-ABA2-000393D60422@mit.edu> Date: Wed, 28 Aug 2002 18:17:15 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > two questions: > > 1) Have you done a careful review? I'm working on it now. > 2) What do you propose in Zeroconf's place? now is not the time to ask. suffice it to say that reviewing this document hasn't raised my opinion of the group. Keith From owner-zeroconf@merit.edu Wed Aug 28 18:35:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22782 for ; Wed, 28 Aug 2002 18:35:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F1A84912CC; Wed, 28 Aug 2002 18:36:20 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BCBB1912CE; Wed, 28 Aug 2002 18:36:19 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A4CD1912CC for ; Wed, 28 Aug 2002 18:36:18 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 81D925DE1A; Wed, 28 Aug 2002 18:36:18 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 1A71D5DD98 for ; Wed, 28 Aug 2002 18:36:18 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7SMaG016297; Wed, 28 Aug 2002 18:36:16 -0400 (EDT) Message-Id: <200208282236.g7SMaG016297@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: Zeroconf Subject: Re: non-DNS name services In-reply-to: (Your message of "Wed, 28 Aug 2002 16:17:44 EDT.") <365CF2B2-BAC3-11D6-ABA2-000393D60422@mit.edu> Date: Wed, 28 Aug 2002 18:36:16 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > no, all I need to prove is that we have an installed base that is > > dependent on the APIs that are used to do DNS lookup having DNS semantics. > > whether those semantics are right or wrong is immaterial if changing > > them will break applications. > > ...which is why we need to TEST this, and get real data that can > be verified, and duplicated. Otherwise, all of this is just arguing > about angels doing the gavotte on sewing hardware. My airplane has a design max speed of 171 miles per hour. This figure is based on analysis of the airframe structure and measured strength of the materials used in its construction. However, it will probably go faster than that before it falls completely apart - both because there is some design margin to account for slight variation in materials and wear over time, and because the analysis techniques used when the airframe was designed could not exactly predict fatigue under all flight conditions. Why don't you get an airplane like mine (I want to keep the one I own), take it up to its ceiling (about 12,500 feet), push the throttle forward and nose down, and TEST it to see when it fails? Testing on live users and networks is no substitute for analysis. Keith From owner-zeroconf@merit.edu Wed Aug 28 18:36:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22825 for ; Wed, 28 Aug 2002 18:36:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0D5F7912CE; Wed, 28 Aug 2002 18:37:56 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D4FA2912CF; Wed, 28 Aug 2002 18:37:55 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C97E1912CE for ; Wed, 28 Aug 2002 18:37:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B1E6B5DE40; Wed, 28 Aug 2002 18:37:54 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 49C455DE1A for ; Wed, 28 Aug 2002 18:37:54 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7SMbm016319; Wed, 28 Aug 2002 18:37:48 -0400 (EDT) Message-Id: <200208282237.g7SMbm016319@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: Zeroconf Subject: Re: non-DNS name services In-reply-to: (Your message of "Wed, 28 Aug 2002 16:22:43 EDT.") Date: Wed, 28 Aug 2002 18:37:48 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > Analysis alone is never enough. didn't say it was. but there are far more cases that you can analyze than those you can test. you need the tests to verify your analysis, not to verify your design. Keith From owner-zeroconf@merit.edu Wed Aug 28 18:47:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA23243 for ; Wed, 28 Aug 2002 18:47:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B2C7191205; Wed, 28 Aug 2002 18:48:26 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 86827912CF; Wed, 28 Aug 2002 18:48:26 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A1A1E91205 for ; Wed, 28 Aug 2002 18:48:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 78BBC5DDC5; Wed, 28 Aug 2002 18:48:01 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by segue.merit.edu (Postfix) with ESMTP id E5E1B5DD98 for ; Wed, 28 Aug 2002 18:48:00 -0400 (EDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 3D1C24B22; Thu, 29 Aug 2002 07:45:57 +0900 (JST) To: Keith Moore Cc: zeroconf@merit.edu In-reply-to: moore's message of Wed, 28 Aug 2002 12:50:19 -0400. <200208281650.g7SGoJ014163@astro.cs.utk.edu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: non-DNS name services From: itojun@iijlab.net Date: Thu, 29 Aug 2002 07:45:57 +0900 Message-Id: <20020828224557.3D1C24B22@coconut.itojun.org> Sender: owner-zeroconf@merit.edu Precedence: bulk >that's just completely wrong. you analyze the design *before* you >deploy it widely. experience with implementation and early deployment >tells you whether the specification was precise enough, and whether >you have any unforseen problems (or benefits). it does NOT tell you >a number of other things - such as the impact on operations of existing >applications or networks, the degree to which it scales, or whether it >affects security. > >for any new technology that affects an existing service, this idea >of "you have to prove it's broken to stop it" is broken. the burden >needs to be on the proposers to demonstrate - certainly by analysis, >perhaps also by operational testing - that the proposal will not have >a disruptive effect. "We reject Kings, presidents, and voting. We believe in rough consensus and RUNNING CODE". so what's bad about trying things out in real life? itojun From owner-zeroconf@merit.edu Wed Aug 28 19:20:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24156 for ; Wed, 28 Aug 2002 19:20:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A59C9912CF; Wed, 28 Aug 2002 19:21:20 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 72F85912D0; Wed, 28 Aug 2002 19:21:20 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 59064912CF for ; Wed, 28 Aug 2002 19:21:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 368AB5DE40; Wed, 28 Aug 2002 19:21:19 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id C2E805DD98 for ; Wed, 28 Aug 2002 19:21:18 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7SNJx016452; Wed, 28 Aug 2002 19:20:00 -0400 (EDT) Message-Id: <200208282320.g7SNJx016452@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: itojun@iijlab.net Cc: Keith Moore , zeroconf@merit.edu Subject: Re: non-DNS name services In-reply-to: (Your message of "Thu, 29 Aug 2002 07:45:57 +0900.") <20020828224557.3D1C24B22@coconut.itojun.org> Date: Wed, 28 Aug 2002 19:19:59 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk "We reject Kings, presidents, and voting. We believe in rough consensus and RUNNING CODE". so what's bad about trying things out in real life? nothing. but we also need to recognize that it has its limitations. also, the internet is a lot bigger place than it used to be. what was "good enough" in the mid-1980s when there were tens of thousands of users on the net and nearly everyone on the net ran some kind of BSD isn't necessarily good enough now. as for the perils of trying things out in real life, I keep thinking of the Tacoma Narrows Bridge, which was built in spite of analysis that showed that it would fail under wind loads. Keith From owner-zeroconf@merit.edu Wed Aug 28 19:25:41 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24297 for ; Wed, 28 Aug 2002 19:25:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5D08A912D0; Wed, 28 Aug 2002 19:26:58 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 2C6C0912D1; Wed, 28 Aug 2002 19:26:58 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 394C8912D0 for ; Wed, 28 Aug 2002 19:26:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 193005DE42; Wed, 28 Aug 2002 19:26:57 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 8E3F25DD98 for ; Wed, 28 Aug 2002 19:26:56 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g7SNQt509804 for ; Wed, 28 Aug 2002 16:26:56 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Wed, 28 Aug 2002 16:26:52 -0700 Received: from graejo.apple.com (graejo.apple.com [17.202.40.111]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g7SNQq324591 for ; Wed, 28 Aug 2002 16:26:52 -0700 (PDT) Date: Wed, 28 Aug 2002 16:26:37 -0700 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: Joshua Graessley To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <200208282320.g7SNJx016452@astro.cs.utk.edu> Message-Id: <993B1F76-BADD-11D6-A9B3-000393760260@apple.com> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, August 28, 2002, at 04:19 PM, Keith Moore wrote: > as for the perils of trying things out in real life, I keep > thinking of the Tacoma Narrows Bridge, which was built in spite > of analysis that showed that it would fail under wind loads. So is there some analysis (something other than pure speculation) that shows that IPv4 link local addresses or mDNS or NAIS will wreck havoc? I haven't seen anything yet, with the exception of issues with multihomed hosts and IPv4 link-local addresses. -josh From owner-zeroconf@merit.edu Wed Aug 28 19:32:14 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24490 for ; Wed, 28 Aug 2002 19:32:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DB9BB912D1; Wed, 28 Aug 2002 19:33:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AADB7912D2; Wed, 28 Aug 2002 19:33:27 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 38E05912D1 for ; Wed, 28 Aug 2002 19:33:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 31EB15DE30; Wed, 28 Aug 2002 19:33:07 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by segue.merit.edu (Postfix) with ESMTP id C5F5B5DD98 for ; Wed, 28 Aug 2002 19:33:06 -0400 (EDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 0280B4B22; Thu, 29 Aug 2002 08:31:04 +0900 (JST) To: Keith Moore Cc: zeroconf@merit.edu In-reply-to: moore's message of Wed, 28 Aug 2002 19:19:59 -0400. <200208282320.g7SNJx016452@astro.cs.utk.edu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: non-DNS name services From: itojun@iijlab.net Date: Thu, 29 Aug 2002 08:31:03 +0900 Message-Id: <20020828233104.0280B4B22@coconut.itojun.org> Sender: owner-zeroconf@merit.edu Precedence: bulk >>also, the internet is a lot bigger place than it used to be. >>what was "good enough" in the mid-1980s when there were tens of >>thousands of users on the net and nearly everyone on the >>net ran some kind of BSD isn't necessarily good enough now. tell me - what kind of service will break at utk.edu if i use multicast DNS in my network at itojun.org? the network size argument you have been using does not convince me at all. itojun From owner-zeroconf@merit.edu Wed Aug 28 19:38:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24691 for ; Wed, 28 Aug 2002 19:38:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5C0159121A; Wed, 28 Aug 2002 19:40:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 29F52912D2; Wed, 28 Aug 2002 19:40:14 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 0BA729121A for ; Wed, 28 Aug 2002 19:40:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E62D85DE45; Wed, 28 Aug 2002 19:40:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 7E93C5DE42 for ; Wed, 28 Aug 2002 19:40:12 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7SNcs016513; Wed, 28 Aug 2002 19:38:54 -0400 (EDT) Message-Id: <200208282338.g7SNcs016513@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: itojun@iijlab.net Cc: Keith Moore , zeroconf@merit.edu Subject: Re: non-DNS name services In-reply-to: (Your message of "Thu, 29 Aug 2002 08:31:03 +0900.") <20020828233104.0280B4B22@coconut.itojun.org> Date: Wed, 28 Aug 2002 19:38:54 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > tell me - what kind of service will break at utk.edu if i use > multicast DNS in my network at itojun.org? tell me - do you think that that software devleopers want their products to act differently depending on whether they're run at utk.edu or itojun.org? I'm in the middle of doing detailed analysis on LLMNR - so I'll refrain from making detailed comments until that's done. And I'll make those comments to the dnsext WG. Keith From owner-zeroconf@merit.edu Wed Aug 28 22:05:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27786 for ; Wed, 28 Aug 2002 22:05:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 783E4912D1; Wed, 28 Aug 2002 22:07:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49ACD912D8; Wed, 28 Aug 2002 22:07:15 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2FFEC912D1 for ; Wed, 28 Aug 2002 22:07:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0B9CE5DE63; Wed, 28 Aug 2002 22:07:14 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 98E0F5DE5D for ; Wed, 28 Aug 2002 22:07:13 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7T27A016997; Wed, 28 Aug 2002 22:07:10 -0400 (EDT) Message-Id: <200208290207.g7T27A016997@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: zeroconf@merit.edu Subject: Re: non-DNS name services In-reply-to: (Your message of "Wed, 28 Aug 2002 16:26:37 PDT.") <993B1F76-BADD-11D6-A9B3-000393760260@apple.com> Date: Wed, 28 Aug 2002 22:07:10 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > So is there some analysis (something other than pure speculation) that > shows that IPv4 link local addresses or mDNS or NAIS will wreck havoc? Yes, there are several problems with IPv4 LL, many of which I've described in detail in comments to this WG and to the IESG. No they are not addressed in the current draft. I'm working on the analysis for LLMNR. Yes, there are problems with it also - descriptions are forthcoming. Keith From owner-zeroconf@merit.edu Thu Aug 29 00:09:28 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00532 for ; Thu, 29 Aug 2002 00:09:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A1ABA9121D; Thu, 29 Aug 2002 00:10:46 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 77A34912CE; Thu, 29 Aug 2002 00:10:46 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 614479121D for ; Thu, 29 Aug 2002 00:10:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3FE285DE6A; Thu, 29 Aug 2002 00:10:45 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id D1B8D5DD98 for ; Thu, 29 Aug 2002 00:10:44 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA01806 for ; Thu, 29 Aug 2002 00:10:44 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA09351 for ; Thu, 29 Aug 2002 00:10:44 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id AAA15239 for ; Thu, 29 Aug 2002 00:10:43 -0400 (EDT) Date: Thu, 29 Aug 2002 00:10:40 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208282217.g7SMHF016266@astro.cs.utk.edu> Message-Id: <477D4A80-BB05-11D6-B2AE-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, August 28, 2002, at 06:17 PM, Keith Moore wrote: >> two questions: >> >> 1) Have you done a careful review? > > I'm working on it now. commenting on something without having carefully reviewed it. > >> 2) What do you propose in Zeroconf's place? > > now is not the time to ask. suffice it to say that reviewing this > document hasn't raised my opinion of the group. well, blasting the idea without a good replacement is a waste of time, eh? john From owner-zeroconf@merit.edu Thu Aug 29 00:16:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00599 for ; Thu, 29 Aug 2002 00:16:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 827D7912CE; Thu, 29 Aug 2002 00:17:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4CCCA912D1; Thu, 29 Aug 2002 00:17:16 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D5CFD912CE for ; Thu, 29 Aug 2002 00:17:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A9D035DE5B; Thu, 29 Aug 2002 00:17:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 4A1285DD98 for ; Thu, 29 Aug 2002 00:17:08 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id AAA03086 for ; Thu, 29 Aug 2002 00:17:07 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA26962 for ; Thu, 29 Aug 2002 00:17:07 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id AAA16387 for ; Thu, 29 Aug 2002 00:17:07 -0400 (EDT) Date: Thu, 29 Aug 2002 00:17:03 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208282236.g7SMaG016297@astro.cs.utk.edu> Message-Id: <2C146A7B-BB06-11D6-B2AE-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, August 28, 2002, at 06:36 PM, Keith Moore wrote: >>> no, all I need to prove is that we have an installed base that is >>> dependent on the APIs that are used to do DNS lookup having DNS >>> semantics. >>> whether those semantics are right or wrong is immaterial if changing >>> them will break applications. >> >> ...which is why we need to TEST this, and get real data that can >> be verified, and duplicated. Otherwise, all of this is just arguing >> about angels doing the gavotte on sewing hardware. > > My airplane has a design max speed of 171 miles per hour. This figure > is > based on analysis of the airframe structure and measured strength of > the > materials used in its construction. However, it will probably go > faster > than that before it falls completely apart - both because there is some > design margin to account for slight variation in materials and wear > over > time, and because the analysis techniques used when the airframe was > designed could not exactly predict fatigue under all flight conditions. > > Why don't you get an airplane like mine (I want to keep the one I own), > take it up to its ceiling (about 12,500 feet), push the throttle > forward > and nose down, and TEST it to see when it fails? The military does this all the time...they're called test pilots for a reason. You'll note they find all kinds of things the design didn't point out. This is how we discover all kinds of interesting things about the limits of an airframe..sometimes unintentionally...like the B-52 that survived a barrel roll...or that a KC-135R model can climb at a 70 Degree angle with no real problems. The real world hits you with variables you can't predict, which is where a paper-only test fails miserably. Paper testing helps you deal quickly with the predictable issues, so you can focus real world testing on the odd things humans do. > > Testing on live users and networks is no substitute for analysis. It's not *supposed* to be a *substitute. They work *together*. Either alone is *useless* because you miss too much overly relying on a single method. Both together shore up each other's weaknesses and provide a picture of what you are testing that *neither* can ever provide on their own. which is why the intelligent tester uses both methods. john From owner-zeroconf@merit.edu Thu Aug 29 00:17:32 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00643 for ; Thu, 29 Aug 2002 00:17:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E5928912D1; Thu, 29 Aug 2002 00:18:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D6473912DD; Thu, 29 Aug 2002 00:18:47 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 35EB6912E0 for ; Thu, 29 Aug 2002 00:17:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EF5945DE5B; Thu, 29 Aug 2002 00:17:46 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 8DBF85DD98 for ; Thu, 29 Aug 2002 00:17:46 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA03120 for ; Thu, 29 Aug 2002 00:17:46 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA26988 for ; Thu, 29 Aug 2002 00:17:45 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id AAA16420 for ; Thu, 29 Aug 2002 00:17:45 -0400 (EDT) Date: Thu, 29 Aug 2002 00:17:42 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208282237.g7SMbm016319@astro.cs.utk.edu> Message-Id: <4346124C-BB06-11D6-B2AE-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, August 28, 2002, at 06:37 PM, Keith Moore wrote: >> Analysis alone is never enough. > > didn't say it was. but there are far more cases that you can analyze > than those you can test. you need the tests to verify your analysis, > not to verify your design. they do both in the end, analysis can't cover everything. Reality is too chaotic. john From owner-zeroconf@merit.edu Thu Aug 29 00:18:51 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00662 for ; Thu, 29 Aug 2002 00:18:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 03AA0912DD; Thu, 29 Aug 2002 00:20:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C9407912DE; Thu, 29 Aug 2002 00:20:13 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BF874912DD for ; Thu, 29 Aug 2002 00:20:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB8405DE5B; Thu, 29 Aug 2002 00:20:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 4AD8B5DD98 for ; Thu, 29 Aug 2002 00:20:12 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id AAA03641 for ; Thu, 29 Aug 2002 00:20:11 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA09737 for ; Thu, 29 Aug 2002 00:20:11 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id AAA16928 for ; Thu, 29 Aug 2002 00:20:11 -0400 (EDT) Date: Thu, 29 Aug 2002 00:19:35 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208282320.g7SNJx016452@astro.cs.utk.edu> Message-Id: <86A5628A-BB06-11D6-B2AE-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, August 28, 2002, at 07:19 PM, Keith Moore wrote: > as for the perils of trying things out in real life, I keep > thinking of the Tacoma Narrows Bridge, which was built in spite > of analysis that showed that it would fail under wind loads. Deliberate stupidity cancels everything out. on paper, a B-1B's ECM system is a snap to maintain, 200+ *easily replaceable" units....the reality is quite different, but for reasons you couldn't predict without doing the replacing. john From owner-zeroconf@merit.edu Thu Aug 29 00:20:12 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00685 for ; Thu, 29 Aug 2002 00:20:11 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A8FB3912DE; Thu, 29 Aug 2002 00:21:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 785E9912DF; Thu, 29 Aug 2002 00:21:34 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 74BFD912DE for ; Thu, 29 Aug 2002 00:21:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 657F05DE5B; Thu, 29 Aug 2002 00:21:33 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 02A015DD98 for ; Thu, 29 Aug 2002 00:21:32 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id AAA03915 for ; Thu, 29 Aug 2002 00:21:32 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id AAA09776 for ; Thu, 29 Aug 2002 00:21:32 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id AAA17234 for ; Thu, 29 Aug 2002 00:21:31 -0400 (EDT) Date: Thu, 29 Aug 2002 00:21:28 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208282338.g7SNcs016513@astro.cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Wednesday, August 28, 2002, at 07:38 PM, Keith Moore wrote: >> tell me - what kind of service will break at utk.edu if i use >> multicast DNS in my network at itojun.org? > > tell me - do you think that that software devleopers want their > products > to act differently depending on whether they're run at utk.edu or > itojun.org? So far, I see no evidence that this will happen other than vague warnings of bad things. john From owner-zeroconf@merit.edu Thu Aug 29 08:26:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18629 for ; Thu, 29 Aug 2002 08:26:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A2DB9912CC; Thu, 29 Aug 2002 08:27:49 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6BF5E912E7; Thu, 29 Aug 2002 08:27:49 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 53FD3912CC for ; Thu, 29 Aug 2002 08:27:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 39BB75DE76; Thu, 29 Aug 2002 08:27:48 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id C74F95DE52 for ; Thu, 29 Aug 2002 08:27:47 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7TCRk013443; Thu, 29 Aug 2002 08:27:46 -0400 (EDT) Message-Id: <200208291227.g7TCRk013443@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: Zeroconf Subject: Re: non-DNS name services In-reply-to: (Your message of "Thu, 29 Aug 2002 00:10:40 EDT.") <477D4A80-BB05-11D6-B2AE-000393D60422@mit.edu> Date: Thu, 29 Aug 2002 08:27:46 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > >> two questions: > >> > >> 1) Have you done a careful review? > > > > I'm working on it now. > > commenting on something without having carefully reviewed it. I had in fact carefully reviewed an earlier version of mdns; I just hadn't read it recently. So it was possible that the problems had been fixed. But they haven't. > > > >> 2) What do you propose in Zeroconf's place? > > > > now is not the time to ask. suffice it to say that reviewing this > > document hasn't raised my opinion of the group. > > well, blasting the idea without a good replacement is a waste of time, eh? frankly I think it would be more constructive if people would actually try to address the technical problems with their proposals rather than claim that they don't exist and to malign the person who points them out. From owner-zeroconf@merit.edu Thu Aug 29 08:31:03 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18879 for ; Thu, 29 Aug 2002 08:31:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AD7CD912E7; Thu, 29 Aug 2002 08:30:31 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 749EB912E8; Thu, 29 Aug 2002 08:30:31 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 488C7912E7 for ; Thu, 29 Aug 2002 08:30:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 835F45DE79; Thu, 29 Aug 2002 08:30:28 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 1670F5DE52 for ; Thu, 29 Aug 2002 08:30:28 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7TCUR013464; Thu, 29 Aug 2002 08:30:27 -0400 (EDT) Message-Id: <200208291230.g7TCUR013464@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: Zeroconf Subject: Re: non-DNS name services In-reply-to: (Your message of "Thu, 29 Aug 2002 00:19:35 EDT.") <86A5628A-BB06-11D6-B2AE-000393D60422@mit.edu> Date: Thu, 29 Aug 2002 08:30:27 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > as for the perils of trying things out in real life, I keep > > thinking of the Tacoma Narrows Bridge, which was built in spite > > of analysis that showed that it would fail under wind loads. > > Deliberate stupidity cancels everything out. on paper, a B-1B's ECM > system is a snap to maintain, 200+ *easily replaceable" units....the > reality is quite different, but for reasons you couldn't predict > without doing the replacing. truly, analysis can fail, just as testing can fail. but it's certainly appropriate to use analysis before you widely deploy something, particularly something that changes the functionality of a widely-used service. From owner-zeroconf@merit.edu Thu Aug 29 08:36:18 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19155 for ; Thu, 29 Aug 2002 08:36:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2C1E5912E8; Thu, 29 Aug 2002 08:37:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EFA91912E9; Thu, 29 Aug 2002 08:37:35 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CD976912E8 for ; Thu, 29 Aug 2002 08:37:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B598D5DE79; Thu, 29 Aug 2002 08:37:34 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 4D6755DE52 for ; Thu, 29 Aug 2002 08:37:34 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7TCbX013483; Thu, 29 Aug 2002 08:37:33 -0400 (EDT) Message-Id: <200208291237.g7TCbX013483@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: Zeroconf Subject: Re: non-DNS name services In-reply-to: (Your message of "Thu, 29 Aug 2002 00:17:03 EDT.") <2C146A7B-BB06-11D6-B2AE-000393D60422@mit.edu> Date: Thu, 29 Aug 2002 08:37:33 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > The military does this all the time...they're called test pilots for a > reason. You'll note they find all kinds of things the design didn't > point out. This is how we discover all kinds of interesting things > about the limits of an airframe..sometimes unintentionally...like the > B-52 that survived a barrel roll... my understanding is that properly done, a barrel roll is a 1G maneuver. so I see no reason any sufficiently powered aircraft couldn't survive it as long as its engines, fuel system, etc could handle the brief inverted operation. it won't stress the airframe. but I certainly agree that testing and analysis are both useful, and that both are often necessary. my beef is with the idea that testing alone is sufficient when the potentail for disruption (and the associated cost) are high. Keith From owner-zeroconf@merit.edu Thu Aug 29 10:09:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22914 for ; Thu, 29 Aug 2002 10:09:17 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 978F5912E9; Thu, 29 Aug 2002 10:10:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62A1F912EA; Thu, 29 Aug 2002 10:10:36 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5AF78912E9 for ; Thu, 29 Aug 2002 10:10:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 34C875DE88; Thu, 29 Aug 2002 10:10:35 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id C83645DDD1 for ; Thu, 29 Aug 2002 10:10:34 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA03010 for ; Thu, 29 Aug 2002 10:10:34 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA25876 for ; Thu, 29 Aug 2002 10:10:33 -0400 (EDT) Received: from HUSTLER.MIT.EDU (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA24599 for ; Thu, 29 Aug 2002 10:10:33 -0400 (EDT) Date: Thu, 29 Aug 2002 10:10:29 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208291227.g7TCRk013443@astro.cs.utk.edu> Message-Id: <12CF5269-BB59-11D6-8C06-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, August 29, 2002, at 08:27 AM, Keith Moore wrote: >> well, blasting the idea without a good replacement is a waste of >> time, eh? > > frankly I think it would be more constructive if people would actually > try to > address the technical problems with their proposals rather than claim > that they > don't exist and to malign the person who points them out. I, and a lot of people, simply want *proof* of these problems...yes or no. So far, we haven't been able to test them. All the criticism has been "may" or "could" or "might", but until someone can say "did" and "does", then we *don't know for sure*. Which is why real, physical testing of potential problems is needed. Otherwise, we knife something based on theory. That would be an even greater waste of time. john From owner-zeroconf@merit.edu Thu Aug 29 10:14:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23184 for ; Thu, 29 Aug 2002 10:14:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7ADC8912EA; Thu, 29 Aug 2002 10:15:06 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8E71912EB; Thu, 29 Aug 2002 10:15:05 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 35884912EA for ; Thu, 29 Aug 2002 10:15:03 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8E5DB5DE77; Thu, 29 Aug 2002 10:15:02 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id C12CE5DDD1 for ; Thu, 29 Aug 2002 10:15:01 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA06679 for ; Thu, 29 Aug 2002 10:15:01 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA26696 for ; Thu, 29 Aug 2002 10:15:01 -0400 (EDT) Received: from HUSTLER.MIT.EDU (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA26329 for ; Thu, 29 Aug 2002 10:15:00 -0400 (EDT) Date: Thu, 29 Aug 2002 10:14:56 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208291230.g7TCUR013464@astro.cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, August 29, 2002, at 08:30 AM, Keith Moore wrote: >> Deliberate stupidity cancels everything out. on paper, a B-1B's ECM >> system is a snap to maintain, 200+ *easily replaceable" units....the >> reality is quite different, but for reasons you couldn't predict >> without doing the replacing. > > truly, analysis can fail, just as testing can fail. but it's certainly > appropriate to use analysis before you widely deploy something, > particularly something that changes the functionality of a widely-used > service. There is a difference between testing deplyoments and production deployments. I agree that revamping anything for Zeroconf right now would be immature. *But*...I also think radically changing or dumping Zeroconf based on what is almost entirely theory would be just as immature. So you test the potential problems. *That* way, you have real, reproducible hard data. You can argue theory, you can argue analysis. It's real hard to argue with : "If you set this system up under these parameter, it does the following bad things..." As well, if you have real, hard data from real testing, then you make it *far* easier to implement spec changes in a methodical, coherent fashion. Never ignore analysis, but don't insist that it's a substitute for firing up the system either. john From owner-zeroconf@merit.edu Thu Aug 29 10:18:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23349 for ; Thu, 29 Aug 2002 10:18:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CFE93912EB; Thu, 29 Aug 2002 10:19:56 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 94F47912EC; Thu, 29 Aug 2002 10:19:56 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8F3DB912EB for ; Thu, 29 Aug 2002 10:19:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 735045DE88; Thu, 29 Aug 2002 10:19:55 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 0F9B75DDD1 for ; Thu, 29 Aug 2002 10:19:55 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA06883 for ; Thu, 29 Aug 2002 10:19:54 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA10546 for ; Thu, 29 Aug 2002 10:17:20 -0400 (EDT) Received: from HUSTLER.MIT.EDU (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA27090 for ; Thu, 29 Aug 2002 10:17:20 -0400 (EDT) Date: Thu, 29 Aug 2002 10:17:15 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208291237.g7TCbX013483@astro.cs.utk.edu> Message-Id: <04E7A1D5-BB5A-11D6-8C06-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, August 29, 2002, at 08:37 AM, Keith Moore wrote: >> The military does this all the time...they're called test pilots for a >> reason. You'll note they find all kinds of things the design didn't >> point out. This is how we discover all kinds of interesting things >> about the limits of an airframe..sometimes unintentionally...like the >> B-52 that survived a barrel roll... > > my understanding is that properly done, a barrel roll is a 1G maneuver. > so I see no reason any sufficiently powered aircraft couldn't survive > it > as long as its engines, fuel system, etc could handle the brief > inverted > operation. it won't stress the airframe. Actually, in the B-52's case, the spine of the aircraft looked like a human spine...the pilot almost lost control of his bladder when he saw it. Went from 20-30,000 feet to 1,000 feet...B-52's aren't designed for that at all... > > but I certainly agree that testing and analysis are both useful, and > that both are often necessary. my beef is with the idea that testing > alone is sufficient when the potentail for disruption (and the > associated > cost) are high. > > I've never advocated denying analysis for testing. Nor have I advocated breaking things for testing. Plan the test and test the plan. john From owner-zeroconf@merit.edu Thu Aug 29 11:10:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25939 for ; Thu, 29 Aug 2002 11:10:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B410B912F0; Thu, 29 Aug 2002 11:12:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 87425912F2; Thu, 29 Aug 2002 11:12:09 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 756E8912F0 for ; Thu, 29 Aug 2002 11:12:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5E2675DE41; Thu, 29 Aug 2002 11:12:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id E92885DDD1 for ; Thu, 29 Aug 2002 11:12:07 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7TFC6014337; Thu, 29 Aug 2002 11:12:06 -0400 (EDT) Message-Id: <200208291512.g7TFC6014337@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: Zeroconf Subject: Re: non-DNS name services In-reply-to: (Your message of "Thu, 29 Aug 2002 10:10:29 EDT.") <12CF5269-BB59-11D6-8C06-000393D60422@mit.edu> Date: Thu, 29 Aug 2002 11:12:06 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > I, and a lot of people, simply want *proof* of these problems...yes or > no. So far, we haven't been able to test them. All the criticism has > been "may" or "could" or "might", but until someone can say "did" and > "does", then we *don't know for sure*. nope. you've got it backwards. when you're trying to standardize technologies that change how IP and DNS work - i.e. two of the three most critical parts of Internet technology - the burden needs to be on the proposers to analyze the risks and persuasively argue that the changes you are propsing will not cause harm to existing infrastrucutre or applicatoins. mere testing is unpersuasive because it cannot even begin to cover the conditions that will be encountered in the real world. > Which is why real, physical testing of potential problems is needed. > Otherwise, we knife something based on theory. That would be an even > greater waste of time. no, the greater waste of time is trying to fix problems caused by irresponsible widespread deployment of poorly-analyzed technology. Keith From owner-zeroconf@merit.edu Thu Aug 29 11:17:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26350 for ; Thu, 29 Aug 2002 11:17:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BB44A912F2; Thu, 29 Aug 2002 11:19:20 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8CBF1912F3; Thu, 29 Aug 2002 11:19:20 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 937CB912F2 for ; Thu, 29 Aug 2002 11:19:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6B47B5DE90; Thu, 29 Aug 2002 11:19:19 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from coconut.itojun.org (coconut.itojun.org [219.101.47.130]) by segue.merit.edu (Postfix) with ESMTP id E24035DE52 for ; Thu, 29 Aug 2002 11:19:18 -0400 (EDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id ED7354B22; Fri, 30 Aug 2002 00:18:55 +0900 (JST) To: Keith Moore Cc: "John C. Welch" , Zeroconf In-reply-to: moore's message of Thu, 29 Aug 2002 11:12:06 -0400. <200208291512.g7TFC6014337@astro.cs.utk.edu> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: non-DNS name services From: itojun@iijlab.net Date: Fri, 30 Aug 2002 00:18:55 +0900 Message-Id: <20020829151856.ED7354B22@coconut.itojun.org> Sender: owner-zeroconf@merit.edu Precedence: bulk >> Which is why real, physical testing of potential problems is needed. >> Otherwise, we knife something based on theory. That would be an even >> greater waste of time. >no, the greater waste of time is trying to fix problems caused by >irresponsible widespread deployment of poorly-analyzed technology. from the recent measurement results made against lame delegation, TTL misconfiguration and such, i don't believe DNS behavior is analyzed well enough (it is still a mistery why it works this well). so if i follow your logic you need to remove DNS from your infrastructure. you have to type in IP addresses in numeric form :-P itojun From owner-zeroconf@merit.edu Thu Aug 29 11:32:34 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27119 for ; Thu, 29 Aug 2002 11:32:33 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D231A912F3; Thu, 29 Aug 2002 11:33:46 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 872829129E; Thu, 29 Aug 2002 11:33:46 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D81FF912F3 for ; Thu, 29 Aug 2002 11:32:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B985B5DE52; Thu, 29 Aug 2002 11:32:33 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 572425DDD1 for ; Thu, 29 Aug 2002 11:32:33 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA11430 for ; Thu, 29 Aug 2002 11:32:32 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA09096 for ; Thu, 29 Aug 2002 11:32:32 -0400 (EDT) Received: from HUSTLER.MIT.EDU (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id LAA25779 for ; Thu, 29 Aug 2002 11:32:32 -0400 (EDT) Date: Thu, 29 Aug 2002 11:32:27 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208291512.g7TFC6014337@astro.cs.utk.edu> Message-Id: <86206679-BB64-11D6-B555-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, August 29, 2002, at 11:12 AM, Keith Moore wrote: >> I, and a lot of people, simply want *proof* of these problems...yes or >> no. So far, we haven't been able to test them. All the criticism has >> been "may" or "could" or "might", but until someone can say "did" and >> "does", then we *don't know for sure*. > > nope. you've got it backwards. when you're trying to standardize > technologies that change how IP and DNS work - i.e. two of the three > most critical parts of Internet technology - the burden needs to be on > the proposers to analyze the risks and persuasively argue that the > changes you are propsing will not cause harm to existing infrastrucutre > or applicatoins. mere testing is unpersuasive because it cannot even > begin to cover the conditions that will be encountered in the real > world. Sigh...so in other words, since you cannot cover 100% of every situation, then we should sit on our hands and never test anything again, but rely on the perfect and complete accuracy of theoretical analysis...which gave us such great and widely implemented protocols like OSI. According to your logic, nothing should be done anywhere unless every possible contingency can be accounted for. So no more software updates, because you cannot predict and test for every single situation. No more new hardware, you cannot predict and test for every situation. What the heck, we didn't need anything more than what we have now anyway. Obviously any work on dns and TCP/IP should be immediately halted until a 100% guarantee can be made that all possible problems have been predicted and corrected. Pardon me if I think that this is of course, silly. Obviously we cannot build a replica of the internet. But if enough people test in different situations, we get a good sample that will minimize the unpredictable. Murphy's law is not a theory. I don't expect that any testing will be 100% effective. But in combination with analysis, it will be *really* close. > >> Which is why real, physical testing of potential problems is needed. >> Otherwise, we knife something based on theory. That would be an even >> greater waste of time. > > no, the greater waste of time is trying to fix problems caused by > irresponsible widespread deployment of poorly-analyzed technology. Um...have you read anything I've written? I said *testing* not *production deployment*. I really fail to understand why you think that testing and analysis are mutually exclusive, and that testing and production are not.. john From owner-zeroconf@merit.edu Thu Aug 29 11:32:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27137 for ; Thu, 29 Aug 2002 11:32:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id BC35E9129E; Thu, 29 Aug 2002 11:34:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8DE11912F4; Thu, 29 Aug 2002 11:34:11 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5C20B9129E for ; Thu, 29 Aug 2002 11:34:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 49D975DE41; Thu, 29 Aug 2002 11:34:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id D63A75DDD1 for ; Thu, 29 Aug 2002 11:34:08 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7TFWl014649; Thu, 29 Aug 2002 11:32:48 -0400 (EDT) Message-Id: <200208291532.g7TFWl014649@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: itojun@iijlab.net Cc: Keith Moore , "John C. Welch" , Zeroconf Subject: Re: non-DNS name services In-reply-to: (Your message of "Fri, 30 Aug 2002 00:18:55 +0900.") <20020829151856.ED7354B22@coconut.itojun.org> Date: Thu, 29 Aug 2002 11:32:47 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > >> Which is why real, physical testing of potential problems is needed. > >> Otherwise, we knife something based on theory. That would be an even > >> greater waste of time. > >no, the greater waste of time is trying to fix problems caused by > >irresponsible widespread deployment of poorly-analyzed technology. > > from the recent measurement results made against lame delegation, TTL > misconfiguration and such, i don't believe DNS behavior is analyzed > well enough (it is still a mistery why it works this well). I'd probably agree. > so if i follow your logic you need to remove DNS from your > infrastructure. you have to type in IP addresses in numeric form :-P no, it doesn't follow. for better or worse, DNS is already deployed, and people depend on it. the fact that DNS is already deployed doesn't justify deploying other things that change how DNS or IP operates, for which there is plenty of reason to suspect that they will break applications, and for which analysis provides no reason to be confident that they will not break applications. Keith From owner-zeroconf@merit.edu Thu Aug 29 12:11:54 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28926 for ; Thu, 29 Aug 2002 12:11:54 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 78BB691208; Thu, 29 Aug 2002 12:13:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 48A849121D; Thu, 29 Aug 2002 12:13:14 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3036091208 for ; Thu, 29 Aug 2002 12:13:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 147845DEA8; Thu, 29 Aug 2002 12:13:13 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 9E62B5DEA6 for ; Thu, 29 Aug 2002 12:13:12 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7TGDB014916; Thu, 29 Aug 2002 12:13:11 -0400 (EDT) Message-Id: <200208291613.g7TGDB014916@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: Zeroconf Subject: Re: non-DNS name services In-reply-to: (Your message of "Thu, 29 Aug 2002 11:32:27 EDT.") <86206679-BB64-11D6-B555-000393D60422@mit.edu> Date: Thu, 29 Aug 2002 12:13:11 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > On Thursday, August 29, 2002, at 11:12 AM, Keith Moore wrote: > > >> I, and a lot of people, simply want *proof* of these problems...yes or > >> no. So far, we haven't been able to test them. All the criticism has > >> been "may" or "could" or "might", but until someone can say "did" and > >> "does", then we *don't know for sure*. > > > > nope. you've got it backwards. when you're trying to standardize > > technologies that change how IP and DNS work - i.e. two of the three > > most critical parts of Internet technology - the burden needs to be on > > the proposers to analyze the risks and persuasively argue that the > > changes you are propsing will not cause harm to existing infrastrucutre > > or applicatoins. mere testing is unpersuasive because it cannot even > > begin to cover the conditions that will be encountered in the real > > world. > > Sigh...so in other words, since you cannot cover 100% of every > situation, then we should sit on our hands and never test anything > again, but rely on the perfect and complete accuracy of theoretical > analysis... No, that's not what I said, and your interpretation of it is unwarranted. But if you can't even interpret plain English text then you are obviously incapble of performing analysis on a technical protocol specification. Hence, further discussion along these lines with you is futile. Keith From owner-zeroconf@merit.edu Thu Aug 29 12:33:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00103 for ; Thu, 29 Aug 2002 12:33:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 16EA89121D; Thu, 29 Aug 2002 12:34:44 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D901C9129E; Thu, 29 Aug 2002 12:34:43 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C48ED9121D for ; Thu, 29 Aug 2002 12:34:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA5045DEA0; Thu, 29 Aug 2002 12:34:42 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 49F9A5DE81 for ; Thu, 29 Aug 2002 12:34:42 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA05278 for ; Thu, 29 Aug 2002 12:34:41 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA25367 for ; Thu, 29 Aug 2002 12:34:41 -0400 (EDT) Received: from HUSTLER.MIT.EDU (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA20238 for ; Thu, 29 Aug 2002 12:34:41 -0400 (EDT) Date: Thu, 29 Aug 2002 12:34:37 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208291613.g7TGDB014916@astro.cs.utk.edu> Message-Id: <35366CA7-BB6D-11D6-8B44-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, August 29, 2002, at 12:13 PM, Keith Moore wrote: >> Sigh...so in other words, since you cannot cover 100% of every >> situation, then we should sit on our hands and never test anything >> again, but rely on the perfect and complete accuracy of theoretical >> analysis... > > No, that's not what I said, and your interpretation of it is > unwarranted. > > But if you can't even interpret plain English text then you are > obviously > incapble of performing analysis on a technical protocol specification. > Hence, further discussion along these lines with you is futile. If people continually misinterpret you, maybe you should make an effort to be more concise and precise in your language. You *said*: "mere testing is unpersuasive because it cannot even begin to cover the conditions that will be encountered in the real world." which of course no one has advocated. you've also *said*: "as for your supposed real-world testing, I don't think MIT can even approach the diversity that exists in the internet. So I'd consider it useless." now, it's not unreasonable to derive from these statements that you seem to think that if you cannot test for *everything* and *anything*, then testing is useless and shouldn't even be attempted. I, nor anyone else has advocated testing without analysis, although you have continually acted as though we have. If you aren't listening to anyone who disagrees with you is saying, then you're right, further discussion is futile. john From owner-zeroconf@merit.edu Thu Aug 29 12:51:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01048 for ; Thu, 29 Aug 2002 12:51:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 19E1391216; Thu, 29 Aug 2002 12:53:02 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D7E9F9129E; Thu, 29 Aug 2002 12:53:01 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CB91C91216 for ; Thu, 29 Aug 2002 12:53:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B001E5DEA8; Thu, 29 Aug 2002 12:53:00 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 46CF35DEA6 for ; Thu, 29 Aug 2002 12:53:00 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7TGqx015068; Thu, 29 Aug 2002 12:52:59 -0400 (EDT) Message-Id: <200208291652.g7TGqx015068@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: Zeroconf Subject: Re: non-DNS name services In-reply-to: (Your message of "Thu, 29 Aug 2002 12:34:37 EDT.") <35366CA7-BB6D-11D6-8B44-000393D60422@mit.edu> Date: Thu, 29 Aug 2002 12:52:59 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > now, it's not unreasonable to derive from these statements that you > seem to think that if you cannot test for *everything* and *anything*, > then testing is useless and shouldn't even be attempted. yes it is unreasonable to derive that, because that's not what was said. what I said was that you need to do analysis about possible failure modes, and that the kinds of tests that are done need to be driven by the analysis - not by merely deploying it somewhere and seeing if it works. something that I didn't say (but which I believe) is that testing can reveal failures that weren't disclosed by analysis, but that the failure of a test to demonstrate a flaw doesn't necessarily mean that the analysis that said there was a flaw was wrong - since you usually can't provide sufficient test coverage. > I, nor anyone else has advocated testing without analysis perhaps not, but I haven't seen any attempt to actually *do* the analysis. Keith From owner-zeroconf@merit.edu Thu Aug 29 12:58:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01615 for ; Thu, 29 Aug 2002 12:58:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 976C19129E; Thu, 29 Aug 2002 12:59:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62C6E912CC; Thu, 29 Aug 2002 12:59:27 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 447769129E for ; Thu, 29 Aug 2002 12:59:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1D99B5DEA8; Thu, 29 Aug 2002 12:59:26 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by segue.merit.edu (Postfix) with ESMTP id 8116A5DEA6 for ; Thu, 29 Aug 2002 12:59:25 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id JAA12053; Thu, 29 Aug 2002 09:59:24 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id g7TGxNM27646; Thu, 29 Aug 2002 09:59:23 -0700 X-mProtect: <200208291659> Nokia Silicon Valley Messaging Protection Received: from UNKNOWN (205.226.2.89, claiming to be "iprg.nokia.com") by darkstar.iprg.nokia.com smtpdSLACz1; Thu, 29 Aug 2002 09:59:21 PDT Message-ID: <3D6E52EA.71CE2197@iprg.nokia.com> Date: Thu, 29 Aug 2002 09:59:22 -0700 From: "Charles E. Perkins" Organization: Nokia Research Center X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "John C. Welch" Cc: Zeroconf Subject: Re: non-DNS name services References: <35366CA7-BB6D-11D6-8B44-000393D60422@mit.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hello John, I've read most of the volumes of discourse on this, trying to see all sides. I'd be interested in your short answers to these questions: - Is there any non-DNS solution that would make sense to you? - Do you agree that name resolution is qualitatively different than service resolution? - Could you imagine changing SLP in some way to fit the needs as you perceive them? If so, then why isn't that a better idea than changing DNS? - Is anyone contending that zeroconf (per se) is itself harmful? I hope not, but some of the messages seem to be ambiguous on this point. My idea on analysis vs. testing, by the way, is that both are crucial. And I thought everyone agreed on that. Unfortunately, it's totally easy to find examples where one or the other was omitted, and success still happened. It's also possible to find examples where one was omitted, and blame consequent failure on that. It's also possible to find examples where analysis indicates "failure" and yet success still happens (maybe NAT as an example), but because somehow the costs shown by analysis are not perceived as outweighing the benefits. Maybe even the costs are cumulative and the customers do not somehow mind until it's too late (consider the parable of the lobster in the cooking pot). The point of this rambling paragraph is that the debate can go on forever without conclusion because both sides have ample evidence that they're correct because they are both close enough to being correct. Regards, Charlie P. "John C. Welch" wrote: > > On Thursday, August 29, 2002, at 12:13 PM, Keith Moore wrote: > > >> Sigh...so in other words, since you cannot cover 100% of every > >> situation, then we should sit on our hands and never test anything > >> again, but rely on the perfect and complete accuracy of theoretical > >> analysis... > > > > No, that's not what I said, and your interpretation of it is > > unwarranted. > > > > But if you can't even interpret plain English text then you are > > obviously > > incapble of performing analysis on a technical protocol specification. > > Hence, further discussion along these lines with you is futile. > > If people continually misinterpret you, maybe you should make an effort > to be more concise and precise in your language. > > You *said*: > > "mere testing is unpersuasive because it cannot even begin to cover the > conditions that will be encountered in the real world." > > which of course no one has advocated. > > you've also *said*: > > "as for your supposed real-world testing, I don't think MIT can even > approach the diversity that exists in the internet. So I'd consider it > useless." > > now, it's not unreasonable to derive from these statements that you > seem to think that if you cannot test for *everything* and *anything*, > then testing is useless and shouldn't even be attempted. > > I, nor anyone else has advocated testing without analysis, although you > have continually acted as though we have. If you aren't listening to > anyone who disagrees with you is saying, then you're right, further > discussion is futile. > > john From owner-zeroconf@merit.edu Thu Aug 29 13:11:24 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02264 for ; Thu, 29 Aug 2002 13:11:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 10BB9912CC; Thu, 29 Aug 2002 13:12:45 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CE3A5912CE; Thu, 29 Aug 2002 13:12:44 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 30D2A912CC for ; Thu, 29 Aug 2002 13:12:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE9615DEA8; Thu, 29 Aug 2002 13:12:41 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id 7ED7A5DEA0 for ; Thu, 29 Aug 2002 13:12:41 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA20152 for ; Thu, 29 Aug 2002 13:12:40 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA01355 for ; Thu, 29 Aug 2002 13:12:40 -0400 (EDT) Received: from HUSTLER.MIT.EDU (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id NAA02792 for ; Thu, 29 Aug 2002 13:12:40 -0400 (EDT) Date: Thu, 29 Aug 2002 13:12:39 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208291652.g7TGqx015068@astro.cs.utk.edu> Message-Id: <85C949E6-BB72-11D6-B3DA-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, August 29, 2002, at 12:52 PM, Keith Moore wrote: >> now, it's not unreasonable to derive from these statements that you >> seem to think that if you cannot test for *everything* and *anything*, >> then testing is useless and shouldn't even be attempted. > > yes it is unreasonable to derive that, because that's not what was > said. > what I said was that you need to do analysis about possible failure > modes, > and that the kinds of tests that are done need to be driven by the > analysis - not by merely deploying it somewhere and seeing if it works. I *never* said "Just deploy it and see if it works". I said test it and see how the analysis really works, and get some real, as opposed to theoretical data. If there's something broke, testing will quickly reveal it, and likely give you a better idea of how to fix it. > > something that I didn't say (but which I believe) is that testing can > reveal > failures that weren't disclosed by analysis, but that the failure of a > test to demonstrate a flaw doesn't necessarily mean that the analysis > that > said there was a flaw was wrong - since you usually can't provide > sufficient > test coverage. Then design a test to beat on a theoretical flaw. If analysis shows a likely problem, you can test for that. > >> I, nor anyone else has advocated testing without analysis > > perhaps not, but I haven't seen any attempt to actually *do* the > analysis. Um...right. Everyone here has just advocated blindly implementing Zeroconf as is, with no testing or analysis whatsoever. john From owner-zeroconf@merit.edu Thu Aug 29 13:26:59 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02817 for ; Thu, 29 Aug 2002 13:26:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 770779129E; Thu, 29 Aug 2002 13:28:20 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4ABAA912CE; Thu, 29 Aug 2002 13:28:20 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2E8089129E for ; Thu, 29 Aug 2002 13:28:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 15FDE5DEAA; Thu, 29 Aug 2002 13:28:19 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id A01455DEA0 for ; Thu, 29 Aug 2002 13:28:18 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id NAA26399 for ; Thu, 29 Aug 2002 13:28:18 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id NAA03642 for ; Thu, 29 Aug 2002 13:28:17 -0400 (EDT) Received: from HUSTLER.MIT.EDU (HUSTLER.MIT.EDU [18.174.0.40]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id NAA07548 for ; Thu, 29 Aug 2002 13:28:17 -0400 (EDT) Date: Thu, 29 Aug 2002 13:28:16 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <3D6E52EA.71CE2197@iprg.nokia.com> Message-Id: X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, August 29, 2002, at 12:59 PM, Charles E. Perkins wrote: > I've read most of the volumes of discourse on this, trying to > see all sides. I'd be interested in your short answers to > these questions: > > - Is there any non-DNS solution that would make sense to you? So far, no. I haven't seen hide nor hair of one that would be implementable across the range of platforms and work in a predicable, usable fashion. > > - Do you agree that name resolution is qualitatively different > than service resolution? It depends on how you look at it. If you mean that service resolution has to return all possible capabilities of a device, then yes. However, if all you want are a list of names of things that do , then not really. And so far, the best, and most useful implementations of service discovery return names of things that print, share files, etc. So, based on that, and the fact that humans look for things by name, not capabilities, then name resolution is the best way to go for service resolution. And we already have a name resolution system, that on paper, is unwieldy, kludgy, limited, yadda, yadda....but, it works, it works well, and I have yet to see any hard data of any sort from any naysayer that shows how Zeroconf is going to somehow globally pooch DNS. I'm going to test it on my own, and see how things actually work. If more people take what little analysis has been done, test that, add to the valid list of what is good and bad, then we will quickly get a valid idea of the way to refine and implement, or not implement Zeroconf. > > - Could you imagine changing SLP in some way to fit the > needs as you perceive them? If so, then why isn't that > a better idea than changing DNS? I first have to imagine an implementation of SLP that isn't so poor as to be unusable., and it has to be usable on more than three platforms. So far, *maybe* Novell has a usable SLP implementation. Apple's is file sharing only and sucks. Sun's is too complex to be taken widely usable, and therefore isn't. It doesn't exist as far as Microsoft is concerned. It's a great protocol, but the designers completely pooched implementation, and in fact, Apple is *dropping* SLP anyway. So none of the two majority desktop systems really support SLP anymore. Maybe if implementation and testing had mattered as much as theory, we wouldn't need to have this argument. As far as SLP itself goes? It's too complicated. It tries to do too much, and in doing so, works really poorly on the platforms that it works at all on. Engineerspeak aside, humans just want a list of printers, servers, etc. near them. Name the printers well, and you're golden. People just want a list of stuff that does what they need with meaningful names. Unless you get that, you are going to be barking up the wrong tree forever. > > - Is anyone contending that zeroconf (per se) is itself > harmful? I hope not, but some of the messages seem to > be ambiguous on this point. some people do. I'm not one of them until I see proof. > > My idea on analysis vs. testing, by the way, is that both > are crucial. And I thought everyone agreed on that. so did I. Evidently, we were wrong. > Unfortunately, it's totally easy to find examples where > one or the other was omitted, and success still happened. > It's also possible to find examples where one was omitted, > and blame consequent failure on that. It's also possible > to find examples where analysis indicates "failure" and > yet success still happens (maybe NAT as an example), but > because somehow the costs shown by analysis are not > perceived as outweighing the benefits. Maybe even > the costs are cumulative and the customers do not somehow > mind until it's too late (consider the parable of the > lobster in the cooking pot). The point of this rambling > paragraph is that the debate can go on forever without > conclusion because both sides have ample evidence that > they're correct because they are both close enough to > being correct. > I just think that any idea that gets to the point where it can be tested should be. Theory is good, analysis is good, but in the end, testing data is still better, and in concert, all three give you the best data. john From owner-zeroconf@merit.edu Thu Aug 29 13:49:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03769 for ; Thu, 29 Aug 2002 13:49:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6CDA8912CE; Thu, 29 Aug 2002 13:51:10 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 35FB0912D1; Thu, 29 Aug 2002 13:51:10 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 24111912CE for ; Thu, 29 Aug 2002 13:51:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 031675DEC8; Thu, 29 Aug 2002 13:51:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 4F6275DEB7 for ; Thu, 29 Aug 2002 13:51:08 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g7THp7m20553 for ; Thu, 29 Aug 2002 10:51:07 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 29 Aug 2002 10:51:06 -0700 Received: from adsl-64-171-18-123.dsl.sntc01.pacbell.net (vpn-gh-1106.apple.com [17.254.140.81]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g7THp5V10942 for ; Thu, 29 Aug 2002 10:51:05 -0700 (PDT) Date: Thu, 29 Aug 2002 10:50:51 -0700 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: Joshua Graessley To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <3D6E52EA.71CE2197@iprg.nokia.com> Message-Id: X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Thursday, August 29, 2002, at 09:59 AM, Charles E. Perkins wrote: > > Hello John, > > I've read most of the volumes of discourse on this, trying to > see all sides. I'd be interested in your short answers to > these questions: > > - Is there any non-DNS solution that would make sense to you? I haven't seen anything else either. Why would we want to invent another protocol to work for an unconfigured network when one that is already out there will work so well? > - Do you agree that name resolution is qualitatively different > than service resolution? DNS stands for Domain Name System right? Was it ever stated that DNS is really just a Domain Host Name System. What is the difference in using DNS to name services in addition to hosts. They're all just named RRs. > - Could you imagine changing SLP in some way to fit the > needs as you perceive them? If so, then why isn't that > a better idea than changing DNS? SLP could be changed, but the degree of change required to make SLP work appears to be a lot more effort that just using what already exists in DNS. In addition, the effort to get SLP deployed appears to be much more work than DNS. DNS doesn't need to change to support finding services, all of the necessary RRs and infrastructure are already there. DNS-NIAS does not require any changes to the DNS protocol, it is just a usage model. There are no additional RRs required. There are no changes required of servers. There are no changes required of the client, though libraries that give application developers a simpler API than res_query would make things a lot easier. It is not at all clear how DNS-NIAS would lead to the meltdown of the internet as one on this list has so passionately argued would happen. > - Is anyone contending that zeroconf (per se) is itself > harmful? I hope not, but some of the messages seem to > be ambiguous on this point. I don't think anyone has said that. > My idea on analysis vs. testing, by the way, is that both > are crucial. And I thought everyone agreed on that. > Unfortunately, it's totally easy to find examples where > one or the other was omitted, and success still happened. > It's also possible to find examples where one was omitted, > and blame consequent failure on that. It's also possible > to find examples where analysis indicates "failure" and > yet success still happens (maybe NAT as an example), but > because somehow the costs shown by analysis are not > perceived as outweighing the benefits. Maybe even > the costs are cumulative and the customers do not somehow > mind until it's too late (consider the parable of the > lobster in the cooking pot). The point of this rambling > paragraph is that the debate can go on forever without > conclusion because both sides have ample evidence that > they're correct because they are both close enough to > being correct. > > Regards, > Charlie P. > > > > "John C. Welch" wrote: >> >> On Thursday, August 29, 2002, at 12:13 PM, Keith Moore wrote: >> >>>> Sigh...so in other words, since you cannot cover 100% of every >>>> situation, then we should sit on our hands and never test anything >>>> again, but rely on the perfect and complete accuracy of theoretical >>>> analysis... >>> >>> No, that's not what I said, and your interpretation of it is >>> unwarranted. >>> >>> But if you can't even interpret plain English text then you are >>> obviously >>> incapble of performing analysis on a technical protocol >>> specification. >>> Hence, further discussion along these lines with you is futile. >> >> If people continually misinterpret you, maybe you should make an >> effort >> to be more concise and precise in your language. >> >> You *said*: >> >> "mere testing is unpersuasive because it cannot even begin to cover >> the >> conditions that will be encountered in the real world." >> >> which of course no one has advocated. >> >> you've also *said*: >> >> "as for your supposed real-world testing, I don't think MIT can even >> approach the diversity that exists in the internet. So I'd consider >> it >> useless." >> >> now, it's not unreasonable to derive from these statements that you >> seem to think that if you cannot test for *everything* and *anything*, >> then testing is useless and shouldn't even be attempted. >> >> I, nor anyone else has advocated testing without analysis, although >> you >> have continually acted as though we have. If you aren't listening to >> anyone who disagrees with you is saying, then you're right, further >> discussion is futile. >> >> john From owner-zeroconf@merit.edu Fri Aug 30 10:32:01 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19003 for ; Fri, 30 Aug 2002 10:32:01 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C7DFD91328; Fri, 30 Aug 2002 10:32:31 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5453091327; Fri, 30 Aug 2002 10:31:48 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A48F89120E for ; Fri, 30 Aug 2002 10:30:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7BCAD5DDC4; Fri, 30 Aug 2002 10:30:21 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.6]) by segue.merit.edu (Postfix) with ESMTP id CF28F5DDCE for ; Fri, 30 Aug 2002 10:30:15 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7UEU5U19274; Fri, 30 Aug 2002 21:30:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7UEQTD03018; Fri, 30 Aug 2002 21:26:39 +0700 (ICT) From: Robert Elz To: itojun@iijlab.net Cc: Keith Moore , "John C. Welch" , Zeroconf Subject: Re: non-DNS name services In-Reply-To: <20020829151856.ED7354B22@coconut.itojun.org> References: <20020829151856.ED7354B22@coconut.itojun.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Aug 2002 21:26:29 +0700 Message-ID: <3016.1030717589@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Fri, 30 Aug 2002 00:18:55 +0900 From: itojun@iijlab.net Message-ID: <20020829151856.ED7354B22@coconut.itojun.org> | from the recent measurement results made against lame delegation, TTL | misconfiguration and such, i don't believe DNS behavior is analyzed | well enough (it is still a mistery why it works this well). Actually, there's no real mystery at all - if you think a little about what is failing, and what is working, and add some knowledge of the DNS design to all of that, it is all blindingly obvious why it works. kre From owner-zeroconf@merit.edu Fri Aug 30 10:33:44 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19095 for ; Fri, 30 Aug 2002 10:33:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B24BE91324; Fri, 30 Aug 2002 10:32:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E1B859120E; Fri, 30 Aug 2002 10:32:37 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id BBA2191324 for ; Fri, 30 Aug 2002 10:30:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A965D5DDB5; Fri, 30 Aug 2002 10:30:46 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.6]) by segue.merit.edu (Postfix) with ESMTP id BFD2C5DDB8 for ; Fri, 30 Aug 2002 10:30:14 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7UEU5U19273; Fri, 30 Aug 2002 21:30:06 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7UEQlD03024; Fri, 30 Aug 2002 21:26:47 +0700 (ICT) From: Robert Elz To: "John C. Welch" Cc: Zeroconf Subject: Re: non-DNS name services In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Aug 2002 21:26:47 +0700 Message-ID: <3022.1030717607@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 29 Aug 2002 13:28:16 -0400 From: "John C. Welch" Message-ID: | I just think that any idea that gets to the point where it can be | tested should be. Theory is good, analysis is good, but in the end, | testing data is still better, and in concert, all three give you the | best data. I think you're missing the point that it is useless to test unless you have some idea what to test for. Basic operation under ordinary circumstances is fine - but also easy. Other than in the wildest circumstances, if someone can look at a protocol and believe it will work (which its author at least generally does) then it is probably close enough that if you just turn in on it will "work". Testing to see that is a waste of time (and you usually get plenty of it anyway, as a side effect, while shaking out implementation bugs, as distinct from protocol bugs). To achieve anything worthwhile, you have to know what to test for. That is, you look at the protocol, and you're suspicious that it doesn't scale well, so you test a very large installation, and see what happens. Or you look at the protocol, and are suspicious that it won't work well if responses are slow, so you stick it on a slow server on a very heavily loaded network, with a long RTT, and see. Or you are suspicious that it won't do well if there's heavy packet loss, so you ... But just "try it and see if it works ok for me" kind of testing is completely useless for our purposes. It is just fine if your aim is to decide whether to use the thing or not yourself, but not if the aim is (as ours is here) to recommend to others that they use it. kre From owner-zeroconf@merit.edu Fri Aug 30 10:33:52 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19112 for ; Fri, 30 Aug 2002 10:33:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1767891323; Fri, 30 Aug 2002 10:32:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A2B2E9120E; Fri, 30 Aug 2002 10:32:24 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 06E1691323 for ; Fri, 30 Aug 2002 10:30:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E8DD35DDC4; Fri, 30 Aug 2002 10:30:23 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from ratree.psu.ac.th (unknown [202.28.97.6]) by segue.merit.edu (Postfix) with ESMTP id 550B35DDB5 for ; Fri, 30 Aug 2002 10:30:18 -0400 (EDT) Received: from delta.cs.mu.OZ.AU (delta.coe.psu.ac.th [172.30.0.98]) by ratree.psu.ac.th (8.11.6/8.11.6) with ESMTP id g7UEUGU19287; Fri, 30 Aug 2002 21:30:16 +0700 (ICT) Received: from munnari.OZ.AU (localhost [127.0.0.1]) by delta.cs.mu.OZ.AU (8.11.6/8.11.6) with ESMTP id g7UEQxD03034; Fri, 30 Aug 2002 21:26:59 +0700 (ICT) From: Robert Elz To: "John C. Welch" Cc: Zeroconf Subject: Re: non-DNS name services In-Reply-To: <477D4A80-BB05-11D6-B2AE-000393D60422@mit.edu> References: <477D4A80-BB05-11D6-B2AE-000393D60422@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 30 Aug 2002 21:26:59 +0700 Message-ID: <3032.1030717619@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 29 Aug 2002 00:10:40 -0400 From: "John C. Welch" Message-ID: <477D4A80-BB05-11D6-B2AE-000393D60422@mit.edu> | well, blasting the idea without a good replacement is a waste of time, | eh? This is total nonsense. If an idea is a poor one, then that is what it is, whether or not there's an alternative. Sometimes, pressing need, and the lack of an alternative might drive one to accept a poor idea. But it is still a poor idea, it doesn't become better just because people are forced into using it. kre From owner-zeroconf@merit.edu Fri Aug 30 10:46:52 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19642 for ; Fri, 30 Aug 2002 10:46:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9B8A09120E; Fri, 30 Aug 2002 10:47:32 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1A332912B5; Fri, 30 Aug 2002 10:47:19 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1559E9120E for ; Fri, 30 Aug 2002 10:46:12 -0400 (EDT) Received: by segue.merit.edu (Postfix) id DE7515DDC0; Fri, 30 Aug 2002 10:46:12 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by segue.merit.edu (Postfix) with ESMTP id A70385DDB5 for ; Fri, 30 Aug 2002 10:46:12 -0400 (EDT) Received: from repligate ([67.37.180.69]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020830144612.JAWH18992.mailhost.chi1.ameritech.net@repligate>; Fri, 30 Aug 2002 09:46:12 -0500 Message-ID: <126001c25034$136e6a80$8c56fea9@repligate> From: "Jim Fleming" To: "Robert Elz" , "John C. Welch" Cc: "Zeroconf" References: <477D4A80-BB05-11D6-B2AE-000393D60422@mit.edu> <3032.1030717619@munnari.OZ.AU> Subject: Re: non-DNS name services Date: Fri, 30 Aug 2002 09:46:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Robert Elz" To: "John C. Welch" Cc: "Zeroconf" Sent: Friday, August 30, 2002 9:26 AM Subject: Re: non-DNS name services > Date: Thu, 29 Aug 2002 00:10:40 -0400 > From: "John C. Welch" > Message-ID: <477D4A80-BB05-11D6-B2AE-000393D60422@mit.edu> > > | well, blasting the idea without a good replacement is a waste of time, > | eh? > > This is total nonsense. If an idea is a poor one, then that is > what it is, whether or not there's an alternative. > > Sometimes, pressing need, and the lack of an alternative might drive > one to accept a poor idea. But it is still a poor idea, it doesn't > become better just because people are forced into using it. > > kre > IPv6 is a good example of that. It can be expensive to blindly accept poor ideas. http://www.iht.com/articles/69229.html PARIS Europe's bold hopes for third-generation mobile-phone services have come crashing down to earth. By one estimate, perhaps half of the licenses that West European companies bought two years ago for fast networks will never be used - meaning $50 billion will have been spent for nothing." ================================ Who pays for bad ideas ? Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt From owner-zeroconf@merit.edu Fri Aug 30 12:27:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24271 for ; Fri, 30 Aug 2002 12:27:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2F9DE91327; Fri, 30 Aug 2002 12:29:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E8C1C91329; Fri, 30 Aug 2002 12:29:15 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id E560E91327 for ; Fri, 30 Aug 2002 12:29:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CD7D35DDC4; Fri, 30 Aug 2002 12:29:14 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 6B69D5DDA7 for ; Fri, 30 Aug 2002 12:29:14 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA10472 for ; Fri, 30 Aug 2002 12:29:13 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA23756 for ; Fri, 30 Aug 2002 12:29:13 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA29929 for ; Fri, 30 Aug 2002 12:29:13 -0400 (EDT) Date: Fri, 30 Aug 2002 11:52:17 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <3032.1030717619@munnari.OZ.AU> Message-Id: <75A78A2A-BC30-11D6-84F7-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Aug 30, 2002, at 10:26 US/Eastern, Robert Elz wrote: > | well, blasting the idea without a good replacement is a waste of > time, > | eh? > > This is total nonsense. If an idea is a poor one, then that is > what it is, whether or not there's an alternative. It doesn't mean a poor idea isn't poor. But if you're going to spend the time to blast away at any idea, then it's far more constructive to spend just as much time trying to come up with a better way to solve the problem. john From owner-zeroconf@merit.edu Fri Aug 30 12:31:42 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24395 for ; Fri, 30 Aug 2002 12:31:41 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 110B091329; Fri, 30 Aug 2002 12:32:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A81189132A; Fri, 30 Aug 2002 12:32:21 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 5AFEF91329 for ; Fri, 30 Aug 2002 12:31:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 35FD25DDC1; Fri, 30 Aug 2002 12:31:40 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id BC60D5DDA7 for ; Fri, 30 Aug 2002 12:31:39 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA10477 for ; Fri, 30 Aug 2002 12:29:14 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA21449 for ; Fri, 30 Aug 2002 12:29:14 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA29934 for ; Fri, 30 Aug 2002 12:29:13 -0400 (EDT) Date: Fri, 30 Aug 2002 11:59:12 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <3022.1030717607@munnari.OZ.AU> Message-Id: <6D7133D8-BC31-11D6-84F7-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Aug 30, 2002, at 10:26 US/Eastern, Robert Elz wrote: > > | I just think that any idea that gets to the point where it can be > | tested should be. Theory is good, analysis is good, but in the end, > | testing data is still better, and in concert, all three give you > the > | best data. > > I think you're missing the point that it is useless to test unless > you have some idea what to test for. Of course...but at the moment, we *do* have things to test for: 1) Interaction with current DNS setups 2) Interaction with current network addressing setups 3) Interaction with current security setups 4) Interaction with current services > > Basic operation under ordinary circumstances is fine - but also easy. > Other than in the wildest circumstances, if someone can look at a > protocol and believe it will work (which its author at least generally > does) then it is probably close enough that if you just turn in on > it will "work". Testing to see that is a waste of time (and you > usually > get plenty of it anyway, as a side effect, while shaking out > implementation > bugs, as distinct from protocol bugs). I've no doubt that you can get basic operation out of anything. You test to see what happens when you beat on it. When you do 'cool' things with it. When you do silly things with it. When you do deliberately stupid things to it. When you let people who *aren't* network geeks at it. > > To achieve anything worthwhile, you have to know what to test for. > That is, you look at the protocol, and you're suspicious that it > doesn't > scale well, so you test a very large installation, and see what > happens. Right. No argument > Or you look at the protocol, and are suspicious that it won't work well > if responses are slow, so you stick it on a slow server on a very > heavily > loaded network, with a long RTT, and see. Or you are suspicious that > it > won't do well if there's heavy packet loss, so you ... Right. No argument. > > But just "try it and see if it works ok for me" kind of testing is > completely useless for our purposes. It is just fine if your aim > is to decide whether to use the thing or not yourself, but not if > the aim is (as ours is here) to recommend to others that they use it. The idea is to get a *lot* of people testing it in different setups, to probe for faults and bugs, to see how it holds up under the infinite varieties of what we call 'normal' use. And *abnormal use*, whatever that means. I'm working to see what happens when you get a *lot* of people banging on it, how well it holds up, what the network does, etc. there are already very obvious things to test for, and as the analysis continues, we'll get more things to test for. And Zeroconf will either become better, or it will be obvious that it isn't going to work. But you won't know for sure with *just* testing, or *just* analysis. You *have* to have both. john From owner-zeroconf@merit.edu Fri Aug 30 12:37:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24598 for ; Fri, 30 Aug 2002 12:37:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7C8409132B; Fri, 30 Aug 2002 12:38:31 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 49B2F9132C; Fri, 30 Aug 2002 12:38:31 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 464429132B for ; Fri, 30 Aug 2002 12:38:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 330525DDC1; Fri, 30 Aug 2002 12:38:30 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from www.mediatonic.com (64-204-129-69.client.dsl.net [64.204.129.69]) by segue.merit.edu (Postfix) with ESMTP id 8BA045DDA7 for ; Fri, 30 Aug 2002 12:38:29 -0400 (EDT) Received: from 64-204-129-68.client.dsl.net (64-204-129-68.client.dsl.net [64.204.129.68]) by www.mediatonic.com (8.10.2/8.10.2) with ESMTP id g7UGcSX09267 for ; Fri, 30 Aug 2002 09:38:28 -0700 (PDT) Date: Fri, 30 Aug 2002 09:38:30 -0700 Subject: Slightly OT: Apple to Release Source Code to its zeroconf implementation Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: james mcmurry To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <6D7133D8-BC31-11D6-84F7-000393D60422@mit.edu> Message-Id: X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Very great idea ! This will help everyone to understand zeroconf more! http://maccentral.macworld.com/news/0208/29.rendezvous.php From owner-zeroconf@merit.edu Fri Aug 30 13:02:53 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25719 for ; Fri, 30 Aug 2002 13:02:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2C7D09132B; Fri, 30 Aug 2002 13:03:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CFECD91327; Fri, 30 Aug 2002 13:03:40 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6A0709120E for ; Fri, 30 Aug 2002 13:01:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4050A5DDCE; Fri, 30 Aug 2002 13:01:44 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by segue.merit.edu (Postfix) with ESMTP id BE0E15DDA7 for ; Fri, 30 Aug 2002 13:01:43 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id g7UH1Y3x027536; Fri, 30 Aug 2002 10:01:34 -0700 (PDT) Received: from JSCHNIZL-W2K1.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id g7UH1Z8k000744; Fri, 30 Aug 2002 10:01:36 -0700 (PDT) Message-Id: <4.3.2.7.2.20020830125315.018931a0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 30 Aug 2002 13:01:32 -0400 To: james mcmurry From: John Schnizlein Subject: Re: Slightly OT: Apple to Release Source Code to its zeroconf implementation Cc: Zeroconf In-Reply-To: References: <6D7133D8-BC31-11D6-84F7-000393D60422@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-zeroconf@merit.edu Precedence: bulk Thank you for bringing this to our attention. There are several problems with this text. ZeroConf is not a standard (yet). This language is not consistent with the fact that the IETF is not composed of company representatives, but individual contributors. How can it be "first documented" when there is no RFC yet? Internet Drafts are explicitly not to be referenced. Rendezvous is Apple's implementation of the ZeroConf standard documented by the Internet Engineering Task Force (IETF), the group responsible for defining Internet standards. First documented in the late 1990s by the IETF and sponsored by Apple, Rendezvous is a zero configuration technology that brings together Internet IP standards and LAN networks. At 12:38 PM 8/30/2002, james mcmurry wrote: >Very great idea ! > >This will help everyone to understand zeroconf more! > >http://maccentral.macworld.com/news/0208/29.rendezvous.php From owner-zeroconf@merit.edu Fri Aug 30 13:11:36 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26075 for ; Fri, 30 Aug 2002 13:11:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 91BB09120E; Fri, 30 Aug 2002 13:12:56 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6166D91327; Fri, 30 Aug 2002 13:12:56 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 4AF199120E for ; Fri, 30 Aug 2002 13:12:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2999A5DDD0; Fri, 30 Aug 2002 13:12:55 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by segue.merit.edu (Postfix) with ESMTP id 105635DDA7 for ; Fri, 30 Aug 2002 13:12:55 -0400 (EDT) Received: from repligate ([67.37.180.69]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020830171254.MOLO18992.mailhost.chi1.ameritech.net@repligate>; Fri, 30 Aug 2002 12:12:54 -0500 Message-ID: <136c01c25048$9277fe40$8c56fea9@repligate> From: "Jim Fleming" To: "james mcmurry" , "John Schnizlein" Cc: "Zeroconf" , References: <6D7133D8-BC31-11D6-84F7-000393D60422@mit.edu> <4.3.2.7.2.20020830125315.018931a0@wells.cisco.com> Subject: Re: Slightly OT: Apple to Release Source Code to its zeroconf implementation Date: Fri, 30 Aug 2002 12:13:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "John Schnizlein" > > This language is not consistent with the fact that the IETF is not > composed of company representatives, but individual contributors. > http://www.ietf.org "The IETF is an organized activity of the Internet Society" ...the Internet Society is a company...it has "company representatives"... http://www.icann.org/announcements/announcement-19aug02.htm "We received eleven very strong and thoughtful proposals," noted Stuart Lynn, President of ICANN. "We appreciate the response of the institutions behind these proposals. The ISOC proposal was the only one that received top ranking from all three evaluation teams. ==== The ISOC plans to be a Registry.....Apple is a Registry.....both are companies.... http://www.iana.org/assignments/ipv4-address-space 017/8 Apple Computer Inc. Jul 92 ==== http://maccentral.macworld.com/news/0208/29.rendezvous.php Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt P.S. CISCO is a company.... From owner-zeroconf@merit.edu Fri Aug 30 13:21:55 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26493 for ; Fri, 30 Aug 2002 13:21:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E7CBF91327; Fri, 30 Aug 2002 13:23:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AAD3B9132D; Fri, 30 Aug 2002 13:23:15 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9B38691327 for ; Fri, 30 Aug 2002 13:23:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 79D985DDD0; Fri, 30 Aug 2002 13:23:14 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 123095DDA7 for ; Fri, 30 Aug 2002 13:23:14 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7UHNB014441; Fri, 30 Aug 2002 13:23:11 -0400 (EDT) Message-Id: <200208301723.g7UHNB014441@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: james mcmurry Cc: Zeroconf Subject: Re: Slightly OT: Apple to Release Source Code to its zeroconf implementation In-reply-to: (Your message of "Fri, 30 Aug 2002 09:38:30 PDT.") Date: Fri, 30 Aug 2002 13:23:11 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > Very great idea ! very bad idea - this will propagate buggy protocols that isn't yet up to standards-track quality. actually I have no problem with distributing code for use on an experimental basis as long as people are aware that the protocols are subject to change - I think it's very unfortunate that this code is in shipping production products. Keith From owner-zeroconf@merit.edu Fri Aug 30 13:26:11 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26619 for ; Fri, 30 Aug 2002 13:26:09 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CF8BE9132D; Fri, 30 Aug 2002 13:27:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9AC1A9132E; Fri, 30 Aug 2002 13:27:18 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 838609132D for ; Fri, 30 Aug 2002 13:27:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 604375DDA7; Fri, 30 Aug 2002 13:27:16 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by segue.merit.edu (Postfix) with ESMTP id 264A85DDD4 for ; Fri, 30 Aug 2002 13:27:16 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.104]) by gnat.inet.org (Postfix) with ESMTP id 442C367103; Fri, 30 Aug 2002 09:41:46 -0400 (EDT) Date: Fri, 30 Aug 2002 13:27:07 -0400 Subject: Re: Slightly OT: Apple Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: Zeroconf To: Keith Moore From: RJ Atkinson In-Reply-To: <200208301723.g7UHNB014441@astro.cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Aug 30, 2002, at 13:23 America/Montreal, Keith Moore wrote: > I think it's very unfortunate that this code > is in shipping production products. Since it works just fine, I'm sure glad that it is running in my laptop today (and not at some future decade when IETF gets its process unwedged)... Oh, and Apple is to be commended for making their source code available. Thanks also to Stuart Cheshire, who no doubt had some hand in this happening... Cheers, Ran From owner-zeroconf@merit.edu Fri Aug 30 13:28:30 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26692 for ; Fri, 30 Aug 2002 13:28:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2A16B9132E; Fri, 30 Aug 2002 13:29:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E56969132F; Fri, 30 Aug 2002 13:29:35 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id CFA029132E for ; Fri, 30 Aug 2002 13:29:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B82EB5DDD0; Fri, 30 Aug 2002 13:29:34 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 507815DDA7 for ; Fri, 30 Aug 2002 13:29:34 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7UHTX014461; Fri, 30 Aug 2002 13:29:33 -0400 (EDT) Message-Id: <200208301729.g7UHTX014461@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: Zeroconf Subject: Re: non-DNS name services In-reply-to: (Your message of "Fri, 30 Aug 2002 11:52:17 EDT.") <75A78A2A-BC30-11D6-84F7-000393D60422@mit.edu> Date: Fri, 30 Aug 2002 13:29:33 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > It doesn't mean a poor idea isn't poor. But if you're going to spend > the time to blast away at any idea, then it's far more constructive to > spend just as much time trying to come up with a better way to solve > the problem. a bit of analysis shows that that's not necessarily true. if a proposal will do harm if propagated, then any effort which results in minimizing and/or delaying the harm done is well spent. on the other hand, a half-baked competing proposal - even one which has the kernel of a better idea buried in it - is often little better than no proposal. sometimes it is worse, because an apparently-complete proposal (even if it is based on a bad idea) may seem to compare favorably with an incomplete one (even if it is based on a good idea). this is usually a fallacy based on failure to compare both proposals with respect to the same set of requirements, but it's a mistake that is commonly made. Keith From owner-zeroconf@merit.edu Fri Aug 30 13:32:57 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26928 for ; Fri, 30 Aug 2002 13:32:57 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 72C099132F; Fri, 30 Aug 2002 13:33:39 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AEEB391330; Fri, 30 Aug 2002 13:33:36 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 72DF99132F for ; Fri, 30 Aug 2002 13:32:59 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 422C55DDA7; Fri, 30 Aug 2002 13:32:59 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id BE17F5DDD0 for ; Fri, 30 Aug 2002 13:32:58 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7UHWv014484; Fri, 30 Aug 2002 13:32:57 -0400 (EDT) Message-Id: <200208301732.g7UHWv014484@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: "John C. Welch" Cc: Zeroconf Subject: Re: non-DNS name services In-reply-to: (Your message of "Fri, 30 Aug 2002 11:59:12 EDT.") <6D7133D8-BC31-11D6-84F7-000393D60422@mit.edu> Date: Fri, 30 Aug 2002 13:32:57 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > But you won't know for sure with *just* testing, or *just* analysis. > You *have* to have both. but you do not need to have all of your analysis verified by testing, or vice versa. analysis and testing tend to cover different cases - you learn from each of them, but you can only use one to verify the other when they overlap. for instance, there's no practical way to test the effect of zeroconf protocols on the wide variety of applications and wide variety of network configurations that are out there. the most test coverage you can hope for is to try it with the applications you use normally and on a few specific network configurations. that's not even a drop in the bucket. From owner-zeroconf@merit.edu Fri Aug 30 13:33:25 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26956 for ; Fri, 30 Aug 2002 13:33:24 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 136AB91330; Fri, 30 Aug 2002 13:34:46 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D0C2991331; Fri, 30 Aug 2002 13:34:45 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8A40C91330 for ; Fri, 30 Aug 2002 13:34:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6E9955DDD0; Fri, 30 Aug 2002 13:34:44 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 065105DDA7 for ; Fri, 30 Aug 2002 13:34:44 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7UHYd014501; Fri, 30 Aug 2002 13:34:39 -0400 (EDT) Message-Id: <200208301734.g7UHYd014501@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: RJ Atkinson Cc: Keith Moore , Zeroconf Subject: Re: Slightly OT: Apple In-reply-to: (Your message of "Fri, 30 Aug 2002 13:27:07 EDT.") Date: Fri, 30 Aug 2002 13:34:39 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > I think it's very unfortunate that this code > > is in shipping production products. > > Since it works just fine, I'm sure glad that it is > running in my laptop today (and not at some future decade > when IETF gets its process unwedged)... ah, but it *doesn't* work just fine - it just hasn't broken when you tried it - at least not in a way that you noticed. I do appreciate their giving the code away - it makes it more likely that there will be free implementations of the fixed version of zeroconf once we get the protocols fixed. The problem is in misleading the public that this is a robust protocol. Keith From owner-zeroconf@merit.edu Fri Aug 30 13:35:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27029 for ; Fri, 30 Aug 2002 13:35:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0EF9891336; Fri, 30 Aug 2002 13:36:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CA47291335; Fri, 30 Aug 2002 13:36:29 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 862E191334 for ; Fri, 30 Aug 2002 13:36:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5F9CA5DDD0; Fri, 30 Aug 2002 13:36:24 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from www.mediatonic.com (64-204-129-69.client.dsl.net [64.204.129.69]) by segue.merit.edu (Postfix) with ESMTP id B06E35DDA7 for ; Fri, 30 Aug 2002 13:36:23 -0400 (EDT) Received: from 64-204-129-68.client.dsl.net (64-204-129-68.client.dsl.net [64.204.129.68]) by www.mediatonic.com (8.10.2/8.10.2) with ESMTP id g7UHaMX09457 for ; Fri, 30 Aug 2002 10:36:22 -0700 (PDT) Date: Fri, 30 Aug 2002 10:36:24 -0700 Subject: Re: Slightly OT: Apple Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: james mcmurry To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <012523CF-BC3F-11D6-A7A6-000393681A12@mediatonic.com> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit I think this is a great experiment that the zeroconf group should follow. Think of it, suddenly there is a base of over 100,000 (Apple Press Release on monday stating they had sold 100,000 copies over the weekend, not counting the sell out of 10.2 in England) users who have this implementation of zeroconf running on their systems. Granted not everyone will be using it immediately, but they will over time. I think Apple, by releasing their source code, is making a gesture that they want a speedier process, and want others (like printer manufacturers) to get up to speed quicker. Now Keith may think this is a very BAD idea, I know. Keith is very important in this process, you always need a Keith around to be the real Devils-Advocate to ensure we really dont do anything stupid. But in the end, you need to draw a line in the sand, and jump.......good bad, right or wrong..... Jim On Friday, August 30, 2002, at 10:27 AM, RJ Atkinson wrote: > > On Friday, Aug 30, 2002, at 13:23 America/Montreal, Keith Moore wrote: >> I think it's very unfortunate that this code >> is in shipping production products. > > Since it works just fine, I'm sure glad that it is > running in my laptop today (and not at some future decade > when IETF gets its process unwedged)... > > Oh, and Apple is to be commended for making their > source code available. Thanks also to Stuart Cheshire, > who no doubt had some hand in this happening... > > Cheers, > > Ran > From owner-zeroconf@merit.edu Fri Aug 30 13:35:22 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27048 for ; Fri, 30 Aug 2002 13:35:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 01A9091333; Fri, 30 Aug 2002 13:36:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BCF7591334; Fri, 30 Aug 2002 13:36:20 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 96F3E91333 for ; Fri, 30 Aug 2002 13:36:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 78B185DDD0; Fri, 30 Aug 2002 13:36:19 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by segue.merit.edu (Postfix) with ESMTP id 55C685DDA7 for ; Fri, 30 Aug 2002 13:36:19 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.104]) by gnat.inet.org (Postfix) with ESMTP id EC8B167103; Fri, 30 Aug 2002 09:50:54 -0400 (EDT) Date: Fri, 30 Aug 2002 13:36:15 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: "John C. Welch" , Zeroconf To: Keith Moore From: RJ Atkinson In-Reply-To: <200208301729.g7UHTX014461@astro.cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Keith, If you'd spent the time doing analysis this week, instead of blathering on the wrong IETF mailing list, you might have actually been able to generate a list of technical problems you perceive. Its rather a pity that you preferred to send high volumes of repetitive non-technical email rather than spend the time doing the analysis you seem to think is required. Sigh. Ran From owner-zeroconf@merit.edu Fri Aug 30 13:38:27 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27171 for ; Fri, 30 Aug 2002 13:38:26 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F1DC491331; Fri, 30 Aug 2002 13:39:47 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B6E3A91334; Fri, 30 Aug 2002 13:39:46 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A955D91331 for ; Fri, 30 Aug 2002 13:39:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 935F95DDD0; Fri, 30 Aug 2002 13:39:45 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by segue.merit.edu (Postfix) with ESMTP id 7A3F05DDA7 for ; Fri, 30 Aug 2002 13:39:45 -0400 (EDT) Received: from repligate ([67.37.180.69]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020830173945.NEVR18992.mailhost.chi1.ameritech.net@repligate>; Fri, 30 Aug 2002 12:39:45 -0500 Message-ID: <13e201c2504c$526dcf60$8c56fea9@repligate> From: "Jim Fleming" To: "james mcmurry" , "Zeroconf" References: Subject: Re: Slightly OT: Apple to Release Source Code to its zeroconf implementation Date: Fri, 30 Aug 2002 12:40:24 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "james mcmurry" To: "Zeroconf" Sent: Friday, August 30, 2002 11:38 AM Subject: Slightly OT: Apple to Release Source Code to its zeroconf implementation > Very great idea ! > > > This will help everyone to understand zeroconf more! > > http://maccentral.macworld.com/news/0208/29.rendezvous.php > > Should we release the C@t ? http://www.ddj.com/articles/1993/9310/ http://maccentral.macworld.com/news/0208/25.jaguar.php Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt From owner-zeroconf@merit.edu Fri Aug 30 13:41:38 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27370 for ; Fri, 30 Aug 2002 13:41:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id ACC8091334; Fri, 30 Aug 2002 13:42:57 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7E14591335; Fri, 30 Aug 2002 13:42:57 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8CDA291334 for ; Fri, 30 Aug 2002 13:42:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7CC565DDD4; Fri, 30 Aug 2002 13:42:56 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by segue.merit.edu (Postfix) with ESMTP id 55BDD5DDA7 for ; Fri, 30 Aug 2002 13:42:56 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.104]) by gnat.inet.org (Postfix) with ESMTP id 1361867103; Fri, 30 Aug 2002 09:57:31 -0400 (EDT) Date: Fri, 30 Aug 2002 13:42:51 -0400 Subject: Re: Slightly OT: Apple Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: Zeroconf To: Keith Moore From: RJ Atkinson In-Reply-To: <200208301734.g7UHYd014501@astro.cs.utk.edu> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Aug 30, 2002, at 13:34 America/Montreal, Keith Moore wrote: > ah, but it *doesn't* work just fine Keith, Please send a formal proof that it is broken. Until then, I will continue to believe that you have NO DATA, NO ANALYSIS, and NO CLUE what you are blathering about. No amount of ongoing random whiney non-substantive email from you is going to change what the rest of the world thinks. You get no points for volume of irrelevant email either. Ran rja@extremenetworks.com From owner-zeroconf@merit.edu Fri Aug 30 13:43:06 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27450 for ; Fri, 30 Aug 2002 13:43:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A888A91335; Fri, 30 Aug 2002 13:44:29 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 73BE791337; Fri, 30 Aug 2002 13:44:29 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6002D91335 for ; Fri, 30 Aug 2002 13:44:28 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4EEB55DDD4; Fri, 30 Aug 2002 13:44:28 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 265045DDA7 for ; Fri, 30 Aug 2002 13:44:23 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7UHiI014534; Fri, 30 Aug 2002 13:44:18 -0400 (EDT) Message-Id: <200208301744.g7UHiI014534@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ X-PGP-Key: 2F07A741 ; 78 15 8E 8B C0 06 5D D1 BC 08 05 7F 42 81 7E 90 To: iesg@ietf.org, iab@iab.org Cc: Zeroconf Subject: hypocrisy of zeroconf From: Keith Moore Date: Fri, 30 Aug 2002 13:44:17 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk you know, if I said "hey, I've got an idea for a new TCP extension that allows it to optimize for short request/replys in two packets" then I *know* I'd get serious pushback on that because it's been known (via analysis) for decades that you need at least five packets to do that reliably - at least, for the set of assumptions in which TCP is expected to operate. arguments of the form "hey, it works when I try it" would fall on deaf ears - I'd be expected to either provide proof that the earlier work was incorrect or to show that I'm exploiting a useful case for which the original analysis did not apply. And I'd consider that entirely reasonable. on the other hand, when the zeroconf folks say "hey, we can redefine IP to work differently than applications expect, and we can also redefine DNS to work differently than applications expect, and it won't break anything - we tried it and it works for us!" then people say "hey, what a wonderful thing this is! isn't it nice that [vendor] is shipping it in product without bothering to do either analysis of the probable failure modes or waiting for the bugs to be worked out!" Keith From owner-zeroconf@merit.edu Fri Aug 30 13:48:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27686 for ; Fri, 30 Aug 2002 13:48:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F19CD91339; Fri, 30 Aug 2002 13:49:08 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6503491338; Fri, 30 Aug 2002 13:49:05 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 61E0A9133A for ; Fri, 30 Aug 2002 13:47:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 40F005DDD0; Fri, 30 Aug 2002 13:47:29 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id C8C825DDA7 for ; Fri, 30 Aug 2002 13:47:28 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7UHlQ014565; Fri, 30 Aug 2002 13:47:26 -0400 (EDT) Message-Id: <200208301747.g7UHlQ014565@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: RJ Atkinson Cc: Keith Moore , Zeroconf Subject: Re: Slightly OT: Apple In-reply-to: (Your message of "Fri, 30 Aug 2002 13:42:51 EDT.") Date: Fri, 30 Aug 2002 13:47:26 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk Ran, > Please send a formal proof that it is broken. that's essentially what they said about the Tacoma Narrows Bridge - we don't believe your wind analysis because you can't formally prove it. From owner-zeroconf@merit.edu Fri Aug 30 13:48:23 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27706 for ; Fri, 30 Aug 2002 13:48:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 180AE91337; Fri, 30 Aug 2002 13:47:00 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4D75591338; Fri, 30 Aug 2002 13:46:25 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id F083F91337 for ; Fri, 30 Aug 2002 13:46:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C4B795DDD0; Fri, 30 Aug 2002 13:46:20 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 5C12A5DDA7 for ; Fri, 30 Aug 2002 13:46:20 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7UHkG014551; Fri, 30 Aug 2002 13:46:16 -0400 (EDT) Message-Id: <200208301746.g7UHkG014551@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: RJ Atkinson Cc: Keith Moore , "John C. Welch" , Zeroconf Subject: Re: non-DNS name services In-reply-to: (Your message of "Fri, 30 Aug 2002 13:36:15 EDT.") Date: Fri, 30 Aug 2002 13:46:16 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk Ran, As I've said repeatedly I'm working on analysis of mDNS, but it's extremely time-consuming. Furthermore, when members of this group clearly indicate that they're not capable of understanding analysis, that seems like a good indication that the analysis is a waste of time - at least for this audience. Keith From owner-zeroconf@merit.edu Fri Aug 30 13:51:23 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27816 for ; Fri, 30 Aug 2002 13:51:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id F2CCD91338; Fri, 30 Aug 2002 13:52:44 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B5EAE9133A; Fri, 30 Aug 2002 13:52:43 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C8B9691338 for ; Fri, 30 Aug 2002 13:52:42 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AF4595DDDD; Fri, 30 Aug 2002 13:52:42 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from e35.co.us.ibm.com (e35.co.us.ibm.com [32.97.110.133]) by segue.merit.edu (Postfix) with ESMTP id 01B145DDDC for ; Fri, 30 Aug 2002 13:52:41 -0400 (EDT) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e35.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id g7UHq3BA020972; Fri, 30 Aug 2002 13:52:04 -0400 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g7UHq2xh199910; Fri, 30 Aug 2002 11:52:02 -0600 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g7UHmrc07780; Fri, 30 Aug 2002 13:48:53 -0400 Message-Id: <200208301748.g7UHmrc07780@rotala.raleigh.ibm.com> To: Keith Moore Cc: iesg@ietf.org, iab@iab.org, Zeroconf Subject: Re: hypocrisy of zeroconf In-Reply-To: Message from "Fri, 30 Aug 2002 13:44:17 EDT." <200208301744.g7UHiI014534@astro.cs.utk.edu> Date: Fri, 30 Aug 2002 13:48:53 -0400 From: Thomas Narten Sender: owner-zeroconf@merit.edu Precedence: bulk Keith, If you're going to send mail to the iab/iesg, you might want to at least include context so folk there know what it is you are complaining about and perhaps also indicate what should be done instead. I suspect that most folk who read your note will recognize that you are unhappy, but not have the foggiest why. (Truth-in-advertising: I've been following the discussions on zeroconf and am not completely sure what your specific issue is and I'd rather not be guessing, given the range of discussion that has been taking place.) Thomas From owner-zeroconf@merit.edu Fri Aug 30 13:55:17 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27966 for ; Fri, 30 Aug 2002 13:55:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6B86E9133A; Fri, 30 Aug 2002 13:56:37 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 329DC9133B; Fri, 30 Aug 2002 13:56:37 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 1AE1A9133A for ; Fri, 30 Aug 2002 13:56:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id EE2CE5DDD0; Fri, 30 Aug 2002 13:56:35 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by segue.merit.edu (Postfix) with ESMTP id CC08F5DDA7 for ; Fri, 30 Aug 2002 13:56:35 -0400 (EDT) Received: from repligate ([67.37.180.69]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020830175635.NNPM18992.mailhost.chi1.ameritech.net@repligate> for ; Fri, 30 Aug 2002 12:56:35 -0500 Message-ID: <143101c2504e$acbddb70$8c56fea9@repligate> From: "Jim Fleming" To: References: <200208301734.g7UHYd014501@astro.cs.utk.edu> Subject: Has the public been mislead...? Date: Fri, 30 Aug 2002 12:57:14 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Keith Moore" To: "RJ Atkinson" Cc: "Keith Moore" ; "Zeroconf" Sent: Friday, August 30, 2002 12:34 PM Subject: Re: Slightly OT: Apple > > > I think it's very unfortunate that this code > > > is in shipping production products. > > > > Since it works just fine, I'm sure glad that it is > > running in my laptop today (and not at some future decade > > when IETF gets its process unwedged)... > > ah, but it *doesn't* work just fine - it just hasn't broken when > you tried it - at least not in a way that you noticed. > > I do appreciate their giving the code away - it makes it more likely > that there will be free implementations of the fixed version of zeroconf > once we get the protocols fixed. The problem is in misleading the public > that this is a robust protocol. > Has the public been mislead about how robust IPv6 is ? Has anyone seen how many changes have to be made to the BSD version of 6to4 to make it robust ? Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... Have you tried ?....2911: ?...or next year's version ?...2003: ?...or 3911: ? http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.ethereal.com http://www.netfilter.org From owner-zeroconf@merit.edu Fri Aug 30 13:57:37 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28088 for ; Fri, 30 Aug 2002 13:57:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 50DF09133B; Fri, 30 Aug 2002 13:58:57 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1C04F9133C; Fri, 30 Aug 2002 13:58:57 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 024249133B for ; Fri, 30 Aug 2002 13:58:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E01305DDD5; Fri, 30 Aug 2002 13:58:55 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from www.mediatonic.com (64-204-129-69.client.dsl.net [64.204.129.69]) by segue.merit.edu (Postfix) with ESMTP id 436F75DDD4 for ; Fri, 30 Aug 2002 13:58:55 -0400 (EDT) Received: from 64-204-129-68.client.dsl.net (64-204-129-68.client.dsl.net [64.204.129.68]) by www.mediatonic.com (8.10.2/8.10.2) with ESMTP id g7UHwsX09587 for ; Fri, 30 Aug 2002 10:58:54 -0700 (PDT) Date: Fri, 30 Aug 2002 10:58:56 -0700 Subject: Re: Slightly OT: Apple Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: james mcmurry To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208301747.g7UHlQ014565@astro.cs.utk.edu> Message-Id: <2728D526-BC42-11D6-B664-000393681A12@mediatonic.com> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Well, Yes and No... http://www.failuremag.com/arch_science_tacomanarrows.html Jim (disclaimer - I actually worked for 3 years at Failure Analysis Associates......) On Friday, August 30, 2002, at 10:47 AM, Keith Moore wrote: > Ran, > >> Please send a formal proof that it is broken. > > that's essentially what they said about the Tacoma Narrows Bridge - > we don't believe your wind analysis because you can't formally prove > it. > From owner-zeroconf@merit.edu Fri Aug 30 14:18:07 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28980 for ; Fri, 30 Aug 2002 14:18:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6BE4291327; Fri, 30 Aug 2002 14:16:20 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C1A2D9132F; Fri, 30 Aug 2002 14:16:16 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 05FE191327 for ; Fri, 30 Aug 2002 14:16:13 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D205F5DDD4; Fri, 30 Aug 2002 14:16:13 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id 663835DDCE for ; Fri, 30 Aug 2002 14:16:13 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7UIG4014649; Fri, 30 Aug 2002 14:16:04 -0400 (EDT) Message-Id: <200208301816.g7UIG4014649@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Thomas Narten Cc: Keith Moore , iesg@ietf.org, iab@iab.org, Zeroconf Subject: Re: hypocrisy of zeroconf In-reply-to: (Your message of "Fri, 30 Aug 2002 13:48:53 EDT.") <200208301748.g7UHmrc07780@rotala.raleigh.ibm.com> Date: Fri, 30 Aug 2002 14:16:04 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > If you're going to send mail to the iab/iesg, you might want to at > least include context so folk there know what it is you are > complaining about and perhaps also indicate what should be done > instead. noted. I had hoped IESG would be more up on this WG especially since it's trying to change the behavior of fundamental pieces of Internet infrastructure, but I certainly recognize that IESG folks never have enough time to cover everything that deserves scrutiny. unfortunately I don't know how to include context without going into lots of detail which is going to take more time both to write and to read, and is going to have to wait until at least next week. Keith From owner-zeroconf@merit.edu Fri Aug 30 14:20:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29060 for ; Fri, 30 Aug 2002 14:19:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6ADE791324; Fri, 30 Aug 2002 14:21:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 361AB9132B; Fri, 30 Aug 2002 14:21:21 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3295491324 for ; Fri, 30 Aug 2002 14:21:20 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 13F3F5DDD4; Fri, 30 Aug 2002 14:21:20 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 89F425DDCE for ; Fri, 30 Aug 2002 14:21:19 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g7UILJm04018 for ; Fri, 30 Aug 2002 11:21:19 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 30 Aug 2002 11:21:18 -0700 Received: from graejo.apple.com (graejo.apple.com [17.202.40.111]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g7UILI323430 for ; Fri, 30 Aug 2002 11:21:18 -0700 (PDT) Date: Fri, 30 Aug 2002 11:21:02 -0700 Subject: Re: hypocrisy of zeroconf Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: Joshua Graessley To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208301744.g7UHiI014534@astro.cs.utk.edu> Message-Id: <3D5C009A-BC45-11D6-BE61-000393760260@apple.com> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, August 30, 2002, at 10:44 AM, Keith Moore wrote: > on the other hand, when the zeroconf folks say "hey, we can redefine > IP to work differently than applications expect, and we can also > redefine > DNS to work differently than applications expect, and it won't break > anything - we tried it and it works for us!" then people say > "hey, what a wonderful thing this is! isn't it nice that [vendor] is > shipping it in product without bothering to do either analysis of the > probable failure modes or waiting for the bugs to be worked out!" Still blathering by my measure. There is nothing about the zeroconf proposals that "redefines IP to work differently than applications expect". An application that uses IP can continue to transparently do so with an IPv4 link local address without knowing the difference. Using a link-local IPv4 address does not change anything. It does create problems when using a multihomed host but most of those problems can be solved in the IP stack. The only problem that can't be solved in the stack is the ambiguity of an IPv4 link local address that may exist on more than one interface. This can also be a problem with the use of private network address ranges. So does the benefit of using IPv4 link-local addresses outweigh the risks that people will have problems with multihoming? I think so. You keep claiming that we're trying to "redefine DNS to work differently than applications expect". There are APIs that applications uses to access DNS, usually for the purpose of resolving a name to an address or an address to a name. Most applications know nothing about the actual implementation of DNS. Does an application care if a recursive query is done? No. Why should it care if a query is sent to the multicast address instead of a unicast address? -josh From owner-zeroconf@merit.edu Fri Aug 30 14:20:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29104 for ; Fri, 30 Aug 2002 14:20:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 456E69132B; Fri, 30 Aug 2002 14:22:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14B379132F; Fri, 30 Aug 2002 14:22:18 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 298F29132B for ; Fri, 30 Aug 2002 14:22:17 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 166D55DDD4; Fri, 30 Aug 2002 14:22:17 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id 39C255DDCE for ; Fri, 30 Aug 2002 14:22:12 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g7UIMBm04142 for ; Fri, 30 Aug 2002 11:22:11 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 30 Aug 2002 11:22:11 -0700 Received: from graejo.apple.com (graejo.apple.com [17.202.40.111]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g7UIMA323917 for ; Fri, 30 Aug 2002 11:22:10 -0700 (PDT) Date: Fri, 30 Aug 2002 11:21:54 -0700 Subject: Re: Slightly OT: Apple Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: Joshua Graessley To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208301747.g7UHlQ014565@astro.cs.utk.edu> Message-Id: <5C8833A2-BC45-11D6-BE61-000393760260@apple.com> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, August 30, 2002, at 10:47 AM, Keith Moore wrote: > Ran, > >> Please send a formal proof that it is broken. > > that's essentially what they said about the Tacoma Narrows Bridge - > we don't believe your wind analysis because you can't formally prove > it. So Keith, What is your wind analysis? -josh From owner-zeroconf@merit.edu Fri Aug 30 14:25:56 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29395 for ; Fri, 30 Aug 2002 14:25:56 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id CFA2A9132F; Fri, 30 Aug 2002 14:27:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A0D8C9133C; Fri, 30 Aug 2002 14:27:16 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id A38899132F for ; Fri, 30 Aug 2002 14:27:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 87EA65DDD5; Fri, 30 Aug 2002 14:27:15 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by segue.merit.edu (Postfix) with ESMTP id 538C85DDCE for ; Fri, 30 Aug 2002 14:27:15 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.104]) by gnat.inet.org (Postfix) with ESMTP id 22A5F67103; Fri, 30 Aug 2002 10:41:51 -0400 (EDT) Date: Fri, 30 Aug 2002 14:27:11 -0400 Subject: Re: hypocrisy of zeroconf Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: Zeroconf To: Keith Moore From: RJ Atkinson In-Reply-To: <200208301816.g7UIG4014649@astro.cs.utk.edu> Message-Id: <19960059-BC46-11D6-9A98-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Aug 30, 2002, at 14:16 America/Montreal, Keith Moore wrote: >> If you're going to send mail to the iab/iesg, you might want to at >> least include context so folk there know what it is you are >> complaining about and perhaps also indicate what should be done >> instead. > > noted. I had hoped IESG would be more up on this WG especially since > it's trying to change the behavior of fundamental pieces of Internet > infrastructure, but I certainly recognize that IESG folks never have > enough time to cover everything that deserves scrutiny. > > unfortunately I don't know how to include context without going into > lots of detail which is going to take more time both to write and to > read, and is going to have to wait until at least next week. Keith, The main problem all along has been lack of specific technical details in your emails that a reasonable person could review and understand. IMNVHO, it really would be best if you did whatever work/analysis/other you think is necessary, submerged while doing that, and resurfaced only when you can put a specific technical issue in front of the ZeroConf WG *for a proposal actually being handled within the ZeroConf WG* (as different from being handled within DNSEXT WG, for example). Thanks, Ran PS: I've trimmed the distribution of my reply deliberately and quite substantially. From owner-zeroconf@merit.edu Fri Aug 30 14:33:02 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29821 for ; Fri, 30 Aug 2002 14:33:02 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A14E39133D; Fri, 30 Aug 2002 14:34:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5A2049133C; Fri, 30 Aug 2002 14:34:09 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7E2C69133B for ; Fri, 30 Aug 2002 14:34:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5CD015DDD5; Fri, 30 Aug 2002 14:34:05 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by segue.merit.edu (Postfix) with ESMTP id E6E605DDD0 for ; Fri, 30 Aug 2002 14:34:04 -0400 (EDT) Received: from astro.cs.utk.edu (localhost [127.0.0.1]) by astro.cs.utk.edu (cf 8.9.3) with ESMTP id g7UIY1014816; Fri, 30 Aug 2002 14:34:01 -0400 (EDT) Message-Id: <200208301834.g7UIY1014816@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: RJ Atkinson Cc: Keith Moore , Zeroconf Subject: Re: hypocrisy of zeroconf In-reply-to: (Your message of "Fri, 30 Aug 2002 14:27:11 EDT.") <19960059-BC46-11D6-9A98-00039357A82A@extremenetworks.com> Date: Fri, 30 Aug 2002 14:34:01 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > IMNVHO, it really would be best if you did whatever work/analysis/other > you think is necessary, submerged while doing that, and resurfaced only > when you can put a specific technical issue in front of the ZeroConf WG > *for a proposal actually being handled within the ZeroConf WG* > (as different from being handled within DNSEXT WG, for example). one problem with doing that is that it's very difficult for IESG to push back on a group that thinks it has completed its work with little or no dissent. people need to be reminded from time to time that there are problems with the work so that they aren't completely surprised when the detailed analysis does arrive. Keith From owner-zeroconf@merit.edu Fri Aug 30 14:42:10 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00409 for ; Fri, 30 Aug 2002 14:42:10 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D122691329; Fri, 30 Aug 2002 14:43:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A258091331; Fri, 30 Aug 2002 14:43:30 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id AB1D791329 for ; Fri, 30 Aug 2002 14:43:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 940455DDD7; Fri, 30 Aug 2002 14:43:29 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id CF2135DDD5 for ; Fri, 30 Aug 2002 14:43:28 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g7UIhS517709 for ; Fri, 30 Aug 2002 11:43:28 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Fri, 30 Aug 2002 11:43:27 -0700 Received: from [17.255.97.96] (vpn-scv-x3-120.apple.com [17.219.194.120]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id g7UIhRb27422; Fri, 30 Aug 2002 11:43:27 -0700 (PDT) User-Agent: Microsoft-Entourage/10.0.0.1309 Date: Fri, 30 Aug 2002 11:43:25 -0700 Subject: Re: Slightly OT: Apple From: joe holt To: james mcmurry , Zeroconf Message-ID: In-Reply-To: <2728D526-BC42-11D6-B664-000393681A12@mediatonic.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit The Golden Gate Bridge also experienced unexpected and disturbing undulations after it was first opened in 1937, requiring retrofitting. In 1951 a violent storm swayed the bridge 27 ft side to side. Because of the retrofits the bridge survived with only minor damage. People of vision do their best and put something out there. It's never perfect the first time 'round. Great ideas get refined by experience and time in the real world. This next year is going to be an exciting one for ZeroConf. /joe On 8/30/02 10:58 AM, james mcmurry wrote: > Well, > > Yes and No... > > > > http://www.failuremag.com/arch_science_tacomanarrows.html > > > > > > > > Jim > > (disclaimer - I actually worked for 3 years at Failure Analysis > Associates......) > > > On Friday, August 30, 2002, at 10:47 AM, Keith Moore wrote: > >> Ran, >> >>> Please send a formal proof that it is broken. >> >> that's essentially what they said about the Tacoma Narrows Bridge - >> we don't believe your wind analysis because you can't formally prove >> it. >> > From owner-zeroconf@merit.edu Fri Aug 30 14:43:09 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00449 for ; Fri, 30 Aug 2002 14:43:08 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B825491331; Fri, 30 Aug 2002 14:44:30 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 835AD9133B; Fri, 30 Aug 2002 14:44:30 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8E11491331 for ; Fri, 30 Aug 2002 14:44:29 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7D23B5DDD5; Fri, 30 Aug 2002 14:44:29 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from gnat.inet.org (gnat.inet.org [63.108.254.91]) by segue.merit.edu (Postfix) with ESMTP id 54A7F5DDCE for ; Fri, 30 Aug 2002 14:44:29 -0400 (EDT) Received: from mosquito.inet.org (unknown [10.18.3.104]) by gnat.inet.org (Postfix) with ESMTP id 1F2FB67103; Fri, 30 Aug 2002 10:59:05 -0400 (EDT) Date: Fri, 30 Aug 2002 14:44:25 -0400 Subject: Re: hypocrisy of zeroconf Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) Cc: Zeroconf To: Keith Moore From: RJ Atkinson In-Reply-To: <200208301834.g7UIY1014816@astro.cs.utk.edu> Message-Id: <81A4203B-BC48-11D6-9A98-00039357A82A@extremenetworks.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Aug 30, 2002, at 14:34 America/Montreal, Keith Moore wrote: > one problem with doing that is that it's very difficult for IESG to > push back on a group that thinks it has completed its work with > little or no dissent. people need to be reminded from time to time Keith, How many times a day do you think is sufficient ? Right now, it appears that you think the IESG needs hourly reminders. Surely the IESG are more competent than that. I know for certain that they are already overly busy with real work (as different from potential future work that isn't yet real). Even if I bought your argument, which I don't since you haven't made a *technical* argument yet, I'd think once a week would be more than sufficient to make it clear that you are unhappy. And I'm still wondering why you are spun up in ZeroConf about a proposal that is being handled in a different WG (but, PLEASE, don't explain that to me because I'm not really that interested). Ran From owner-zeroconf@merit.edu Fri Aug 30 15:33:46 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02298 for ; Fri, 30 Aug 2002 15:33:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 38D929133C; Fri, 30 Aug 2002 15:34:51 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9166491333; Fri, 30 Aug 2002 15:34:42 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 766A991339 for ; Fri, 30 Aug 2002 15:34:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 5E9CA5DDBE; Fri, 30 Aug 2002 15:34:24 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by segue.merit.edu (Postfix) with ESMTP id D3F015DDAE for ; Fri, 30 Aug 2002 15:34:23 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g7UJYJm17664 for ; Fri, 30 Aug 2002 12:34:19 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 30 Aug 2002 12:34:19 -0700 Received: from [17.202.45.251] (il0204a-dhcp123.apple.com [17.202.45.251]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id g7UJYJ304146 for ; Fri, 30 Aug 2002 12:34:19 -0700 (PDT) Message-Id: <200208301934.g7UJYJ304146@scv3.apple.com> Subject: Re: Slightly OT: Apple to Release Source Code to its zeroconf implementation Date: Fri, 30 Aug 2002 12:34:22 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Zeroconf" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: owner-zeroconf@merit.edu Precedence: bulk >Thank you for bringing this to our attention. >There are several problems with this text. > >ZeroConf is not a standard (yet). John is of course right. Zeroconf is NOT an IETF Standard (yet). I apologize for any misinformation that may be being disseminated. However, while I can apologize for it, there is little I can do to stop it. I can't control what independent journalists write, and Apple's PR team doesn't like journalists talking to anyone but appointed Apple spokespersons, so I rarely get the chance to explain to those journalists the difference between an Internet Draft, Informational RFC, Proposed Standard RFC, etc. I do try to keep Apple's own Web pages honest. For example, the marketing people insist on calling IPv4 Link-Local addressing an "industry standard" (because Apple and Microsoft have been shipping it in large volumes for over four years) but I don't let them call it an "IETF Standard", because it is not. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Fri Aug 30 15:34:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02312 for ; Fri, 30 Aug 2002 15:33:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2668A91336; Fri, 30 Aug 2002 15:34:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E9D8F91333; Fri, 30 Aug 2002 15:34:54 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id C60379133B for ; Fri, 30 Aug 2002 15:34:44 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AB0675DDAE; Fri, 30 Aug 2002 15:34:44 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 48DEB5DDA7 for ; Fri, 30 Aug 2002 15:34:44 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA25305 for ; Fri, 30 Aug 2002 15:34:43 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA20054 for ; Fri, 30 Aug 2002 15:34:43 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA21833 for ; Fri, 30 Aug 2002 15:34:41 -0400 (EDT) Date: Fri, 30 Aug 2002 15:34:41 -0400 Subject: Re: Slightly OT: Apple to Release Source Code to its zeroconf implementation Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <4.3.2.7.2.20020830125315.018931a0@wells.cisco.com> Message-Id: <8745968A-BC4F-11D6-84F7-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Aug 30, 2002, at 13:01 US/Eastern, John Schnizlein wrote: > This language is not consistent with the fact that the IETF is not > composed of company representatives, but individual contributors. > > How can it be "first documented" when there is no RFC yet? > Internet Drafts are explicitly not to be referenced. It's *MacCentral*...we aren't talking about Jim Leherer here. john From owner-zeroconf@merit.edu Fri Aug 30 15:34:05 2002 Received: from trapdoor.merit.edu (trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02326 for ; Fri, 30 Aug 2002 15:34:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 23DAB91339; Fri, 30 Aug 2002 15:34:51 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DEE5991336; Fri, 30 Aug 2002 15:33:49 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 3CFAF91333 for ; Fri, 30 Aug 2002 15:33:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2BAB85DDAE; Fri, 30 Aug 2002 15:33:48 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id BDC6C5DDA7 for ; Fri, 30 Aug 2002 15:33:47 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA00127 for ; Fri, 30 Aug 2002 15:33:47 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA19356 for ; Fri, 30 Aug 2002 15:33:46 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA21307 for ; Fri, 30 Aug 2002 15:33:46 -0400 (EDT) Date: Fri, 30 Aug 2002 15:33:45 -0400 Subject: Re: Slightly OT: Apple to Release Source Code to its zeroconf implementation Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208301723.g7UHNB014441@astro.cs.utk.edu> Message-Id: <6657DDE2-BC4F-11D6-84F7-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Aug 30, 2002, at 13:23 US/Eastern, Keith Moore wrote: > very bad idea - this will propagate buggy protocols that isn't yet up > to standards-track quality. It will also help get any bugs in the code fixed. It will also help it get looked at by a wide range of eyes and expertise. That is *a good thing* > > actually I have no problem with distributing code for use on an > experimental basis as long as people are aware that the protocols > are subject to change - I think it's very unfortunate that this code > is in shipping production products. Well, the world doesn't have time to wait for more arguing over the concept. We have work to do, and this will help it get done. john From owner-zeroconf@merit.edu Fri Aug 30 15:34:33 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02348 for ; Fri, 30 Aug 2002 15:34:32 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A426C91333; Fri, 30 Aug 2002 15:35:47 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6D4AE9133B; Fri, 30 Aug 2002 15:35:47 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 61C0091333 for ; Fri, 30 Aug 2002 15:35:46 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 503A45DDC1; Fri, 30 Aug 2002 15:35:46 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by segue.merit.edu (Postfix) with ESMTP id E2FE65DDAE for ; Fri, 30 Aug 2002 15:35:45 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id PAA00830 for ; Fri, 30 Aug 2002 15:35:45 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA20225 for ; Fri, 30 Aug 2002 15:35:45 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA22290 for ; Fri, 30 Aug 2002 15:35:44 -0400 (EDT) Date: Fri, 30 Aug 2002 15:35:44 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208301729.g7UHTX014461@astro.cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Aug 30, 2002, at 13:29 US/Eastern, Keith Moore wrote: > if a proposal will do harm if propagated, then any effort which results > in minimizing and/or delaying the harm done is well spent. Well, when you get from "if" to "will" with solid proof, you let me know. > > on the other hand, a half-baked competing proposal - even one which has > the kernel of a better idea buried in it - is often little better than > no proposal. sometimes it is worse, because an apparently-complete > proposal (even if it is based on a bad idea) may seem to compare > favorably > with an incomplete one (even if it is based on a good idea). this is > usually a fallacy based on failure to compare both proposals with > respect to the same set of requirements, but it's a mistake that is > commonly made. Well, so far, MIT's DNS hasn't come crashing down. john From owner-zeroconf@merit.edu Fri Aug 30 15:35:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02389 for ; Fri, 30 Aug 2002 15:35:30 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A345C9133B; Fri, 30 Aug 2002 15:36:44 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 6C81C9133E; Fri, 30 Aug 2002 15:36:44 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 56BC89133B for ; Fri, 30 Aug 2002 15:36:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 424BD5DDC4; Fri, 30 Aug 2002 15:36:43 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id D4EF25DDC1 for ; Fri, 30 Aug 2002 15:36:42 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA26045 for ; Fri, 30 Aug 2002 15:36:42 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA19685 for ; Fri, 30 Aug 2002 15:36:42 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA22924 for ; Fri, 30 Aug 2002 15:36:41 -0400 (EDT) Date: Fri, 30 Aug 2002 15:36:41 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208301732.g7UHWv014484@astro.cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Aug 30, 2002, at 13:32 US/Eastern, Keith Moore wrote: >> But you won't know for sure with *just* testing, or *just* analysis. >> You *have* to have both. > > but you do not need to have all of your analysis verified by testing, > or vice versa. analysis and testing tend to cover different cases - > you learn from each of them, but you can only use one to verify the > other when they overlap. You still get better results from both, and unverified analysis is never as reliable. > > for instance, there's no practical way to test the effect of zeroconf > protocols on the wide variety of applications and wide variety of > network configurations that are out there. the most test coverage you > can hope for is to try it with the applications you use normally and > on a few specific network configurations. that's not even a drop in > the > bucket. If enough people test it, the bucket is filled. john From owner-zeroconf@merit.edu Fri Aug 30 15:37:16 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02445 for ; Fri, 30 Aug 2002 15:37:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B300A9133E; Fri, 30 Aug 2002 15:38:36 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7C1FC9133F; Fri, 30 Aug 2002 15:38:36 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 8318E9133E for ; Fri, 30 Aug 2002 15:38:35 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 61AB65DDC1; Fri, 30 Aug 2002 15:38:35 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from oldtms704.pearsontc.com (ptcfw.ot.hdmss.net [63.69.110.4]) by segue.merit.edu (Postfix) with ESMTP id 47F8C5DDAE for ; Fri, 30 Aug 2002 15:38:35 -0400 (EDT) Received: from oldtms031.prenhall.com (localhost [127.0.0.1]) by oldtms704.pearsontc.com (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0H1O0031H8YZ3R@oldtms704.pearsontc.com> for zeroconf@merit.edu; Fri, 30 Aug 2002 15:32:59 -0400 (EDT) Received: by OLDTMS031 with Internet Mail Service (5.5.2654.89) id ; Fri, 30 Aug 2002 15:39:17 -0400 Content-return: allowed Date: Fri, 30 Aug 2002 15:45:17 -0400 From: "Thomas, Stephane" Subject: Please remove from the list To: "'zeroconf@merit.edu'" Message-id: <1DC3E81F41F3D211A2290050041B88CB0474CF99@oldtms019.schuster.com> MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7BIT Hello, I would like to be removed from this list please. My e-mail address is: Stephane.thomas@awl.com Thank you! steph -----Original Message----- From: John C. Welch [mailto:jwelch@MIT.EDU] Sent: Friday, August 30, 2002 12:37 PM To: Zeroconf Subject: Re: non-DNS name services On Friday, Aug 30, 2002, at 13:32 US/Eastern, Keith Moore wrote: >> But you won't know for sure with *just* testing, or *just* analysis. >> You *have* to have both. > > but you do not need to have all of your analysis verified by testing, > or vice versa. analysis and testing tend to cover different cases - > you learn from each of them, but you can only use one to verify the > other when they overlap. You still get better results from both, and unverified analysis is never as reliable. > > for instance, there's no practical way to test the effect of zeroconf > protocols on the wide variety of applications and wide variety of > network configurations that are out there. the most test coverage you > can hope for is to try it with the applications you use normally and > on a few specific network configurations. that's not even a drop in > the > bucket. If enough people test it, the bucket is filled. john **************************************************************************** This email may contain confidential material. If you were not an intended recipient, Please notify the sender and delete all copies. We may monitor email to and from our network. **************************************************************************** From owner-zeroconf@merit.edu Fri Aug 30 15:38:19 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02490 for ; Fri, 30 Aug 2002 15:38:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 95BDD9133F; Fri, 30 Aug 2002 15:39:33 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 62E4291340; Fri, 30 Aug 2002 15:39:33 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 596619133F for ; Fri, 30 Aug 2002 15:39:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 431D05DDC1; Fri, 30 Aug 2002 15:39:32 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id D5E325DDAE for ; Fri, 30 Aug 2002 15:39:31 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA27010 for ; Fri, 30 Aug 2002 15:39:31 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA20124 for ; Fri, 30 Aug 2002 15:39:31 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA24274 for ; Fri, 30 Aug 2002 15:39:30 -0400 (EDT) Date: Fri, 30 Aug 2002 15:39:30 -0400 Subject: Re: Slightly OT: Apple Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208301734.g7UHYd014501@astro.cs.utk.edu> Message-Id: <33A92DC2-BC50-11D6-84F7-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Aug 30, 2002, at 13:34 US/Eastern, Keith Moore wrote: >> Since it works just fine, I'm sure glad that it is >> running in my laptop today (and not at some future decade >> when IETF gets its process unwedged)... > > ah, but it *doesn't* work just fine - it just hasn't broken when > you tried it - at least not in a way that you noticed. Actually, *so far* it does work fine. If it only breaks in unnoticeable ways, then it's not broken at any level that we care about. unless it breaks something real, in a repeatable fashion, it's a 'what if'. you can always 'what if' something to the grave. > > I do appreciate their giving the code away - it makes it more likely > that there will be free implementations of the fixed version of > zeroconf > once we get the protocols fixed. The problem is in misleading the > public > that this is a robust protocol. Prove it's not robust, since you've made the accusation. Show me something it's *actually* broke. Not theoretically broke, not may break some day. Show me something it's actually broken, and document it so it can get fixed. john From owner-zeroconf@merit.edu Fri Aug 30 15:39:48 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02589 for ; Fri, 30 Aug 2002 15:39:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3694191340; Fri, 30 Aug 2002 15:41:02 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E940F91341; Fri, 30 Aug 2002 15:41:01 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id DFE0B91340 for ; Fri, 30 Aug 2002 15:41:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id CACE75DDC1; Fri, 30 Aug 2002 15:41:00 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 6815B5DDAE for ; Fri, 30 Aug 2002 15:41:00 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA27615 for ; Fri, 30 Aug 2002 15:40:59 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA21022 for ; Fri, 30 Aug 2002 15:40:59 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA25126 for ; Fri, 30 Aug 2002 15:40:59 -0400 (EDT) Date: Fri, 30 Aug 2002 15:40:59 -0400 Subject: Re: hypocrisy of zeroconf Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208301744.g7UHiI014534@astro.cs.utk.edu> Message-Id: <68821856-BC50-11D6-84F7-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Aug 30, 2002, at 13:44 US/Eastern, Keith Moore wrote: > on the other hand, when the zeroconf folks say "hey, we can redefine > IP to work differently than applications expect, and we can also > redefine > DNS to work differently than applications expect, and it won't break > anything - we tried it and it works for us!" then people say > "hey, what a wonderful thing this is! isn't it nice that [vendor] is > shipping it in product without bothering to do either analysis of the > probable failure modes or waiting for the bugs to be worked out!" > And your analysis with proof of all the bad things zeroconf does is where? john From owner-zeroconf@merit.edu Fri Aug 30 15:41:40 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02679 for ; Fri, 30 Aug 2002 15:41:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D7DBB91341; Fri, 30 Aug 2002 15:42:58 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A705891342; Fri, 30 Aug 2002 15:42:58 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 9775991341 for ; Fri, 30 Aug 2002 15:42:57 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7D0965DDC1; Fri, 30 Aug 2002 15:42:57 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 1B7B45DDAE for ; Fri, 30 Aug 2002 15:42:57 -0400 (EDT) Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA28288 for ; Fri, 30 Aug 2002 15:42:56 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA20671 for ; Fri, 30 Aug 2002 15:42:56 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA26023 for ; Fri, 30 Aug 2002 15:42:55 -0400 (EDT) Date: Fri, 30 Aug 2002 15:42:55 -0400 Subject: Re: non-DNS name services Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208301746.g7UHkG014551@astro.cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Aug 30, 2002, at 13:46 US/Eastern, Keith Moore wrote: > As I've said repeatedly I'm working on analysis of mDNS, but it's > extremely > time-consuming. Good analysis always is, as is good testing. > > Furthermore, when members of this group clearly indicate that they're > not > capable of understanding analysis, that seems like a good indication > that > the analysis is a waste of time - at least for this audience. Dude, you show me a balanced, objective, repeatable analysis that shows proof that Zeroconf will break stuff, and I will stand right next to you and demand it gets fixed. The only thing this group appears to be not capable of is taking vague 'chicken little' warnings with no proof seriously. Screaming "bad things may happen" is not analysis. john From owner-zeroconf@merit.edu Fri Aug 30 15:44:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02756 for ; Fri, 30 Aug 2002 15:44:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B2DB591342; Fri, 30 Aug 2002 15:45:14 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 411A591343; Fri, 30 Aug 2002 15:45:14 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 2085891342 for ; Fri, 30 Aug 2002 15:45:11 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B8B3F5DDC1; Fri, 30 Aug 2002 15:45:11 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id 579EA5DDAE for ; Fri, 30 Aug 2002 15:45:11 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA29122 for ; Fri, 30 Aug 2002 15:45:10 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA21620 for ; Fri, 30 Aug 2002 15:45:10 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA27092 for ; Fri, 30 Aug 2002 15:45:10 -0400 (EDT) Date: Fri, 30 Aug 2002 15:45:09 -0400 Subject: Re: Slightly OT: Apple Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208301747.g7UHlQ014565@astro.cs.utk.edu> Message-Id: X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Aug 30, 2002, at 13:47 US/Eastern, Keith Moore wrote: >> Please send a formal proof that it is broken. > > that's essentially what they said about the Tacoma Narrows Bridge - > we don't believe your wind analysis because you can't formally prove > it. That was one case, and they were dumb to ignore the analysis. *However*, at least in that case, there was an analysis to ignore. You have yet to provide an analysis of any kind. I can also point to quite a few things where analysis said it wouldn't work, yet it did, and well. Aeronautics is full of them. I for one am glad that the Wright brothers tested ideas as well as analyzed them. remember...studied analysis said you couldn't fly faster than the speed of sound. john From owner-zeroconf@merit.edu Fri Aug 30 15:48:31 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02953 for ; Fri, 30 Aug 2002 15:48:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 625599132E; Fri, 30 Aug 2002 15:49:51 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4620C91343; Fri, 30 Aug 2002 15:49:29 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 74D9E9132E for ; Fri, 30 Aug 2002 15:48:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 552C15DDC1; Fri, 30 Aug 2002 15:48:01 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by segue.merit.edu (Postfix) with ESMTP id E7D9B5DDAE for ; Fri, 30 Aug 2002 15:48:00 -0400 (EDT) Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA00202 for ; Fri, 30 Aug 2002 15:48:00 -0400 (EDT) Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA22016 for ; Fri, 30 Aug 2002 15:48:00 -0400 (EDT) Received: from Hustler.local. (109-8-189-66.wo.cpe.charter-ne.com [66.189.8.109]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA28451 for ; Fri, 30 Aug 2002 15:47:59 -0400 (EDT) Date: Fri, 30 Aug 2002 15:47:59 -0400 Subject: Re: hypocrisy of zeroconf Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: "John C. Welch" To: Zeroconf Content-Transfer-Encoding: 7bit In-Reply-To: <200208301834.g7UIY1014816@astro.cs.utk.edu> Message-Id: <62FE1D3A-BC51-11D6-84F7-000393D60422@mit.edu> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, Aug 30, 2002, at 14:34 US/Eastern, Keith Moore wrote: > one problem with doing that is that it's very difficult for IESG to > push back on a group that thinks it has completed its work with > little or no dissent. people need to be reminded from time to time > that there are problems with the work so that they aren't completely > surprised when the detailed analysis does arrive. ....you haven't come up with one single legitimate problem. You've listed an encyclopedia's worth of vague warnings about the end of the Internet if Zeroconf gets out on it...hmm...nope, hasn't happened. john From owner-zeroconf@merit.edu Fri Aug 30 17:27:49 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06356 for ; Fri, 30 Aug 2002 17:27:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 471ED91225; Fri, 30 Aug 2002 17:29:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1102C91324; Fri, 30 Aug 2002 17:29:08 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 6ECA991225 for ; Fri, 30 Aug 2002 17:29:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 4390E5DDDC; Fri, 30 Aug 2002 17:29:07 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailhost.chi1.ameritech.net (mailhost1-chcgil.chcgil.ameritech.net [206.141.192.67]) by segue.merit.edu (Postfix) with ESMTP id EC7345DD8E for ; Fri, 30 Aug 2002 17:29:06 -0400 (EDT) Received: from repligate ([65.43.115.217]) by mailhost.chi1.ameritech.net (InterMail vM.4.01.02.17 201-229-119) with SMTP id <20020830212906.SVNA18992.mailhost.chi1.ameritech.net@repligate>; Fri, 30 Aug 2002 16:29:06 -0500 Message-ID: <00a401c2506c$5d80b000$8c56fea9@repligate> From: "Jim Fleming" To: "Zeroconf" , "Stuart Cheshire" Cc: , , , "Joe Baptista" , "@quasar Internet Solutions, Inc." , , "Bruce Young" , "Joanna Lane" , "Joop Teernstra" , , , "Richard Henderson" , "Richard J. Sexton" , , , , , , , , , , , , , , , , , , , , , References: <200208301934.g7UJYJ304146@scv3.apple.com> Subject: "...IPv4 Link-Local addressing an "industry standard"...." Date: Fri, 30 Aug 2002 16:29:44 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit From: "Stuart Cheshire" "...IPv4 Link-Local addressing an "industry standard"...." "(because Apple and Microsoft have been shipping it in large volumes for over four years)" ============================== Are you saying that large companies can bypass ICANN (aka IANA) and take large blocks of IPv4 Address space ?....and justify that on the basis that they ship products for years in volume ? http://www.webopedia.com/TERM/A/APIPA.html "The IP address range is 169.254.0.1 through 169.254.255.254." ==== Do TLDs also work that way ?....can large companies just take them ?...and bypass ICANN (IANA) ? How about special e-mail addresses ?....Does Cheshire.C@t work ? Should we release the C@t ? http://www.ddj.com/articles/1993/9310/ http://maccentral.macworld.com/news/0208/25.jaguar.php Jim Fleming 2002:[IPv4]:000X:03DB:...IPv8 is closer than you think... http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt 3:75 APPLE ----- Original Message ----- From: "Stuart Cheshire" To: "Zeroconf" Sent: Friday, August 30, 2002 2:34 PM Subject: Re: Slightly OT: Apple to Release Source Code to its zeroconf implementation > >Thank you for bringing this to our attention. > >There are several problems with this text. > > > >ZeroConf is not a standard (yet). > > John is of course right. > > Zeroconf is NOT an IETF Standard (yet). > > I apologize for any misinformation that may be being disseminated. > However, while I can apologize for it, there is little I can do to stop > it. I can't control what independent journalists write, and Apple's PR > team doesn't like journalists talking to anyone but appointed Apple > spokespersons, so I rarely get the chance to explain to those journalists > the difference between an Internet Draft, Informational RFC, Proposed > Standard RFC, etc. > > I do try to keep Apple's own Web pages honest. For example, the marketing > people insist on calling IPv4 Link-Local addressing an "industry > standard" (because Apple and Microsoft have been shipping it in large > volumes for over four years) but I don't let them call it an "IETF > Standard", because it is not. > > Stuart Cheshire > * Wizard Without Portfolio, Apple Computer > * Chairman, IETF ZEROCONF > * www.stuartcheshire.org > From owner-zeroconf@merit.edu Fri Aug 30 17:48:00 2002 Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06874 for ; Fri, 30 Aug 2002 17:47:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0B24C91225; Fri, 30 Aug 2002 17:49:08 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B731891324; Fri, 30 Aug 2002 17:49:05 -0400 (EDT) Delivered-To: zeroconf@trapdoor.merit.edu Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id D518491225 for ; Fri, 30 Aug 2002 17:47:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B7FD65DDDC; Fri, 30 Aug 2002 17:47:16 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by segue.merit.edu (Postfix) with ESMTP id 37DE95DD8E for ; Fri, 30 Aug 2002 17:47:16 -0400 (EDT) Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g7ULlF527682 for ; Fri, 30 Aug 2002 14:47:15 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 30 Aug 2002 14:47:14 -0700 Received: from graejo.apple.com (graejo.apple.com [17.202.40.111]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id g7ULlFb14935 for ; Fri, 30 Aug 2002 14:47:15 -0700 (PDT) Date: Fri, 30 Aug 2002 14:46:59 -0700 Subject: Re: "...IPv4 Link-Local addressing an "industry standard"...." Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v543) From: Joshua Graessley To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <00a401c2506c$5d80b000$8c56fea9@repligate> Message-Id: <02C906C0-BC62-11D6-BE61-000393760260@apple.com> X-Mailer: Apple Mail (2.543) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Friday, August 30, 2002, at 02:29 PM, Jim Fleming wrote: > From: "Stuart Cheshire" > "...IPv4 Link-Local addressing an "industry standard"...." > "(because Apple and Microsoft have been shipping it in large volumes > for over four years)" > ============================== > > Are you saying that large companies can bypass ICANN (aka IANA) and > take large blocks of > IPv4 Address space ?....and justify that on the basis that they ship > products for years in volume ? > > http://www.webopedia.com/TERM/A/APIPA.html > "The IP address range is 169.254.0.1 through 169.254.255.254." > ==== According to the draft, the 169.254/16 range has been registered with IANA. -josh