SMTP Operational Experience in Mixed IPv4/v6 Environments
RFC 3974

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: RFC Editor <rfc-editor@rfc-editor.org>
Cc: The IESG <iesg@ietf.org>, <iana@iana.org>, ietf-announce@ietf.org
Subject: Re: Informational RFC to be: 
         draft-motonori-dualstack-smtp-requirement-02.txt 

The IESG has no problem with the publication of 'SMTP Operational 
Experience in Mixed IPv4/v6 Environments' 
<draft-motonori-dualstack-smtp-requirement-02.txt> as an Informational 
RFC. 

The IESG would also like the IRSG or RFC-Editor to review the comments in 
the datatracker 
(https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=11415&rfc_flag=0) 
related to this document and determine whether or not they merit 
incorporation into the document. Comments may exist in both the ballot 
and the comment log. 

The IESG contact person is Bert Wijnen.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-motonori-dualstack-smtp-requirement-02.txt


The process for such documents is described at http://www.rfc-editor.org/indsubs.html.

Thank you,

The IESG Secretary

Ballot Text

Technical Summary
 
 This document talks about SMTP operational experiences in IPv4/v6 dual
 stack environments.  As IPv6-capable SMTP servers are deployed, it has
 become apparent that certain configurations of MX records are necessary
 for stable dual-stack (IPv4 and IPv6) SMTP operation.  This document
 clarifies the problems that exist in the transition period between IPv4
 SMTP and IPv6 SMTP.  It also defines operational requirements for stable
 IPv4/v6 SMTP operation.

 This document does not define any new protocol. 

Working Group Summary
 
 This is not a WG document. However it was reviewed by a DNS expert and 
 also by a few participants from the v6Ops WG. APPS ADs have also
 checked this document.
 
Protocol Quality
 
 Bert wijnen has checked this document for conflicts with IETF work.

RFC-Editor Notes:

- Pls add standard IESG note on front page as per 
  draft-iesg-rfced-documents-03.txt, sect 4, bullet 1.

   The content of this RFC was at one time considered by the IETF,
   and therefore it may resemble a current IETF work in progress or
   a published IETF work. This RFC is not a candidate for any level
   of Internet Standard. The IETF disclaims any knowledge of the
   fitness of this RFC for any purpose, and in particular notes that
   the decision to publish is not based on IETF review for such
   things as security, congestion control or inappropriate
   interaction with deployed protocols.  The RFC Editor has chosen
   to publish this document at its discretion. Readers of this RFC
   should exercise caution in evaluating its value for
   implementation and deployment.

- Pls add additional IESG note on front page as follows:

   This document contains a specific interpretation of the applicability
   of the MX processing algorithm in RFC 2821, Section 5, to dual-stack 
   environments.  Implementors are cautioned that they must reference
   RFC 2821 for the full algorithm; this document is not to be considered
   a full restatement of RFC 2821, and, in case of ambiguity, RFC 2821 is
   authoritative.

- pls fix name of author, sect 2, first para (page 2) 
  OLD:
    Name System [Mokapetris, 1987] .  MX RRs are looked up in DNS to
  NEW:
    Name System [Mockapetris, 1987] .  MX RRs are looked up in DNS to
- pls fix name of author, refrences section, page 7
  OLD:
    Mokapetris, 1987.
    P.V. Mokapetris, "Domain names - implementation and specification" in
    RFC1035 (November 1987). ftp://ftp.isi.edu/in-notes/rfc1035.txt.
  NEW:
    Mockapetris, 1987.
    P.V. Mockapetris, "Domain names - implementation and specification" in
    RFC1035 (November 1987). ftp://ftp.isi.edu/in-notes/rfc1035.txt.

- You may want to make sure that you get references properly split into
  Normative and Informative.

RFC Editor Note