Keith - I think we might actually be more in agreement than disagreement. You have pointed out several places where I wasn't clear; let me see if I can clarify...
One global clarification - I used the term "requirements" in the sense I often see the term (mis)used. What I've written is more a "wish list", and I have every expectation that some of the requirements can't be met and other requirements are mutually exclusive. The list should be used a yardstick for measuring proposed solutions. 1. I agree - the DNS configuration discussion should be qualified by a global "if the host wants to find out about local DNS services". Suggestions about how to word that qualification will be gratefully accepted. I did try to be clear that "addresses for DNS servers" is a separate problem from "domain and domain search list"... 2. My wording for requirement 12 was unclear. What I meant was "if the host requests information about DNS servers, the list of servers can be customized for that host". I don't intend that a network admin can force a host to use a specific set of DNS servers; rather, different hosts can get configured with different lists of DNS servers 3. If interpreted as absolute, binary requirements, 7 and 8 are quite likely fantasies. I intend 7 and 8 to be goals that proposed solutions can be measured against. 4. In requirement 6, I was trying to express the requirement that the host can trust the servers it learns about through DNS configuration. If that wording is clearer, I'll use it in the requirements list. 5. In the note about requirement 7, I guess simply "defined in an Internet Draft" might be sufficient. I was hoping to be able to restrict consideration to protocols that are already under development and have achieved some level of maturity. 6. The note about requirement 11 was intended as a definition for a phrase in requirement 11; it should read: "A host and a server are in the same site if they can exchange datagrams using site-local addresses." At 09:23 AM 4/23/2002 -0400, Keith Moore wrote: >I strongly disagree with a number of the 'requirements' you've proposed. > >1. it is not possible in general for a host to determine it's proper >DNS configuration from information provided by the network, because >the DNS search path that the host wants to use may not be the one >that the local network specifies. even trusting the local network's >DNS servers to serve as the interface to other DNS zones is a stretch. >it's fine if hosts want to do this, not fine to insist that they do this. > >hosts MUST therefore be able to specify their own DNS configuration which >overrides that specified by the local network environment, and this >seems to contradict your 'requirements' #10 and #12. > >2. re 'requirement' #12: it's absolutely unacceptable for IETF to dictate >that a network administrator can 'control' what DNS servers a host can >use - this is fundamentally a host issue and not a network issue; >it's outside of the scope of what a network should be able to dictate >to a host. again, the fact that a host is currently connected to a >certain location in the network should not be taken as evidence that the >context in which that host operates (dns servers, search path, default >domain) should have anything to do with that network location. > >3. 'requirements' #7,8 are premature at best and probably a fantasy. >it's highly unlikely that DNS discovery can be implemented without some >new protocol definition and implementation, even if you use similar >packet formats and port # to those that exist now you are certainly >going to need to change client and server code - and that is a protocol >change. so I think at the very least these are poorly worded. > >more importantly, this decision is best made after alternatives >have been considered - not as an a priori 'requirement' that >presumes the solution. > >4. I'm not at all sure what it means to 'authenticate the reliability' >of a server, so I think this needs to be reworded. > >5. note #7: there's no such thing as a 'standards-track Internet Draft' > >6. requirement #11 and your note about #11 seem to be mutually >exclusive - you can't use site-local addresses when the host >and server are at different sites. of course, it's fine to use >site-local addresses between hosts and servers at the same site. > > > > IPv6 DNS Configuration Requirements > > ------------------------------------ > > > > 1. Host receives IPv6 address(es) of DNS server(s) available to the > > host for DNS resolution > > 1.a. The list of servers includes only currently available > > servers > > 1.b. The host can obtain the addresses of new servers as needed > > 2. Hosts obtain DNS configuration with no manual configuration > > 3. The addresses of a particular server are provided to hosts with no > > manual configuration of that server > > 4. Hosts obtain DNS configuration using only those resources required > > for DNS resolution > > 5. Hosts obtain DNS configuration without the manual configuration of > > any external service > > 6. Hosts can (if desired) authenticate the reliability of servers > > 7. Definition of DNS configuration requires no additional > > protocol definition > > 8. Implementation of DNS configuration requires no additional protocol > > implementation > > 9. Time to initial deployment is minimal > > 10. Hosts have one way to perform DNS configuration > > 11. DNS configuration operates when host and DNS servers are in same > > site or in different sites > > 12. A network administrator can control what servers a host uses > > 13. Host is configured with domain and domain search list > > > > Notes: > > ------ > > 2. (and 3.) Hosts and DNS servers operate as "plug-and-play" or > > "zeroconf" > > 7. "additional protocol definition" means protocols not currently a > > standard or defined in a standards-track Internet Draft > > 8. "no additional protocol implementation" means hosts and servers > > are not required to include code for protocols that they wouldn't > > otherwise implement > > 10. Hosts shouldn't need to try several different DNS Configuration > > protocols to find which one is available on a link > > 11. Hosts and DNS servers can exchange datagrams using site-local > > addresses > > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
