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. 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.) 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 -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
