Fwd: [spf-discuss] IAB Response to the Appeal from Julian Mehnle : ietf-mxcomp

I was just made aware that the 2-day old message I sent didn't get to
the mailing list, and I am now asked to (manually) resent it.

I hereby resent the request that I have received, which includes the
copy of my original message, and the explanation of why it was delayed
for as long as 2 days and 9 hours.

Thanks,
Constantine.

---------- Forwarded message ----------
Return-Path: <[email protected]>
Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227])
        by mx.gmail.com with ESMTP id 15si2744981nzn.2006.03.04.13.53.49;
        Sat, 04 Mar 2006 13:53:50 -0800 (PST)
Received-SPF: neutral (gmail.com: 192.245.12.227 is neither permitted
nor denied by best guess record for domain of [email protected])
Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169])
	(authenticated bits=0)
	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k24LrlKD010248
	for <[email protected]>; Sat, 4 Mar 2006 14:53:48 -0700 (MST)
	(envelope-from [email protected])
Mime-Version: 1.0
Message-Id: <p06230901c02fbcdaa944@[10.20.30.249]>
In-Reply-To: <[email protected]>
References: <[email protected]>
Date: Sat, 4 Mar 2006 13:53:41 -0800
To: [email protected]
From: Paul Hoffman / IMC <[email protected]>
Subject: Re: [spf-discuss] IAB Response to the Appeal from Julian Mehnle :
 ietf-mxcomp
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

>  >From owner-ietf-mxcomp Thu Mar  2 05:45:00 2006
>Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.207])
>	by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22Cix0Z090243
>	for <[email protected]>; Thu, 2 Mar 2006 05:45:00 -0700 (MST)
>	(envelope-from [email protected])
>Received: by zproxy.gmail.com with SMTP id n29so414566nzf
>         for <[email protected]>; Thu, 02 Mar 2006 04:44:59 -0800 (PST)
>DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
>         s=beta; d=gmail.com;
>
>h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
>
>b=sLgMY8rRp/pv+GqWilXAdGWnJe7KnH9ZGZuOLCkSRk5T10exf3p96djYO5gIDXygoXVCiiR2yI6zY460DCCnDvM8zQQ8tYNnsMMt85Jl1sUI92LA7ZJ0bZFrk5oLfpVs834/4SRqvxHOQPjNnFGau/MNA5z64rsT0kchy83XH2Y=
>Received: by 10.64.179.7 with SMTP id b7mr631040qbf;
>         Thu, 02 Mar 2006 04:44:59 -0800 (PST)
>Received: by 10.65.73.3 with HTTP; Thu, 2 Mar 2006 04:44:59 -0800 (PST)
>Message-ID: <[email protected]>
>Date: Thu, 2 Mar 2006 12:44:59 +0000
>From: "Constantine A. Murenin" <[email protected]>
>To: [email protected]
>Subject: Re: [spf-discuss] IAB Response to the Appeal from Julian
>MehnleCc: "Julian Mehnle" <[email protected]>,
>         "Internet Architecture Board" <[email protected]>,
>         MARID <[email protected]>,
>         "SPF Council" <[email protected]>,
>         "Internet Engineering Task Force" <[email protected]>,
>         "Iesg (E-mail)" <[email protected]>
>In-Reply-To: <[email protected]>
>MIME-Version: 1.0
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Disposition: inline
>References: <[email protected]>
>	 <[email protected]>
>Content-Transfer-Encoding: 8bit
>X-MIME-Autoconverted: from quoted-printable to 8bit by
>balder-227.proper.com id k22Cj00Z090245
>
>On 02/03/06, Leslie Daigle <[email protected]> wrote:
>>  On February 8, 2006, The IAB received an appeal from Julian Mehnle
>>  appealing the IESG decision to publish draft-lyon-senderid-core as an
>>  Experimental RFC. According to the procedures in Section 6.5.2 of RFC
>>  2026, the IAB has reviewed the situation and issues the following
>>  response.
>>
>>  1. Summary of IAB Response
>>
>>  The appeal is denied and the IESG's decision is upheld.
>>
>>
>>  2. Background
>>
>>  After the termination of the MARID WG, the IESG approved both
>>  draft-schlitt-spf-classic-02 and draft-lyon-senderid-core as
>>  Experimental RFCs. Both RFCs were to bear the following note:
>>
>>        "The following documents (draft-schlitt-spf-classic,
>>        draft-katz-submitter, draft-lyon-senderid-core,
>>        draft-lyon-senderid-pra) are published simultaneously as
>>        Experimental RFCs, although there is no general technical consensus
>>        and efforts to reconcile the two approaches have failed.  As such
>>        these documents have not received full IETF review and are
>>        published "AS-IS" to document the different approaches as they were
>>        considered in the MARID working group.
>
>The problem is that they ARE NOT published AS-IS to document the
>different approaches as they were considered (and _documented_) in the
>MARID working group. This IESG statement clearly violates the reality,
>just look at what was presented in the appeal:
>
><<The conflict arose only after the IESG asked for individual draft
>submissions from the SPF and Sender ID authors and
>draft-lyon-senderid-core-00 was submitted (which for the first time
>included the re-interpretation of "v=spf1" records for the PRA
>identity). Accepting such a submission despite the prior consensus of
>the MARID WG[5] (which was closed afterwards) that "v=spf1" should not
>be used for checking of PRA clearly violates the ultimate goal of
>producing reliable standards.>>
>
><<It is also worth noting that at the time the MARID WG was closed,
>the then-current Sender ID specification
>draft-ietf-marid-protocol-03[18] did not include the re-use of
>"v=spf1" records for PRA checking. This was only introduced in the
>individual submission draft-lyon-senderid-core-00 [19] in October
>2004. Also did Microsoft's record generation wizards generate only
>"v=spf2.0/pra" records until the end of October[20,21], when they
>began generating only "v=spf1" records.>>
>
>I have not heard anyone question this issue with Sender ID that was
>once again raised in the IAB appeal. Do you thus find it ethical and
>professional to publish these RFCs with the note that does not reflect
>the documented reality of the MARID WG?
>
>If any note is to be included in the RFCs, it should be the one from
>the appeal.
>
>Cheers,
>Constantine.

The message above was not sent to the mailing list because, as an anti-spam
measure, the list software prevents people whose exact address is not on any
mailing list we run from posting to lists. I have now permanently added the
above address to the "OK to post" list. Please send your message to the list
again.
---------- End of forwarded message ----------