Subject: [dnsop] draft-ietf-dnsop-serverid-05.txt review

From: Brett Carr <[email-masked]>
Date: Thu, 15 Dec 2005 23:49:20 +0100 (CET)

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