Subject: RE: [dhcwg] Review of Service-Discovery-Type options in DHCP

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 17 Jul 2002 06:46:36 -0500

For service/server discovery via DNS, might not the DNS search
list make more sense? In the simplest case, Domain Name = DNS
Search List, but in more complex networks that is not the case.

Domain name might be division.company.com wereas search list
might be division.company.com and company.com. In this case,
you'd locate the service whether it was at the division level
or corporate level. A mail server might be at the division level.
An NTP server might be at the corporate level.

This point seems to have little to do directly with DHCP?

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, July 17, 2002 1:41 AM
To: Ralph Droms
Cc: Stuart Cheshire; DHCP discussion list
Subject: Re: [dhcwg] Review of Service-Discovery-Type options in DHCP

> I have always thought of the "Domain Name" option as specifying the domain 
> name that the client should attach to its hostname to form its FQDN.  
> Stuart suggests a somewhat different definition - the "Domain Name" option 
> simply identifies the domain name for the network to which the client is 
> attached.  The client can then use that information in any way it wants: 
> to form an FQDN if it needs one, to form service names.
>

I think Stuart's definition is more generally correct.   The only time when 
the domain name option specifies the client's domain name is when the 
client doesn't have a domain name that it cares to assert.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Jul 2002 10:21:48 +0900

If you use the domain name search list as a resource discovery search list 
as well, then this constrains your use of the domain name search list in a 
way that makes me uncomfortable.   Likewise with the domain name.   If a 
mechanism like this is the right way to go (and I don't agree that it is), 
then it would have to be another search list - it should not be overloaded.

TBF, I would rather use SLP than either DHCP or DNS, if it worked.   My 
interest in promoting the use of DHCP options for this is not that I think 
it's the right solution in the end, but that I think it's useful now.   It 
also provides a useful upgrade path for non-SLP-compliant devices - you 
have the DHCP server do the SLP request on behalf of the client.   This 
allows SLP and non-SLP clients to coexist in a way that is not obnoxious 
for the network administrator.  Non-SLP clients might get different results,
  because of the weaknesses of DHCP as a service location protocol, but they 
will get results.

I see a lot of pushback on using DHCP for service location, and I wonder if 
some of this is motivated by a wish to eliminate competition for SLP, so 
that SLP has a chance to get deployed.   If so, perhaps I've described a 
way that everybody can win.   It's definitely not my intention to prevent 
deployment of SLP to benefit DHCP.   I just want something that works, and 
I think that having two solutions that solve the problem in different ways 
is likely to produce the right results.