Zeroconf and UPnP

From owner-zeroconf@merit.edu Sun Jul 7 21:45: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 VAA16600 for ; Sun, 7 Jul 2002 21:45:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B24959123B; Sun, 7 Jul 2002 21:46:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 63BA59124E; Sun, 7 Jul 2002 21:46: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 94EF69123B for ; Sun, 7 Jul 2002 21:46:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7D8DE5DE3A; Sun, 7 Jul 2002 21:46:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from lennier.cc.vt.edu (lennier.cc.vt.edu [198.82.162.213]) by segue.merit.edu (Postfix) with ESMTP id 157545DE11 for ; Sun, 7 Jul 2002 21:46:09 -0400 (EDT) Received: from zidane.cc.vt.edu (IDENT:mirapoint@zidane-lb.cc.vt.edu [10.1.1.13]) by lennier.cc.vt.edu (8.11.4/8.11.4) with ESMTP id g681k8A279509 for ; Sun, 7 Jul 2002 21:46:08 -0400 (EDT) Received: from Phani (ari418-c.ari.vt.edu [208.17.194.149]) by zidane.cc.vt.edu (Mirapoint Messaging Server MOS 3.1.0.54-GA) with SMTP id AFJ06311; Sun, 7 Jul 2002 21:46:07 -0400 (EDT) Message-ID: <001601c22621$3c9a8110$95c211d0@Phani> Reply-To: "Phaneendra Kumar Piratla" From: "Phaneendra Kumar Piratla" To: Subject: Multiple Networks Date: Sun, 7 Jul 2002 21:46:10 -0400 Organization: Alexandria Research Institute MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C225FF.B55B8F80" 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 This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C225FF.B55B8F80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have few questions regarding the zeroconf protocol which I am unclear = about. Can there be two or more separate zeroconf networks, existing = simultaneously at one point in space? If so, how does hosts react when they come under the area of another = zeroconf network? =20 Thanks in advance, Phani. ------=_NextPart_000_0013_01C225FF.B55B8F80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have few questions regarding the = zeroconf=20 protocol which I am unclear about.

Can there be two or more separate=20 zeroconf networks, existing simultaneously at one point in=20 space?

If so, how does hosts react = when they come=20 under the area of another zeroconf network?

Thanks in advance,

Phani.

------=_NextPart_000_0013_01C225FF.B55B8F80-- From owner-zeroconf@merit.edu Sun Jul 7 22:19: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 WAA18086 for ; Sun, 7 Jul 2002 22:19:18 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 82A3B91255; Sun, 7 Jul 2002 22:19:59 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4E4409125F; Sun, 7 Jul 2002 22:19: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 568BA91255 for ; Sun, 7 Jul 2002 22:19:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 42BD65DE11; Sun, 7 Jul 2002 22:19:58 -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 E446F5DDCB for ; Sun, 7 Jul 2002 22:19:56 -0400 (EDT) Received: from pc-00087 ([144.135.25.78]) by mta05ps.bigpond.com (Netscape Messaging Server 4.15 mta05ps Apr 29 2002 13:22:02) with SMTP id GYWRHT00.625; Mon, 8 Jul 2002 12:13:05 +1000 Received: from CPE-203-51-28-192.nsw.bigpond.net.au ([203.51.28.192]) by PSMAM04.mailsvc.email.bigpond.com(MailRouter V3.0n 92/49080); 08 Jul 2002 12:13:05 From: Brad Hards To: "Phaneendra Kumar Piratla" , Subject: Re: Multiple Networks Date: Mon, 8 Jul 2002 12:09:34 +1000 User-Agent: KMail/1.4.5 References: <001601c22621$3c9a8110$95c211d0@Phani> In-Reply-To: <001601c22621$3c9a8110$95c211d0@Phani> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200207081209.34546.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Mon, 8 Jul 2002 11:46, Phaneendra Kumar Piratla wrote: > I have few questions regarding the zeroconf protocol which I am unclear > about. > > Can there be two or more separate zeroconf networks, existing > simultaneously at one point in space? If so, how does hosts react when they > come under the area of another zeroconf network? I am not sure I understand what you mean when you talk about a network existing a "point in space". The concept of network (to me, at least) inherently requires two or more parties, and two things can't generally exist in the same place at the same time. This is much more fundamental than zeroconf. If you mean "if I have two seperate zeroconf networks and join them" (say by connecting two previously seperate LAN segments) or "if I have a zeroconf host and move it to another network" (say, the host is wireless), then those situations are specifically covered in the IETF draft. If that is not what you mean, then you need to rephrase the question before I can help you. A specific example might help. Brad -- http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. From owner-zeroconf@merit.edu Fri Jul 12 09:33: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 JAA21753 for ; Fri, 12 Jul 2002 09:33:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 17091913A5; Fri, 12 Jul 2002 09:34:03 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DC069913A6; Fri, 12 Jul 2002 09:34:02 -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 4EF19913A5 for ; Fri, 12 Jul 2002 09:34:01 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 33B695DEF0; Fri, 12 Jul 2002 09:34:01 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from Cs.Nott.AC.UK (pat.cs.nott.ac.uk [128.243.20.9]) by segue.merit.edu (Postfix) with SMTP id 66EA95DEEE for ; Fri, 12 Jul 2002 09:34:00 -0400 (EDT) Received: from scarlet.cs.nott.ac.uk by pat.Cs.Nott.AC.UK id aa29956; 12 Jul 2002 14:33 BST Received: from wormtail.cs.nott.ac.uk by scarlet.Cs.Nott.AC.UK id aa16628; 12 Jul 2002 14:32 BST Message-ID: <3D2EDA89.CAD4EFA4@cs.nott.ac.uk> Date: Fri, 12 Jul 2002 14:32:57 +0100 From: Morcos G Mikhail X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: zeroconf@merit.edu Subject: comments and ideas . Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Hi all , I have some comments and ideas I want to discuss with you : 1- In the draft it is mentiond that if a host sees 2 conflicting arp packets carrying its IP then it must cease using this IP and starts using another one , this is simply a good way for attacking a zeroconf network .. just issue 2 conflicting arp packets within 1 sec for a certian host and it is down ?? 2- For hosts that have different link-local address for different interfaces [sec 3.3.2 in the draft] the out going packets must be identified by the source and destination address and port numbers ,not just by the destination address and port number alone . This imposes some difficulties for the implementations of zerconf protocol because it forces the host that has multiple interfaces to work similar to a router, because the host has to remember the interface from which packets arrive and it has to answer this packet through the same interface and so on .. 4- All hosts has to process each arp request or reply and compare it with its IP address to detect conflicts and this may imposes some delays on the Pcs performance . 3- Why don't we use rarp instead of arp for allocating an IP address , and here how it goes : a- Any host that needs an IP address sends a rarp packet requesting and IP and this is by default broadcasted b- Upon recieving the rarp request packet all hosts respond by sending a series of rarp replies the first one contains their IP address and the rest contains all the IP address that are in their cache c- When a host recieves all this replies it has to choose an IP address which is not sent to it . This approach has many advantages : 1- The number of broadcast packets is less , just 1 broadcast for the rarp request and all the rarp replies will be unicasted [by default] . 2- No changes in the packet format of the rarp protocol. 3- Upon recieving a rarp request the zerconf protocol implmentation may alret the users and ask them to either accept the new host in their network or not and here network attacks become less . 4- The host that initiated the rarp request will have all the IPs and physical address of the neighbouring Pcs . 5- With this kind of information and the fact that the IP is choosen Randomly using the hardware address of the network interface card the propability to choose a conflicting IP becomes less . 6- For hosts that have different interfaces on different links ,these hosts issue rarp request on all the links that they are connected to and upon recieving the replies they will choose IPs that are completely differnet form the IPs that are already in use on both links and this and this removes the address reuse ambiguity . 7- The hosts that fails or busy to respond its IP address is most likely stored on any of the caches of other hosts and it will be sent to the host that requested an IP address so the propability to choose a conflicting IP address becomes less . 8- For security issues , hosts must not respond to rarp requests that is initiated from the same Hardware Address within a certain period of time [to be calculated so that no flooding happens to the network ] . Best regards , Morcos George mikhail Msc. researcher Faculty of Computer Since and Informatin Technology Nottingham Univesrity England . From owner-zeroconf@merit.edu Mon Jul 15 09:02: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 JAA02860 for ; Mon, 15 Jul 2002 09:02:39 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C5CA69127E; Mon, 15 Jul 2002 09:03:26 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8952F9127F; Mon, 15 Jul 2002 09:03: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 752499127E for ; Mon, 15 Jul 2002 09:03:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 646185DE8B; Mon, 15 Jul 2002 09:03:25 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from web12902.mail.yahoo.com (web12902.mail.yahoo.com [216.136.174.69]) by segue.merit.edu (Postfix) with SMTP id C84635DE02 for ; Mon, 15 Jul 2002 09:03:24 -0400 (EDT) Message-ID: <20020715130324.63405.qmail@web12902.mail.yahoo.com> Received: from [212.103.160.163] by web12902.mail.yahoo.com via HTTP; Mon, 15 Jul 2002 06:03:24 PDT Date: Mon, 15 Jul 2002 06:03:24 -0700 (PDT) From: nagabhushana ramaswamy Subject: Welcome to zeroconf To: Morcos G Mikhail Cc: zeroconf@merit.edu In-Reply-To: <20020715124835.2AE329127E@trapdoor.merit.edu> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1764745265-1026738204=:62994" Sender: owner-zeroconf@merit.edu Precedence: bulk --0-1764745265-1026738204=:62994 Content-Type: text/plain; charset=us-ascii Dear Morcos, welcome to zeroconf - Bijan Jabbaria, PhD --------------------------------- Do You Yahoo!? Yahoo! Autos - Get free new car price quotes --0-1764745265-1026738204=:62994 Content-Type: text/html; charset=us-ascii

Dear Morcos,

welcome to zeroconf

- Bijan Jabbaria, PhD

Do You Yahoo!?
Yahoo! Autos - Get free new car price quotes --0-1764745265-1026738204=:62994-- From owner-zeroconf@merit.edu Wed Jul 17 09:39: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 JAA16209 for ; Wed, 17 Jul 2002 09:39:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D4AF49122A; Wed, 17 Jul 2002 09:40:41 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A494791262; Wed, 17 Jul 2002 09:40: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 B2BC09122A for ; Wed, 17 Jul 2002 09:40:40 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9970C5DE6C; Wed, 17 Jul 2002 09:40:40 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from coconut.itojun.org (coconut.itojun.org [210.160.95.97]) by segue.merit.edu (Postfix) with ESMTP id F04025DD8D for ; Wed, 17 Jul 2002 09:40:39 -0400 (EDT) Received: from itojun.org (localhost [127.0.0.1]) by coconut.itojun.org (Postfix) with ESMTP id 9245F4B22 for ; Wed, 17 Jul 2002 22:40:35 +0900 (JST) To: zeroconf@merit.edu Subject: draft-itojun-ipv6-nodeinfo-zeroconflookup-00.txt 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 Date: Wed, 17 Jul 2002 22:40:35 +0900 From: Jun-ichiro itojun Hagino Message-Id: <20020717134035.9245F4B22@coconut.itojun.org> Sender: owner-zeroconf@merit.edu Precedence: bulk (resend as it did not seem to show up on the archive) draft-itojun-ipv6-nodeinfo-zeroconflookup-00.txt do anyone have comments on this, or how should i go forward with it? (informational/experimental is fine for me) itojun From owner-zeroconf@merit.edu Wed Jul 17 20:10: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 UAA03141 for ; Wed, 17 Jul 2002 20:10:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8442C912BA; Wed, 17 Jul 2002 20:11:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4FB7F912BC; Wed, 17 Jul 2002 20:11: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 5006D912BA for ; Wed, 17 Jul 2002 20:11:37 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 36DAD5DE7E; Wed, 17 Jul 2002 20:11:37 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from zrc2s0jx.nortelnetworks.com (zrc2s0jx.nortelnetworks.com [47.103.122.112]) by segue.merit.edu (Postfix) with ESMTP id 9D1CF5DDB0 for ; Wed, 17 Jul 2002 20:11:36 -0400 (EDT) Received: from zsc4c000.us.nortel.com (zsc4c000.us.nortel.com [47.81.138.47]) by zrc2s0jx.nortelnetworks.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g6I0BmP05986 for ; Wed, 17 Jul 2002 19:11:49 -0500 (CDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <39AVY51C>; Wed, 17 Jul 2002 17:11:33 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C0320AF13@zsc3c032.us.nortel.com> From: "Venkatesh Raju" To: zeroconf@merit.edu Subject: Zeroconf and UPnP Date: Wed, 17 Jul 2002 17:11:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22DEF.AC32FBB2" 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_01C22DEF.AC32FBB2 Content-Type: text/plain; charset="ISO-8859-1" Hi, I'm curious about the relationship between the Zeroconf working group and the UPnP forum. While I've not studied the drafts extensively it appears that both are addressing the same problems and in the same spaces. If this topic has been discussed below I apologize for bringing it up again; a pointer to the previous thread would be appreciated! Thanks, Venky ------_=_NextPart_001_01C22DEF.AC32FBB2 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Zeroconf and UPnP

Hi,
I'm curious about the relationship between the Zeroconf = working group and the UPnP forum. While I've not studied the = drafts extensively it appears that both are addressing the same = problems and in the same spaces. If this topic has been discussed = below I apologize for bringing it up again; a pointer to the previous = thread would be appreciated!

Thanks,
Venky

------_=_NextPart_001_01C22DEF.AC32FBB2-- From owner-zeroconf@merit.edu Thu Jul 18 09:13: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 JAA01721 for ; Thu, 18 Jul 2002 09:13:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 8CC509123A; Thu, 18 Jul 2002 09:14:25 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 60B1A9123B; Thu, 18 Jul 2002 09:14: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 68C799123A for ; Thu, 18 Jul 2002 09:14:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 53A375DDC6; Thu, 18 Jul 2002 09:14:24 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by segue.merit.edu (Postfix) with ESMTP id C95435DD93 for ; Thu, 18 Jul 2002 09:14:23 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA27267; Thu, 18 Jul 2002 07:14:22 -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 g6IDEKb19816; Thu, 18 Jul 2002 15:14:20 +0200 (MEST) Date: Thu, 18 Jul 2002 15:13:37 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: Venkatesh Raju Cc: zeroconf@merit.edu Subject: Re: Zeroconf and UPnP In-Reply-To: <7B802811BE77D51189910002A55CFD2C0320AF13@zsc3c032.us.nortel.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Venkatesh, On Wed, 17 Jul 2002, Venkatesh Raju wrote: > I'm curious about the relationship between the Zeroconf working > group and the UPnP forum. While I've not studied the drafts extensively it > appears that both are addressing the same problems and in the same spaces. > If this topic has been discussed below I apologize for bringing it up again; > a pointer to the previous thread would be appreciated! The zeroconf working group is a working group of the ietf. See www.ietf.org. The UPnP forum is an industry consortium. See www.upnp.org. These two organizations have no official relationship. Erik Guttman ZEROCONF cochair From owner-zeroconf@merit.edu Thu Jul 18 09:20: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 JAA01892 for ; Thu, 18 Jul 2002 09:20:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 31A939123B; Thu, 18 Jul 2002 09:21:02 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id AC02D91255; Thu, 18 Jul 2002 09:21: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 6F0869123B for ; Thu, 18 Jul 2002 09:21:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3AC535DEF7; Thu, 18 Jul 2002 09:21:00 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from gw-nl6.philips.com (gw-nl6.philips.com [212.153.235.103]) by segue.merit.edu (Postfix) with ESMTP id C64385DDBA; Thu, 18 Jul 2002 09:20:59 -0400 (EDT) Received: from smtpscan-nl4.philips.com (smtpscan-nl4.philips.com [130.139.36.24]) by gw-nl6.philips.com (Postfix) with ESMTP id AA754A14A4; Thu, 18 Jul 2002 15:20:58 +0200 (MET DST) Received: from smtprelay-nl1.philips.com (localhost [127.0.0.1]) by smtpscan-nl4.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA03595; Thu, 18 Jul 2002 15:20:57 +0200 (MET DST) From: peter.van.der.stok@philips.com Received: from ehv501soh.diamond.philips.com (e3soh01.diamond.philips.com [130.139.54.47]) by smtprelay-nl1.philips.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id PAA22284; Thu, 18 Jul 2002 15:20:57 +0200 (MET DST) To: Venkatesh Raju Cc: owner-zeroconf@merit.edu, zeroconf@merit.edu Subject: Re: Zeroconf and UPnP X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Thu, 18 Jul 2002 15:18:33 +0200 X-MIMETrack: Serialize by Router on ehv501soh/H/SERVER/PHILIPS(Release 5.0.9a |January 7, 2002) at 18/07/2002 15:18:22, Serialize complete at 18/07/2002 15:18:22 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_alternative 004958D2C1256BFA_=" Sender: owner-zeroconf@merit.edu Precedence: bulk This is a multipart message in MIME format. --=_alternative 004958D2C1256BFA_= Content-Type: text/plain; charset="us-ascii" venkatesh, In the UPnP standard a reference exist to AutoIP and an old internet draft of Zeroconf link-local addressing. The expectation is that a reference to the future link-local RFC will be put in the UPnP dependent on thoughts on AutoIP and contents of draft. greetings peter Peter van der Stok Philips Research Laboratories Eindhoven Bldg: WDC 3-041 Prof. Holstlaan 4 Phone: +31 40 2742649 5656 AA Eindhoven Fax: +31 40 2786516 The Netherlands Mailto: Peter.van.der.Stok@ philips.com Erik Guttman Sent by: owner-zeroconf@merit.edu 18-07-2002 15:13 To: Venkatesh Raju cc: zeroconf@merit.edu (bcc: Peter van der Stok/EHV/RESEARCH/PHILIPS) Subject: Re: Zeroconf and UPnP Classification: Venkatesh, On Wed, 17 Jul 2002, Venkatesh Raju wrote: > I'm curious about the relationship between the Zeroconf working > group and the UPnP forum. While I've not studied the drafts extensively it > appears that both are addressing the same problems and in the same spaces. > If this topic has been discussed below I apologize for bringing it up again; > a pointer to the previous thread would be appreciated! The zeroconf working group is a working group of the ietf. See www.ietf.org. The UPnP forum is an industry consortium. See www.upnp.org. These two organizations have no official relationship. Erik Guttman ZEROCONF cochair --=_alternative 004958D2C1256BFA_= Content-Type: text/html; charset="us-ascii"
venkatesh,

In the UPnP standard a reference exist to AutoIP and an old internet draft of Zeroconf link-local addressing.
The expectation is that a reference to the future link-local RFC will be put in the UPnP
dependent on thoughts on AutoIP and contents of draft.

greetings

peter

Peter van der Stok Philips Research Laboratories Eindhoven
Bldg: WDC 3-041 Prof. Holstlaan 4
Phone: +31 40 2742649 5656 AA Eindhoven
Fax: +31 40 2786516 The Netherlands
Mailto: Peter.van.der.Stok@ philips.com

Erik Guttman <Erik.Guttman@Sun.COM>
Sent by: owner-zeroconf@merit.edu

18-07-2002 15:13

To: Venkatesh Raju <orion@nortelnetworks.com>
cc: zeroconf@merit.edu
(bcc: Peter van der Stok/EHV/RESEARCH/PHILIPS)
Subject: Re: Zeroconf and UPnP

Classification:

Venkatesh,

On Wed, 17 Jul 2002, Venkatesh Raju wrote:
> I'm curious about the relationship between the Zeroconf working
> group and the UPnP forum. While I've not studied the drafts extensively it
> appears that both are addressing the same problems and in the same spaces.
> If this topic has been discussed below I apologize for bringing it up again;
> a pointer to the previous thread would be appreciated!

The zeroconf working group is a working group of the ietf.
See www.ietf.org.

The UPnP forum is an industry consortium.
See www.upnp.org.

These two organizations have no official relationship.

Erik Guttman
ZEROCONF cochair

--=_alternative 004958D2C1256BFA_=-- From owner-zeroconf@merit.edu Thu Jul 18 12:40: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 MAA07717 for ; Thu, 18 Jul 2002 12:40:35 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 496C0912CB; Thu, 18 Jul 2002 12:40:12 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA5BF912CD; Thu, 18 Jul 2002 12:40: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 3BA53912CB for ; Thu, 18 Jul 2002 12:40:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 102105DEE1; Thu, 18 Jul 2002 12:40:07 -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 739385DE52 for ; Thu, 18 Jul 2002 12:40:06 -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 g6IGdso10478; Thu, 18 Jul 2002 09:39:55 -0700 (PDT) Received: by zsc4c000.us.nortel.com with Internet Mail Service (5.5.2653.19) id <39AVY85Z>; Thu, 18 Jul 2002 09:39:54 -0700 Message-ID: <7B802811BE77D51189910002A55CFD2C0320B2E8@zsc3c032.us.nortel.com> From: "Venkatesh Raju" To: Erik Guttman , zeroconf@merit.edu Subject: RE: Zeroconf and UPnP Date: Thu, 18 Jul 2002 09:39:52 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C22E79.BD914F14" 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_01C22E79.BD914F14 Content-Type: text/plain; charset="ISO-8859-1" Hi Erik, Thanks for responding! The charter of the two groups appear to be similar although UPnP appears to be looking at an expanded scope - services and applications in addition to address configuration. I guess I'll rephrase my question in a different way: if I were developing say a printer, home router, or other peripheral, would I implement UPnP or zeroconf? Thanks, Venky -----Original Message----- From: Erik Guttman [mailto:Erik.Guttman@Sun.COM] Sent: Thursday, July 18, 2002 6:14 AM To: Raju, Venkatesh [SC101:6909:EXCH] Cc: zeroconf@merit.edu Subject: Re: Zeroconf and UPnP Venkatesh, On Wed, 17 Jul 2002, Venkatesh Raju wrote: > I'm curious about the relationship between the Zeroconf working > group and the UPnP forum. While I've not studied the drafts extensively it > appears that both are addressing the same problems and in the same spaces. > If this topic has been discussed below I apologize for bringing it up again; > a pointer to the previous thread would be appreciated! The zeroconf working group is a working group of the ietf. See www.ietf.org. The UPnP forum is an industry consortium. See www.upnp.org. These two organizations have no official relationship. Erik Guttman ZEROCONF cochair ------_=_NextPart_001_01C22E79.BD914F14 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable RE: Zeroconf and UPnP

Hi Erik,
Thanks for responding! The charter of = the two groups appear to be similar although UPnP appears to be looking = at an expanded scope - services and applications in addition to address = configuration.

I guess I'll rephrase my question in a different way: = if I were developing say a printer, home router, or other peripheral, = would I implement UPnP or zeroconf?

Thanks,
Venky

-----Original Message-----
From: Erik Guttman [mailto:Erik.Guttman@Sun.COM]
Sent: Thursday, July 18, 2002 6:14 AM
To: Raju, Venkatesh [SC101:6909:EXCH]
Cc: zeroconf@merit.edu
Subject: Re: Zeroconf and UPnP

Venkatesh,

On Wed, 17 Jul 2002, Venkatesh Raju wrote:
> I'm curious = about the relationship between the Zeroconf working
> group and the UPnP forum. While I've not = studied the drafts extensively it
> appears that both are addressing the same = problems and in the same spaces.
> If this topic has been discussed below I = apologize for bringing it up again;
> a pointer to the previous thread would be = appreciated!

The zeroconf working group is a working group of the = ietf.
See www.ietf.org.

The UPnP forum is an industry consortium.
See www.upnp.org.

These two organizations have no official = relationship.

Erik Guttman
ZEROCONF cochair

------_=_NextPart_001_01C22E79.BD914F14-- From owner-zeroconf@merit.edu Thu Jul 18 13:34: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 NAA08759 for ; Thu, 18 Jul 2002 13:34:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E24EE912CE; Thu, 18 Jul 2002 13:35:33 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A98C7912CF; Thu, 18 Jul 2002 13:35: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 B87F8912CE for ; Thu, 18 Jul 2002 13:35:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A19D25DE66; Thu, 18 Jul 2002 13:35:32 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 0B0C45DDBA for ; Thu, 18 Jul 2002 13:35:32 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23710; Thu, 18 Jul 2002 10:35:30 -0700 (PDT) Received: from sun.com (vpn-129-159-0-20.EMEA.Sun.COM [129.159.0.20]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with ESMTP id g6IHZSb29391; Thu, 18 Jul 2002 19:35:28 +0200 (MEST) Message-ID: <3D36FC5C.40901@sun.com> Date: Thu, 18 Jul 2002 19:35:24 +0200 From: Erik Guttman User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us, de, fr MIME-Version: 1.0 To: Venkatesh Raju Cc: zeroconf@merit.edu Subject: Re: Zeroconf and UPnP References: <7B802811BE77D51189910002A55CFD2C0320B2E8@zsc3c032.us.nortel.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 Venkatesh Raju wrote: > Thanks for responding! The charter of the two groups appear to be > similar although UPnP appears to be looking at an expanded scope - > services and applications in addition to address configuration. > > I guess I'll rephrase my question in a different way: if I were > developing say a printer, home router, or other peripheral, would I > implement UPnP or zeroconf? Whether a vendor uses IETF standards or proprietary protocols is a decision which we have no influence over. Our goal is to produce the best standards we can. Erik From owner-zeroconf@merit.edu Thu Jul 18 22:57: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 WAA20100 for ; Thu, 18 Jul 2002 22:57:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E18CB91271; Thu, 18 Jul 2002 22:58:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B343691273; Thu, 18 Jul 2002 22:58: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 B574291271 for ; Thu, 18 Jul 2002 22:58:08 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 98BFF5DE6D; Thu, 18 Jul 2002 22:58:08 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from delta.cs.mu.OZ.AU (unknown [133.93.71.210]) by segue.merit.edu (Postfix) with ESMTP id CDE675DDF0 for ; Thu, 18 Jul 2002 22:58:06 -0400 (EDT) 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 g6J2uv812100; Fri, 19 Jul 2002 11:56:58 +0900 (JST) X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 From: Robert Elz To: Erik Guttman Cc: Venkatesh Raju , zeroconf@merit.edu Subject: Re: Zeroconf and UPnP In-Reply-To: <3D36FC5C.40901@sun.com> References: <3D36FC5C.40901@sun.com> <7B802811BE77D51189910002A55CFD2C0320B2E8@zsc3c032.us.nortel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 19 Jul 2002 11:56:57 +0900 Message-ID: <12098.1027047417@munnari.OZ.AU> Sender: owner-zeroconf@merit.edu Precedence: bulk Date: Thu, 18 Jul 2002 19:35:24 +0200 From: Erik Guttman Message-ID: <3D36FC5C.40901@sun.com> | Whether a vendor uses IETF standards or proprietary protocols is a | decision which we have no influence over. Our goal is to produce the | best standards we can. This is all quite true - but is also singularly unhelpful. You might (almost) as well have said that IETF meetings supply coffee to attendees... Another thing that the IETF (and its working groups) do, or should do, is produce applicability statements, to give some guidance to implementors as to exactly when it is appropriate to implement each of the standards that are produced, and when it is not. That kind of thing seems to be what was being requested here, and it is an entirely reasonable request. kre From owner-zeroconf@merit.edu Fri Jul 19 10:38: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 KAA10126 for ; Fri, 19 Jul 2002 10:38:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5420491205; Fri, 19 Jul 2002 10:39:26 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 240BB9123E; Fri, 19 Jul 2002 10:39: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 2231B91205 for ; Fri, 19 Jul 2002 10:39:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0A01B5DE18; Fri, 19 Jul 2002 10:39:25 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from burp.tkv.asdf.org (burp.tkv.asdf.org [212.16.99.49]) by segue.merit.edu (Postfix) with ESMTP id 122BE5DDBF for ; Fri, 19 Jul 2002 10:39:24 -0400 (EDT) Received: (from msa@localhost) by burp.tkv.asdf.org (8.9.3/8.9.3/Debian 8.9.3-21) id RAA17474; Fri, 19 Jul 2002 17:39:17 +0300 Date: Fri, 19 Jul 2002 17:39:17 +0300 Message-Id: <200207191439.RAA17474@burp.tkv.asdf.org> From: Markku Savela To: zeroconf@merit.edu Subject: draft-ietf-zeroconf-ipv4-linklocal-05.txt with IPv6/IPv4 stack Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk It has been dumped on me to implement IPv4 link locals into IPv6/IPv4 stack. In this stack Most of the code is shared between IPv6 and IPv4. Thus, I would have hoped to have as little extra warts as possible in the control paths. In general, the IPv4 link local fits quite well, when you handle them the same as IPv6 link local. The control logic of IPv6 duplicate address detection (DAD) works almost as is with this (by just tweaking the parameters: number of DAD's, etc.). IPv6 does not include the "announcement part" (not a big problem). However, requiring TTL to be 255 whenever source or destination is link local is a bit jarring. It would be nice if both IPv6 and IPv4 had same logic in this. I wonder what would break if I just require the same with IPv6 link locals (most of the link local use there is ND, which already requires hoplimit=255)? From owner-zeroconf@merit.edu Sun Jul 21 21:02: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 VAA12968 for ; Sun, 21 Jul 2002 21:02:23 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4DBD291217; Sun, 21 Jul 2002 21:03:01 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 198B491238; Sun, 21 Jul 2002 21:03: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 21A1491217 for ; Sun, 21 Jul 2002 21:03:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id ED0785DDED; Sun, 21 Jul 2002 21:02:59 -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 BE1D45DDCA for ; Sun, 21 Jul 2002 21:02:59 -0400 (EDT) Received: from fwd11.sul.t-online.de by mailout03.sul.t-online.com with smtp id 17WRbG-00025O-01; Mon, 22 Jul 2002 03:02:58 +0200 Received: from cookie.tjansen.de (520059241914-0001@[217.82.9.115]) by fmrl11.sul.t-online.com with esmtp id 17WRbA-1JCvUeC; Mon, 22 Jul 2002 03:02:52 +0200 From: Tim Jansen Reply-To: tim@tjansen.de To: zeroconf@merit.edu Subject: Relationship DNS-SD and SLP Date: Mon, 22 Jul 2002 03:14:16 +0200 User-Agent: KMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200207220314.16297.ml@tjansen.de> X-Sender: 520059241914-0001@t-dialin.net Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit Hi... I wonder why Zeroconf uses DNS-SD and not SLP. Especially as older MacOS X versions already supported SLP, and now Rendezvous adds DNS-SD. Does SLP have any disadvantages that prevent it from being used for Zeroconf? bye... From owner-zeroconf@merit.edu Sun Jul 21 22:32: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 WAA14657 for ; Sun, 21 Jul 2002 22:32:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D313B91244; Sun, 21 Jul 2002 22:33:08 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 98B4891248; Sun, 21 Jul 2002 22:33: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 BB44191244 for ; Sun, 21 Jul 2002 22:33:07 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A91AB5DE58; Sun, 21 Jul 2002 22:33:07 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 3CE5C5DE47 for ; Sun, 21 Jul 2002 22:33:07 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g6M1ddk29885; Sun, 21 Jul 2002 18:39:39 -0700 Date: Sun, 21 Jul 2002 18:39:38 -0700 (PDT) From: Bernard Aboba To: tim@tjansen.de Cc: zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP In-Reply-To: <200207220314.16297.ml@tjansen.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > I wonder why Zeroconf uses DNS-SD and not SLP. Especially as older MacOS X > versions already supported SLP, and now Rendezvous adds DNS-SD. Does SLP have > any disadvantages that prevent it from being used for Zeroconf? mDNS is not a service discovery protocol, it is a name resolution protocol. Nowhere in the Zeroconf documents is mDNS described as a service discovery protocol, and the mDNS document itself (draft-ietf-dnsext-mdns-10.txt) explicitly states that it is not about service discovery. So I'm curious as to how you came to this conclusion. From owner-zeroconf@merit.edu Mon Jul 22 02:16: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 CAA26446 for ; Mon, 22 Jul 2002 02:16:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 669DD9120A; Mon, 22 Jul 2002 02:17:37 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 363229121F; Mon, 22 Jul 2002 02:17: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 4CC6F9120A for ; Mon, 22 Jul 2002 02:17:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2EA485DF12; Mon, 22 Jul 2002 02:17:36 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id A38FB5DE29 for ; Mon, 22 Jul 2002 02:17:35 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g6M5O5131834; Sun, 21 Jul 2002 22:24:05 -0700 Date: Sun, 21 Jul 2002 22:24:05 -0700 (PDT) From: Bernard Aboba To: Aidan Williams Cc: tim@tjansen.de, , Stuart Cheshire Subject: Re: Relationship DNS-SD and SLP In-Reply-To: <3D3B8C1B.69DF4550@motorola.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > One thing that does bother me is the link-local nature dns-sd (via its > mDNS heritage). That seems to limit scalability and also makes life > hard in small routed networks. I think you've got it backwards. It is the m(ulticast) in mDNS that creates a potential scalability problem. One response to that is to limit the scope of the multicast. Hence, linklocal multicast name resolution (LLMNR). Other responses could also be imagined, such as the multicast supression mechanisms found in SLPv2. However, the DNSEXT WG was concerned about the potential issues in expanding the scope of mDNS beyond linklocal, and unimpressed with the rationale for doing so, given the ubiquity of unicast DNS. From owner-zeroconf@merit.edu Mon Jul 22 02:32: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 CAA26728 for ; Mon, 22 Jul 2002 02:32:59 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 00D2D9121F; Mon, 22 Jul 2002 02:33:49 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C2D3E91248; Mon, 22 Jul 2002 02: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 D50C09121F for ; Mon, 22 Jul 2002 02:33:47 -0400 (EDT) Received: by segue.merit.edu (Postfix) id B1B805DE29; Mon, 22 Jul 2002 02:33: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 38F245DE05 for ; Mon, 22 Jul 2002 02:33:47 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g6M5eHK31962; Sun, 21 Jul 2002 22:40:17 -0700 Date: Sun, 21 Jul 2002 22:40:17 -0700 (PDT) From: Bernard Aboba To: Aidan Williams Cc: tim@tjansen.de, , Stuart Cheshire Subject: Re: Relationship DNS-SD and SLP In-Reply-To: <3D3B8C1B.69DF4550@motorola.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > It seems like just about any request response > protocol can be pressed into use for service discovery. If this is true, I'd suggest that it is only because the "problem" is not sufficiently well defined. As Erik has pointed out many times, there is an important distinction between finding *an* instance of a service (any instance, the "closest" instance, the "least loaded" instance, etc.) and a *particular* instance of a service with a given set of characteristics. The latter problem is the one to which the term "service discovery" is typically applied, at least within the IETF. I'd also note that just because it may be possible to discover a service in many different ways, that does not mean that all these ways should be implemented. On the Internet, it is not always true that having N ways to do something is better than having a single, interoperable way to do something. > The most useful property of a service location protocol is that it > be reasonably ubiquitous. If ubiquity were the most useful property of a service location protocol then there would be no need for an IP service location protocol at all, since Novell IPX, Microsoft NetBEUI, and AppleTalk have had this functionality for many years. Rather, the most important property of a service location protocol is that it solves the stated problem, and does so with the desired scalability. > Right at the moment we seem to be creating > a new mechanism for each new service discovery scenario we encounter, > and I'm not sure that heads us in the right direction. I'm not sure who the "we" refers to in this sentence. It does not appear that any IETF WG (or even the IETF as a whole) is guilty of this. Perhaps you are thinking about "IPv6 configuration" rather than service discovery? That shoe might fit better. From owner-zeroconf@merit.edu Mon Jul 22 02:34: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 CAA26799 for ; Mon, 22 Jul 2002 02:34:07 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1276591248; Mon, 22 Jul 2002 02:34:57 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D242A9124F; Mon, 22 Jul 2002 02:34: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 D66F391248 for ; Mon, 22 Jul 2002 02:34:55 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C59AF5DF6E; Mon, 22 Jul 2002 02:34:55 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mta05bw.bigpond.com (mta05bw.bigpond.com [139.134.6.95]) by segue.merit.edu (Postfix) with ESMTP id B9E025DF59 for ; Mon, 22 Jul 2002 02:34:54 -0400 (EDT) Received: from pc-00084 ([144.135.24.78]) by mta05bw.bigpond.com (Netscape Messaging Server 4.15 mta05bw May 23 2002 23:53:28) with SMTP id GZN0Y100.C6H; Mon, 22 Jul 2002 16:34:49 +1000 Received: from CPE-203-51-25-224.nsw.bigpond.net.au ([203.51.25.224]) by bwmam04.mailsvc.email.bigpond.com(MailRouter V3.0n 29/18651291); 22 Jul 2002 16:34:48 From: Brad Hards To: Bernard Aboba , tim@tjansen.de Subject: Re: Relationship DNS-SD and SLP Date: Mon, 22 Jul 2002 16:30:44 +1000 User-Agent: KMail/1.4.5 Cc: zeroconf@merit.edu 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: <200207221630.44841.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Mon, 22 Jul 2002 11:39, Bernard Aboba wrote: > > I wonder why Zeroconf uses DNS-SD and not SLP. Especially as older MacOS > > X versions already supported SLP, and now Rendezvous adds DNS-SD. Does > > SLP have any disadvantages that prevent it from being used for Zeroconf? > > mDNS is not a service discovery protocol, it is a name resolution > protocol. Nowhere in the Zeroconf documents is mDNS described as a service > discovery protocol, and the mDNS document itself > (draft-ietf-dnsext-mdns-10.txt) explicitly states that it is not about > service discovery. Tim's question doesn't mention multicast DNS, AFAICS. DNS Service Discovery isn't really about multicast DNS, it is kind of a complementary peer. Tim: I asked Stuart Cheshire almost exactly the same question, and he pointed to http://files.dns-sd.org/draft-cheshire-dnsext-nbp.txt (I'd point you to section 3, to save time). > So I'm curious as to how you came to this conclusion. Bernard: I'm curious why you confused these issues. Brad -- http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. From owner-zeroconf@merit.edu Mon Jul 22 04:46: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 EAA28638 for ; Mon, 22 Jul 2002 04:46:06 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7543291221; Mon, 22 Jul 2002 04:46:57 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 3D08391250; Mon, 22 Jul 2002 04:46: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 0E4E391221 for ; Mon, 22 Jul 2002 04:46:56 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E88285DE0A; Mon, 22 Jul 2002 04:46:55 -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 C40525DDC1 for ; Mon, 22 Jul 2002 04:46:51 -0400 (EDT) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate4.mot.com (motgate4 2.1) with ESMTP id BAA11259; Mon, 22 Jul 2002 01:46:46 -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 BAA21194; Mon, 22 Jul 2002 01:46:43 -0700 (MST)] Received: from motorola.com ([10.238.2.130]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g6M8kdnw004931; Mon, 22 Jul 2002 18:46:39 +1000 (EST) Message-ID: <3D3BC66F.2303E4DC@motorola.com> Date: Mon, 22 Jul 2002 18:46:39 +1000 From: Aidan Williams X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: tim@tjansen.de, zeroconf@merit.edu, Stuart Cheshire Subject: Re: Relationship DNS-SD and SLP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > > One thing that does bother me is the link-local nature dns-sd (via its > > mDNS heritage). That seems to limit scalability and also makes life > > hard in small routed networks. > > I think you've got it backwards. It is the m(ulticast) in mDNS that > creates a potential scalability problem. One response to that is to limit > the scope of the multicast. Hence, linklocal multicast name resolution > (LLMNR). > Backwards might be a matter of which way you are facing.. ;) I would like it to be able to "scale" above a single link. In particular, I have a home gateway box that routes between networks (private ipv4 and 6to4 ipv6), and I need something special to make LLMNR work between links. (I seem to recall pushback against supporting this by bridging the requests through the router, and pushback against mapping LLMNR names into the unicast dns namespace). > However, the DNSEXT WG was concerned about the potential issues in > expanding the scope of mDNS beyond linklocal, and unimpressed with > the rationale for doing so, given the ubiquity of unicast DNS. Maybe you could summarise that discussion. I certainly don't have a clear understanding of what the problems were said to be. The ubiquity of unicast DNS doesn't help a whole lot if it has to be configured. In the case of my routed gateway a non-LL MNR is appealing. - aidan From owner-zeroconf@merit.edu Mon Jul 22 05:34: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 FAA29430 for ; Mon, 22 Jul 2002 05:34:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 6C31191228; Mon, 22 Jul 2002 05:35:32 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 35E2491250; Mon, 22 Jul 2002 05:35: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 E513291228 for ; Mon, 22 Jul 2002 05:35:30 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C556D5DF9E; Mon, 22 Jul 2002 05:35:30 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from motgate4.mot.com (unknown [144.189.100.102]) by segue.merit.edu (Postfix) with ESMTP id 6293E5DDBE for ; Mon, 22 Jul 2002 05:35:30 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id CAA01898; Mon, 22 Jul 2002 02:35:22 -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 CAA19266; Mon, 22 Jul 2002 02:35:30 -0700 (MST)] Received: from motorola.com ([10.238.2.130]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g6M9Z9nw011022; Mon, 22 Jul 2002 19:35:13 +1000 (EST) Message-ID: <3D3BD1CD.8DB89ABC@motorola.com> Date: Mon, 22 Jul 2002 19:35:09 +1000 From: Aidan Williams X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bernard Aboba Cc: tim@tjansen.de, zeroconf@merit.edu, Stuart Cheshire Subject: Re: Relationship DNS-SD and SLP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Bernard Aboba wrote: > > > It seems like just about any request response > > protocol can be pressed into use for service discovery. > > If this is true, I'd suggest that it is only because the "problem" is not > sufficiently well defined. As Erik has pointed out many times, there is > an important distinction between finding *an* instance of a service (any > instance, the "closest" instance, the "least loaded" instance, etc.) and a > *particular* instance of a service with a given set of characteristics. > The latter problem is the one to which the term "service discovery" is > typically applied, at least within the IETF. > I certainly agree about the problem definition part, although I wonder if we have a plethora of solutions because service discovery can be looked at in so many ways (e.g. configuring the NTP information vs discovering an available NTP server vs anycast routing to the closest NTP server). Maybe I'm being unfair, but the great thing appears to be that the problem can be defined to match the solution already thought of. I might be missing something, but a protocol for locating "particular" services seems to be a superset of a protocol that locates "any" service. ("closest" seems to require topology info, which is harder). > I'd also note that just because it may be possible to discover a service > in many different ways, that does not mean that all these ways should be > implemented. On the Internet, it is not always true that having N ways to > do something is better than having a single, interoperable way to do > something. > Do you think this is true for service discovery? > > The most useful property of a service location protocol is that it > > be reasonably ubiquitous. > > If ubiquity were the most useful property of a service location > protocol then there would be no need for an IP service location > protocol at all, since Novell IPX, Microsoft NetBEUI, and AppleTalk > have had this functionality for many years. > I'm not following you. It seems to me that an IP service location protocol is required because the other ones you mentioned aren't IP (unless you count running them on top of IP). Or, if they all run on top of IP, why did the IETF invent SLP? NIH? > Rather, the most important property of a service location protocol is that > it solves the stated problem, and does so with the desired scalability. > To me this statement doesn't say much more than "X should work". If there are several protocols that do basically "work" do we just use them all? Maybe each protocol should be thought of as defining one standard mechanism for how it should be discovered. > > Right at the moment we seem to be creating > > a new mechanism for each new service discovery scenario we encounter, > > and I'm not sure that heads us in the right direction. > > I'm not sure who the "we" refers to in this sentence. It does not appear > that any IETF WG (or even the IETF as a whole) is guilty of this. Perhaps > you are thinking about "IPv6 configuration" rather than service discovery? > That shoe might fit better. I was referring (rather grandiosely) to the IETF in general. Yes, the debate about DNS service discovery springs to mind however it isn't the only one. -- 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 Mon Jul 22 09:02: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 JAA03163 for ; Mon, 22 Jul 2002 09:02:58 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D5DA191257; Mon, 22 Jul 2002 09:01:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9D62B91258; Mon, 22 Jul 2002 09:01: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 B1DCD91257 for ; Mon, 22 Jul 2002 09:01:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 8D5675DFAF; Mon, 22 Jul 2002 09:01:13 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 1CF5E5DDAB for ; Mon, 22 Jul 2002 09:01:13 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g6MC7g303579; Mon, 22 Jul 2002 05:07:42 -0700 Date: Mon, 22 Jul 2002 05:07:41 -0700 (PDT) From: Bernard Aboba To: Aidan Williams Cc: tim@tjansen.de, , Stuart Cheshire Subject: Re: Relationship DNS-SD and SLP In-Reply-To: <3D3BC66F.2303E4DC@motorola.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > > However, the DNSEXT WG was concerned about the potential issues in > > expanding the scope of mDNS beyond linklocal, and unimpressed with > > the rationale for doing so, given the ubiquity of unicast DNS. > > Maybe you could summarise that discussion. I certainly don't have a > clear understanding of what the problems were said to be. Basically, home gateways often implement DHCP/DNS proxy, so that if a router is present there is no apparent need for mDNS. > The ubiquity of unicast DNS doesn't help a whole lot if it has to be > configured. In the case of my routed gateway a non-LL MNR is appealing. Since the home gateway is itself the DNS proxy, there is no configuration required. From owner-zeroconf@merit.edu Mon Jul 22 10:36:29 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 KAA05312 for ; Mon, 22 Jul 2002 10:36:29 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0B6F49122A; Mon, 22 Jul 2002 10:37:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CB59C9125A; Mon, 22 Jul 2002 10:37: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 B50679122A for ; Mon, 22 Jul 2002 10:37:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 996BE5DF92; Mon, 22 Jul 2002 10:37:16 -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 3C5695DE6E for ; Mon, 22 Jul 2002 10:37:16 -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 IAA15676; Mon, 22 Jul 2002 08:36:59 -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 g6MEavb22610; Mon, 22 Jul 2002 16:36:57 +0200 (MEST) Date: Mon, 22 Jul 2002 16:36:15 +0200 (CEST) From: Erik Guttman X-Sender: erikg@field To: Aidan Williams Cc: Bernard Aboba , tim@tjansen.de, zeroconf@merit.edu, Stuart Cheshire Subject: Re: Relationship DNS-SD and SLP In-Reply-To: <3D3BD1CD.8DB89ABC@motorola.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Mon, 22 Jul 2002, Aidan Williams wrote: > Bernard Aboba wrote: > > > > > It seems like just about any request response > > > protocol can be pressed into use for service discovery. > > > > If this is true, I'd suggest that it is only because the "problem" is not > > sufficiently well defined. As Erik has pointed out many times, there is > > an important distinction between finding *an* instance of a service (any > > instance, the "closest" instance, the "least loaded" instance, etc.) and a > > *particular* instance of a service with a given set of characteristics. > > The latter problem is the one to which the term "service discovery" is > > typically applied, at least within the IETF. > > > > I certainly agree about the problem definition part, although I wonder > if we have a plethora of solutions because service discovery can be > looked at in so many ways (e.g. configuring the NTP information vs > discovering an available NTP server vs anycast routing to the closest > NTP server). Maybe I'm being unfair, but the great thing appears to > be that the problem can be defined to match the solution already > thought of. > > I might be missing something, but a protocol for locating "particular" > services seems to be a superset of a protocol that locates "any" > service. ("closest" seems to require topology info, which is harder). These are different problems. For many services 'any' is OK, nearest is GREAT. For some services (like file servers, databases, anything with a physical location you care about, limited access or specific data you can't get anywhere else) - you need to find a particular service. > > I'd also note that just because it may be possible to discover a service > > in many different ways, that does not mean that all these ways should be > > implemented. On the Internet, it is not always true that having N ways to > > do something is better than having a single, interoperable way to do > > something. > > > > Do you think this is true for service discovery? There are several issues surrounding service discovery which could be much better handled in a single protocol. Otherwise it is very difficult to get uniform behavior for a user. 1) security - which services can advertise themselves? what configuration do services, clients and infrastructure need? what is the policy - what does one do with unauthenticated services one discovers? 2) organization - what administrative hierarchy is presented for browsing? 3) performance - what does the administrator have to improve performance? 4) parameters - what parameters can one obtain for services from the service discovery mechanism to configure clients (beyond merely the address of the server)? what is the 'schema' for these parameters? 5) naming - what are service names? 6) management - what does an administrator have to do to 'set up' a group of clients and servers so that all the clients in the enterprise can discover all the same set of services? How can this be controlled? 7) internet what has to happen to the protocol to make it scale resource to the internet - so services can be discovered in discovery - other administrative domains? This is only a partial list. Its pretty hard to get these things right for even a single service discovery protocol. I believe it would be impossible to do if every protocol had its own discovery mechanism. Erik From owner-zeroconf@merit.edu Mon Jul 22 14:32: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 OAA25789 for ; Mon, 22 Jul 2002 14:32:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 386669128A; Mon, 22 Jul 2002 14:33:09 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 546EB91289; Mon, 22 Jul 2002 14:33: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 30A579128B for ; Mon, 22 Jul 2002 14:32:43 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0CF845DDDC; Mon, 22 Jul 2002 14:32:43 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by segue.merit.edu (Postfix) with ESMTP id CF8815DDB3 for ; Mon, 22 Jul 2002 14:32:42 -0400 (EDT) Received: from fwd06.sul.t-online.de by mailout07.sul.t-online.com with smtp id 17Whyz-000545-0C; Mon, 22 Jul 2002 20:32:33 +0200 Received: from cookie.tjansen.de (520059241914-0001@[217.226.24.70]) by fmrl06.sul.t-online.com with esmtp id 17Whys-0QxLG4C; Mon, 22 Jul 2002 20:32:26 +0200 From: Tim Jansen Reply-To: tim@tjansen.de To: Brad Hards Subject: Re: Relationship DNS-SD and SLP Date: Mon, 22 Jul 2002 20:44:14 +0200 User-Agent: KMail/1.4.5 References: <200207221630.44841.bhards@bigpond.net.au> In-Reply-To: <200207221630.44841.bhards@bigpond.net.au> Cc: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200207222044.14830.ml@tjansen.de> X-Sender: 520059241914-0001@t-dialin.net Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Monday 22 July 2002 08:30, Brad Hards wrote: > Tim: I asked Stuart Cheshire almost exactly the same question, and he > pointed to http://files.dns-sd.org/draft-cheshire-dnsext-nbp.txt > (I'd point you to section 3, to save time). Thanks, this is what I was looking for. Its arguments did not convince me though. 1. If a user-friendly name for a SLP SA is needed, you can put it into an attribute 2. You can append those attributes to the URL if you need to display them to the user (for example "service:printer:http://169.254.17.202;(name=Epson Stylus 900n)") 3. If you need a persistent identifier for a SA or device and the host name or IP is not persistent, you can put an identifier in an attribute (for example a large random number or a ethernet hardware address). bye... From owner-zeroconf@merit.edu Mon Jul 22 15:35: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 PAA01533 for ; Mon, 22 Jul 2002 15:35:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C842D9128C; Mon, 22 Jul 2002 15:36:43 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9A35C9128E; Mon, 22 Jul 2002 15:36: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 3F53C9128C for ; Mon, 22 Jul 2002 15:36:41 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 273035DDD0; Mon, 22 Jul 2002 15:36: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 CC9695DDA7 for ; Mon, 22 Jul 2002 15:36:40 -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 g6MJadk16258 for ; Mon, 22 Jul 2002 12:36:39 -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, 22 Jul 2002 12:36:01 -0700 Received: from [206.111.147.156] (vpn-gh-65.apple.com [17.254.136.64]) by scv3.apple.com (8.11.3/8.11.3) with SMTP id g6MJadT23727 for ; Mon, 22 Jul 2002 12:36:39 -0700 (PDT) Message-Id: <200207221936.g6MJadT23727@scv3.apple.com> Subject: Re: DELIVERY FAILURE: User spencer.giacalone (spencer.giacalone@predictive.com) not listed in public Name & Address Book Date: Mon, 22 Jul 2002 12:36:42 -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 Apologies for all the annoying "DELIVERY FAILURE" messages. I have manually removed "spencer.giacalone@predictive.com" from the list, so they should stop now. If you are still out there somewhere Spencer, I apologise for having to do this. Please contact me, or just re-join the list yourself with a new email address. Thanks. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-zeroconf@merit.edu Mon Jul 22 18:40: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 SAA17229 for ; Mon, 22 Jul 2002 18:40:34 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0F8A791229; Mon, 22 Jul 2002 18:41:24 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id D17C29122E; Mon, 22 Jul 2002 18:41: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 B102A91229 for ; Mon, 22 Jul 2002 18:41:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9272B5DD99; Mon, 22 Jul 2002 18:41:22 -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 29E8F5DE1C for ; Mon, 22 Jul 2002 18:41:22 -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 g6MMfBt20518; Mon, 22 Jul 2002 18:41:11 -0400 (EDT) Message-Id: <200207222241.g6MMfBt20518@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bernard Aboba Cc: tim@tjansen.de, zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP In-reply-to: (Your message of "Sun, 21 Jul 2002 18:39:38 PDT.") Date: Mon, 22 Jul 2002 18:41:11 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > I wonder why Zeroconf uses DNS-SD and not SLP. Especially as older MacOS X > > versions already supported SLP, and now Rendezvous adds DNS-SD. Does SLP have > > any disadvantages that prevent it from being used for Zeroconf? > > mDNS is not a service discovery protocol, it is a name resolution protocol. perhaps a more relevant question is, why is a name resolution protocol more appropriate for ad hoc networks than a service discovery protocol? I don't think it is. first because part of the definition of an ad hoc network is that you cannot assume a central authority for name assignment. second, if you want devices to ship and be able to work out of the box then you can't expect them to have DNS names that are both meaningful to humans and relative to some DNS tree. the most they can reasonably expect to do is advertise their characteristics, and SLP seems like a better fit for that. third, a lot of the problem with the linklocal proposal is the idea that these things should ever appear in DNS - where they can confuse applications that aren't prepared to deal with limited-scope addresses that can fail to work at any time. Keith From owner-zeroconf@merit.edu Mon Jul 22 20:21: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 UAA25355 for ; Mon, 22 Jul 2002 20:21:44 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 4FF9691231; Mon, 22 Jul 2002 20:22:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 17BFA91232; Mon, 22 Jul 2002 20:22: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 E17D691231 for ; Mon, 22 Jul 2002 20:22:32 -0400 (EDT) Received: by segue.merit.edu (Postfix) id C6B0F5DDCA; Mon, 22 Jul 2002 20:22:32 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mta01bw.bigpond.com (mta01bw.bigpond.com [139.134.6.78]) by segue.merit.edu (Postfix) with ESMTP id 874205DD8E for ; Mon, 22 Jul 2002 20:22:31 -0400 (EDT) Received: from 192.168.1.248 ([144.135.24.87]) by mta01bw.bigpond.com (Netscape Messaging Server 4.15 mta01bw May 23 2002 23:53:28) with SMTP id GZOEDG00.223; Tue, 23 Jul 2002 10:22:28 +1000 Received: from CPE-203-51-25-117.nsw.bigpond.net.au ([203.51.25.117]) by bwmam07.mailsvc.email.bigpond.com(MailRouter V3.0n 56/12110662); 23 Jul 2002 10:22:25 From: Brad Hards To: Keith Moore , Bernard Aboba Subject: Re: Relationship DNS-SD and SLP Date: Tue, 23 Jul 2002 10:17:59 +1000 User-Agent: KMail/1.4.5 Cc: zeroconf@merit.edu References: <200207222241.g6MMfBt20518@astro.cs.utk.edu> In-Reply-To: <200207222241.g6MMfBt20518@astro.cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200207231017.59566.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, 23 Jul 2002 08:41, Keith Moore wrote: > > > I wonder why Zeroconf uses DNS-SD and not SLP. Especially as older > > > MacOS X versions already supported SLP, and now Rendezvous adds DNS-SD. > > > Does SLP have any disadvantages that prevent it from being used for > > > Zeroconf? > > > > mDNS is not a service discovery protocol, it is a name resolution > > protocol. > > perhaps a more relevant question is, why is a name resolution protocol more > appropriate for ad hoc networks than a service discovery protocol? > > I don't think it is. > > first because part of the definition of an ad hoc network is that you > cannot assume a central authority for name assignment. Agreed. In fact, you can safely assume that there is not such an authority. > second, if you want devices to ship and be able to work out of the box then > you can't expect them to have DNS names that are both meaningful to humans > and relative to some DNS tree. the most they can reasonably expect to do > is advertise their characteristics, and SLP seems like a better fit for > that. Confusion. I think of DNS as a tool that turns (as if by magic) some kind of name into some kind of address (that Just Works[tm]), and can turn it back again as well. Tree is an implementation detail for scalability. All I want out of a zeroconf naming system is to be able to put a name in to my GUI, and be able to access the thing with that name. If I have two identical printers, I'd be happy to be able to change the name on one of them, especially if someone told me to do so. I don't want printer X to require that laptop Y is turned on and running though, if I'm trying to print from workstation Z. What I want out of a zeroconf service discovery system is to be able to put in some combination of attributes (possibly none), and be offered a choice of services on my network. I don't care much about the names or IP addresses, just what that service can do. For example, I care that it is an colour printer, and doesn't have much queued work, and is in the west end of the building, not that it has the name "bolo-meister". > third, a lot of the problem with the linklocal proposal is the idea that > these things should ever appear in DNS - where they can confuse > applications that aren't prepared to deal with limited-scope addresses that > can fail to work at any time. Some applications can't handle IPv6. That is a bug too. What worries me is that we don't (AFAICT) have a standard set of attributes and naming conventions for services. For example, how do I find a colour printer without much work on my floor. What would that look like for SLP or DNS-SD or any other sevice discovery system? Or "who has the network storage with the engineering groups files?" Or "who has a link to the internet that will cost less than 1c/megabyte?" Note: I'm not looking for _a_ way to do this, I'm looking for _the_ way to do this, that will work in general. Brad -- http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. From owner-zeroconf@merit.edu Mon Jul 22 20:43: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 UAA27040 for ; Mon, 22 Jul 2002 20:43:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id E895C91291; Mon, 22 Jul 2002 20:44:26 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id B412F91292; Mon, 22 Jul 2002 20:44: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 B665091291 for ; Mon, 22 Jul 2002 20:44:25 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9CE7E5DE9F; Mon, 22 Jul 2002 20:44:25 -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 4D25F5DD8E for ; Mon, 22 Jul 2002 20:44:25 -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 g6N0iNA13076 for ; Mon, 22 Jul 2002 17:44:23 -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, 22 Jul 2002 17:43:44 -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 g6N0iNl03493 for ; Mon, 22 Jul 2002 17:44:23 -0700 (PDT) Date: Mon, 22 Jul 2002 17:44:23 -0700 Subject: Re: Relationship DNS-SD and SLP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v536) From: Joshua Graessley To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <200207222241.g6MMfBt20518@astro.cs.utk.edu> Message-Id: <54ED9A8E-9DD5-11D6-8F67-000393760260@apple.com> X-Mailer: Apple Mail (2.536) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, July 22, 2002, at 03:41 PM, Keith Moore wrote: >>> I wonder why Zeroconf uses DNS-SD and not SLP. Especially as older >>> MacOS X >>> versions already supported SLP, and now Rendezvous adds DNS-SD. Does >>> SLP have >>> any disadvantages that prevent it from being used for Zeroconf? >> >> mDNS is not a service discovery protocol, it is a name resolution >> protocol. > > perhaps a more relevant question is, why is a name resolution protocol > more > appropriate for ad hoc networks than a service discovery protocol? > > I don't think it is. DNS is not just a name resolution protocol. DNS is a distributed database. One of the functions it serves is name to address resolution. DNS already has a record type for services, it just hasn't been used much yet. > first because part of the definition of an ad hoc network is that you > cannot > assume a central authority for name assignment. This is why multicast DNS is used instead of unicast DNS. > second, if you want devices to ship and be able to work out of the box > then > you can't expect them to have DNS names that are both meaningful to > humans > and relative to some DNS tree. the most they can reasonably expect to > do > is advertise their characteristics, and SLP seems like a better fit > for that. The problem with SLP, in my opinion, is that it is overly complicated. The complication arises from the goal of advertising all of the characteristics of services and supporting very specific queries. While a DNS host name is limited in the characters that may be used, the DNS packet format has no such restrictions. In addition, there is no reason that a host name should have anything to do with the service that host is advertising. This seems to be something SLP has overlooked. > third, a lot of the problem with the linklocal proposal is the idea > that > these things should ever appear in DNS - where they can confuse > applications > that aren't prepared to deal with limited-scope addresses that can > fail to > work at any time. What do issues with linklocal address assignment have to do with using multicast DNS to discover local services? -josh From owner-zeroconf@merit.edu Mon Jul 22 23:34:36 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 XAA11734 for ; Mon, 22 Jul 2002 23:34:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 5DDEA9129E; Mon, 22 Jul 2002 23:33:19 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4A1A8912A0; Mon, 22 Jul 2002 23:33: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 C46B09129F for ; Mon, 22 Jul 2002 23:31:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A60095DE50; Mon, 22 Jul 2002 23:31:21 -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 67ED75DDA0 for ; Mon, 22 Jul 2002 23:31:21 -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 g6N3VBt21296; Mon, 22 Jul 2002 23:31:12 -0400 (EDT) Message-Id: <200207230331.g6N3VBt21296@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brad Hards Cc: Keith Moore , Bernard Aboba , zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP In-reply-to: (Your message of "Tue, 23 Jul 2002 10:17:59 +1000.") <200207231017.59566.bhards@bigpond.net.au> Date: Mon, 22 Jul 2002 23:31:11 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > > > I wonder why Zeroconf uses DNS-SD and not SLP. Especially as older > > > > MacOS X versions already supported SLP, and now Rendezvous adds DNS-SD. > > > > Does SLP have any disadvantages that prevent it from being used for > > > > Zeroconf? > > > > > > mDNS is not a service discovery protocol, it is a name resolution > > > protocol. > > > > perhaps a more relevant question is, why is a name resolution protocol more > > appropriate for ad hoc networks than a service discovery protocol? > > > > I don't think it is. > > > > first because part of the definition of an ad hoc network is that you > > cannot assume a central authority for name assignment. > Agreed. In fact, you can safely assume that there is not such an authority. > > > second, if you want devices to ship and be able to work out of the box then > > you can't expect them to have DNS names that are both meaningful to humans > > and relative to some DNS tree. the most they can reasonably expect to do > > is advertise their characteristics, and SLP seems like a better fit for > > that. > Confusion. I think of DNS as a tool that turns (as if by magic) some kind of > name into some kind of address (that Just Works[tm]), and can turn it back > again as well. Tree is an implementation detail for scalability. okay, then you're not talking about DNS names anymore, because apps can't depend on those names to have the properties that DNS names have such as global uniqueness. so you don't want to use the same API to look them up that you use to make DNS queries, because that will confuse apps that expect the names and answers returned from that interface to act like DNS. and there's no particular reason to use the DNS protocol, because most of the RR types in DNS implicitly assume some kind of distributed management that is not present in an ad hoc system. > What I want out of a zeroconf service discovery system is to be able to put > in some combination of attributes (possibly none), and be offered a choice of > services on my network. I don't care much about the names or IP addresses, > just what that service can do. I think you do care about the names and IP addresses because once you've identified a service that you want to use then you want to know how to talk to it. If you let the user choose which device/service to use then you want to present the name to the user in a menu. Just because you didn't start your query with a name doesn't mean you don't care about the name. Of course if you have a service discovery system (and it seens like you need one) then you don't need the pseudo-DNS anymore, because you can look up the device/service names just as easily using the service discovery system. > > third, a lot of the problem with the linklocal proposal is the idea that > > these things should ever appear in DNS - where they can confuse > > applications that aren't prepared to deal with limited-scope addresses that > > can fail to work at any time. > Some applications can't handle IPv6. That is a bug too. I don't see what one has to do with the other. IPv6 doesn't interfere with apps that don't know about IPv6 - they never see the IPv6 addresses because they don't ever do AAAA queries. whereas IPv4 linklocal addresses do have the potential to interfere with IPv4 apps if those addresses show up in contexts (like DNS results) where better-behaved IPv4 addresses usually appear. of course with NATs etc IPv4 is pretty much of a mess anyway, but LLs make it worse, partially because apps end up having to treat LL addresses differently than other addresses. > What worries me is that we don't (AFAICT) have a standard set of > attributes and naming conventions for services. For example, how do > I find a colour printer without much work on my floor. What would that > look like for SLP or DNS-SD or any other sevice discovery system? well we won't solve that problem for an unmanaged network until we figure out a way for devices to discover their location without help (not that hard by itself) relative to their physical surroundings (much harder) so that the searcher can figure out the concept of "on my floor" (presumably in the same building) by itself. > Or "who has the network storage with the engineering groups files?" same thing - "engineering group" inherently requires management > Or "who has a link to the internet that will cost less than 1c/megabyte?" same thing - cost requires management, not to mention the management needed to authenticate for billing purposes. so none of the above are problems for zeroconf to tackle. that said, having a standard, local, service discovery facility *would* be useful, while trying to replicate DNS doesn't seem very useful at all for this environment. > Note: I'm not looking for _a_ way to do this, I'm looking for _the_ way > to do this, that will work in general. I don't think there will ever be "the" way of doing service discovery - there's a fair amount of evidence that you need a variety of service discovery methods depending on the nature of your search. Keith From owner-zeroconf@merit.edu Tue Jul 23 00:16: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 AAA14857 for ; Tue, 23 Jul 2002 00:16:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 2583E91308; Tue, 23 Jul 2002 00:15:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A3D5D9130A; Tue, 23 Jul 2002 00:15: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 F33D591308 for ; Tue, 23 Jul 2002 00:15:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 11ED15DE40; Tue, 23 Jul 2002 00:15:26 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from internaut.com (unknown [64.38.134.99]) by segue.merit.edu (Postfix) with ESMTP id 4DB3D5DDF9 for ; Tue, 23 Jul 2002 00:15:25 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g6N3Lcg11547; Mon, 22 Jul 2002 20:21:38 -0700 Date: Mon, 22 Jul 2002 20:21:38 -0700 (PDT) From: Bernard Aboba To: Keith Moore Cc: Brad Hards , Subject: Re: Relationship DNS-SD and SLP In-Reply-To: <200207230331.g6N3VBt21296@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > okay, then you're not talking about DNS names anymore, because apps can't > depend on those names to have the properties that DNS names have such as > global uniqueness. If application difficulties were as great as you make them seen, then why is it so easy for applications to work both with an /etc/hosts file and with DNS? > so you don't want to use the same API to look them > up that you use to make DNS queries, because that will confuse apps that > expect the names and answers returned from that interface to act like DNS. Given that operating systems have supported multiple name resolution mechanisms for decades now based on the same APIs with no ill effects, this concern hardly seems justified. > and there's no particular reason to use the DNS protocol, because most of > the RR types in DNS implicitly assume some kind of distributed management > that is not present in an ad hoc system. Nope. RR types in DNS make no such assumptions; it is resolvers that make the assumptions, and resolvers can change to provide seamless support to applications, as they have done for decades. > Of course if you have a service discovery system (and it seens like you > need one) then you don't need the pseudo-DNS anymore, because you can > look up the device/service names just as easily using the service > discovery system. Not true. How does service discovery enable the resolution of "ping foo"? From owner-zeroconf@merit.edu Tue Jul 23 00: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 AAA15288 for ; Tue, 23 Jul 2002 00:21:55 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D09D491301; Tue, 23 Jul 2002 00:21:25 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id EA97891317; Tue, 23 Jul 2002 00:21: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 038DD91311 for ; Tue, 23 Jul 2002 00:18:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id E27B45DDF9; Tue, 23 Jul 2002 00:18:53 -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 7185B5DD8E for ; Tue, 23 Jul 2002 00:18: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 g6N4Iht21967; Tue, 23 Jul 2002 00:18:44 -0400 (EDT) Message-Id: <200207230418.g6N4Iht21967@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Joshua Graessley Cc: zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP In-reply-to: (Your message of "Mon, 22 Jul 2002 17:44:23 PDT.") <54ED9A8E-9DD5-11D6-8F67-000393760260@apple.com> Date: Tue, 23 Jul 2002 00:18:43 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > DNS is not just a name resolution protocol. DNS is a distributed > database. One of the functions it serves is name to address resolution. > DNS already has a record type for services, it just hasn't been used > much yet. yes, but DNS still only accepts names as queries - even with the SRV record there is no way to say "tell me about all of the printers within this area". and there never will be. > > first because part of the definition of an ad hoc network is that you > > cannot assume a central authority for name assignment. > > This is why multicast DNS is used instead of unicast DNS. so what? the management of the namespace is completely orthogonal to the way the queries are transmitted over the network. using multicast won't solve the problem that the DNS namespace is completely incompatible with an ad hoc network. > > second, if you want devices to ship and be able to work out of the box > > then > > you can't expect them to have DNS names that are both meaningful to > > humans > > and relative to some DNS tree. the most they can reasonably expect to > > do > > is advertise their characteristics, and SLP seems like a better fit > > for that. > > The problem with SLP, in my opinion, is that it is overly complicated. > The complication arises from the goal of advertising all of the > characteristics of services and supporting very specific queries. okay, fine - I'll restate then. SLP is a far better starting point than DNS for the kinds of lookups you need to do in an ad hoc network. I certainly won't claim that SLP couldn't use improvement. > While a DNS host name is limited in the characters that may be used, > the DNS packet format has no such restrictions. character set is also irrelevant to this question. DNS simply doesn't have any way to say "find the nearest video projectors" and that's really what you need. I won't claim that you can't take the DNS protocol and try to make it look like a service discovery protocol - after all, you can fit almost anything into a request-response protocol if you try hard enough - but the DNS design is already strained enough just trying to do name lookup, and what you need for this problem isn't name lookup. it's really insane to try to make DNS solve this problem, and trying to won't be good for either this problem or DNS or the apps that try to use it. > In addition, there is > no reason that a host name should have anything to do with the service > that host is advertising. This seems to be something SLP has overlooked. SLP definitely needs fixing. but it's a better starting point. > > third, a lot of the problem with the linklocal proposal is the idea > > that > > these things should ever appear in DNS - where they can confuse > > applications > > that aren't prepared to deal with limited-scope addresses that can > > fail to > > work at any time. > > What do issues with linklocal address assignment have to do with using > multicast DNS to discover local services? the point is that LL addresses are much less likely to cause harm if they don't show up in the same contexts that ordinary addresses do. if they show up in DNS responses, they'll break things. if the app thinks its doing a DNS query but the OS tries to be clever an does an mDNS query that returns LL addresses, it will break apps that expect an address to be reasonably stable and unambiguous. (and yes, there are other kinds of ill-behaved addresses besides v4 LL; this is a general problem that needs to be addresed, but part of the solution is in limiting how LL addresses are used and the contexts in which they appear) Keith From owner-zeroconf@merit.edu Tue Jul 23 00:37: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 AAA16973 for ; Tue, 23 Jul 2002 00:37:38 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id A4B6F912A2; Tue, 23 Jul 2002 00:38:27 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7643C912A4; Tue, 23 Jul 2002 00:38: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 47E18912A2 for ; Tue, 23 Jul 2002 00:38:26 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 35F4C5DE24; Tue, 23 Jul 2002 00:38:26 -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 B98F75DD8E for ; Tue, 23 Jul 2002 00:38:25 -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 g6N4b7t22024; Tue, 23 Jul 2002 00:37:07 -0400 (EDT) Message-Id: <200207230437.g6N4b7t22024@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bernard Aboba Cc: Keith Moore , Brad Hards , zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP In-reply-to: (Your message of "Mon, 22 Jul 2002 20:21:38 PDT.") Date: Tue, 23 Jul 2002 00:37:07 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > okay, then you're not talking about DNS names anymore, because apps can't > > depend on those names to have the properties that DNS names have such as > > global uniqueness. > > If application difficulties were as great as you make them seen, then why > is it so easy for applications to work both with an /etc/hosts file and > with DNS? it's *not* easy to make this work on any scale. have you ever tried it? on our local network hosts files are forbidden to have any but a few 'emergency' addresses in them - (if they're enabled at all), and DNS lookups have to come first, because otherwise we end up trying to track down obscure problems when a host's address changes and the host files don't change to reflect that. for similar reasons we had to completely disable NIS hosts maps and WINS. from a different angle, one of the reasons that gethostbyname() is a lousy interface for DNS queries is that it was designed to read a host file (i.e. a local disk file), where (a) you expect a more-or-less immediate response (so it's okay to block during the call) and (b) you simply don't have failure modes like "temporary inability to contact server" or "name exists but there are no A records" that applications often need to handle differently than "no such host". (no, it's NOT okay to bounce mail if you get a temp failure on the DNS lookup, but there are still lots of programs doing this. and no, it's NOT okay for a web browser to say "no such server" when the the query on the DNS name fails for temporary reasons.) > > so you don't want to use the same API to look them > > up that you use to make DNS queries, because that will confuse apps that > > expect the names and answers returned from that interface to act like DNS. > > Given that operating systems have supported multiple name resolution > mechanisms for decades now based on the same APIs with no ill effects, > this concern hardly seems justified. "no ill effects" is one of the most ridiculous things I've ever seen stated in IETF. it's been a disaster for applications and for users. obviously you've never tried to make an application work in a wide variety of operating environments, and you've never tried to administer a heterogeneous network of any size. > > and there's no particular reason to use the DNS protocol, because most of > > the RR types in DNS implicitly assume some kind of distributed management > > that is not present in an ad hoc system. > > Nope. RR types in DNS make no such assumptions; it is resolvers that make > the assumptions, and resolvers can change to provide seamless support to > applications, as they have done for decades. wow, you just said something even more ridiculous. the semantics of RR types are well defined in their RFCs, and (with the possible exception of TXT) have global scope - they're the same everywhere in the DNS. most of those definitions have been stable for a long time. application programmers depend on those semantics. for "resolvers" to change those semantics on a local basis is a gross and utterly irresponsible protocol violation... it's insanity. > > Of course if you have a service discovery system (and it seens like you > > need one) then you don't need the pseudo-DNS anymore, because you can > > look up the device/service names just as easily using the service > > discovery system. > > Not true. How does service discovery enable the resolution of "ping foo"? why should a name be different than any other service attribute? just find all nearby systems with name="foo" but don't expect an application like "ping" to do this unless it's explicitly coded to do so. Keith From owner-zeroconf@merit.edu Tue Jul 23 00:43: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 AAA17558 for ; Tue, 23 Jul 2002 00:43:00 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 1AA0B912A4; Tue, 23 Jul 2002 00:43:50 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id DA50E912A5; Tue, 23 Jul 2002 00:43: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 B8070912A4 for ; Tue, 23 Jul 2002 00:43:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 98DA55DE24; Tue, 23 Jul 2002 00:43:48 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mta05bw.bigpond.com (mta05bw.bigpond.com [139.134.6.95]) by segue.merit.edu (Postfix) with ESMTP id 8A97F5DD8E for ; Tue, 23 Jul 2002 00:43:47 -0400 (EDT) Received: from pc-00086 ([144.135.24.78]) by mta05bw.bigpond.com (Netscape Messaging Server 4.15 mta05bw May 23 2002 23:53:28) with SMTP id GZOQGW00.ABQ; Tue, 23 Jul 2002 14:43:44 +1000 Received: from CPE-203-51-25-224.nsw.bigpond.net.au ([203.51.25.224]) by bwmam04.mailsvc.email.bigpond.com(MailRouter V3.0n 29/20459726); 23 Jul 2002 14:43:44 From: Brad Hards To: Keith Moore Subject: Re: Relationship DNS-SD and SLP Date: Tue, 23 Jul 2002 14:39:38 +1000 User-Agent: KMail/1.4.5 Cc: zeroconf@merit.edu References: <200207230331.g6N3VBt21296@astro.cs.utk.edu> In-Reply-To: <200207230331.g6N3VBt21296@astro.cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200207231439.38052.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, 23 Jul 2002 13:31, Keith Moore wrote: > > Confusion. I think of DNS as a tool that turns (as if by magic) some kind > > of name into some kind of address (that Just Works[tm]), and can turn it > > back again as well. Tree is an implementation detail for scalability. > > okay, then you're not talking about DNS names anymore, because apps can't > depend on those names to have the properties that DNS names have such as > global uniqueness. so you don't want to use the same API to look them > up that you use to make DNS queries, because that will confuse apps that > expect the names and answers returned from that interface to act like DNS. > and there's no particular reason to use the DNS protocol, because most of > the RR types in DNS implicitly assume some kind of distributed management > that is not present in an ad hoc system. Maybe. On my normal managed LAN, I can ask for the address of "gateway", and get "gateway.cuneata.net.", where "gateway" isn't unique, but "gateway.cuneata.net." is unique (or had better be, I don't think I got taken by the latest scam :). "gateway.linklocal" isn't that much of a extension. However it probably doesn't belong in the same DNS space as my authenticated name/address pairs, both to stop confusing applications and to prevent pollution of my DNS. BTW: is there an example of a major application that will work with NAT, and not work with LL? > > What I want out of a zeroconf service discovery system is to be able to > > put in some combination of attributes (possibly none), and be offered a > > choice of services on my network. I don't care much about the names or IP > > addresses, just what that service can do. > > I think you do care about the names and IP addresses because once you've > identified a service that you want to use then you want to know how to > talk to it. If you let the user choose which device/service to use then > you want to present the name to the user in a menu. Just because you > didn't start your query with a name doesn't mean you don't care about the > name. Agree. At the service discovery step, I want to choose a capability. At the service usage step, I want to communicate. > Of course if you have a service discovery system (and it seens like you > need one) then you don't need the pseudo-DNS anymore, because you can > look up the device/service names just as easily using the service > discovery system. Maybe, maybe not. Example situation: Tim Jansen and I meet at Linux-Kongress, want to copy over the latest tarball of zcip. We are both using link-local addresses on laptops linked into the main conference network. I have some files available for rsync, and he has a client. How does get the file? I can tell him what I call my machine ("leon"), and that the file is available, but that won't help without some kind of name lookup (which could be DNS). Or is there a way of phrasing a service discovery query "find me the file with zcip in the name"? > > What worries me is that we don't (AFAICT) have a standard set of > > attributes and naming conventions for services. For example, how do > > I find a colour printer without much work on my floor. What would that > > look like for SLP or DNS-SD or any other sevice discovery system? > > well we won't solve that problem for an unmanaged network until we > figure out a way for devices to discover their location without help > (not that hard by itself) relative to their physical surroundings > (much harder) so that the searcher can figure out the concept of > "on my floor" (presumably in the same building) by itself. I'm happy to configure the printers location when I put it down. But what do I configure it to so that (in a zeroconf network), I can get allow people to find it using a "standard" query? Or a simpler case (which doesn't require management) - I want to build a zeroconf printer that is a colour bubblejet that can do A5, A4 or A3, but not that dodgy American Letter format. What are the attributes that I should program into its SLP SA or DNS-SD reporting, or whatever? Brad -- http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. From owner-zeroconf@merit.edu Tue Jul 23 01:38: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 BAA21090 for ; Tue, 23 Jul 2002 01:38:45 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 55C20912A9; Tue, 23 Jul 2002 01:39:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1EE71912AA; Tue, 23 Jul 2002 01:39: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 D4759912A9 for ; Tue, 23 Jul 2002 01:39:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id BAA6F5DE7E; Tue, 23 Jul 2002 01:39:33 -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 EEC235DDF9 for ; Tue, 23 Jul 2002 01: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 g6N5dJt22145; Tue, 23 Jul 2002 01:39:19 -0400 (EDT) Message-Id: <200207230539.g6N5dJt22145@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brad Hards Cc: Keith Moore , zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP In-reply-to: (Your message of "Tue, 23 Jul 2002 14:39:38 +1000.") <200207231439.38052.bhards@bigpond.net.au> Date: Tue, 23 Jul 2002 01:39:19 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > On Tue, 23 Jul 2002 13:31, Keith Moore wrote: > > > Confusion. I think of DNS as a tool that turns (as if by magic) some kind > > > of name into some kind of address (that Just Works[tm]), and can turn it > > > back again as well. Tree is an implementation detail for scalability. > > > > okay, then you're not talking about DNS names anymore, because apps can't > > depend on those names to have the properties that DNS names have such as > > global uniqueness. so you don't want to use the same API to look them > > up that you use to make DNS queries, because that will confuse apps that > > expect the names and answers returned from that interface to act like DNS. > > and there's no particular reason to use the DNS protocol, because most of > > the RR types in DNS implicitly assume some kind of distributed management > > that is not present in an ad hoc system. > Maybe. > On my normal managed LAN, I can ask for the address of "gateway", and > get "gateway.cuneata.net.", where "gateway" isn't unique, but > "gateway.cuneata.net." is unique (or had better be, I don't think I got taken by the > latest scam :). > "gateway.linklocal" isn't that much of a extension. However it > probably doesn't belong in the same DNS space as my authenticated > name/address pairs, both to stop confusing applications and to prevent > pollution of my DNS. it's even worse than that, because "gateway.linklocal" doesn't mean the same thing to you as it does to me, if our contexts are different. so you can't use that name in a referral from one app to another and expect it to work. even ad hoc networks don't necessarily exist as disconnected islands. people will be running laptops or palmtops that participate in an ad hoc local network around a conference table in some hotel meeting room at the same time that they're tied via a wireless link to a VPN to the corporate wireless network, and maybe another VPN to a home network. what does "printer.linklocal" mean then - is it the printer in the room, or the printer at the office, or the printer at home? and can I reasonably say "just print to printer.linklocal" to someone across the table? (especially given the assumption that some appliances are going to use linklocal as their sole means of addressing...) and even within the same context there can be multiple hosts that claim the same name. in DNS there is only one authority and RRset for any given name, so DNS query interfaces don't have the possibility of saying "there are multiple hosts claiming this name, choose one of the following..." > BTW: is there an example of a major application that will work with NAT, > and not work with LL? YES!!!!!!! First of all, what do you mean by "major application"? Do you think that email and web are the only apps that matter? "major" apps are the apps that *you* need to get work done, or to communicate with others in the way that works for *you*. those differ from one kind of user, and from one kind of enterprise customer, to another. there is no typical internet user anymore. would you consider SIP a major app? it doesn't work over NAT, and the midcom group is making a royal mess trying to figure out how to make it work. how about multiplayer real-time games? you don't see them much in the business world, but there's a fairly big market out there... some of them sort-of work with NAT but not in a general fashion - e.g. you have to tunnel messages through central proxies. for the people I work with, cluster computing systems are essential, and they don't work over NAT. you might not think of them as "major" but they are used to implement essential services like large-scale modeling. essentially all high-performance computing today is cluster computing. > > > What I want out of a zeroconf service discovery system is to be able to > > > put in some combination of attributes (possibly none), and be offered a > > > choice of services on my network. I don't care much about the names or IP > > > addresses, just what that service can do. > > > > I think you do care about the names and IP addresses because once you've > > identified a service that you want to use then you want to know how to > > talk to it. If you let the user choose which device/service to use then > > you want to present the name to the user in a menu. Just because you > > didn't start your query with a name doesn't mean you don't care about the > > name. > Agree. At the service discovery step, I want to choose a capability. At the > service usage step, I want to communicate. > > > Of course if you have a service discovery system (and it seens like you > > need one) then you don't need the pseudo-DNS anymore, because you can > > look up the device/service names just as easily using the service > > discovery system. > Maybe, maybe not. > > Example situation: Tim Jansen and I meet at Linux-Kongress, want to copy > over the latest tarball of zcip. We are both using link-local addresses on > laptops linked into the main conference network. I have some files available > for rsync, and he has a client. How does get the file? > I can tell him what I call my machine ("leon"), and that the file is available, but > that won't help without some kind of name lookup (which could be DNS). > > Or is there a way of phrasing a service discovery query "find me the > file with zcip in the name"? it seems easier to make the service discovery query "find me the nearby machine that asserts a name of leon". then if he gets multiple answers back (some machine names are fairly common), he needs to disambiguate that somehow... the point is that you're as likely to need to do a query for some other attribute as you are for a name. and even if you're looking for something that matches a name, in an ad hoc network you're going to need to deal with the possibility of name conflicts that don't exist in DNS. > > > > What worries me is that we don't (AFAICT) have a standard set of > > > attributes and naming conventions for services. For example, how do > > > I find a colour printer without much work on my floor. What would that > > > look like for SLP or DNS-SD or any other sevice discovery system? > > > > well we won't solve that problem for an unmanaged network until we > > figure out a way for devices to discover their location without help > > (not that hard by itself) relative to their physical surroundings > > (much harder) so that the searcher can figure out the concept of > > "on my floor" (presumably in the same building) by itself. > I'm happy to configure the printers location when I put it down. But > what do I configure it to so that (in a zeroconf network), I can get > allow people to find it using a "standard" query? well, it sort of seems to me that if you configure the printer at all then you're not talking "zeroconf" anymore - you're talking about having to have an interface for that printer to allow it to be configured (impractical for many kinds of appliance) and if you "configure" that printer when you "put it down" you can about as easily arrange for DHCP to give it a stable IP address and a stable DNS name. and it also seems to me that "zeroconf" networks are most likely to be used in ad hoc situations - if the network is going to be up long enough for the names and locations of devices to be stable then (again) it's worth it to start managing that network to some degree. though I'll accept that a network can be expected to have a mixture of ad hoc and configured devices. the printer may be stationary while the laptops move around, etc. so in some cases it might be reasonable to configure a particular printer to know some of its attributes even if you can't expect to configure every device that might appear on the local network(s) to which that printer is attached. that doesn't mean that name lookup is a good solution in general to the problem of finding services on a network. of course the ability to discover local resources by means other than name lookups is useful for both zeroconf and managed networks, and it would be nice if the same mechanism could work for both cases. but in the case of a network where everything is managed, things are in stable locations, etc. name lookup is "good enough" for many purposes - whereas in ad hoc networks where services and their locations are probably *not* stable then you need a more versatile service. > Or a simpler case (which doesn't require management) - I want > to build a zeroconf printer that is a colour bubblejet that can do > A5, A4 or A3, but not that dodgy American Letter format. What > are the attributes that I should program into its SLP SA or > DNS-SD reporting, or whatever? ask the IPP people - they've been thinking about this stuff for awhile, though I don't think it's been heavily targeted at SLP. Keith From owner-zeroconf@merit.edu Tue Jul 23 03:00: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 DAA01398 for ; Tue, 23 Jul 2002 03:00:42 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 23EFA912B4; Tue, 23 Jul 2002 03:01:00 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E798A912BA; Tue, 23 Jul 2002 03:00: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 C5A7B912B4 for ; Tue, 23 Jul 2002 03:00:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 72E845DF1C; Tue, 23 Jul 2002 03:00:58 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mta02bw.bigpond.com (mta02bw.bigpond.com [139.134.6.34]) by segue.merit.edu (Postfix) with ESMTP id EE0295DE51 for ; Tue, 23 Jul 2002 03:00:56 -0400 (EDT) Received: from pc-00086 ([144.135.24.78]) by mta02bw.bigpond.com (Netscape Messaging Server 4.15 mta02bw May 23 2002 23:53:28) with SMTP id GZOWT500.27J; Tue, 23 Jul 2002 17:00:41 +1000 Received: from CPE-203-51-25-224.nsw.bigpond.net.au ([203.51.25.224]) by bwmam04.mailsvc.email.bigpond.com(MailRouter V3.0n 29/20732948); 23 Jul 2002 17:00:28 From: Brad Hards To: Keith Moore Subject: Re: Relationship DNS-SD and SLP Date: Tue, 23 Jul 2002 16:56:21 +1000 User-Agent: KMail/1.4.5 Cc: Keith Moore , zeroconf@merit.edu References: <200207230539.g6N5dJt22145@astro.cs.utk.edu> In-Reply-To: <200207230539.g6N5dJt22145@astro.cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200207231656.21459.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, 23 Jul 2002 15:39, Keith Moore wrote: > it's even worse than that, because "gateway.linklocal" doesn't mean the > same thing to you as it does to me, if our contexts are different. Clearly this only has meaning *on the same local link*. > so you can't use that name in a referral from one app to another > and expect it to work. even ad hoc networks don't necessarily exist as > disconnected islands. people will be running laptops or palmtops that > participate in an ad hoc local network around a conference table in > some hotel meeting room at the same time that they're tied via a wireless > link to a VPN to the corporate wireless network, and maybe another VPN to a > home network. what does "printer.linklocal" mean then - is it the > printer in the room, or the printer at the office, or the printer at home? Clearly, to the 169.254/16 link. I don't know how to handle the case where someone might be on two 169.254/16 links though. > and can I reasonably say "just print to printer.linklocal" to someone > across the table? (especially given the assumption that some appliances > are going to use linklocal as their sole means of addressing...) If you can't, then we've lost. This has to be the outcome of zeroconf. > and even within the same context there can be multiple hosts that > claim the same name. in DNS there is only one authority and RRset > for any given name, so DNS query interfaces don't have the possibility > of saying "there are multiple hosts claiming this name, choose > one of the following..." Again, either this works, or it doesn't. If you can't handle two hosts claiming to have the same name, then there is no name lookup in a zeroconf network. If the current API is broken, then we need to fix it. > > BTW: is there an example of a major application that will work with NAT, > > and not work with LL? > > YES!!!!!!! > > First of all, what do you mean by "major application"? Do you think > that email and web are the only apps that matter? "major" apps are the > apps that *you* need to get work done, or to communicate with others in the > way that works for *you*. those differ from one kind of user, and from one > kind of enterprise customer, to another. there is no typical internet > user anymore. Concur. Major application is "something I've heard of", for the purposes of this discussion. Probably I should have used "protocol" rather than application, because any application can have bugs, and like my previous assertion that just as applications have to be updated to handle IPv6 (and before that, NAT and CIDR maybe), then it is reasonable to expect people to update applications to handle service discovery, 169.254/16 addresses and "DNS can return non-unique names" PROVIDED that those are valid IETF requirements. > would you consider SIP a major app? it doesn't work over NAT, and the > midcom group is making a royal mess trying to figure out how to make it > work. SIP == "Session Initiation Protocol"? Never heard of it.... That wasn't the question. I asked for an app that _worked_ with NAT. > how about multiplayer real-time games? you don't see them much in the > business world, but there's a fairly big market out there... some of them > sort-of work with NAT but not in a general fashion - e.g. you have to > tunnel messages through central proxies. This is the sort of application that will reasonably work with Link Local, and not with NAT. That's the reverse question to what I asked. > for the people I work with, cluster computing systems are essential, > and they don't work over NAT. you might not think of them as "major" but > they are used to implement essential services like large-scale modeling. > essentially all high-performance computing today is cluster computing. Again, this will work with 169.254/16. It also isn't a representative zeroconf market. > > Or is there a way of phrasing a service discovery query "find me the > > file with zcip in the name"? > > it seems easier to make the service discovery query "find me the nearby > machine that asserts a name of leon". then if he gets multiple answers > back (some machine names are fairly common), he needs to disambiguate that > somehow... That would be a naming service. Whether that is different to the service discovery service is implementation detail. (ie I don't care if it is DNS a'la Bind, it only has do name to address to name lookups). > the point is that you're as likely to need to do a query for some other > attribute as you are for a name. and even if you're looking for > something that matches a name, in an ad hoc network you're going to need > to deal with the possibility of name conflicts that don't exist in DNS. > > > > > What worries me is that we don't (AFAICT) have a standard set of > > > > attributes and naming conventions for services. For example, how do > > > > I find a colour printer without much work on my floor. What would > > > > that look like for SLP or DNS-SD or any other sevice discovery > > > > system? > > > > > > well we won't solve that problem for an unmanaged network until we > > > figure out a way for devices to discover their location without help > > > (not that hard by itself) relative to their physical surroundings > > > (much harder) so that the searcher can figure out the concept of > > > "on my floor" (presumably in the same building) by itself. > > > > I'm happy to configure the printers location when I put it down. But > > what do I configure it to so that (in a zeroconf network), I can get > > allow people to find it using a "standard" query? > > well, it sort of seems to me that if you configure the printer at all > then you're not talking "zeroconf" anymore - you're talking about > having to have an interface for that printer to allow it to be configured > (impractical for many kinds of appliance) and if you "configure" that > printer when you "put it down" you can about as easily arrange for > DHCP to give it a stable IP address and a stable DNS name. Not so. The whole point of zeroconf isn't that you don't have to ever administer things. It is that you can run networks without the central registry and without reliance on an unrelated box being on-line. So I can type in "lounge room" or "basement" into my printer, and not have to worry that my DHCP server and DNS server are available. The other thing is that if you assume that everyone has a DNS server and can set up a DHCP server, then you don't need zeroconf. But the world isn't like that. My parents have no idea about networking - but my Mum could probably plug colour coded cables into sockets. At that point, she should be able to print a notice for the gardening group. USB can do that - the question is whether IP will ever be able to. > and it also seems to me that "zeroconf" networks are most likely to be > used in ad hoc situations - if the network is going to be up long enough > for the names and locations of devices to be stable then (again) it's worth > it to start managing that network to some degree. If it requires management, then you excluded 99% of people. Home networks for non-networking gurus are very difficult. It isn't just a matter of temporary - it is a matter of reasonable effort for reasonable outcomes. Home networks may not be protected by IPSEC, not have central registries, may not have DNS servers. But that is appropriate for some applications. Management should never require anything more than giving the device a name and plugging it into a hub. > though I'll accept that a network can be expected to have a mixture of > ad hoc and configured devices. the printer may be stationary while the > laptops move around, etc. so in some cases it might be reasonable to > configure a particular printer to know some of its attributes even if you > can't expect to configure every device that might appear on the local > network(s) to which that printer is attached. that doesn't mean that > name lookup is a good solution in general to the problem of finding > services on a network. Agree with the point that name lookup isn't everything, but it is still necessary. Name is about the only thing that is stable on my laptop. I use different operating systems, networking devices, etc. Tim still needs to find my laptop if he wants the _latest_ version of that file. > of course the ability to discover local resources by means other > than name lookups is useful for both zeroconf and managed networks, > and it would be nice if the same mechanism could work for both cases. Absolutely. DNS-SD without a specified application API is dead. > > Or a simpler case (which doesn't require management) - I want > > to build a zeroconf printer that is a colour bubblejet that can do > > A5, A4 or A3, but not that dodgy American Letter format. What > > are the attributes that I should program into its SLP SA or > > DNS-SD reporting, or whatever? > > ask the IPP people - they've been thinking about this stuff for > awhile, though I don't think it's been heavily targeted at SLP. OK - an even easier question. "I'm at a conference, and I want to print that email from Keith. How do I find a printer on my local link?" Brad -- http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. From owner-zeroconf@merit.edu Tue Jul 23 03:19: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 DAA01777 for ; Tue, 23 Jul 2002 03:19:05 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C202091234; Tue, 23 Jul 2002 03:19:55 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7F9A3912BA; Tue, 23 Jul 2002 03:19: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 797AE91234 for ; Tue, 23 Jul 2002 03:19:54 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 54BE45DDEF; Tue, 23 Jul 2002 03:19: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 A6D635DDB0 for ; Tue, 23 Jul 2002 03:19:53 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g6N6QH313086; Mon, 22 Jul 2002 23:26:17 -0700 Date: Mon, 22 Jul 2002 23:26:17 -0700 (PDT) From: Bernard Aboba To: Keith Moore Cc: Joshua Graessley , Subject: Re: Relationship DNS-SD and SLP In-Reply-To: <200207230418.g6N4Iht21967@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > yes, but DNS still only accepts names as queries - even with the SRV > record there is no way to say "tell me about all of the printers within > this area". and there never will be. Yes, and that's a critical distinction between name resolution and service discovery. > so what? the management of the namespace is completely orthogonal > to the way the queries are transmitted over the network. using > multicast won't solve the problem that the DNS namespace is > completely incompatible with an ad hoc network. There is, for example, no concept of delegation in mDNS. And it is also true that mDNS is not appropriate for resolution of FQDNs in most cases. However, few hosts spend all their time connected to adhoc networks, and names persist while network connections change. Therefore, there is little intrinsic reason why a host connected to an adhoc network could not have earlier obtained, and subsequently respond to queries for, an FQDN. Rather, I would argue that the difficulty of utilizing mDNS to resolve FQDNs arises largely from the difficulty of implementing appropriate security mechanisms in the purely adhoc case, rather than from an intrinsic namespace incompatibility. Were it possible to use DNS security within adhoc name resolution, the difficulties in use of the DNS namespace with mDNS would be largely resolved. > okay, fine - I'll restate then. SLP is a far better starting point > than DNS for the kinds of lookups you need to do in an ad hoc network. I think you're overly constraining the kind of interactions that occur in adhoc networks. Aside from finding a printer or file server, there can also be a need for directed file transfers or web usage. How does SLP help with displaying "http://foo/myfolder/"? > character set is also irrelevant to this question. DNS simply doesn't > have any way to say "find the nearest video projectors" and that's really > what you need. I'd claim that the question of the "best" service is a completely different question than either name resolution or classic service discovery. > SLP definitely needs fixing. but it's a better starting point. I'm curious as to what exactly needs to be "fixed". SLPv2 has evolved over a long period in response to deployment experience and critical evaluations. So I'm curious as to what you believe is still missing. > apps expect an address to be reasonably stable and unambiguous. This seems to argue for applications caching the result of name resolutions. That's a dangerous game, with or without mDNS, if only for the sake of resilience. In reality, Internet hosts go down on a regular basis, and well written applications need to deal with that gracefully. As for the necessity of "unambiguous" naming, I'd remind you that NetBIOS names exist within a flat hierarchy and have been in widespread use for decades without causing the application problems you mention. From owner-zeroconf@merit.edu Tue Jul 23 03:37: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 DAA02112 for ; Tue, 23 Jul 2002 03:37:49 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 3EC40912BB; Tue, 23 Jul 2002 03:36:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 042F2912BE; Tue, 23 Jul 2002 03:36: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 1449C912BB for ; Tue, 23 Jul 2002 03:36:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F3E695DDEF; Tue, 23 Jul 2002 03: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 747BC5DDB0 for ; Tue, 23 Jul 2002 03:36:30 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.10.2/8.10.2) with ESMTP id g6N6ggw13219; Mon, 22 Jul 2002 23:42:42 -0700 Date: Mon, 22 Jul 2002 23:42:41 -0700 (PDT) From: Bernard Aboba To: Keith Moore Cc: Brad Hards , Subject: Re: Relationship DNS-SD and SLP In-Reply-To: <200207230437.g6N4b7t22024@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk > it's *not* easy to make this work on any scale. have you ever tried it? Yup. We run a network with more than 80K hosts, day in and day out. > for similar reasons we had to completely disable NIS hosts maps and WINS. I'm sorry that your admins lack the skill to properly maintain NIS or WINS. But saying that these systems are unworkable strains credibility -- thousands of sites run them successfully. > from a different angle, one of the reasons that gethostbyname() is > a lousy interface for DNS queries is that it was designed to read a host > file (i.e. a local disk file), where (a) you expect a more-or-less > immediate response (so it's okay to block during the call) and (b) you > simply don't have failure modes like "temporary inability to contact server" > or "name exists but there are no A records" that applications often > need to handle differently than "no such host". (no, it's NOT okay to > bounce mail if you get a temp failure on the DNS lookup, but there are > still lots of programs doing this. and no, it's NOT okay for a web > browser to say "no such server" when the the query on the DNS name fails > for temporary reasons.) Yes, it's hard for applications to use name resolution correctly. So what? Well written applications need not exhibit any of these problems. > "no ill effects" is one of the most ridiculous things I've ever seen stated > in IETF. it's been a disaster for applications and for users. One might say the same thing about sockets, yet I don't see you arguing to avoid changes to TCP :) > obviously... you've never tried to administer a heterogeneous network > of any size. Hmmm... I guess running a network with more than two million users, several thousand routers and some of the Internet's most heavily loaded web servers doesn't qualify, huh? > programmers depend on those semantics. for "resolvers" to change those > semantics on a local basis is a gross and utterly irresponsible protocol > violation... it's insanity. Yet that is exactly what RFC 1536 did, for example, and the world didn't end. From owner-zeroconf@merit.edu Tue Jul 23 04: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 EAA02910 for ; Tue, 23 Jul 2002 04:02:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 493FE912BD; Tue, 23 Jul 2002 04:03:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 14D40912BE; Tue, 23 Jul 2002 04:03: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 D094B912BD for ; Tue, 23 Jul 2002 04:02:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id AA78C5DDB0; Tue, 23 Jul 2002 04:02:16 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 5E88A5DD9D for ; Tue, 23 Jul 2002 04:02:16 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA15403; Tue, 23 Jul 2002 01:02:14 -0700 (PDT) Received: from qwer (qwer [129.157.142.111]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6N82Cb00735; Tue, 23 Jul 2002 10:02:12 +0200 (MEST) Date: Tue, 23 Jul 2002 10:02:12 +0200 (MEST) From: Erik Guttman X-Sender: erikg@qwer To: Keith Moore Cc: Joshua Graessley , zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP In-Reply-To: <200207230418.g6N4Iht21967@astro.cs.utk.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Keith, Joshua, Regarding SLP: Since the SVRLOC WG concluded going on two years ago, an ad hoc group has formed to work on continuing standardization. We have a draft of RFC2608bis which aims at addressing known issues with the protocol, specifically: - reducing the requirements on SAs - eliminating complex operations which were hard to implement and explain - resolving issues which have arisen with the protocol through operational experience The basic goal is to remove features which do not have a solid basis of interoperability and utility as we have found from three years of experience as a proposed standard. We clarify the rest. We want to do interoperability testing as soon as the spec is done and advance the protocol to draft standard. All of the changes proposed so far would retain backwards compatibility - which is to say, existing SLP implementations would conform to the new spec. New implementations will not include some features which were previously in the protocol. Now, if there are ways suggested to improve the protocol which would greatly improve SLP, we *could* consider breaking backward compatib- ility and creating a new proposed standard 'SLPv3'. Please consider what we have already achieved, as I think it goes a long way to address shortcomings of SLP. I invite your comments and participation. Please see site: http://www.srvloc.org list: to subscribe: http://lists.sourceforge.net/lists/listinfo/srvloc-discuss archive: http://www.geocrawler.com/lists/3/SourceForge/12970/0 drafts: http://www.ietf.org/internet-drafts/draft-guttman-svrloc-rfc2608bis-02.txt http://www.ietf.org/internet-drafts/draft-guttman-svrloc-serviceid-01.txt http://www.ietf.org/internet-drafts/draft-kempf-svrloc-rfc2614bis-00.txt [and more] RFC2608bis is 40 pages, an improvement over RFC2608 (54 pages) and RFC2165 (69 pages). It indicates our progress in simplification of the protocol. --- > > In addition, there is > > no reason that a host name should have anything to do with the service > > that host is advertising. This seems to be something SLP has overlooked. > > SLP definitely needs fixing. but it's a better starting point. SLP doesn't require any relationship between the host name and the advertised service. SLP service advertisements include the following information, standardized by the service templates registered with IANA. See http://www.iana.org/assignments/svrloc-templates.htm - a 'type of service' string, registered with IANA or vendor specific - a 'scope' string, either default or set by a local administration to group services - a URI, which generally indicates the location of the service, but could be used for some other purpose - an unordered group of attributes, which could include the name of the service, the location of the service, configuration parameters, attributes of the service, etc. - digital signatures to allow the recipient of the above information to verify that it came from a source which the receiver has been configured to trust (at least so far as to be a legitimate source of service advertisements). As far as improving or fixing SLP, your input is extremely welcome and timely! Erik ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._. E r i k G u t t m a n Short email (<140 characters) to Solaris Installation and Deployment 01728655497@d2-message.de Sun Microsystems cell: +49 172 865 5497 From owner-zeroconf@merit.edu Tue Jul 23 04:24: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 EAA03263 for ; Tue, 23 Jul 2002 04:24:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 20ABF912BE; Tue, 23 Jul 2002 04:25:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id E65CC912BF; Tue, 23 Jul 2002 04:25: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 F0D23912BE for ; Tue, 23 Jul 2002 04:25:09 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D9C525DE8F; Tue, 23 Jul 2002 04:25:09 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id 5DC5B5DE51 for ; Tue, 23 Jul 2002 04:25:09 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id BAA25439; Tue, 23 Jul 2002 01:25:07 -0700 (PDT) Received: from qwer (qwer [129.157.142.111]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6N8P4b01670; Tue, 23 Jul 2002 10:25:04 +0200 (MEST) Date: Tue, 23 Jul 2002 10:25:04 +0200 (MEST) From: Erik Guttman X-Sender: erikg@qwer To: Brad Hards Cc: Keith Moore , zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP In-Reply-To: <200207231439.38052.bhards@bigpond.net.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Brad, On Tue, 23 Jul 2002, Brad Hards wrote: > Or a simpler case (which doesn't require management) - I want > to build a zeroconf printer that is a colour bubblejet that can do > A5, A4 or A3, but not that dodgy American Letter format. What > are the attributes that I should program into its SLP SA or > DNS-SD reporting, or whatever? Please see: http://www.iana.org/assignments/svrloc-templates/printer.2.0.en According to this, the printer would advertise itself as service type = service:printer:ipp URI = service:printer:ipp://169.254.23.16:631/myqueue scope = default attributes = ...,(printer-media-supported=iso-a4,iso-a5,iso-a3),... and service type = service:printer:lpr:// URI = service:printer:lpr://somehost.example.com:515/myqueue scope = default attributes = ...,(printer-media-supported=iso-a4,iso-a5,iso-a3),... Notes: 1) In the IPP case, an address is given instead of a hostname. This is OK, but a hostname is preferred. The host advertising the printer is in a zeroconf scenario and has no name assigned and only a link local address. It can still use SLP to advertise itself, and be discovered. 2) The port numbers in both the URLs listed are optional as they are the well known port numbers. Including them doesn't hurt. A client can request a printer with a SLP service request including service type = service:printer:ipp scope = default query = (printer-media-supported=iso-a4) It will receive a SLP service reply with: service URL = service:printer:ipp://169.254.23.16:631/myqueue The entire list of attributes associated with that printer can be retreived with an Attribute request or in the service reply itself if RFC 3059 Attribute List Extensions are supported. The code to do this advertisement is only 3 lines or so of C or Java, while the request probably requires about 10 lines - using the SLP API (RFC 2614). Erik From owner-zeroconf@merit.edu Tue Jul 23 06: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 GAA05651 for ; Tue, 23 Jul 2002 06:47:40 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0D46691209; Tue, 23 Jul 2002 06:48:32 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id BF11B91235; Tue, 23 Jul 2002 06:48: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 C2DE591209 for ; Tue, 23 Jul 2002 06:47:45 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9ECF55DEDC; Tue, 23 Jul 2002 06:47: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 225B35DD9E for ; Tue, 23 Jul 2002 06:47: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 g6NAlik18338 for ; Tue, 23 Jul 2002 03:47:44 -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, 23 Jul 2002 03:47:44 -0700 Received: from [17.202.41.197] (rlopez.apple.com [17.202.41.197]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g6NAlcT16613 for ; Tue, 23 Jul 2002 03:47:38 -0700 (PDT) Mime-Version: 1.0 X-Sender: rod@apple.com (Unverified) Message-Id: Date: Tue, 23 Jul 2002 03:47:21 -0700 To: zeroconf@merit.edu From: Rod Subject: Re: Relationship DNS-SD and SLP Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk >On Tue, 23 Jul 2002, Brad Hards wrote: >> Or a simpler case (which doesn't require management) - I want >> to build a zeroconf printer that is a colour bubblejet that can do >> A5, A4 or A3, but not that dodgy American Letter format. What >> are the attributes that I should program into its SLP SA or >> DNS-SD reporting, or whatever? "I'm a printer." >Please see: > http://www.iana.org/assignments/svrloc-templates/printer.2.0.en > >According to this, the printer would advertise itself as > > service type = service:printer:ipp > URI = service:printer:ipp://169.254.23.16:631/myqueue > scope = default > attributes = ...,(printer-media-supported=iso-a4,iso-a5,iso-a3),... > >and > > service type = service:printer:lpr:// > URI = service:printer:lpr://somehost.example.com:515/myqueue > scope = default > attributes = ...,(printer-media-supported=iso-a4,iso-a5,iso-a3),... So for something like a file server, I'd want to do something like: service type = service:ftp:ftp:// URI = service:ftp:ftp://169.254.23.16:21 scope = default attributes = ...,(files=asa.jpg, pag.jpg, chip.jpg, par.jpg, tu.jpg, cielo.jpg, par2.jpg, tuno1.jpg, cielo2.jpg, parque.jpg, tunovio2.jpg, marco.jpg, parque2.jpg, usps.jpg, ent.jpg, parque3.jpg, via.jpg, experiment.jpg, parque5.jpg, vista.jpg, eye.jpg, parque6.jpg, xico.jpg, etc. etc. etc. etc....) Hey, who needs 'ls'? Or an even better example, for something like a music exchange program or network jukebox software, I would just list the thousands of songs in the device's playlist right in the attributes section! Hmmm................... What ever happened to the layered approach of solving a problem? - STEP ONE, SERVICE DISCOVERY PROTOCOL - - Hi! I want to print. I'm looking for a printer. - Yo, over here, I'm a printer. I speak protocol. - END OF STEP ONE - - STEP TWO, PRINTING PROTOCOL - - Hi printer! (Handshake.) Can you print in color on size A3? - Sure, bring it on. (Prints...) - END OF STEP TWO - Isn't this far better than: - Hi! I want to print. I'm looking for a printer! - Yo, over here, I'm a printer. I can do sizes iso-a0, iso-a1, iso-a2, iso-a3, iso-a4, iso-a5, iso-a6, iso-a7, iso-a8, iso-a9, iso-a10, iso-b0, iso-b1, iso-b2, iso-b3, iso-b4, iso-b5, iso-b6, iso-b7, iso-b8, iso-b9, iso-b10... oh and I can also print in black and white, grayscale, or color... I can use FinePrint or PhotoGrade printing, I can print 1, 2, 4, 6, 9, or 16 pages per sheet, I can feed paper from cassette 1, cassette 2, manual feed or envelope feeder... but that one's out of envelopes right now... I can also print collated or not... I can print with low, medium, or high quality... you get the idea. Of course, printing is probably not the best example, since current printing protocols are not always sufficient for all that we want them to do, but that should be a problem for them (currently being addressed by the IPP guys) like Keith mentioned, not the -service discovery- protocol. Even if the requirements on SAs are reduced, it doesn't change the fundamental paradigm flaw (for our purposes at least) of looking for a service's attributes, characteristics, and capabilities, instead of just a simple service instance, which makes everything a lot simpler and cleaner. This is where DNS-SD shines. I think SLP mixes apples and oranges, tries to take over work that should belong somewhere else, and reinvents the wheel in some cases. I want to look for a file server. After I find one (or several) I'll bother with asking it what files it is offering. There are anough ways for me to do that already. This same basic concept should apply to any service, be it a printer, jukebox server, TiVo, coffee machine, etc. I'll quote Josh Graessley's email: "The problem with SLP, in my opinion, is that it is overly complicated. The complication arises from the goal of advertising all of the characteristics of services and supporting very specific queries." And draft-cheshire-dnsext-nbp: "This could be useful on extremely large networks with very many printers, but may be overkill for a small home network with only one or two printers." And even in the extreme case where some narrowing of a list of services was strictly required, DNS-SD still provides enough basic flexibility to do so without getting too complex: "6. Selective Queries This proposal does not attempt to define an arbitrary query language for service discovery, nor do we believe one is necessary. However, there are some circumstances where narrowing the list of results may be useful. A printing client that wishes to discover only printers that accept Postscript over lpr over TCP should issue a PTR query for the name "_postscript._lpr._tcp.example.com." Only printers that support Postscript should register this PTR record pointing to their name. Note that the printer's Service Instance Name which this PTR record points to is unchanged -- it is still something of the form "ThePrinter._lpr._tcp.example.com." The domain in which printer SRV records are registered defines the namespace within which printer names are unique. Additional subtypes (e.g. "_postscript") of the basic service type (e.g. "_lpr._tcp") serve to narrow the list of results, not to create more namespace." Again, I don't have anything against SLP, but I don't think it's really the way to go for ad-hoc or home networks, which are the main focus of Zeroconf. Another mistake that I think people are making is mixing up the goals and functionality of two different things, Multicast DNS and DNS Service Discovery. I've heard phrases like "look up services by name" and "name lookups as a solution to finding services on a network" be used constantly here. This is fundamentally wrong, and brings a lot of confusion. You are not going to look up services by name, or use names to find a type of service. You are going to look up a service by TYPE (using SRV records with types and, if necessary, subtypes) and THIS will return the service's NAME, which you can conveniently use to communicate with the device, without worrying about its address or if it changes. Even though the DNS protocol is used on both cases (in DNS-SD it's mostly out of convenience), these two are not the same thing, and DNS-SD is far less limited than it would appear by just thinking it uses a 'name to find a service.' -Rod Lopez From owner-zeroconf@merit.edu Tue Jul 23 07:00: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 HAA05863 for ; Tue, 23 Jul 2002 07:00:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id DB13891235; Tue, 23 Jul 2002 07:00:21 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9DD3B91237; Tue, 23 Jul 2002 07:00: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 9411B91235 for ; Tue, 23 Jul 2002 07:00:19 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 375E75DD9E; Tue, 23 Jul 2002 07:00:17 -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 D26615DD9D for ; Tue, 23 Jul 2002 07:00:15 -0400 (EDT) Received: from pc-00086 ([144.135.24.78]) by mta06bw.bigpond.com (Netscape Messaging Server 4.15 mta06bw May 23 2002 23:53:28) with SMTP id GZP7WC00.4U4; Tue, 23 Jul 2002 21:00:12 +1000 Received: from CPE-203-51-25-224.nsw.bigpond.net.au ([203.51.25.224]) by bwmam04.mailsvc.email.bigpond.com(MailRouter V3.0n 29/21156141); 23 Jul 2002 21:00:11 From: Brad Hards To: Rod , zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP Date: Tue, 23 Jul 2002 20:56:04 +1000 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: <200207232056.04446.bhards@bigpond.net.au> Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Tue, 23 Jul 2002 20:47, Rod wrote: > >On Tue, 23 Jul 2002, Brad Hards wrote: > >> Or a simpler case (which doesn't require management) - I want > >> to build a zeroconf printer that is a colour bubblejet that can do > >> A5, A4 or A3, but not that dodgy American Letter format. What > >> are the attributes that I should program into its SLP SA or > >> DNS-SD reporting, or whatever? > > "I'm a printer." What does this look like in Rendevous? What goes over the wire? What does the application ask the support libraries? How would it look for a fax machine? Brad -- http://conf.linux.org.au. 22-25Jan2003. Perth, Australia. Birds in Black. From owner-zeroconf@merit.edu Tue Jul 23 07:00: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 HAA05883 for ; Tue, 23 Jul 2002 07:00:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE58E91237; Tue, 23 Jul 2002 07:00:49 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 67E0E912BF; Tue, 23 Jul 2002 07:00: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 6DF2491237 for ; Tue, 23 Jul 2002 07:00:48 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 43DA35DD9E; Tue, 23 Jul 2002 07:00:48 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from nwkea-mail-1.sun.com (nwkea-mail-1.sun.com [192.18.42.13]) by segue.merit.edu (Postfix) with ESMTP id E1BE15DD9D for ; Tue, 23 Jul 2002 07:00:47 -0400 (EDT) Received: from hs-ehdb03-01.Germany.Sun.COM ([129.157.142.201]) by nwkea-mail-1.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA27890; Tue, 23 Jul 2002 04:00:46 -0700 (PDT) Received: from qwer (qwer [129.157.142.111]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6NB0ib07212; Tue, 23 Jul 2002 13:00:44 +0200 (MEST) Date: Tue, 23 Jul 2002 13:00:44 +0200 (MEST) From: Erik Guttman X-Sender: erikg@qwer To: Rod Cc: zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk Rod, On Tue, 23 Jul 2002, Rod wrote: > "I'm a printer." On many networks you would get a lot of answers back for a query like that. > So for something like a file server, I'd want to do something like: > > service type = service:ftp:ftp:// > URI = service:ftp:ftp://169.254.23.16:21 > scope = default > attributes = ...,(files=asa.jpg, pag.jpg, chip.jpg, par.jpg, > tu.jpg, cielo.jpg, par2.jpg, tuno1.jpg, cielo2.jpg, parque.jpg, > tunovio2.jpg, marco.jpg, parque2.jpg, usps.jpg, ent.jpg, parque3.jpg, > via.jpg, experiment.jpg, parque5.jpg, vista.jpg, eye.jpg, > parque6.jpg, xico.jpg, etc. etc. etc. etc....) > > Hey, who needs 'ls'? No one has suggested exhausted listing of content using SLP. Instead, I might list a relative or absolute path of some meaning to an application or installer, or some metadata about my files or a description - "Rod's scrapbook", for example. Any of these would help you manually or a program automatically locate the data. > What ever happened to the layered approach of solving a problem? > > - STEP ONE, SERVICE DISCOVERY PROTOCOL - > > - Hi! I want to print. I'm looking for a printer. > - Yo, over here, I'm a printer. I speak protocol. > > - END OF STEP ONE - > > - STEP TWO, PRINTING PROTOCOL - > You leave out: - Hi printer! (Handshake.) Can you print in color on size A3? - No. - Hi printer! (Handshake.) Can you print in color on size A3? - No. - Hi printer! (Handshake.) Can you print in color on size A3? - No. - Hi printer! (Handshake.) Can you print in color on size A3? - No. - Hi printer! (Handshake.) Can you print in color on size A3? - No. - Hi printer! (Handshake.) Can you print in color on size A3? - No. - Hi printer! (Handshake.) Can you print in color on size A3? - No. ... > - Hi printer! (Handshake.) Can you print in color on size A3? > - Sure, bring it on. > > (Prints...) > > - END OF STEP TWO - It is not much more complicated is it to process a query for a type and an attribute=value than just a type. It is a lot friendlier on the network and on the client software to not have each client have to interrogate all servers to find the one it can use. Erik From owner-zeroconf@merit.edu Tue Jul 23 07:27: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 HAA06229 for ; Tue, 23 Jul 2002 07:27:36 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B6C9B912BF; Tue, 23 Jul 2002 07:28:23 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 860E1912C2; Tue, 23 Jul 2002 07:28: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 55AA7912BF for ; Tue, 23 Jul 2002 07:28:22 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 396F85DDE7; Tue, 23 Jul 2002 07:28:22 -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 B13FF5DD9D for ; Tue, 23 Jul 2002 07:28:21 -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 g6NBSHk21594 for ; Tue, 23 Jul 2002 04:28:17 -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, 23 Jul 2002 04:27:38 -0700 Received: from [17.202.41.197] (rlopez.apple.com [17.202.41.197]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id g6NBSHl00594 for ; Tue, 23 Jul 2002 04:28:17 -0700 (PDT) Mime-Version: 1.0 X-Sender: rod@apple.com (Unverified) Message-Id: In-Reply-To: References: Date: Tue, 23 Jul 2002 04:28:00 -0700 To: zeroconf@merit.edu From: Rod Subject: Re: Relationship DNS-SD and SLP Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk At 1:00 PM +0200 7/23/02, Erik Guttman wrote: >Rod, > >On Tue, 23 Jul 2002, Rod wrote: >> "I'm a printer." >On many networks you would get a lot of answers back for a query like that. I totally agree. That's why I specifically focused my comments towards ad-hoc and home network scenarios, where you are much less likely to get excessive answers back. And I quoted that excrept from draft-cheshire-dnsext-nbp: "This [...] may be overkill for a small home network with only one or two printers." >No one has suggested exhausted listing of content using SLP. >Instead, I might list a relative or absolute path of some >meaning to an application or installer, or some metadata >about my files or a description - "Rod's scrapbook", for >example. Any of these would help you manually or a program >automatically locate the data. I agree, I was exaggerating to get my point across, which is that the service discovery protocol should not have to deal with all this endless sea of attributes and characteristics of services. That's what each service protocol is designed for. Mixing them in with the service discovery protocol seems like overkill and makes things more complicated, overdone, and tedious, in my opinion. > > What ever happened to the layered approach of solving a problem? >> >> - STEP ONE, SERVICE DISCOVERY PROTOCOL - >> >> - Hi! I want to print. I'm looking for a printer. >> - Yo, over here, I'm a printer. I speak protocol. >> >> - END OF STEP ONE - >> >> - STEP TWO, PRINTING PROTOCOL - >> > >You leave out: > - Hi printer! (Handshake.) Can you print in color on size A3? > - No. > - Hi printer! (Handshake.) Can you print in color on size A3? > - No. > - Hi printer! (Handshake.) Can you print in color on size A3? > - No. > - Hi printer! (Handshake.) Can you print in color on size A3? > - No. > - Hi printer! (Handshake.) Can you print in color on size A3? > - No. > - Hi printer! (Handshake.) Can you print in color on size A3? > - No. > - Hi printer! (Handshake.) Can you print in color on size A3? > - No. > ... Wow, that's one rich home. :-)) Again: "This [...] may be overkill for a small home network with only one or two printers." >It is not much more complicated is it to process a query for >a type and an attribute=value than just a type. It is a lot >friendlier on the network and on the client software to not >have each client have to interrogate all servers to find the >one it can use. It is not more complicated to process, but I don't think that's the issue here. There are many technologies that have failed because their complexity got out of hand. Not because they were harder to process, but because they either were harder to manage, implement, understand, tried to accomplish too many things at the same time, or a combination of these. Once again, I think it depends on the context. Like I previously stated, in the context I was talking about, which is the one Zeroconf focuses on, SLP looks like overkill. Regards, -Rod Lopez From owner-zeroconf@merit.edu Tue Jul 23 08:24: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 IAA07938 for ; Tue, 23 Jul 2002 08:24:52 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 07765912F9; Tue, 23 Jul 2002 08:25:38 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id C6E64912FA; Tue, 23 Jul 2002 08:25: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 A4E3D912F9 for ; Tue, 23 Jul 2002 08:25:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 93D485DDB9; Tue, 23 Jul 2002 08:25:36 -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 EC9AA5DD9D for ; Tue, 23 Jul 2002 08:25:35 -0400 (EDT) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate4.mot.com (motgate4 2.1) with ESMTP id FAA18420 for ; Tue, 23 Jul 2002 05:25:35 -0700 (MST)] Received: [from homer.arc.corp.mot.com (homer.arc.corp.mot.com [10.238.80.38]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id FAA25931 for ; Tue, 23 Jul 2002 05:25:33 -0700 (MST)] Received: from arc.corp.mot.com ([10.238.2.41]) by homer.arc.corp.mot.com (8.12.2/8.12.2) with ESMTP id g6NCPVnw012806 for ; Tue, 23 Jul 2002 22:25:32 +1000 (EST) Message-ID: <3D3D4B3B.9B74E8C6@arc.corp.mot.com> Date: Tue, 23 Jul 2002 22:25:31 +1000 From: Varuni Witana X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 Cc: zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit Rod wrote: > > At 1:00 PM +0200 7/23/02, Erik Guttman wrote: > >Rod, > > > >On Tue, 23 Jul 2002, Rod wrote: > >> "I'm a printer." > >On many networks you would get a lot of answers back for a query like that. > > I totally agree. That's why I specifically focused my comments > towards ad-hoc and home network scenarios, where you are much less > likely to get excessive answers back. And I quoted that excrept from > draft-cheshire-dnsext-nbp: > > "This [...] may be overkill for a small home network with only one > or two printers." > There seems to be some consensus that a zeroconf network may contain services where the choice of the instance is dependent on its attributes. Before we get too fixated on how many printers a person might have in their home :) is it possible to quantify how many distinct instances of a service need to exist before scalability issues with having to query each one in turn, overcome the perceived complexity of SLP? Another question, are we going to have such a clear cut demarcation between devices meant to be used in fixed networks (which would use SLP) and devices meant for the home market which would use mdns? Regards Varuni -- Varuni Witana Senior Research Engineer Email: varuni@arc.corp.mot.com Sydney Networks Research Lab Ph: +61 2 9666 0647 Motorola Australian Research Centre Fax: +61 2 9666 0501 From owner-zeroconf@merit.edu Tue Jul 23 08:48: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 IAA09116 for ; Tue, 23 Jul 2002 08:48:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 572D691239; Tue, 23 Jul 2002 08:48:59 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1EEB4912FA; Tue, 23 Jul 2002 08:48: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 3127B91239 for ; Tue, 23 Jul 2002 08:48:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 1E83A5DDE7; Tue, 23 Jul 2002 08:48:58 -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 4E6A95DDB9 for ; Tue, 23 Jul 2002 08:48:53 -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 GAA10107; Tue, 23 Jul 2002 06:48:52 -0600 (MDT) Received: from qwer (qwer [129.157.142.111]) by hs-ehdb03-01.Germany.Sun.COM (8.10.2+Sun/8.10.2/ENSMAIL,v2.2) with SMTP id g6NCmnb10658; Tue, 23 Jul 2002 14:48:49 +0200 (MEST) Date: Tue, 23 Jul 2002 14:48:50 +0200 (MEST) From: Erik Guttman X-Sender: erikg@qwer To: Rod Cc: zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-zeroconf@merit.edu Precedence: bulk On Tue, 23 Jul 2002, Rod wrote: > "This [...] may be overkill for a small home network with only one > or two printers." So, we need a service discovery protocol for the home, for the enterprise, for the internet, for the distributed object framework, for the telephony core network services, for the data center, for network infrastructure discovery? We end up without any way of coordinating all of these, keeping them consistent and making sure the approach scales well when it is (oops!) used a larger network than intended. Erik From owner-zeroconf@merit.edu Tue Jul 23 09:26: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 JAA11018 for ; Tue, 23 Jul 2002 09:26:22 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id B8E749123A; Tue, 23 Jul 2002 09:27:11 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 8ED46912FC; Tue, 23 Jul 2002 09:27: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 8ED479123A for ; Tue, 23 Jul 2002 09:27:10 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6A6CB5DE5E; Tue, 23 Jul 2002 09:27:10 -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 65D7D5DDF7 for ; Tue, 23 Jul 2002 09:27:09 -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 EF37F5988E; Tue, 23 Jul 2002 14:27:10 +0100 (BST) Message-ID: <004901c2324c$a4961e00$5801a8c0@localdomain> From: "Philip Nye" To: "Varuni Witana" Cc: References: <3D3D4B3B.9B74E8C6@arc.corp.mot.com> Subject: Re: Relationship DNS-SD and SLP Date: Tue, 23 Jul 2002 14:27:05 +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: "Varuni Witana" > > > >> "I'm a printer." > > >On many networks you would get a lot of answers back for a query like that. > > > > I totally agree. That's why I specifically focused my comments > > towards ad-hoc and home network scenarios, where you are much less > > likely to get excessive answers back. And I quoted that excrept from > > draft-cheshire-dnsext-nbp: > > > > "This [...] may be overkill for a small home network with only one > > or two printers." > > > There seems to be some consensus that a zeroconf network may contain > services where the choice of the instance is dependent on its > attributes. > Before we get too fixated on how many printers a person might have in > their home :) > is it possible to quantify how many distinct instances of a service need > to exist before scalability issues with having to query each one in > turn, overcome the perceived complexity of SLP? > > Another question, are we going to have such a clear cut demarcation > between devices meant to be used in fixed networks (which would use SLP) > and devices meant for the home market which would use mdns? This is just the issue I am wrestling with. There is no point of demarcation in the scalability continuum. Lets say I am designing a cheap printer, I cannot afford the resources to build in every service discovery protocol under the sun. On the other hand, neither can I afford to say that it won't work properly when your network grows beyond a certain size or complexity - customers don't like that kind of thing. So it seems to me that either DNS-SD has to scale gracefully all the way up to huge, or that I will have to bite the bullet and build in something tougher like SLP anyway. And then why would I want to do DNS-SD as well? Philip Nye From owner-zeroconf@merit.edu Tue Jul 23 10:00: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 KAA12434 for ; Tue, 23 Jul 2002 10:00:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id C145B912FD; Tue, 23 Jul 2002 10:01:18 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 78FD491303; Tue, 23 Jul 2002 10:01: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 8985F912FD for ; Tue, 23 Jul 2002 10:01:16 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7581B5DF73; Tue, 23 Jul 2002 10:01:16 -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 0AFC25DE5E for ; Tue, 23 Jul 2002 10:01: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 g6NE16t15871; Tue, 23 Jul 2002 10:01:07 -0400 (EDT) Message-Id: <200207231401.g6NE16t15871@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Brad Hards Cc: Keith Moore , zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP In-reply-to: (Your message of "Tue, 23 Jul 2002 16:56:21 +1000.") <200207231656.21459.bhards@bigpond.net.au> Date: Tue, 23 Jul 2002 10:01:06 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > On Tue, 23 Jul 2002 15:39, Keith Moore wrote: > > it's even worse than that, because "gateway.linklocal" doesn't mean the > > same thing to you as it does to me, if our contexts are different. > Clearly this only has meaning *on the same local link*. right, but machines can have interfaces on multiple links, and some of those interfaces might be tunnel endpoints. (after all, what's the purpose of a VPN except to give you presence on a remote network so you can access those resources - and if LLs are used in the way this group seems to think they will be, those resources might include hosts accessible only via a LL address.) > > and can I reasonably say "just print to printer.linklocal" to someone > > across the table? (especially given the assumption that some appliances > > are going to use linklocal as their sole means of addressing...) > If you can't, then we've lost. This has to be the outcome of zeroconf. well, it might get easier to disambiguate if you're not restricted to matching a single attribute when looking for that printer. > > and even within the same context there can be multiple hosts that > > claim the same name. in DNS there is only one authority and RRset > > for any given name, so DNS query interfaces don't have the possibility > > of saying "there are multiple hosts claiming this name, choose > > one of the following..." > Again, either this works, or it doesn't. If you can't handle two hosts > claiming to have the same name, then there is no name lookup in > a zeroconf network. If the current API is broken, then we need to > fix it. the DNS API isn't broken (at least, not for this reason) because DNS - by design - can't have naming conflicts. applications quite reasonably depend on DNS not having more than one RRset per name. but trying to use the DNS API to look up names where there might be collisions *is* broken. > > > BTW: is there an example of a major application that will work with NAT, > > > and not work with LL? > > > > YES!!!!!!! > > > > First of all, what do you mean by "major application"? Do you think > > that email and web are the only apps that matter? "major" apps are the > > apps that *you* need to get work done, or to communicate with others in the > > way that works for *you*. those differ from one kind of user, and from one > > kind of enterprise customer, to another. there is no typical internet > > user anymore. > Concur. Major application is "something I've heard of", for the purposes > of this discussion. Probably I should have used "protocol" rather than > application, because any application can have bugs, and like my > previous assertion that just as applications have to be updated to > handle IPv6 (and before that, NAT and CIDR maybe), then it is reasonable > to expect people to update applications to handle service discovery, > 169.254/16 addresses and "DNS can return non-unique names" > PROVIDED that those are valid IETF requirements. NO. as a fundamental part of its design, DNS names *are* unique. > > would you consider SIP a major app? it doesn't work over NAT, and the > > midcom group is making a royal mess trying to figure out how to make it > > work. > SIP == "Session Initiation Protocol"? Never heard of it.... > That wasn't the question. I asked for an app that _worked_ with NAT. sorry - I did misread the question. obviously NATs are a hot button for me... broad generalization: most apps that only involve two endpoints work with NATs as long as the app "inside" the NAT initiates all connections and as long as the app or users uses DNS names (and therefore they'll get translated by the DNS ALG on the NAT) rather than IP addresses. (But DNS ALG creates problems of its own because those addresses leak into other contexts where they're not valid) so no, I don't think that every app that works with NAT will work with v4 LL addresses - some of the problems are the same between the two spaces (both private addrs and LL address are ambiguous) and some are different (v4 addrs are subject to being shot down without notice, breaking TCP connections, and DNS lookups of any kind are a poor mechanism for obtaining v4 LL addresses) > > how about multiplayer real-time games? you don't see them much in the > > business world, but there's a fairly big market out there... some of them > > sort-of work with NAT but not in a general fashion - e.g. you have to > > tunnel messages through central proxies. > This is the sort of application that will reasonably work with Link Local, and > not with NAT. That's the reverse question to what I asked. it's quite a stretch to assume that all of the participants of a RT game are on the same link in the LL case but on different sides of a NAT in the NAT case... > > > Or is there a way of phrasing a service discovery query "find me the > > > file with zcip in the name"? > > > > it seems easier to make the service discovery query "find me the nearby > > machine that asserts a name of leon". then if he gets multiple answers > > back (some machine names are fairly common), he needs to disambiguate that > > somehow... > That would be a naming service. Whether that is different to the service > discovery service is implementation detail. it wouldn't be exclusively a naming service, because it would return other information than just each machine's name (one machine named leon is an imac, another is a thinkpad...) > > well, it sort of seems to me that if you configure the printer at all > > then you're not talking "zeroconf" anymore - you're talking about > > having to have an interface for that printer to allow it to be configured > > (impractical for many kinds of appliance) and if you "configure" that > > printer when you "put it down" you can about as easily arrange for > > DHCP to give it a stable IP address and a stable DNS name. > Not so. The whole point of zeroconf isn't that you don't have to > ever administer things. It is that you can run networks without the > central registry and without reliance on an unrelated box being > on-line. So I can type in "lounge room" or "basement" into my printer, > and not have to worry that my DHCP server and DNS server > are available. my strong impression is that there's more than one "whole point" of zeroconf. > The other thing is that if you assume that everyone has a > DNS server and can set up a DHCP server, then you > don't need zeroconf. But the world isn't like that. My parents > have no idea about networking - but my Mum could probably > plug colour coded cables into sockets. At that point, she should > be able to print a notice for the gardening group. is your Mum going to configure a printer to know its location? > USB can > do that - the question is whether IP will ever be able to. well for USB the problem is somewhat easier - because you're unlikely to have a USB connection to a network halfway across the planet (but you might well have a VPN tunnel to such a location, and want to access devices on an IP network in such a location). and chances are that you'll *know* what is on your local USB network. and from my limited exposure to USB I don't think they're trying to use simple name lookup from a global name space to find devices. that and with USB there was no expectation that USB appliances would work with an existing set of applications that was designed to talk with IP hosts... whereas there does seem to be an expectation that existing IP apps can talk to LL devices even though they violate a number of assumptions that many apps quite reasonably make. > > and it also seems to me that "zeroconf" networks are most likely to be > > used in ad hoc situations - if the network is going to be up long enough > > for the names and locations of devices to be stable then (again) it's worth > > it to start managing that network to some degree. > If it requires management, then you excluded 99% of people. understood and agreed. at the same time, if you expect LL networks to use the same interfaces and applications as existing IP networks, you need to make LL networks behave like IP networks, and some of the characteristics of IP networks (like stable, unique addresses and globally unique host names) are difficult to achieve without some degree of management. > Home networks for non-networking gurus are very difficult. It isn't > just a matter of temporary - it is a matter of reasonable effort for > reasonable outcomes. Home networks may not be protected by IPSEC, > not have central registries, may not have DNS servers. But that is > appropriate for some applications. Management should never require > anything more than giving the device a name and plugging it > into a hub. actually giving the device a name may be too much to ask. > > though I'll accept that a network can be expected to have a mixture of > > ad hoc and configured devices. the printer may be stationary while the > > laptops move around, etc. so in some cases it might be reasonable to > > configure a particular printer to know some of its attributes even if you > > can't expect to configure every device that might appear on the local > > network(s) to which that printer is attached. that doesn't mean that > > name lookup is a good solution in general to the problem of finding > > services on a network. > Agree with the point that name lookup isn't everything, but it is > still necessary. > Name is about the only thing that is stable on my laptop. I use > different operating systems, networking devices, etc. Tim still needs > to find my laptop if he wants the _latest_ version of that file. I don't know how you can move a laptop around and keep the same DNS name - in my experience the name has to change even with dynamic DNS (because one network that I connect to insists on updating the DNS name that *it* has assigned to the laptop to reflect the laptop's current IP address, and so that the address lookup will return *its* name for the laptop rather than say, the name the laptop has at home). So if I'm going to try to assign a stable name for the laptop that works no matter where it happens to be connected, that name can't be the DNS name. > > of course the ability to discover local resources by means other > > than name lookups is useful for both zeroconf and managed networks, > > and it would be nice if the same mechanism could work for both cases. > Absolutely. DNS-SD without a specified application API is dead. it would help to stop calling it anything with DNS in the name, and to stop trying to make it look like DNS. calling it DNS is confusing because the service you're talking about doesn't have the same characteristics of DNS. having it look like DNS isn't reasonable because you need this service to provide more flexibility than you can reasonably shoehorn into the DNS protocol. > > > Or a simpler case (which doesn't require management) - I want > > > to build a zeroconf printer that is a colour bubblejet that can do > > > A5, A4 or A3, but not that dodgy American Letter format. What > > > are the attributes that I should program into its SLP SA or > > > DNS-SD reporting, or whatever? > > > > ask the IPP people - they've been thinking about this stuff for > > awhile, though I don't think it's been heavily targeted at SLP. > OK - an even easier question. "I'm at a conference, and I want to > print that email from Keith. How do I find a printer on my local link?" are you asking what is reasonable, or are you asking how to do this in the context of what zeroconf is trying to define? as for "what is reasonable" I'd say that the user clicks on network neighborhood or runs whatever program his OS uses for that purpose, and maybe it pops up a list of device classes - printers, scanners, video projectors, hosts - and you select 'printer', and then it shows a list of printers, along with characteristics and locations, and you select 'the color printer that is 10m away'. (or lacking GPS coordinates, you select 'the color printer that thinks its in room xyz of Hotel Foo') Keith From owner-zeroconf@merit.edu Tue Jul 23 10: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 KAA13878 for ; Tue, 23 Jul 2002 10:33:46 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D931691255; Tue, 23 Jul 2002 10:34:34 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9EB2491263; Tue, 23 Jul 2002 10:34: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 7236791255 for ; Tue, 23 Jul 2002 10:34:33 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 50DC45DE4F; Tue, 23 Jul 2002 10:34:33 -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 027F05DDF8 for ; Tue, 23 Jul 2002 10:34:32 -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 g6NEYPt20230; Tue, 23 Jul 2002 10:34:25 -0400 (EDT) Message-Id: <200207231434.g6NEYPt20230@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bernard Aboba Cc: Keith Moore , Joshua Graessley , zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP In-reply-to: (Your message of "Mon, 22 Jul 2002 23:26:17 PDT.") Date: Tue, 23 Jul 2002 10:34:25 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > so what? the management of the namespace is completely orthogonal > > to the way the queries are transmitted over the network. using > > multicast won't solve the problem that the DNS namespace is > > completely incompatible with an ad hoc network. > > There is, for example, no concept of delegation in mDNS. And it is also > true that mDNS is not appropriate for resolution of FQDNs in most cases. > However, few hosts spend all their time connected to adhoc networks, and > names persist while network connections change. Therefore, there is little > intrinsic reason why a host connected to an adhoc network could not have > earlier obtained, and subsequently respond to queries for, an FQDN. now that's a disaster waiting to happen. just because a host might have once been associated with an FQDN doesn't mean it's *still* associated with that FQDN. and if one host does a DNS lookup and gets one result for an FQDN while another host does an mDNS lookup and gets a different result, you've just broken DNS. > Rather, I would argue that the difficulty of utilizing mDNS to > resolve FQDNs arises largely from the difficulty of implementing > appropriate security mechanisms in the purely adhoc case, rather than > from an intrinsic namespace incompatibility. Were > it possible to use DNS security within adhoc name resolution, the > difficulties in use of the DNS namespace with mDNS would be largely > resolved. the problem isn't just security, it's also consistency. what you're essentially saying is that mDNS can be used as a cache for real DNS, and with appropriate constraints this might be doable. but with real DNS then there really is an assumption that you can get to an authoritative server - one that is controlled or at least chosen by the party that assigned the name, and which is generally updated in a timely fashion - and get current, authoritative answers from that server. with mDNS this would not be possible - it's as if you're disconnected from the network and you're stuck with whatever is in the cache of your local resolver. > > okay, fine - I'll restate then. SLP is a far better starting point > > than DNS for the kinds of lookups you need to do in an ad hoc network. > > I think you're overly constraining the kind of interactions that occur in > adhoc networks. Aside from finding a printer or file server, there can > also be a need for directed file transfers or web usage. > > How does SLP help with displaying "http://foo/myfolder/"? it doesn't. but URLs are supposed to have globally consistent meanings, and it's not within zeroconf's purview to change that. more generally, just because ad hoc networks are useful is not a justification for this group trying to change the behavior or meaning of well-established interfaces and protocols in whatever manner it sees fit. > > character set is also irrelevant to this question. DNS simply doesn't > > have any way to say "find the nearest video projectors" and that's really > > what you need. > > I'd claim that the question of the "best" service is a completely > different question than either name resolution or classic service > discovery. perhaps. but my point is that trying to overload DNS for this purpose does harm to DNS and to apps, and doesn't really solve your problem anyway. > > SLP definitely needs fixing. but it's a better starting point. > > I'm curious as to what exactly needs to be "fixed". SLPv2 has evolved over > a long period in response to deployment experience and critical > evaluations. So I'm curious as to what you believe is still missing. it's been awhile since I reviewed SLP, so I don't really remember details. but I recall thinking that that service: URI was pretty bogus, and that it was fairly unreasonable to expect SLP to work beyond a relatively local portion of the network topology (nothing inherently wrong with that but some SLP proponents were claiming more generality) > > apps expect an address to be reasonably stable and unambiguous. > > This seems to argue for applications caching the result of name > resolutions. not exactly. but at the same time it's completely reasonable for apps to pass around addresses - for many purposes DNS lookups don't work very well. > That's a dangerous game, with or without mDNS, if only for > the sake of resilience. In reality, Internet hosts go down on a regular > basis, and well written applications need to deal with that gracefully. when the host goes down it tends to break existing connections to that host anyway, and it tends to kill all the apps running on that host anyway, so having the address be able to change when that happens is probably not a big deal. that doens't mean, however, that DNS is the mechanism that every application should use to find the new address of that host if and when it happens to reappear on the network. > As for the necessity of "unambiguous" naming, I'd remind you that NetBIOS > names exist within a flat hierarchy and have been in widespread use for > decades without causing the application problems you mention. NetBIOS doesn't try to look like DNS, and people don't try to use NetBIOS names on an internet-wide scale. (e.g. I don't give you the NetBIOS name of my server and expect you to be able to connect to it) Keith From owner-zeroconf@merit.edu Tue Jul 23 10:50: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 KAA15000 for ; Tue, 23 Jul 2002 10:50:19 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 82FCA91305; Tue, 23 Jul 2002 10:51:08 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id ED80591306; Tue, 23 Jul 2002 10:51: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 B96A791305 for ; Tue, 23 Jul 2002 10:51:05 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A226B5DEDC; Tue, 23 Jul 2002 10:51: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 19F4C5DEC8 for ; Tue, 23 Jul 2002 10:51: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 g6NEost22323; Tue, 23 Jul 2002 10:50:54 -0400 (EDT) Message-Id: <200207231450.g6NEost22323@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Bernard Aboba Cc: Keith Moore , Brad Hards , zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP In-reply-to: (Your message of "Mon, 22 Jul 2002 23:42:41 PDT.") Date: Tue, 23 Jul 2002 10:50:53 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > > it's *not* easy to make this work on any scale. have you ever tried it? > > Yup. We run a network with more than 80K hosts, day in and day out. and how heterogeneous is it? > > for similar reasons we had to completely disable NIS hosts maps and WINS. > > I'm sorry that your admins lack the skill to properly maintain NIS or > WINS. they do have the skill. the proper way to maintain NIS host maps is to turn them off, because they just get in the way. sane admins do not try to make their lives more complex than they need to be. > > from a different angle, one of the reasons that gethostbyname() is > > a lousy interface for DNS queries is that it was designed to read a host > > file (i.e. a local disk file), where (a) you expect a more-or-less > > immediate response (so it's okay to block during the call) and (b) you > > simply don't have failure modes like "temporary inability to contact server" > > or "name exists but there are no A records" that applications often > > need to handle differently than "no such host". (no, it's NOT okay to > > bounce mail if you get a temp failure on the DNS lookup, but there are > > still lots of programs doing this. and no, it's NOT okay for a web > > browser to say "no such server" when the the query on the DNS name fails > > for temporary reasons.) > > Yes, it's hard for applications to use name resolution correctly. So what? > Well written applications need not exhibit any of these problems. you're missing the point, which is this: when you overload interfaces to try to do things that they weren't designed to do, you break apps that use those interface. you're changing the API (often poorly) without changing the apps that were designed to use the old API. > > "no ill effects" is one of the most ridiculous things I've ever seen stated > > in IETF. it's been a disaster for applications and for users. > > One might say the same thing about sockets, yet I don't see you arguing > to avoid changes to TCP :) sockets is a bit klunky, but it works fairly well. the worst problem I have with sockets is that there are some performance implications associated with forcing the programmer to separate (e.g.) connect() and write() and sending an EOF, and it's hard to extend that interface to do some things I want to do with TCP. but (and this is just a guess at what you might be thinking) it is NOT a bug that sockets works with IP addresses rather than DNS names. > > obviously... you've never tried to administer a heterogeneous network > > of any size. > > Hmmm... I guess running a network with more than two million users, > several thousand routers and some of the Internet's most heavily > loaded web servers doesn't qualify, huh? not necessarily. how heterogeneous is it? how much control do you have over your users and their machines? > > programmers depend on those semantics. for "resolvers" to change those > > semantics on a local basis is a gross and utterly irresponsible protocol > > violation... it's insanity. > > Yet that is exactly what RFC 1536 did, for example, and the world didn't > end. 1536 didn't try to change semantics of DNS RRs. Keith From owner-zeroconf@merit.edu Tue Jul 23 11:24: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 LAA17386 for ; Tue, 23 Jul 2002 11:24:16 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AD44A912C0; Tue, 23 Jul 2002 11:25:01 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7488691307; Tue, 23 Jul 2002 11:25: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 6AD3B912C0 for ; Tue, 23 Jul 2002 11:25:00 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 59A645DDF7; Tue, 23 Jul 2002 11:25: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 1A2DD5DEC8 for ; Tue, 23 Jul 2002 11:24: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 g6NFOpt27757; Tue, 23 Jul 2002 11:24:51 -0400 (EDT) Message-Id: <200207231524.g6NFOpt27757@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Rod Cc: zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP In-reply-to: (Your message of "Tue, 23 Jul 2002 04:28:00 PDT.") Date: Tue, 23 Jul 2002 11:24:51 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > I agree, I was exaggerating to get my point across, which is that the > service discovery protocol should not have to deal with all this > endless sea of attributes and characteristics of services. That's > what each service protocol is designed for. Mixing them in with the > service discovery protocol seems like overkill and makes things more > complicated, overdone, and tedious, in my opinion. I disagree, to a point. the service discovery protocol shouldn't have to know about the semantics of those attributes, but it should be able to advertise those attributes for the benefit of client programs that can make use of them. From owner-zeroconf@merit.edu Tue Jul 23 11:26: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 LAA17547 for ; Tue, 23 Jul 2002 11:26:37 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 0EBF191307; Tue, 23 Jul 2002 11:27:26 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id CBF2191309; Tue, 23 Jul 2002 11:27: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 B853C91307 for ; Tue, 23 Jul 2002 11:27:24 -0400 (EDT) Received: by segue.merit.edu (Postfix) id A80075DE9F; Tue, 23 Jul 2002 11:27:24 -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 2F3735DDF7 for ; Tue, 23 Jul 2002 11:27:24 -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 g6NFRLt28108; Tue, 23 Jul 2002 11:27:21 -0400 (EDT) Message-Id: <200207231527.g6NFRLt28108@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Rod Cc: zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP In-reply-to: (Your message of "Tue, 23 Jul 2002 03:47:21 PDT.") Date: Tue, 23 Jul 2002 11:27:21 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > So for something like a file server, I'd want to do something like: > > service type = service:ftp:ftp:// > URI = service:ftp:ftp://169.254.23.16:21 > scope = default > attributes = ...,(files=asa.jpg, pag.jpg, chip.jpg, par.jpg, > tu.jpg, cielo.jpg, par2.jpg, tuno1.jpg, cielo2.jpg, parque.jpg, > tunovio2.jpg, marco.jpg, parque2.jpg, usps.jpg, ent.jpg, parque3.jpg, > via.jpg, experiment.jpg, parque5.jpg, vista.jpg, eye.jpg, > parque6.jpg, xico.jpg, etc. etc. etc. etc....) > > Hey, who needs 'ls'? that's a really silly example. surely nobody expects to use a service discovery protocol in this way. From owner-zeroconf@merit.edu Tue Jul 23 11:30: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 LAA17826 for ; Tue, 23 Jul 2002 11:30:48 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 45F0191309; Tue, 23 Jul 2002 11:31:33 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 1930D9130A; Tue, 23 Jul 2002 11:31: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 B095291309 for ; Tue, 23 Jul 2002 11:31:31 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 9D8305DEDC; Tue, 23 Jul 2002 11:31: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 B00A45DDF7 for ; Tue, 23 Jul 2002 11:31:30 -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 g6NFVTt28695; Tue, 23 Jul 2002 11:31:29 -0400 (EDT) Message-Id: <200207231531.g6NFVTt28695@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Varuni Witana Cc: zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP In-reply-to: (Your message of "Tue, 23 Jul 2002 22:25:31 +1000.") <3D3D4B3B.9B74E8C6@arc.corp.mot.com> Date: Tue, 23 Jul 2002 11:31:29 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > is it possible to quantify how many distinct instances of a service need > to exist before scalability issues with having to query each one in > turn, overcome the perceived complexity of SLP? the v4 LL document has some explicit assumptions about how many hosts are reasonable for links using LL addresses - 1300 hosts is considered an upper bound. so a reasonable test of SLP (or any other candidate discovery protocol for use in ad hoc networks) might be: how well will it work for networks of 1300 hosts with a reasonable mix of host classes (workstations, printers, etc.)? From owner-zeroconf@merit.edu Tue Jul 23 11:37: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 LAA18489 for ; Tue, 23 Jul 2002 11:37:51 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AE5D491265; Tue, 23 Jul 2002 11:38:40 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 79F56912C1; Tue, 23 Jul 2002 11:38: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 8240B91265 for ; Tue, 23 Jul 2002 11:38:39 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 6FC335DEDC; Tue, 23 Jul 2002 11:38:39 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from zeus.anet-chi.com (zeus.anet-chi.com [207.7.4.6]) by segue.merit.edu (Postfix) with ESMTP id 170FE5DED2 for ; Tue, 23 Jul 2002 11:38:39 -0400 (EDT) Received: from jim (as1b-93.chi.il.dial.anet.com [198.92.157.93]) by zeus.anet-chi.com (8.12.2/ANET Internet Solutions) with SMTP id g6NFcRKJ016033; Tue, 23 Jul 2002 10:38:27 -0500 (CDT) Message-ID: <003a01c2325f$40169960$0a00a8c0@unir.com> From: "Jim Fleming" To: "Keith Moore" , "Rod" Cc: References: <200207231527.g6NFRLt28108@astro.cs.utk.edu> Subject: Re: Relationship DNS-SD and SLP Date: Tue, 23 Jul 2002 10:40:18 -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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Keith Moore" To: "Rod" > > > > Hey, who needs 'ls'? > > that's a really silly example. surely nobody expects to use a service > discovery protocol in this way. That is one of the merits of having the "toy" 32-bit IPv4 Internet for silly experiments and Proof-of-Concept market trials. Once all of the testing is worked out, people can move to the more serious and stable IPv8 64-bit address space, using 128-bit DNS services. People do not have to be constrained in their thinking by the narrow-minded I* society. There is a place to expand and grow. Jim Fleming http://www.iana.org/assignments/ipv4-address-space http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt From owner-zeroconf@merit.edu Tue Jul 23 13:27: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 NAA25100 for ; Tue, 23 Jul 2002 13:27:31 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 9AE8E9123C; Tue, 23 Jul 2002 13:28:22 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 66B5D91263; Tue, 23 Jul 2002 13:28: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 5A81D9123C for ; Tue, 23 Jul 2002 13:28:21 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 3E4D15DE5D; Tue, 23 Jul 2002 13:28:21 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by segue.merit.edu (Postfix) with ESMTP id 0D27A5DE5A for ; Tue, 23 Jul 2002 13:28:21 -0400 (EDT) Received: from fwd02.sul.t-online.de by mailout07.sul.t-online.com with smtp id 17X3SK-0003ml-01; Tue, 23 Jul 2002 19:28:16 +0200 Received: from cookie.tjansen.de (520059241914-0001@[217.226.29.205]) by fmrl02.sul.t-online.com with esmtp id 17X3S4-05qhVYC; Tue, 23 Jul 2002 19:28:00 +0200 From: Tim Jansen Reply-To: tim@tjansen.de To: Brad Hards Subject: Re: Relationship DNS-SD and SLP Date: Tue, 23 Jul 2002 19:40:22 +0200 User-Agent: KMail/1.4.5 References: <200207230331.g6N3VBt21296@astro.cs.utk.edu> <200207231439.38052.bhards@bigpond.net.au> In-Reply-To: <200207231439.38052.bhards@bigpond.net.au> Cc: zeroconf@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200207231940.22197.ml@tjansen.de> X-Sender: 520059241914-0001@t-dialin.net Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Tuesday 23 July 2002 06:39, Brad Hards wrote: > Agree. At the service discovery step, I want to choose a capability. At the > service usage step, I want to communicate. Not always. If you have a large number of devices, then you may want to choose a capability. But in your home network, where you have an Epson and a Lexmark printer, you want to select "the Lexmark" or "the Epson". So here DNS-SD works as intended. > Example situation: Tim Jansen and I meet at Linux-Kongress, want to copy > over the latest tarball of zcip. We are both using link-local addresses on > laptops linked into the main conference network. I have some files > available for rsync, and he has a client. How does get the file? > I can tell him what I call my machine ("leon"), and that the file is > available, but that won't help without some kind of name lookup (which > could be DNS). The most natural way would be to have an instant messenger that can discover persons in the local network, so you would search for my name. Fortunately this is quite easy with SIMPLE as IM protocol because it can work peer-to-peer, you just need to discover the other person's URL using a service discovery protocol. > A5, A4 or A3, but not that dodgy American Letter format. What > are the attributes that I should program into its SLP SA or > DNS-SD reporting, or whatever? http://www.isi.edu/in-notes/iana/assignments/svrloc-templates/printer.2.0.en bye... From owner-zeroconf@merit.edu Tue Jul 23 13:30: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 NAA25215 for ; Tue, 23 Jul 2002 13:30:28 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id AEF5B91263; Tue, 23 Jul 2002 13:30:54 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 7EA5391264; Tue, 23 Jul 2002 13:30: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 76AC991263 for ; Tue, 23 Jul 2002 13:30:53 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 556295DE5A; Tue, 23 Jul 2002 13:30:53 -0400 (EDT) Delivered-To: zeroconf@merit.edu Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by segue.merit.edu (Postfix) with ESMTP id 220555DE52 for ; Tue, 23 Jul 2002 13:30:53 -0400 (EDT) Received: from fwd02.sul.t-online.de by mailout09.sul.t-online.com with smtp id 17X3Uj-0006Ow-0G; Tue, 23 Jul 2002 19:30:45 +0200 Received: from cookie.tjansen.de (520059241914-0001@[217.226.29.205]) by fmrl02.sul.t-online.com with esmtp id 17X3UY-0d9XkmC; Tue, 23 Jul 2002 19:30:34 +0200 From: Tim Jansen Reply-To: tim@tjansen.de To: Keith Moore Subject: Re: Relationship DNS-SD and SLP Date: Tue, 23 Jul 2002 19:42:56 +0200 User-Agent: KMail/1.4.5 References: <200207230539.g6N5dJt22145@astro.cs.utk.edu> In-Reply-To: <200207230539.g6N5dJt22145@astro.cs.utk.edu> Cc: zeroconf@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200207231942.56343.ml@tjansen.de> X-Sender: 520059241914-0001@t-dialin.net Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Tuesday 23 July 2002 07:39, Keith Moore wrote: > would you consider SIP a major app? it doesn't work over NAT, and the > midcom group is making a royal mess trying to figure out how to make it > work. Actually it does work as most implementations already support STUN: http://www.ietf.org/internet-drafts/draft-ietf-midcom-stun-01.txt bye... From owner-zeroconf@merit.edu Tue Jul 23 16:18: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 QAA02926 for ; Tue, 23 Jul 2002 16:18:53 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 883F79126A; Tue, 23 Jul 2002 16:19:35 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 4FCF89129C; Tue, 23 Jul 2002 16:19: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 51FE99126A for ; Tue, 23 Jul 2002 16:19:34 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 2DEF15DDCE; Tue, 23 Jul 2002 16:19:34 -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 A2AB55DDB2 for ; Tue, 23 Jul 2002 16:19:33 -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 g6NKJWk01063 for ; Tue, 23 Jul 2002 13:19:32 -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, 23 Jul 2002 13:19:32 -0700 Received: from [17.202.41.197] (rlopez.apple.com [17.202.41.197]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g6NKJVT19190 for ; Tue, 23 Jul 2002 13:19:32 -0700 (PDT) Mime-Version: 1.0 X-Sender: rod@apple.com (Unverified) Message-Id: In-Reply-To: <200207231527.g6NFRLt28108@astro.cs.utk.edu> References: <200207231527.g6NFRLt28108@astro.cs.utk.edu> Date: Tue, 23 Jul 2002 13:19:16 -0700 To: zeroconf@merit.edu From: Rod Subject: Re: Relationship DNS-SD and SLP Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk >At 11:27 AM -0400 7/23/02, Keith Moore wrote: >that's a really silly example. surely nobody expects to use a service >discovery protocol in this way. I'm glad I got the point across then! ;-) I liked your comment: >Sane admins do not try to make their lives more complex than they need to be. -Rod From owner-zeroconf@merit.edu Tue Jul 23 17:22: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 RAA04606 for ; Tue, 23 Jul 2002 17:22:14 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 499F0912C2; Tue, 23 Jul 2002 17:22:59 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 16EAA912C5; Tue, 23 Jul 2002 17:22: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 1D81F912C2 for ; Tue, 23 Jul 2002 17:22:58 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 0B2605DE71; Tue, 23 Jul 2002 17:22:58 -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 CE50B5DDB2 for ; Tue, 23 Jul 2002 17:22:57 -0400 (EDT) Received: from fwd00.sul.t-online.de by mailout08.sul.t-online.com with smtp id 17X77M-0000oh-03; Tue, 23 Jul 2002 23:22:52 +0200 Received: from cookie.tjansen.de (520059241914-0001@[217.226.29.205]) by fmrl00.sul.t-online.com with esmtp id 17X77D-1UYKbAC; Tue, 23 Jul 2002 23:22:43 +0200 From: Tim Jansen Reply-To: tim@tjansen.de To: Rod Subject: Re: Relationship DNS-SD and SLP Date: Tue, 23 Jul 2002 23:35:06 +0200 User-Agent: KMail/1.4.5 References: <200207231527.g6NFRLt28108@astro.cs.utk.edu> In-Reply-To: Cc: zeroconf@merit.edu MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200207232335.06355.ml@tjansen.de> X-Sender: 520059241914-0001@t-dialin.net Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 8bit On Tuesday 23 July 2002 22:19, Rod wrote: > >At 11:27 AM -0400 7/23/02, Keith Moore wrote: > >that's a really silly example. surely nobody expects to use a service > >discovery protocol in this way. > I'm glad I got the point across then! ;-) You didn't, you just showed that it is not very smart to use a service discovery protocol when a protocol for distributed searching would be appropriate. For example a protocol that sends the query to all service agents and they respond to the user agent if they find any matches (BTW it would be quite interesting to add this feature to SLP). bye... From owner-zeroconf@merit.edu Tue Jul 23 17:51: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 RAA05274 for ; Tue, 23 Jul 2002 17:51:25 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D291C91243; Tue, 23 Jul 2002 17:52:15 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id A240E912C5; Tue, 23 Jul 2002 17:52: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 9432691243 for ; Tue, 23 Jul 2002 17:52:14 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 7BB505DDB2; Tue, 23 Jul 2002 17:52:14 -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 F05F05DD8D for ; Tue, 23 Jul 2002 17:52:13 -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 g6NLqCA05008 for ; Tue, 23 Jul 2002 14:52:12 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Tue, 23 Jul 2002 14:51:31 -0700 Received: from [17.202.41.197] (rlopez.apple.com [17.202.41.197]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id g6NLqAl09258; Tue, 23 Jul 2002 14:52:10 -0700 (PDT) Mime-Version: 1.0 X-Sender: rod@apple.com (Unverified) Message-Id: In-Reply-To: <200207232335.06355.ml@tjansen.de> References: <200207231527.g6NFRLt28108@astro.cs.utk.edu> <200207232335.06355.ml@tjansen.de> Date: Tue, 23 Jul 2002 14:51:54 -0700 To: tim@tjansen.de From: Rod Subject: Re: Relationship DNS-SD and SLP Cc: zeroconf@merit.edu Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-zeroconf@merit.edu Precedence: bulk At 11:35 PM +0200 7/23/02, Tim Jansen wrote: >You didn't, you just showed that it is not very smart to use a service >discovery protocol when a protocol for distributed searching would be >appropriate. I wasn't talking about distributed searching (if I understand you correctly). Just a client looking for an ftp service, and a server that is advertising its service and also its 'offerings.' (Files in this case, which is an example I exagerated on purpose.) You're right in a way though, that was precisely my intention. To make a strong distinction between the processes (and protocols) for discovering a service instance, and for discovering said service's characteristics, attributes, and capabilities, in order to express my point of view about how service discovery should work, with focus on Zeroconf networks. Thanks! -Rod From owner-zeroconf@merit.edu Tue Jul 23 18:20: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 SAA06040 for ; Tue, 23 Jul 2002 18:20:47 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id D1E1B912CA; Tue, 23 Jul 2002 18:21:37 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 9EF49912CB; Tue, 23 Jul 2002 18:21: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 850B7912CA for ; Tue, 23 Jul 2002 18:21:36 -0400 (EDT) Received: by segue.merit.edu (Postfix) id 54EAC5DE2F; Tue, 23 Jul 2002 18:21:36 -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 DF1475DD8D for ; Tue, 23 Jul 2002 18:21:35 -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 g6NMLTt17848; Tue, 23 Jul 2002 18:21:29 -0400 (EDT) Message-Id: <200207232221.g6NMLTt17848@astro.cs.utk.edu> X-URI: http://www.cs.utk.edu/~moore/ From: Keith Moore To: Rod Cc: zeroconf@merit.edu Subject: Re: Relationship DNS-SD and SLP In-reply-to: (Your message of "Tue, 23 Jul 2002 13:19:16 PDT.") Date: Tue, 23 Jul 2002 18:21:29 -0400 Sender: owner-zeroconf@merit.edu Precedence: bulk > >that's a really silly example. surely nobody expects to use a service > >discovery protocol in this way. > > I'm glad I got the point across then! ;-) Well, I'm not sure what point you were trying to make. It's certainly not an argument against a service discovery protocol, nor an argument in favor of trying to use a variant of DNS to discover hosts on an ad hoc network. From owner-zeroconf@merit.edu Tue Jul 23 21:37: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 VAA09833 for ; Tue, 23 Jul 2002 21:37:27 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 7967791269; Tue, 23 Jul 2002 21:38:16 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 471049126D; Tue, 23 Jul 2002 21:38: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 1888291269 for ; Tue, 23 Jul 2002 21:38:15 -0400 (EDT) Received: by segue.merit.edu (Postfix) id F05AA5DE61; Tue, 23 Jul 2002 21:38:14 -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 C5EE35DE5F for ; Tue, 23 Jul 2002 21:38:09 -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 g6O1c8k07031 for ; Tue, 23 Jul 2002 18:38: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 ; Tue, 23 Jul 2002 18:37:29 -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 g6O1c7l00892 for ; Tue, 23 Jul 2002 18:38:07 -0700 (PDT) Date: Tue, 23 Jul 2002 18:38:08 -0700 Subject: Re: Relationship DNS-SD and SLP Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v540) From: Joshua Graessley To: zeroconf@merit.edu Content-Transfer-Encoding: 7bit In-Reply-To: <200207230539.g6N5dJt22145@astro.cs.utk.edu> Message-Id: <017B2008-9EA6-11D6-A080-000393760260@apple.com> X-Mailer: Apple Mail (2.540) Sender: owner-zeroconf@merit.edu Precedence: bulk Content-Transfer-Encoding: 7bit On Monday, July 22, 2002, at 10:39 PM, Keith Moore wrote: >>> okay, then you're not talking about DNS names anymore, because apps >>> can't >>> depend on those names to have the properties that DNS names have >>> such as >>> global uniqueness. so you don't want to use the same API to look >>> them >>> up that you use to make DNS queries, because that will confuse apps >>> that >>> expect the names and answers returned from that interface to act >>> like DNS. >>> and there's no particular reason to use the DNS protocol, because >>> most of >>> the RR types in DNS implicitly assume some kind of distributed >>> management >>> that is not present in an ad hoc system. >> Maybe. >> On my normal managed LAN, I can ask for the address of "gateway", and >> get "gateway.cuneata.net.", where "gateway" isn't unique, but >> "gateway.cuneata.net." is unique (or had better be, I don't think I >> got taken by the >> latest scam :). >> "gateway.linklocal" isn't that much of a extension. However it >> probably doesn't belong in the same DNS space as my authenticated >> name/address pairs, both to stop confusing applications and to prevent >> pollution of my DNS. > > it's even worse than that, because "gateway.linklocal" doesn't mean the > same thing to you as it does to me, if our contexts are different. > so you can't use that name in a referral from one app to another > and expect it to work. even ad hoc networks don't necessarily exist as > disconnected islands. people will be running laptops or palmtops that > participate in an ad hoc local network around a conference table in > some hotel meeting room at the same time that they're tied via a > wireless > link to a VPN to the corporate wireless network, and maybe another VPN > to a > home network. what does "printer.linklocal" mean then - is it the > printer in the room, or the printer at the office, or the printer at > home? > and can I reasonably say "just print to printer.linklocal" to someone > across > the table? (especially given the assumption that some appliances > are going to use linklocal as their sole means of addressing...) Ok, so just to try and keep up, you've moved from service discovery to name resolution? It is true that gateway.local. wouldn't mean the same thing to two different people on different networks in much the same way that 10.0.1.12 would would not mean the same thing. Does that mean that names that only have a local scope would not be useful? Addresses without global scope are very useful and application don't necessarily have to be rewritten to make use of them. Throw something nasty like NAT in to the picture and things get pretty hairy, but that's a separate problem. > and even within the same context there can be multiple hosts that > claim the same name. in DNS there is only one authority and RRset > for any given name, so DNS query interfaces don't have the possibility > of saying "there are multiple hosts claiming this name, choose > one of the following..." Name collisions can be detected and avoided. This is not a difficult problem to solve. >> BTW: is there an example of a major application that will work with >> NAT, >> and not work with LL? > > > YES!!!!!!! > > First of all, what do you mean by "major application"? Do you think > that email and web are the only apps that matter? "major" apps are > the apps > that *you* need to get work done, or to communicate with others in the > way > that works for *you*. those differ from one kind of user, and from one > kind of enterprise customer, to another. there is no typical internet > user anymore. > > would you consider SIP a major app? it doesn't work over NAT, and > the > midcom group is making a royal mess trying to figure out how to make > it work. > > how about multiplayer real-time games? you don't see them much in the > business world, but there's a fairly big market out there... some of > them > sort-of work with NAT but not in a general fashion - e.g. you have to > tunnel > messages through central proxies. > > for the people I work with, cluster computing systems are essential, > and they don't work over NAT. you might not think of them as "major" > but > they are used to implement essential services like large-scale > modeling. > essentially all high-performance computing today is cluster computing. All of the examples you have just given do not work with NAT. Brad Hards asked if there were any applications that would work with NAT but not work with link local addresses. > >>>> What I want out of a zeroconf service discovery system is to be >>>> able to >>>> put in some combination of attributes (possibly none), and be >>>> offered a >>>> choice of services on my network. I don't care much about the names >>>> or IP >>>> addresses, just what that service can do. >>> >>> I think you do care about the names and IP addresses because once >>> you've >>> identified a service that you want to use then you want to know how >>> to >>> talk to it. If you let the user choose which device/service to use >>> then >>> you want to present the name to the user in a menu. Just because you >>> didn't start your query with a name doesn't mean you don't care >>> about the >>> name. >> Agree. At the service discovery step, I want to choose a capability. >> At the >> service usage step, I want to communicate. >> >>> Of course if you have a service discovery system (and it seens like >>> you >>> need one) then you don't need the pseudo-DNS anymore, because you can >>> look up the device/service names just as easily using the service >>> discovery system. >> Maybe, maybe not. >> >> Example situation: Tim Jansen and I meet at Linux-Kongress, want to >> copy >> over the latest tarball of zcip. We are both using link-local >> addresses on >> laptops linked into the main conference network. I have some files >> available >> for rsync, and he has a client. How does get the file? >> I can tell him what I call my machine ("leon"), and that the file is >> available, but >> that won't help without some kind of name lookup (which could be DNS). >> >> Or is there a way of phrasing a service discovery query "find me the >> file with zcip in the name"? > > it seems easier to make the service discovery query "find me the nearby > machine that asserts a name of leon". then if he gets multiple answers > back (some machine names are fairly common), he needs to disambiguate > that > somehow... > > the point is that you're as likely to need to do a query for some other > attribute as you are for a name. and even if you're looking for > something that matches a name, in an ad hoc network you're going to > need > to deal with the possibility of name conflicts that don't exist in DNS. I think two different problems are being confused here. Are you arguing about name-to-address translation or service discovery? These are two totally different things. Name-to-address resolution is pretty straightforward. Given a name, what's the address. The example earlier of gateway.linklocal. to some address is name-to-address resolution, not service discovery. Service discovery is much more involved. A common example of service discovery is locating all of the printers on the local link. Most service discovery protocols need two phases. The first phase is to discovery the actual services on the wire. The second phase is to resolve a service name in to the necessary information to make use of the service. Going back to the printer samples, we would want to get a list of all print services for the first phase. Once a print service has been picked, the print service would need to be resolved to the specific information required to actually print such as the ip address, port number, and perhaps print queue name. By separating the service name from the ip address/port number, you can cache service names and look them up just before communicating with a service, allowing the service to transparently change to a different host or use a different address. Part of every service discovery solution is the ability to detect other services with the same name when registering to avoid collisions. This is not an impossible problem to solve. >> >>>> What worries me is that we don't (AFAICT) have a standard set of >>>> attributes and naming conventions for services. For example, how do >>>> I find a colour printer without much work on my floor. What would >>>> that >>>> look like for SLP or DNS-SD or any other sevice discovery system? >>> >>> well we won't solve that problem for an unmanaged network until we >>> figure out a way for devices to discover their location without help >>> (not that hard by itself) relative to their physical surroundings >>> (much harder) so that the searcher can figure out the concept of >>> "on my floor" (presumably in the same building) by itself. >> I'm happy to configure the printers location when I put it down. But >> what do I configure it to so that (in a zeroconf network), I can get >> allow people to find it using a "standard" query? > > well, it sort of seems to me that if you configure the printer at all > then you're not talking "zeroconf" anymore - you're talking about > having to have an interface for that printer to allow it to be > configured > (impractical for many kinds of appliance) and if you "configure" that > printer when you "put it down" you can about as easily arrange for > DHCP to give it a stable IP address and a stable DNS name. Zero configuration doesn't mean zero options. Zero configuration means it can work out of the box without being configured. It makes sense to have a printer using zeroconf allow for someone to change settings such as the advertised printer name. zeroconf is especially important when you first get the printer out of the box and do not have any way to interact with it. With zeroconf, you could potentially hook up the ethernet jack, use service discovery to find the default name the printer has choosen, connect to it, and then set some options such as the name it will advertise print services under and perhaps an IP address if it would be useful for the printer to be globally accessible. > and it also seems to me that "zeroconf" networks are most likely to be > used in ad hoc situations - if the network is going to be up long > enough > for the names and locations of devices to be stable then (again) it's > worth > it to start managing that network to some degree. What do you mean by a zeroconf network? Devices supporting zeroconf can be plugged in to a network and interact with other devices supporting zeroconf without additional configuration. This doesn't mean that every device on the network is unconfigured. There is no reason a device without a globally accessible address should not be able to communicate with a device with a linklocal address if both devices are on the same local link. Devices that are not configured with a global address will be limited to communicating only with other devices on the local link. > though I'll accept that a network can be expected to have a mixture of > ad hoc and configured devices. the printer may be stationary while the > laptops move around, etc. so in some cases it might be reasonable to > configure a particular printer to know some of its attributes even if > you > can't expect to configure every device that might appear on the local > network(s) to which that printer is attached. that doesn't mean that > name lookup is a good solution in general to the problem of finding > services on a network. No argument here, name-to-address resolution is not service discovery. That is not to say that DNS formatted packets cannot be used for service discovery. > of course the ability to discover local resources by means other > than name lookups is useful for both zeroconf and managed networks, > and it would be nice if the same mechanism could work for both cases. Yes, and SLP so far has failed. Perhaps SLPv2 will have better success. I haven't read the draft so I'm not sure if the flaws have been addressed. I'll give it a read tonight. > but in the case of a network where everything is managed, things are > in stable locations, etc. name lookup is "good enough" for many > purposes - whereas in ad hoc networks where services and their > locations > are probably *not* stable then you need a more versatile service. No, name lookup is not good enough, anywhere. We need service discovery for managed and unmanaged networks alike. >> Or a simpler case (which doesn't require management) - I want >> to build a zeroconf printer that is a colour bubblejet that can do >> A5, A4 or A3, but not that dodgy American Letter format. What >> are the attributes that I should program into its SLP SA or >> DNS-SD reporting, or whatever? > > ask the IPP people - they've been thinking about this stuff for > awhile, though I don't think it's been heavily targeted at SLP. Find out what the customers you're targeting support. Is there support for using SLP to find printers built in to common operating systems out there? What about DNS-SD? Can you cover enough of your customers by implementing one or the other? If both will work, which one is simpler? Which one will give your customers a better user experience? -josh From owner-zeroconf@merit.edu Tue Jul 23 22:44: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 WAA12070 for ; Tue, 23 Jul 2002 22:44:03 -0400 (EDT) Received: by trapdoor.merit.edu (Postfix) id 98A4B9126D; Tue, 23 Jul 2002 22:44:52 -0400 (EDT) Delivered-To: zeroconf-outgoing@trapdoor.merit.edu Received: by trapdoor.merit.edu (Postfix, from userid 56) id 5E26A9126E; Tue, 23 Jul 2002 22:44: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 050279126D for ; Tue, 23 Jul 2002 22:44:50 -0400 (EDT) Received: by segue.merit.edu (Postfix) id D7A695DEEA; Tue, 23 Jul 2002 22:44:50 -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 5C7C65DDBE for