Hello, please find below notes from my review of draft-ietf-dnsop-serverid-05.txt
First of all let me say that I think this is a very informative and well put together document. I have only 3 comments, 2 for additional information to be added and 1 for grammar. > 2. Existing Conventions > Recent versions of the commonly deployed Berkeley Internet Name > Domain implementation of the DNS protocol suite from the Internet > Systems Consortium [BIND] support a way of identifying a particular > server via the use of a standards-compliant, if somewhat unusual, DNS > query. Specifically, a query to a late model BIND server for a TXT Maybe it is worth adding in here what version of bind this support started in rather than just mentioning 'late model BIND' server. Might be useful for people reading the document and running BIND to instantly know whether there server supports this functionality. >2.2. Disadvantages > At the same time, there are some serious drawbacks to the CHAOS/TXT > query mechanism that argue against standardizing it as it currently > operates. > 1. It requires an additional query to correlate between the answer > to a DNS query under normal conditions and the supposed identity > of the server receiving the query. There are a number of > situations in which this simply isn't reliable. I think that a slight expansion on 'a number of situations' here might be useful, either some general expansion on what is meant or a couple of examples. and lastly >1. Introduction and Rationale > Identifying which name server is responding to queries is often > useful, particularly in attempting to diagnose name server > difficulties. This is most obviously useful for authoritative > nameservers in the attempt to diagnose the source or prevalence of > inaccurate data, but can also conceivably be useful for caching > resolvers. However, relying on the IP address of the name server has > become more problematic due the deployment of various load balancing > solutions, including the use of shared unicast addresses as > documented in [RFC3258]. due the deployment of various load balancing should read: due to the deployment of various load balancing My apologies if that is too picky, never having done an IETF review before I'm not sure where to draw the line :) With these additions I would definitley regard this document as very useful and would support it moving forwards. Brett... -- Brett Carr Ripe Network Coordination Centre System Engineer -- Operations Group Singel 258 Amsterdam NL http://www.ripe.net GPG Key fingerprint = F20D B2A7 C91D E370 44CF F244 B6A1 EF48 E743 F7D8 . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
