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

Douglas Otis <dotis@mail-abuse.org> Mon, 29 August 2005 11:41 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9i0y-0001B9-Us; Mon, 29 Aug 2005 07:41:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8hZk-00020g-0I; Fri, 26 Aug 2005 13:01:08 -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 NAA01769; Fri, 26 Aug 2005 13:01:04 -0400 (EDT)
Received: from a.mail.sonic.net ([64.142.16.245]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8haT-0005J7-3P; Fri, 26 Aug 2005 13:01:55 -0400
Received: from [168.61.10.151] (SJC-Office-DHCP-151.Mail-Abuse.ORG [168.61.10.151]) (authenticated bits=0) by a.mail.sonic.net (8.13.3/8.13.3) with ESMTP id j7QH0rwg032417 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Fri, 26 Aug 2005 10:00:53 -0700
In-Reply-To: <x4pss0oili.fsf@footbone.schlitt.net>
References: <B5BB79FFA1CF09E73E64D992@B50854F0A9192E8EC6CDA126> <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> <x43bowpzni.fsf@footbone.schlitt.net> <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> <x4pss0oili.fsf@footbone.schlitt.net>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <6503D26C-DB8E-404D-8D8F-5087F64A9119@mail-abuse.org>
Content-Transfer-Encoding: 7bit
From: Douglas Otis <dotis@mail-abuse.org>
Date: Fri, 26 Aug 2005 10:00:52 -0700
To: wayne <wayne@schlitt.net>
X-Mailer: Apple Mail (2.734)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Mon, 29 Aug 2005 07:41:11 -0400
Cc: ietf@ietf.org, IETF MARID WG <ietf-mxcomp@imc.org>, iesg@ietf.org
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

On Aug 26, 2005, at 7:53 AM, wayne wrote:

>
> In <7E876E12-3D43-4BFB-8F5B-76C3E985A610@hxr.us> Andrew Newton  
> <andy@hxr.us> writes:
>
>
>> 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.
>>
>
> I asked for the IESG to not consider the SPF I-D to be experiemental.
> It was turned down.  According to Ted, *none* of the IESG members
> expressed interest in changing the status from Experiemental.
>
> So far, no one has appealed that decision, and there are only a few
> days left to do so.  Like the appeal on the re-use of SPFv1 records, I
> don't think it would be a productive use of my time to write an appeal
> on the experimental status, and thus I won't do it.


If the goal of the SPF Classic draft was intended to capture a point  
in time pre-dating semantic extensions related to RFC-2822 defined  
content, then perhaps the draft should be on an historic track.  ; )

SPF Classic has not achieved the goal of capturing a pristine version  
of pre-MARID semantics.  With some semantic changes introduced by the  
SPF Classic draft itself, these potential semantic conflicts, as well  
as those introduced by Sender-ID, have not been addressed.  Prudent  
accommodations were made within the Sender-ID draft however.  The SPF  
Classic draft has not found higher ground in this regard.  Expecting  
any standards group to retroactively arbitrate semantics restrictions  
for a previously enigmatic DNS record would be disruptive.   An  
unfrozen SPF Classic draft adding provisions for a scoped version of  
the DNS record would allow some percentage of publishers the means to  
indicate their intended semantics when so needed.  The conflict issue  
being described seems specifically based upon a design flaw within  
SPF Classic.

-Doug



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

v2.23.0 | Report a Bug | By Email