I agree with Alain that we need more input/discussion about using well
known addresses for discovery of some services. I think that that will
impact most of our networks' architectures.

I know that a lot of ideas have been already described in former DNS
Discovery Design Team(s).

It seems that we do not all agree on the level of importance of the
services to discover (DNS, NTP, Printers discovery...). I have the
feeling that following that level, each of us assumes that the automatic
discovery solution is allowed to constraint the network in different way
(do we need a third party discovery server ? can we allocate a
pre-defined address? ...). Each time, one can also argue that DHCP or
SLP - protocols already with an RFC status - can achieve those
functions. IMHO it is not clear how to progress. DHCP and SLP might be
enough.

I would be grateful if someone could help me to understand pros and cons
of those solutions (DHCP, SLP) vs pre-defined adresses.

my 0,02%
Luc

> De : Alain Durand [mailto:[EMAIL PROTECTED]
> Envoye : mercredi 5 mars 2003 19:30
> 
> On Wednesday, March 5, 2003, at 10:17  AM, Bill Manning wrote:
> 
> >
> > As a co-author of a couple of previous DNS discovery IDs, I would
> > have to agree that as postulated, the current DNS discovery work
> > has pretty much been OBE. (overtaken by events)
> > There have been two distinct BOFs on this idea in the last 
> five years
> > so I don't think another BOF will be very productive.
> 
> Bill,
> 
> Note that I'm not suggesting a bof on DNS discovery mechanism per se,
> but a bof on generic service discovery using well known, voluntarily 
> ambiguous
> addresses.
> 
>       - Alain.
> 

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------

Reply via email to