SMTP Operational Experience in Mixed IPv4/v6 Environments
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: RFC Editor <email@example.com> Cc: The IESG <firstname.lastname@example.org>, <email@example.com>, firstname.lastname@example.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
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.