ietf
[Top] [All Lists]

Re: Last Call: draft-klensin-rfc2821bis

2008-03-29 02:31:06


--On Saturday, 29 March, 2008 09:33 +0200 Pekka Savola
<pekkas(_at_)netcore(_dot_)fi> wrote:

...
It seems there are two ways of looking at this:

(1) AAAA records in the IPv6 world should do exactly same
things as A records in the IPv4 world, so SMTP should look
for an AAAA record in the absence of an MX record, just as A
records are used in the absence of MX records.

(2) Although some SMTP servers will continue to be found
through A records for legacy reasons, there is no longer a
good reason for any new server not to have a published MX
record.  SMTP clients (senders) will, of course, need to
continue to look up A records, but since there is currently
no significant use of AAAA records for email routing, we
should not perpetuate this legacy in IPv6 as it is in IPv4.
...

I agree with Jim's characterization and IMHO both positions
are  reasonable.

I also prefer (2) because I don't think the original "A
fallback" was  meant to stay there very long and we just never
got around to  deprecating that feature.  If you ask a random
sampling of postmasters  and DNS domain owners, I doubt many
would even remember right off the  bat that such a fallback
exists.

Based on some small experience with email deployment and
operations, I believe that you are wrong.  Indeed, if you asked
a random sampling of those groups --remembering that there are a
huge number of SMTP servers in the world, only a tiny fraction
of which are professional operations and with an even smaller
fraction being large-scale, carefully-managed production ones,
you might discover that many of them had forgotten that there
was such a thing as an MX record and how to set it up.

...
Additionally I believe this is not an issue we as the IETF
should get  stuck at for a longer period.  Reaching closure,
whichever decision it  is, in the timescale of a couple of
months, is IMHO better than a very  strong consensus on the
approach.

Months?  To paraphrase something Ned said much more elegantly, I
think you severely underestimate the degree to which people are
fed up with this revision of this document and the processes
that drag it out.  This issue was raised after the second Last
Call closed.  It is important enough that it was worth some
additional time to be sure that the broader community had
considered the issue.  That has clearly occurred.  While I think
there is fairly clear consensus that the issue needs to be
resolved and documented clearly (although there are dissenters
even from that), I don't believe that I seen any evidence of
anyone who had a strong position changing his or her mind since
the discussion started, nor have I seen a new argument presented
after the first few days.

Certainly, one could go around this loop for months, with people
repeating themselves in ever-louder ways, but do you really
think that would move us forward or result in a better or
clearer consensus?

IMO, it is time to decide and move on.   Like several others, I
think it is more important to decide than what the decision is.
Days would be good.  Maybe a week or so is tolerable.  But
certainly not months.

    john  (Speaking as a frustrated editor who 
           volunteered for a quick project well over a
           year ago)

_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf