Operational Considerations and Issues with IPv6 DNS
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: Internet Architecture Board <firstname.lastname@example.org>, RFC Editor <email@example.com>, dnsop mailing list <firstname.lastname@example.org>, dnsop chair <email@example.com> Subject: Document Action: 'Operational Considerations and Issues with IPv6 DNS' to Informational RFC The IESG has approved the following document: - 'Operational Considerations and Issues with IPv6 DNS ' <draft-ietf-dnsop-ipv6-dns-issues-13.txt> as an Informational RFC This document is the product of the Domain Name System Operations Working Group. The IESG contact persons are David Kessens and Dan Romascanu. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsop-ipv6-dns-issues-13.txt
Technical Summary This memo presents operational considerations and issues with IPv6 Domain Name System (DNS). Working Group Summary This document is a product of the dnsop working group. Protocol Quality David Kessens reviewed this document for the IESG. Note to the RFC Editor: In section B.2, please add a new first paragraph: ADD: NOTE: omitting some critical additional data instead of setting the TC bit violates a 'should' in Section 9 of RFC2181. However, as many implementations still do that [TC-TEST], operators need to understand its implications and we describe that behaviour as well. In section B.2, in 2nd paragraph: REPLACE: Therefore, at least in many scenarios, it would be very useful if the information returned would be consistent and complete -- or if that is not feasible, return no misleading information but rather leave it to the client to query again. WITH: Therefore, at least in many scenarios, it would be very useful if the information returned would be consistent and complete -- or if that is not feasible, leave it to the client to query again. In section B.3: DELETE paragraph: Additionally, to avoid the case where an application would not get an address at all due to some of courtesy additional data being omitted, the resolvers should be able to query the specific records of the desired protocol, not just rely on getting all the required RRsets in the additional section.