Skip to main content

SMTP Operational Experience in Mixed IPv4/v6 Environments
draft-motonori-dualstack-smtp-requirement-01

Revision differences

Document history

Date Rev. By Action
2012-08-22
01 (System) post-migration administrative database adjustment to the No Objection position for Margaret Wasserman
2012-08-22
01 (System) post-migration administrative database adjustment to the No Objection position for Ted Hardie
2004-08-25
01 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2004-08-25
01 Amy Vezza IESG state changed to Approved-announcement sent
2004-08-25
01 Amy Vezza IESG has approved the document
2004-08-25
01 Amy Vezza Closed "Approve" ballot
2004-08-25
01 Bert Wijnen Informaed iesg secretray that announcemetn can be sent with
a set of RFC-Editor notes.
2004-08-25
01 Bert Wijnen Status date has been changed to 2004-08-25 from 2004-08-21
2004-08-25
01 Bert Wijnen State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Bert Wijnen
2004-08-23
01 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2004-08-21
01 Bert Wijnen Checking with IESG members if SET of RFC-Ed notes are OK, and
if so, if AD can clear his DISCUSS.
2004-08-21
01 Bert Wijnen Status date has been changed to 2004-08-21 from 2004-05-08
2004-08-20
01 (System) Removed from agenda for telechat - 2004-08-19
2004-08-19
01 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2004-08-19
01 Margaret Cullen [Ballot Position Update] Position for Margaret Wasserman has been changed to No Objection from Discuss by Margaret Wasserman
2004-08-19
01 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2004-08-19
01 Harald Alvestrand [Ballot comment]
Reviewed by Mark Allman, Gen-ART

