Subject: RE: draft-ietf-zeroconf-reqts-08.txt

From: Jim Busse <[email-masked]>
Date: Wed, 11 Jul 2001 10:20:13 -0700

Erik:

Wordsmithing:  Should the text read "Service discovery protocols MUST allow
users or software to discover instances"  ??

Jim Busse 

 -----Original Message-----
From: 	Erik Guttman [mailto:[email-masked]] 
Sent:	Wednesday, July 11, 2001 8:12 AM
To:	Thomas Narten
Cc:	Daniel Senie; [email-masked]
Subject:	Re: draft-ietf-zeroconf-reqts-08.txt 

> > > > 2.2.1  Web Browsing
> > > >    Requirement:
> > > >    - MUST translate a name to an IP address.
> > > >    - MUST translate an IP address to a name.
> > >
> > >This text curiously doesn't mention the DNS. But, for the web server,
> > >isn't the DNS reverse lookup specifically what is assumed/required?
> 
> > Web servers as such are not dependent on DNS in any form.
Implementations 
> > of web servers often have such dependencies, but reverse lookups are NOT

> > required for proper operation of web servers.
> 
> But the text in the document specifically says web servers do the reverse
> mapping, and that drives the requirement that a reverse mapping be
> doable. Existing web servers use the DNS for this. Are you saying that
> in a zeroconf environment, Web servers can and/or should use something
> other than DNS to do the reverse mapping?
> 
> The point I'm trying to amke is that it seems misleading at best to
> suggest that a generic address to name mapping is needed, if what is
> actually needed is one that applications can use just as they do today
> with DNS.

Yes.  What we want to say is that the upper layer support apps relying
on RFC 1123 DNS interfaces will continue to be supported.  We do not
have to, nor should we, say in the reqts doc how this support is achieved.

> > >Seems like the reqirement is much more specific than just "translate
> > >name to address" and vice versa, and involves integration with the
> > >DNS.
> 
> > Zeroconf is an environment without servers. How are you going to do a
DNS 
> > lookup without a server?
> 
> The web server example above says they will need to do the reverse
> mapping. 

The web server example is motivate and support the listed reqts
for forward and reverse lookup.  What we should really do, perhaps,
is require support for RFC 1123, section 6.1.

> > > > 2.4 Service Discovery Scenarios
> > > >
> > > >    Service discovery protocols allow users to select services and/or
> > > >    hosts by a name that is discovered dynamically, rather than
requiring
> > > >    that the user know the name in advance and type it in correctly.
> > >
> > >Can't an application find and select services without the user being
> > >queried? E.g., isn't DNS a service? Should the user choose the DNS
> > >server?
> 
> > If there's no server serving DNS, it'll be hard to use it.
> 
> Yes. The text suggests that service discovery requires user choose
> from a menu of choices. Is that also true of services like the DNS?
> Does the above exclude services that are generic and where it doesn't
> matter who offers it?

What we really want to say is that services can be discovered and selected, 
by users or by a computer program.  That way the location of the server
does not need to be known in advance for client-server software to function.

We will quickly get into a rathole about DNS here.  One can use mDNS to
resolve DNS names when there is no DNS server.  You can query DNS SRV RRs
to request service instances by type.  That type is a name.  So, the
essential thing is not that one doesn't know the name of the service in
advance, but rather, one doesn't know the particular server instance yet.
One uses a service discovery protocol to obtain these concrete service
locations.

In summary, I suggest that this text be changed to:

 2.4 Service Discovery Scenarios

    Service discovery protocols allow users or software to discover
instances
    and select among available services.  This removes the requirement that
    the user or client software know a server's location in advance and 
    in order for the client to communicate with the server.

Erik