IETF Logo Mail Archive

Re: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

wayne <wayne@schlitt.net> Fri, 09 December 2005 14:14 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ekj1G-0007oT-OC; Fri, 09 Dec 2005 09:14:42 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkiVP-0007uC-95 for ietf@megatron.ietf.org; Fri, 09 Dec 2005 08:41:49 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04639 for <ietf@ietf.org>; Fri, 9 Dec 2005 08:40:42 -0500 (EST)
Received: from schlitt.net ([67.52.51.34] helo=backbone.schlitt.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkiVN-0003nG-98 for ietf@ietf.org; Fri, 09 Dec 2005 08:41:47 -0500
Received: from wayne by backbone.schlitt.net with local (Exim 4.52) id 1EkiUu-0002dX-5q; Fri, 09 Dec 2005 07:41:26 -0600
From: wayne <wayne@schlitt.net>
To: spf-discuss@v2.listbox.com, ietf@ietf.org
References: <200512081104.09113.julian@mehnle.net> <4398AE3D.512D@xyzzy.claranet.de> <Pine.LNX.4.64.0512090838400.13902@netcore.fi> <200512091303.37502.julian@mehnle.net>
Mail-Copies-To: nobody
Content-Type: text/plain; charset="US-ASCII"
Date: Fri, 09 Dec 2005 07:41:12 -0600
In-Reply-To: <200512091303.37502.julian@mehnle.net> (Julian Mehnle's message of "Fri, 9 Dec 2005 13:03:36 +0000")
Message-ID: <x43bl2pevb.fsf@footbone.schlitt.net>
User-Agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.17 (linux)
MIME-Version: 1.0
X-SA-Exim-Connect-IP: <locally generated>
X-SA-Exim-Rcpt-To: spf-discuss@v2.listbox.com, ietf@ietf.org
X-SA-Exim-Mail-From: wayne@schlitt.net
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on backbone.schlitt.net
X-Spam-Status: No, score=-7.0 required=4.0 tests=ALL_TRUSTED,AWL,BAYES_00, GREYLIST_ISWHITE autolearn=ham version=3.0.4
X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100)
X-SA-Exim-Scanned: Yes (on backbone.schlitt.net)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
X-Mailman-Approved-At: Fri, 09 Dec 2005 09:14:40 -0500
Cc:
Subject: Re: [spf-discuss] Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

In <200512091303.37502.julian@mehnle.net> Julian Mehnle <julian@mehnle.net> writes:

> Pekka Savola wrote:
>>
>> Basically the IESG decided that accurate documentation of the running
>> code is more important than documenting something that does not exist,
>> and maybe never will exist.
>
> As my appeal[1] pointed out, at the time draft-lyon-senderid-core-00 was 
> submitted for experimental status, there was no "running code" that 
> actually interpreted "v=spf1" as "spf2.0/mfrom,pra".  So what running code 
> was being documented when draft-lyon-senderid-core-00 was submitted?

Actually, I think the SenderID implementation from sendmail was
interpreting "v=spf1" records using the PRA, but Julian's point is
largely true: the vast majority of implementations that are abusing
SPF version 1 records were released *SINCE* the first objections to
the senderid drafts were raised.  The number of SenderID
implementations is still small.  While I doubt that all
implementations will be fixed, I think the IETF blessing the conflict
will cause the number of implemenations to grow, rather than shrink.

The IESG's first reaction to learning of the conflict between the use
of SPF version 1 records by SenderID was to direct the RFC editor to
remove the warning placed in the SPF I-D.  The IESG did this *without*
informing either of the draft authors about this technical change.  It
took a fair amount of discussion with the IESG to even allow this
problem to be acknowledged.


Now, obviously the IESG feels that they can freely make technical
changes to drafts without the approval of draft authors.  They also
acknowledge that the abuse of SPF version 1 records by the SenderID
spec causes problems.

So, the question is:  why didn't the IESG just change the SenderID
drafts to something that doesn't conflict?


-wayne

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

v2.23.0 | Report a Bug | By Email