Note: Agree with Ted that the quality of the prose is not terribly good.
2004-08-19
01 Harald Alvestrand [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand
2004-08-19
01 Allison Mankin [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Undefined by Allison Mankin
2004-08-19
01 Allison Mankin
[Ballot comment]
Process nit:  RFC 3178 is an Info, needs to move to the Informatives...  (I think there is a split set of
references already, …
[Ballot comment]
Process nit:  RFC 3178 is an Info, needs to move to the Informatives...  (I think there is a split set of
references already, but the Normatives are not called that).  Also Mokapetris -> Mockapetris

I'm glad of Ted's review.  I could imagine that this document, which folks in Japan felt was very
much needed, and I agree is on an important topic, was just not progressing due to IETF WG
charter-related problems?
2004-08-19
01 Allison Mankin
[Ballot comment]
Process nit:  RFC 3178 is an Info, needs to move to the Informatives...  (I think there is a split set of
references already, …
[Ballot comment]
Process nit:  RFC 3178 is an Info, needs to move to the Informatives...  (I think there is a split set of
references already, but the Normatives are not called that).  Also Mokapetris -> Mockapetris

I'm glad of Ted's review.  I could imagine that this document, which folks in Japan felt was very
much needed, was just not progressing due to charter problems?
2004-08-19
01 Allison Mankin [Ballot Position Update] New position, Undefined, has been recorded for Allison Mankin by Allison Mankin
2004-08-19
01 Margaret Cullen
[Ballot discuss]
I don't understand the course that this work is taking.

This used to be a work item of the v6ops WG.  I presented …
[Ballot discuss]
I don't understand the course that this work is taking.

This used to be a work item of the v6ops WG.  I presented this item (along with several others) in an apps area meeting in Vienna in 2003, and there were several technical issues raised with this work.  I don't remember all of the details, and they aren't captured in the apps area minutes, but there is a note:

"- chris newman: to review MX issues and 821 issues"

However , I don't see any indication in the draft that it was reviewed by Chris or modified based on his review.

Did the v6ops WG and the apps area both give up on the idea that we could offer advice on dual-stack operation of SMTP that is technically accurate and has the consensus of the IETF?  If neither of those groups feels that this document is ready for publication, why publish it as an individual submission?
2004-08-19
01 Margaret Cullen [Ballot Position Update] New position, Discuss, has been recorded for Margaret Wasserman by Margaret Wasserman
2004-08-18
01 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2004-08-17
01 Ted Hardie
[Ballot discuss]
This is right on the edge for me.  Reading through the algorithm in section 3 of this
draft, I believe there are cases …
[Ballot discuss]
This is right on the edge for me.  Reading through the algorithm in section 3 of this
draft, I believe there are cases where it is a redefinition of the algorithm in Section 5
of RFC 2821.  In most cases, it is just a restatement of the algorithm with the address
family question brought to the fore, but there are cases where the language doesn't match.
Take this text from the draft:

    Compare each host name in MX records with the names of sending
    host.  If there is any match, drop MX records which have equal to
    or larger than the value of the lowest-preference matching MX
    record (including itself).  If multiple MX records remain, sort the
    MX records in ascending order based on their preference values.
    Loop over steps (3) to (9) on each host name in MX records in a
    sequence.  If no MX records remain, the sending host must be the
    primary MX host.  Other routing rule should be applied.  Finish.

compare it to this text from 2821:

  The relay host MUST
  then inspect the list for any of the names or addresses by which it
  might be known in mail transactions.  If a matching record is found,
  all records at that preference level and higher-numbered ones MUST be
  discarded from consideration.  If there are no records left at that
  point, it is an error condition, and the message MUST be returned as
  undeliverable.  If records do remain, they SHOULD be tried, best
  preference first, as described above.

is "relay host" in 2, the same as "sending host" in 1?

This draft clearly goes beyond requirements, and I think it is clear in its
call for an update of 2821 to handle this.  That this isn't that update
makes the inclusion of this algorithm problematic.

One way to solve this would be to make the IESG note say something like:

"This draft 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."
2004-08-17
01 Ted Hardie [Ballot Position Update] New position, Discuss, has been recorded for Ted Hardie by Ted Hardie
2004-08-10
01 Scott Hollenbeck [Ballot Position Update] Position for Scott Hollenbeck has been changed to No Objection from Undefined by Scott Hollenbeck
2004-08-10
01 Scott Hollenbeck [Ballot comment]
References need to be split normative/informative.
2004-08-10
01 Scott Hollenbeck [Ballot Position Update] New position, Undefined, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2004-08-10
01 Bert Wijnen State Changes to IESG Evaluation from AD Evaluation by Bert Wijnen
2004-08-10
01 Bert Wijnen State Changes to AD Evaluation from Publication Requested by Bert Wijnen
2004-08-10
01 Bert Wijnen Placed on agenda for telechat - 2004-08-19 by Bert Wijnen
2004-08-10
01 Bert Wijnen [Ballot Position Update] New position, Yes, has been recorded for Bert Wijnen
2004-08-10
01 Bert Wijnen Ballot has been issued by Bert Wijnen
2004-08-10
01 Bert Wijnen Created "Approve" ballot
2004-08-10
01 (System) Ballot writeup text was added
2004-08-10
01 (System) Last call text was added
2004-08-10
01 (System) Ballot approval text was added
2004-07-28
01 Dinara Suleymanova State Changes to Publication Requested from AD is watching by Dinara Suleymanova
2004-05-11
01 (System) New version available: draft-motonori-dualstack-smtp-requirement-01.txt
2004-05-08
01 Bert Wijnen State Changes to AD is watching from AD Evaluation::Revised ID Needed by Bert Wijnen
2004-05-08
01 Bert Wijnen Doc goes back to AD is watching because authors will now submit it top RFC-Editor as an individual submission.
2004-05-08
01 Bert Wijnen Status date has been changed to 2004-05-08 from 2004-03-25
2004-05-08
01 Bert Wijnen
When RFC-Editor gets this, we may want to remind them that:

> they still need serious help from a technical proofreader (but, as
> usual, …
When RFC-Editor gets this, we may want to remind them that:

> they still need serious help from a technical proofreader (but, as
> usual, i have to credit them for being much more fluent in english
> than i am in their language, so while the doc needs much work on this
> point i appreciate the effort that they have made in writing it).  one
> hopes that the rfc editor can work with them on this.
>
2004-03-25
01 Bert Wijnen State Changes to AD Evaluation::Revised ID Needed from AD Evaluation::External Party by Bert Wijnen
2004-03-25
01 Bert Wijnen [Note]: 'Checking with v6Ops WG and with APPS Area ADs.' has been cleared by Bert Wijnen
2004-03-25
01 Bert Wijnen
There were some comments from v6Ops folk (Dean and Pekka).

APPS ADs are basically OK with this doc.

I am basically OK with this doc. …
There were some comments from v6Ops folk (Dean and Pekka).

APPS ADs are basically OK with this doc.

I am basically OK with this doc. May need to add new
IPR statement and such as per RFCs3667/8/9.

I am doing a last check with a DNS expert.

Since it is an individual submission, I have recommended to do one more rev and then ask RFC-Editor for publication as Informational RFC.
2004-03-25
01 Bert Wijnen State Change Notice email list have been change to , , from ,
2004-03-25
01 Bert Wijnen Status date has been changed to 2004-03-25 from 2004-02-11
2004-02-11
01 Bert Wijnen State Changes to AD Evaluation::External Party from Publication Requested by Bert Wijnen
2004-02-11
01 Bert Wijnen
I have asked Ted Hardie and/or Ned Freed to take
a look from an SMTP perspective.
I have also asked v6Ops chairs to check if …
I have asked Ted Hardie and/or Ned Freed to take
a look from an SMTP perspective.
I have also asked v6Ops chairs to check if their
comments have been addressed appropriately.
2004-02-11
01 Bert Wijnen [Note]: 'Checking with v6Ops WG and with APPS Area ADs.' added by Bert Wijnen
2004-02-11
01 Bert Wijnen State Change Notice email list have been change to , from
2004-02-11
01 Bert Wijnen
This document is an individual submission.
Initially it was a ngtrans document named
  draft-ietf-ngtrans-ipv6-smtp-requirement-08.txt,
which has been reviewed in v6Ops WG and then …
This document is an individual submission.
Initially it was a ngtrans document named
  draft-ietf-ngtrans-ipv6-smtp-requirement-08.txt,
which has been reviewed in v6Ops WG and then
resulted in the renamed individual document.
2004-02-11
01 Bert Wijnen Draft Added by Bert Wijnen
2004-02-09
00 (System) New version available: draft-motonori-dualstack-smtp-requirement-00.txt