ietf-smtp
[Top] [All Lists]

Re: Has the IETF dropped the ball?

2005-03-08 20:01:15

At 04:34 PM 3/8/2005 -0500, Bruce Lilly wrote:

On Tue March 8 2005 11:51, David MacQuigg wrote:

> The public is getting mad as hell about spam.  There *will* be a solution
> to this problem.  If the IETF doesn't provide it

Spam is a social problem. The IETF is an Engineering group. Engineers
don't solve social problems (as engineers).

The most rewarding efforts in my career have been when I can solve a problem that has social benefit. That is what has me intrigued by this spam problem. I thought of a solution two years ago ( very much like SPF ), but not knowing anything about TCP/IP, I allowed myself to be talked out of it by the experts.

> some politicians or
> bureaucrats will.

Unlikely. They seem to create more problems, such as the aptly
named CAN-SPAM legislation, which confirms that spammers indeed
can spam.

I didn't say the solution would work. :>)

> I may not understand all that is going on in the IETF,
> but it sure looks like they dropped the ball.

Let's try to objectively and calmly consider which ball you
claim has been dropped.

> They have allowed the
> standards effort

Which standards effort? IETF standardizes many things. Are
you complaining about IP? TCP? HTTP? SIP? ACAP? DHCP? What,
precisely?

Email authentication.

> to disintegrate into a bunch of programmers squabbling
> over details that are not needed in a universal standard.

"Universal standard" for what?

A standard allowing MTAs using different authentication methods to communicate with each other and with the other components in an email system. For example, how should a spam filter read the headers and determine the domain to be rated when a forwarder is involved in the transfer?

> If we continue
> the present path, it may be years before there is a clear "victory" in the
> battle between competing and incompatible standards.

It is unclear precisely which standards you are categorizing as
"competing and incompatible".  IETF standards become standards
through one of two processes, as detailed in RFC 2026.  Either
there is some procedure that is not suitable for phased review
and has no interoperability considerations, in which case it is
subject to scrutiny and possibly approved as BCP, which goes
into immediate effect with full force of a standard.  The other
process is the "Standards Track", which begins with a Proposed
Standard, which is itself subject to review (in Internet-Draft
form), is supposed to contain no known technical omissions, to
have resolved design choices, and to be well-understood.  If
there is "a bunch of programmers squabbling over details", that
is a good indication that design choices have not been resolved,
and/or that there is something which is not well-understood,
and/or there are some technical omissions. After remaining at
Proposed Standard for at least 6 months, and after there are at
least two independent and interoperable implementations, a
specification can progress to Draft Standard (after formulated
as a new Internet-Draft and subjected to the review process).
After at least another 4 months and when there is demonstrable
wide support, the specification may finally become a Standard.
Proposed Standards and Draft Standards are not Standards.
Sometimes there are competing design choices, and no clear way
to make an objective decision that would be required to enter
the Standards Track at Proposed Standard.  In such cases, the
competing design specifications might be published as Experimental
RFCs so that a rational choice can be made based on implementation
experience.  Experimental RFCs are not standards, and cannot
become standards except by one of the processes mentioned above
(involving a new Internet-Draft and the review process).
Experimental specifications might well be "competing and
incompatible"; their publication (but let's be clear; they are
in no way standards) provides an opportunity to evaluate the merits
and shortcomings of those specifications in order to gain
understanding, resolve design choices, and ensure that there are
no technical omissions.

What I would most like to see here is a standard so simple and non-controversial that it need not get all the way to final status before people start following it. Putting it on the standards track could do this.

-- Dave

*************************************************************     *
* David MacQuigg, PhD              * email:  dmq'at'gci-net.com   *  *
* IC Design Engineer               * phone:  USA 520-721-4583  *  *  *
* Analog Design Methodologies                                  *  *  *
*                                  * 9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.             * Tucson, Arizona 85710        *
*************************************************************     *