IETF Logo Mail Archive

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

wayne <wayne@schlitt.net> 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 1E9i0q-00018G-4l; Mon, 29 Aug 2005 07:41:16 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E8ekZ-0007fN-SV; Fri, 26 Aug 2005 10:00:10 -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 KAA20930; Fri, 26 Aug 2005 10:00:05 -0400 (EDT)
Received: from schlitt.net ([67.52.51.34] helo=backbone.schlitt.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E8elH-0007Zh-VU; Fri, 26 Aug 2005 10:00:53 -0400
Received: from wayne by backbone.schlitt.net with local (Exim 4.52) id 1E8ejy-0004PM-Lb; Fri, 26 Aug 2005 08:59:36 -0500
From: wayne <wayne@schlitt.net>
To: IETF MARID WG <ietf-mxcomp@imc.org>
References: <B5BB79FFA1CF09E73E64D992@B50854F0A9192E8EC6CDA126> <1124993318.13993.123.camel@thunk> <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us>
Mail-Copies-To: nobody
Content-Type: text/plain; charset="US-ASCII"
Date: Fri, 26 Aug 2005 08:59:29 -0500
In-Reply-To: <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> (Andrew Newton's message of "Fri, 26 Aug 2005 08:47:17 -0400")
Message-ID: <x43bowpzni.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: ietf-mxcomp@imc.org, brc@zurich.ibm.com, hardie@qualcomm.com, iesg@ietf.org, ietf-mxcomp@imc.org, 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: 69a74e02bbee44ab4f8eafdbcedd94a1
X-Mailman-Approved-At: Mon, 29 Aug 2005 07:41:11 -0400
Cc: Ted Hardie <hardie@qualcomm.com>, ietf@ietf.org, MARID <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

In <09E57A88-3A53-4A78-99D9-67E95B93E9C5@hxr.us> Andrew Newton <andy@hxr.us> writes:

> On Aug 25, 2005, at 2:08 PM, Bill Sommerfeld 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?

Yes, the IETF, via that MARID WG, tried to create a new protocol
called SenderID that was based on both SPF and CallerID.  I can see
that newly created protocol being called an experiement, but I don't
see why the IETF should go out of its way to bless a new protocol that
is incompatible with an existing one.

Is this the normal process of the IETF to create conflicting
standards, just because one standard was developed outside the IETF?


-wayne

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

v2.23.0 | Report a Bug | By Email