Subject: DEPLOY: Rejection of Sender ID does not result in standardization of SPF Classic

From: Rand Wacker <[email-masked]>
Date: Fri, 3 Sep 2004 12:55:06 -0700 (PDT)

Over the past two weeks I've seen two kinds of posts to this mailing list:

1) "Here are some technical/legal issues I have with the last call specs,
can we ammend the spec or come up with a well-known workaround?"

2) "I refuse to accept Sender ID for reason X, I vote we dump it and
standardize SPF."

If people saying the latter would state their reason and then be done I
wouldn't be getting so frustrated, but the "standardize SPF" comments are
what really make this process difficult.  There is no either-or in this
discussion.

As the chairs have indicated, we are to be discussing Sender ID on its
technical/legal/real-world merits.  If the group decides to /not/ move
forward and submit the Sender ID drafts to the IESG for whatever reason,
fine, that's the choice of the group.  No-one here should be under the
impression that scuttling Sender ID at this time will give SPF Classic any
fast track through the standards process.  Sender ID and SPF are not
equivalent standards and can not be considered as alternatives to each
other.

I look forward to debating SPF Classic, CSV, MPR, BATV, etc etc etc AT
WHATEVER POINT THE CHAIRS DEEM APPROPRIATE, but this is not that time.
Saying that you want to scuttle Sender ID simply because you prefer SPF is
non-constructive to this group.  In fact, the longer these debates get
drawn out the longer we are prevented from constructively discussing
other approaches which you may prefer!

-Rand

---

From: Daniel Quinlan <[email-masked]>
Date: 03 Sep 2004 13:41:44 -0700

> Over the past two weeks I've seen two kinds of posts to this mailing list:

This message is itself out of order.  It's neither an indication that
you will or will not implement Sender-ID (and I believe Sendmail has
already made their position clear).

I see nothing procedurally wrong or confusing about someone saying "I
cannot implement Sender-ID" and including an aside that someone could
implement SPF as it was last proposed.  You are right that the aside has
no bearing on whether or not the chairs believe there is consensus, only
the statements about Sender-ID.

-- 
Daniel Quinlan
http://www.pathname.com/~quinlan/

---

From: Sam Varshavchik <[email-masked]>
Date: Fri, 03 Sep 2004 19:12:30 -0400

Rand Wacker writes:

> fast track through the standards process.

That's fine.  You might want to study the evolution of NNTP.  There, lack of 
the official IETF stamp of approval did not inhibit NNTP from evolving.  If 
you try to implement NNTP based only on IETF's standards-track 
documentation, you won't get very far.

This may have changed recently, but this has been the case for a long time.