thanks for your timely review;
for point-for-point responses please see below.
I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
Please wait for direction from your document shepherd
or AD before posting a new version of the draft.
Reviewer: Vijay K. Gurbani
Review Date: Mar-07-2010
IESG Telechat date: Mar-11-2010
Summary: This draft is ready for publication as a Proposed Standard.
It has 0 major issues, 0 minor issues and 3 nits.
1/ S1.2 - What is meant by "non-DNS means"? Do you mean
accessing these databases using raw IP addresses? Please
add a sentence or two clarifying this.
The draft says in Section 1.2:
| In general terms, authoritative name servers for a given zone can use
| various means to achieve coherency of the zone contents they serve.
| For example, there are DNS implementations that assemble answers from
| data stored in relational databases (as opposed to master files),
| relying on the database's non-DNS means to synchronize the database
| instances. Some of these non-DNS solutions interoperate in some
| fashion. However, AXFR, IXFR, and NOTIFY are the only protocol-
| defined in-band mechanisms to provide coherence of a set of name
| servers, and they are the only mechanisms specified by the IETF.
A distributed database is a "distributed black box", from the PoV of
the IETF, and most likely even for the customers of such commercial
products. The instances of such databases might be replicated using
protocols standardized in the IETF, but that does not matter here.
We only note that in such cases the name servers do not "load" the zone
data from a "zone file" that needs to be replicated for each server.
The database system itself makes the data available to the name servers
at their respective sites, and it is responsible for keeping the
distributed copies of the database consistent by any means.
A solution of this kind for a large registry oriented domain (say a TLD)
might contain all the registration information needed to manage domain
name delegations through registrars (e.g. all you could get via whois
services, and more), beyond the specific data that will be distributed
(and thereby essentially published) by the DNS. In such cases, the
authoritiative zone data are a 'view' on a database that most likely
is being made available to the authoritative domain servers via some
proprietary API to access a co-located instance of the database.
Such API might co-operate with the database core over inter-process
communication (say shared memory mechanisms or AF_UNIX sockets), IP,
SNA, or whatever you can imagine -- these days it is quite likely
"something over IP", but almost certainly not using the DNS protocol.
Thus, "non-DNS means" is indeed meant literally, indicating something
unspecified and out of scope for DNSEXT.
2/ S1.4, last sentence of the section: suggest better to say,
"The goal of this document is to define AXFR as it is
understood by the DNS community to exist today."
Thanks, we'll adopt this phrase.
3/ S2, last sentence on page 7: "They ought not to interfere
with AXFR ..." Is the interpretation here that the syntax
and semantics of DNS messages should not interfere with
AXFR but the authors are not sure this is indeed the case?
In other words, why not write authoritatively: "The do not
interfere with AXFR ..." instead of hedging your bets and
saying "They ought not to ..."?
Indeed. The tone here was perhaps too cautious.
Will adopt this change too.
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
| TR-Sys Alfred Hoenes | Alfred Hoenes Dipl.-Math., Dipl.-Phys. |
| Gerlinger Strasse 12 | Phone: (+49)7156/9635-0, Fax: -18 |
| D-71254 Ditzingen | E-Mail: ah(_at_)TR-Sys(_dot_)de
Ietf mailing list