An additional (and separate) comment on the DNS discovery draft. Temporarily suspending my disbelief in the mechanism described in this document for purposes of discussion, there's a terminology problem: the draft talks about finding DNS resolvers, which is not really right and which some readers have told me they find confusing.
To be clear: this issue is not the fault of the document authors, the underlying DNS terminology is somewhat confusing and frequently misused. It turns out that there is no good short name for the entity that this mechanism is trying to locate, because the DNS terms "name server" and "resolver" really refer to protocol roles rather than to a particular kind of server. This draft is talking about finding an entity that implements both name server and resolver roles, with the name server role acting as a front end for the resolver role under the rules described in the protocol spec for queries with the "recursion desired" bit turned on. The usual way of referring to this kind of entity is as "a name server that offers recursive service", often abbreviated as "a recursive name server" or just "a recursive server". Some implementations have their own terminology for the various possible combinations of the name server and resolver roles, but the terms I'm using here are based on the protocol specification rather than any particular implementation. Thus assuming that the WG decides to go forward with this draft in spite of my objections, for clarity I would recommend that the draft be changed to use the above terminology (use the full phrase the in the introduction to define one of the abbreviated terms, then use the abbreviated term throughout the rest of the document). -------------------------------------------------------------------- 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] --------------------------------------------------------------------
