I've been thinking about the DNS discovery, as well as the larger "service discovery with no 3rd party dependencies" issue, for a while.
Just like Steve Deering and many others I'd like the IETF to explore the larger issue, since I'm very much interested in making the future Internet more robust than what we have today. But this effort needs to be done carefully to make sure that we are solving a well-defined and well-constrained problem. Thus I think it would make sense to hold a BoF on this topic (perhaps in Yokohama if there are folks willing to work on putting such a BoF together in the very short time that remains). Level 1 of the current DNS discovery draft is likely to set a precedent that well-known unicast addresses will be allocated for services. The IETF has never done that before - we've only allocated well-known *multicast* addresses for services. Going down the path of allocating well-known unicast addresses, even if they are site-local addresses, is something I would be very uncomfortable doing, especially if it is done as a "quick fix" for a short-term DNS discovery solution without knowing what a potential future "service discovery with no 3rd party dependencies" scheme might look like. This concern appears to be shared by some other IESG members based on some discussions last week. These concerns would probably be less strong if the fixed unicast address was one part of a larger architecture, in which the reservation of fixed address was limited and necessary as part of an overall solution. Instead, it appears that this particular choice is being driven by a particular short-term problem with no apparent relationship to future and more general work. So if I was an implementor that wanted a DNS discovery solution as soon as possible, I'd just go with DHCPv6 information-request for now, while participating in the larger, and necessarily longer term, discussions about "service discovery with no 3rd party dependencies". Comments? Erik -------------------------------------------------------------------- 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] --------------------------------------------------------------------
