Constantine A. Murenin
2006-03-04 22:18:48 UTC
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: <***@imc.org>
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 ***@imc.org)
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 <***@gmail.com>; Sat, 4 Mar 2006 14:53:48 -0700 (MST)
(envelope-from ***@imc.org)
Mime-Version: 1.0
Message-Id: <p06230901c02fbcdaa944@[10.20.30.249]>
In-Reply-To: <***@balder-227.proper.com>
References: <***@balder-227.proper.com>
Date: Sat, 4 Mar 2006 13:53:41 -0800
To: ***@gmail.com
From: Paul Hoffman / IMC <***@imc.org>
Subject: Re: [spf-discuss] IAB Response to the Appeal from Julian Mehnle :
ietf-mxcomp
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k22Cix0Z090243
Received: by zproxy.gmail.com with SMTP id n29so414566nzf
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)
Date: Thu, 2 Mar 2006 12:44:59 +0000
Subject: Re: [spf-discuss] IAB Response to the Appeal from Julian
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by
balder-227.proper.com id k22Cj00Z090245
different approaches as they were considered (and _documented_) in the
MARID working group. This IESG statement clearly violates the reality,
<<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 ----------
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: <***@imc.org>
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 ***@imc.org)
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 <***@gmail.com>; Sat, 4 Mar 2006 14:53:48 -0700 (MST)
(envelope-from ***@imc.org)
Mime-Version: 1.0
Message-Id: <p06230901c02fbcdaa944@[10.20.30.249]>
In-Reply-To: <***@balder-227.proper.com>
References: <***@balder-227.proper.com>
Date: Sat, 4 Mar 2006 13:53:41 -0800
To: ***@gmail.com
From: Paul Hoffman / IMC <***@imc.org>
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
Received: by zproxy.gmail.com with SMTP id n29so414566nzf
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)
Date: Thu, 2 Mar 2006 12:44:59 +0000
Subject: Re: [spf-discuss] IAB Response to the Appeal from Julian
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by
balder-227.proper.com id k22Cj00Z090245
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
"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 theappealing 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
"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.
different approaches as they were considered (and _documented_) in the
MARID working group. This IESG statement clearly violates the reality,
<<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.
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 ----------