[EMAIL PROTECTED] (Pekka Savola) writes: > As a generic observation: the document seems to include some of much the > same material as draft-ietf-dnsop-ipv6-issues-11.txt (specifically, its > appendix B). > > If folks think it would be a good idea, some or most of the > stuff in that draft's appendix could be moved here -- as it has a lot of > already IESG-reviewed material on additional section processing. > > Notes below show some issues which also came up (in one form or another) > during dnsop-ipv6-issues. This leads me to think the text needs significant > edits and/or merging/copying form dnsop-ipv6-issues appendix B.
the draft name is draft-ietf-dnsop-ipv6-dns-issues-11.txt for those who, like me, try to use google to find its text. i don't nec'ily consider the iesg an expert on this, so their approval may or may not matter much. the current -respsize- draft describes what a large part of the installed base of dns query initiators actually does. the best thing would be to shorten -respsize- by removing anything it does not absolutely HAVE to say. > 2.2. If the total response size would exceed 512 octets, and if the data > that would not fit belonged in the question, answer, or authority > section, then the TC bit will be set (indicating truncation) which may > cause the requestor to retry using TCP, depending on what information > was desired and what information was omitted. If a retry using TCP is > needed, the total cost of the transaction is much higher. (See [RFC1123 > 6.1.3.2] for details on the protocol requirement that UDP be attempted > before falling back to TCP.) > > ==> "which _may_ cause the requestor..." is incompliant with RFC2181, which > requires that if TC is set, the whole response must be discarded, and then > you retry with TCP. (Whether or not that's efficient or robust is a > different argument, I guess, but that's what the specs mandate.) forgive my ignorance. i was describing behaviour i'm aware of. if rfc2181 says that, it's boneheaded, but we should follow it here (or at least remove any text in -respsize- that conflicts with it) rather than argue about it. > 2.3. RRsets are never sent partially unless truncation occurs, in which > case the final apparent RRset in the final nonempty section must be > considered "possibly damaged". [...] > > ==> this may require a bit of rewording, as above, as the spec says to > discard the response if TC was set no matter what. > > 2.6. Average and maximum question section sizes can be predicted by the > zone owner, since they will know what names actually exist, and can > measure which ones are queried for most often. For cost and performance > reasons, the majority of requests should be satisfied without truncation > or TCP retry. > > ==> as above, "truncation or TCP retry" should maybe be "truncation and > TCP retry" > > 2.9. The best case is no truncation. This is because many requestors > will retry using TCP by reflex, or will automatically re-query for > RRsets that are "possibly truncated", without considering whether the > omitted data was actually necessary. > > ==> as above, not having such "reflexes" would be against RFC2181 and yet, since the installed base actually works the way this -respsize- draft describes, the issues that will affect choices of NS RRsets are exactly as written, and rfc2181 is possibly-irrelevant. perhaps adding a small editorial indicating this schism is the best fix overall? -- Paul Vixie . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
