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

Andrew Newton <andy@hxr.us> Fri, 26 August 2005 14:45 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fSO-0002zk-Dm; Fri, 26 Aug 2005 10:45:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8fSL-0002wS-Ed; Fri, 26 Aug 2005 10:45:22 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24356; Fri, 26 Aug 2005 10:45:19 -0400 (EDT)
Received: from zak.ecotroph.net ([216.93.167.200]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8fT5-0000cU-Pq; Fri, 26 Aug 2005 10:46:08 -0400
Received: from [10.0.1.4] ([::ffff:64.83.8.178]) (AUTH: PLAIN anewton, SSL: TLSv1/SSLv3,128bits,RC4-SHA) by zak.ecotroph.net with esmtp; Fri, 26 Aug 2005 10:45:19 -0400 id 000B3A78.430F2AFF.00007847
In-Reply-To: <x43bowpzni.fsf@footbone.schlitt.net>
References: <B5BB79FFA1CF09E73E64D992@B50854F0A9192E8EC6CDA126> <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> <x43bowpzni.fsf@footbone.schlitt.net>
Mime-Version: 1.0 (Apple Message framework v733)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us>
Content-Transfer-Encoding: 7bit
From: Andrew Newton <andy@hxr.us>
Date: Fri, 26 Aug 2005 10:45:17 -0400
To: wayne <wayne@schlitt.net>
X-Mailer: Apple Mail (2.733)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Content-Transfer-Encoding: 7bit
Cc: Ted Hardie <hardie@qualcomm.com>, ietf@ietf.org, IETF MARID WG <ietf-mxcomp@imc.org>, SPF Discussion <spf-discuss@v2.listbox.com>, iesg@ietf.org
Subject: 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

On Aug 26, 2005, at 9:59 AM, wayne wrote:
>>> In this case, the two experiments interpret the same codepoints  
>>> in the
>>> DNS in subtly different ways.
>>>
>>> A mail-sending domain indicates that it is participating by  
>>> publishing
>>> certain DNS RR's.
>>> Crucially, a mail-sending domain cannot opt in to the SPF experiment
>>> without also opting in to the senderid experiment.  This renders any
>>> claimed results of either experiment suspect.
>>>
>>
>> If this is the source of the conflict, then BOTH experiments should
>> not use the v=spf1 records.
>>
>> -andy
>>
>
> The stated goal of draft-schlitt-spf-classic is to document SPF,
> basically as it was before the IETF got involved.  Yes, the IETF is
> calling it an experiment, which I don't agree with.  It is documenting
> an existing, well established, protocol.
>
>
> Are you saying that the IETF shouldn't publish an RFC that documents
> SPF?

I stated that the SPF and Sender ID experiments should not use the  
v=spf1 records to avoid conflict.  I did not state that the IETF  
should not publish an Experimental RFC about SPF.

But since you brought this up: if you (the author of the document) do  
not consider this to be an experiment, then perhaps the IETF should  
not publish SPF as an Experimental RFC.

-andy

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