Operational Considerations and Issues with IPv6 DNS
RFC 4472

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: Internet Architecture Board <iab@iab.org>,
    RFC Editor <rfc-editor@rfc-editor.org>, 
    dnsop mailing list <dnsop@ietf.org>, 
    dnsop chair <dnsop-chairs@tools.ietf.org>
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.