Re: RFC 3929 on Alternative Decision Making Processes for Consens us-Blocked Decisions in the IETF (fwd)

On Thu, 2004-10-28 at 16:41 -0500, wayne wrote:

> > I disagree. SenderID/SPF is currently in deployment and is working just 
> > fine in production. Maturity was not the problem. 

SenderID != SPF.  Please don't associate the two.  This entire merging
of technologies was such a horribly stupid idea.  Can someone remind me
why we took a perfectly progressive, active and supported technology
that was OPEN and FREE and decided to take it out back and beat the
living tar out of it?  Oh thats right "we" didn't make that decision.
Funny how that works.

> SPF-classic is currently widely deployed.  SenderID, and the new
> SPF-classic, however, are not deployed.  What little information about
> the performance of SenderID indicates that it is probably not as
> reliable as old SPF-classic.
> 
> Maturity certainly was a problem.  

I would consider DK before SenderID, its most certainly more mature and
it also hasn't spent the last ~6 months beating around the proverbial
bush debating stupid software patents.

Cheers,

James

James Couzens,
Programmer
                        ^                            ( ( (      
      ((__))         __\|/__        __|+|__        '. ___ .'    
       (00)           (o o)          (0~0)        '  (> <) '    
---nn-(o__o)-nn---ooO--(_)--Ooo--ooO--(_)--Ooo---ooO--(_)--Ooo---
http://libspf.org -- ANSI C Sender Policy Framework library
http://libsrs.org -- ANSI C Sender Rewriting Scheme library
-----------------------------------------------------------------
PGP: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x7A7C7DCF

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBBgnNZMagRinp8fc8RAuVWAKDiRkhb1+2ZRZlxUgjfHVps3WOfeQCg5DqE
xe6kjOYvPF33dRQOuWsaKjU=
=cPei
-----END PGP SIGNATURE-----