What I find interesting is the trade-off of: The gain in packet compression by using similar names plus the operational advantage of streamlining the names vs The gain by spreading name server names under other TLDs plus the logging convenience of only needing one PTR record per address 1) Compression to insert more name servers or more glue records into a response is an advantage that I think is becoming outdated. With anycast, there is no longer a need to have a name per name server. (Still, a target of about a half-dozen names in the NS set is better than less.) Also, with fewer names listed, there are fewer names to resolve just to get the name server set. (Not all implementations will resolve all the names, but large-market-share ones do.) 2) Operational gains of having similar names is a good thing, but at what cost and for what gain. It would be good to be able to quickly ping all the names with a simple shell script from the top of your head. But what if you misread a problem report and debug e.ext.nic.tld instead of e.int.nic.tld or e.nic.tld.? 3) I would think that having servers listed under other TLDs (as we are looking at a ccTLD here) would be a good thing. Just for the fact that we are spreading the servers about (in DNS, not just topology). In addition, these servers don't count against the glue space hit in the response. 4) Multiple name per address is one of those topics that gets bashed back and forth. At times we find it distasteful to have multiple PTR records in a set, for instance, this makes traceroutes and logs list potentially "wrong" names. Other times we are reminded that it is perfectly natural to allow more than one PTR record in a set. Maybe this is a "it's good for servers but not good for routers" situation. The part of the trade-off I haven't addressed is: The gain by using unique name server names for each delegation vs The need for extra IP addresses in light of a one name per address policy I think we want to allow there to be unique names for name servers so that changes to one delegation do not impact another. I think it is also good not to waste addresses, using them as needed only, which is also possible if the policy of one name-one address is dropped. (I think it is, I'm just supporting a reason to do so.) Nevertheless, what I've debated above doesn't seem to be the point of the document. It seems the document is presenting discomfort with the response. Here I merely tried to detail the technical points, and not get into the response. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar If you knew what I was thinking, you'd understand what I was saying.