(i tried to send this out before, but it didn't come through the dnsop mailman for some reason. just as well, since much more editing was needed.)
replies to two folks here who graciously reviewed the respsize i-d. i've just sent the revised respsize-04 to internet-drafts@, and it's a doozy. i strongly recommend that it be re-read from scratch since it has been very nearly re-written from scratch. (yo, johani! you were right all along!) -------- > From: [EMAIL PROTECTED] (Suresh Krishnaswamy) > Date: Tue, 4 Jul 2006 12:16:35 -0400 > > I've reviewed draft-ietf-dnsop-respsize-03 and I found it to be a > useful document. I support it moving forward in its current form > although clarifications on a couple of points would be helpful. see below. > i) There is still a slight disconnect between the text in 2.2/2.3 and > RFC2181 (referenced in the document) with respect to the re-querying > behavior of "possibly damaged" data. If respsize-03 actually indicates > true behavior, a note to this effect would help. i've just reread [respsize-03 2.2, 2.3] and [rfc2181 9] and i do not see any disconnect. both imply that if TC is set, the final rrset present in the message might be incomplete. (rfc2181 is less direct in its implication but the implication is still quite clear.) both of these documents are descriptions of the same "true behaviour" as far as i can tell. i will split [respsize-03 2.3] into two paragraphs, though, since it presently addresses two topics and it's possible to mis-read it as addressing one. > ii) Section 2.6 says "Some queries to non-existing names can be > large, however, this is not a problem because the responses include a > SOA record in the authority section". It would be useful to explain > why the "possibly damaged" condition is not a problem here. i will split that paragraph into two and expand the second one. > iii) Is there anything to say about AAAA records in section 2.8? (I > felt there should be, since there didn't seem to be anything > currently in this draft that ties up with the conclusion in 4.3). we deliberately said "address records" in 2.8 to include both A and AAAA. i'll see what i can do in section 4 to better justify 4.3. > iv) In section 4.1 is there anything we lose by having all our name > servers reside under the same parent as opposed to having some of > them within a different zone? i've added a new paragraph after 4.1 to explain this issue. > v) Section 4.3: Why "two to five IPv6 nameserver address records" and > not "up to five" (or even "up to seven")? Relates to comment iii) above "up to five" is better. -------- > From: [EMAIL PROTECTED] (Mohsen Souissi) > Date: Wed, 5 Jul 2006 11:50:49 +0200 > > ==> I have read this version as I did for the previous ones. I keep > supporting this draft and I believe we should make it move forward. > > This draft may be very useful for DNS operators managing zones with a > relatively large number of NS's and supporting IPv6 transport, such as > TLD operators. > > Apart from sections numbering which is missing after section 5 ... i've restored these. often i decide not to number the mandatory sections. > ... I have one comment and one question (inline) on section 2.8: > > > 2.8. The minimum useful number of address records is two, since giving > > only one address undermines the redundancy requirement. Implicit > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > ==> When IPv6 transport is supported (presence of AAAA RRs), the > redundancy requirement is not necessarily fulfilled with 2 IP > addresses in the additional section. If both IP addresses are > associated with the same NS (for example one in v4 and the other in > v6) then there is a high probability that both of the become > unreachable if the NS encounters trouble (electricity outage, hardware > crash, DNS server stopped, ...). But in the same time, I presume that > the probability of getting in the additional section 2 IP addresses > associated with the same NS is quite low (assuming of course that the > total NS number is relatively large). So should we keep considering > that the "redundancy requirement" is fulfilled when/if the additional > section contains at least 2 IP addresses? upon re-reading [RFC1034 4.1], i see that the redundancy requirement is for two servers, not two address records. i will institute that change now. -------- . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
