Re: [spfbis] 4408bis update

Scott Kitterman <spf2@kitterman.com> Thu, 16 August 2012 22:02 UTC

Return-Path: <spf2@kitterman.com>
X-Original-To: spfbis@ietfa.amsl.com
Delivered-To: spfbis@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A20CB11E809B for <spfbis@ietfa.amsl.com>; Thu, 16 Aug 2012 15:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zGPiek0M+CJd for <spfbis@ietfa.amsl.com>; Thu, 16 Aug 2012 15:02:21 -0700 (PDT)
Received: from mailout02.controlledmail.com (mailout02.controlledmail.com [72.81.252.18]) by ietfa.amsl.com (Postfix) with ESMTP id ACAFA11E808A for <spfbis@ietf.org>; Thu, 16 Aug 2012 15:02:21 -0700 (PDT)
Received: from mailout02.controlledmail.com (localhost [127.0.0.1]) by mailout02.controlledmail.com (Postfix) with ESMTP id DBCC920E4081; Thu, 16 Aug 2012 18:02:20 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=kitterman.com; s=2007-00; t=1345154540; bh=nLPX2+BVqHudIb+lzPU8qPePTPT+1w67Tv6aK60diy8=; h=From:To:Subject:Date:In-Reply-To:References:From; b=hM6aWZu/RDaaYv3LQpt4sCCUD62Cv70NPgOx4uguD0H70moG/Yd59T8+aWn2fxB+q 4tWRk0oeDj+MWKCMvn8zwbs9tj/tNTuV4eLsEPLHqWMByhlv11FLK7rGsuFvu8ZhU3 SGg2R7WraKiUKoD5UTp0pxMNr5xmSJ0dgGYTzjwQ=
Received: from scott-latitude-e6320.localnet (static-72-81-252-21.bltmmd.fios.verizon.net [72.81.252.21]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailout02.controlledmail.com (Postfix) with ESMTPSA id B2EA520E4077; Thu, 16 Aug 2012 18:02:20 -0400 (EDT)
From: Scott Kitterman <spf2@kitterman.com>
To: spfbis@ietf.org
Date: Thu, 16 Aug 2012 18:02:19 -0400
Message-ID: <1367995.li6hrOxpKc@scott-latitude-e6320>
User-Agent: KMail/4.8.4 (Linux/3.2.0-29-generic-pae; KDE/4.8.4; i686; ; )
In-Reply-To: <502D6A6B.1080804@isdg.net>
References: <1908971.Uo0Ahn547K@scott-latitude-e6320> <20120816202808.GA24136@mx1.yitter.info> <502D6A6B.1080804@isdg.net>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
X-AV-Checked: ClamAV using ClamSMTP
Subject: Re: [spfbis] 4408bis update
X-BeenThere: spfbis@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SPFbis discussion list <spfbis.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/spfbis>, <mailto:spfbis-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/spfbis>
List-Post: <mailto:spfbis@ietf.org>
List-Help: <mailto:spfbis-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/spfbis>, <mailto:spfbis-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Aug 2012 22:02:22 -0000

On Thursday, August 16, 2012 05:47:23 PM Hector Santos wrote:
> Andrew Sullivan wrote:
> > On Thu, Aug 16, 2012 at 04:02:47PM -0400, Hector Santos wrote:
> >> It would of been nice if the editor would of posted for the WG list
> >> to first review the substantial changes he intended to make or add
> > 
> > Why?  This is an Internet Draft.  This is the format we have for
> > reviewing and commenting.  Sending it to the list in advance is not
> > something we want to encourage.
> 
> Because of past experience, and I stress only an isolated experience,
> not my general experience.  From quick reading so far, section 9.0 was
> written without any consensus and now it (and changes) will be much
> harder to overcome, especially if it originates from me,
> unfortunately. Look, too more unprofessional ignorance is going on and
> if thats ok by the group, so be it.  But this is not a HOBBY for me.
> The output of this group directly impacts in my product and how my
> customers will use SPF and I will have my input or the new document
> will not get adopted by me, which means changes not implemented,
> largely ignored. Status quo, picking and choosing what goods vs bad
> and quite frankly, I am tired of this trend for the RFC documents.  I
> had to bring up a more general issue, but its part of what you see
> here.  Sorry.
> 
> Section 9.0 is linked to other existing sections which required a much
> wider engineering review than what was done and I strongly feel there
> is actual empirical information that is not reflected. No problem if
> it wasn't so subjective, was more generic protocol material and more
> reflective of actual practice out there. i.e. some of the stuff we
> should of extracted during the experiment report, unfortunately, we
> focused on other things.  The issues were/are already on the table
> (documented) and I don't think they are un-addressable.

Section 9 is not new.  It's in RFC 4408 and every draft that follows.  There 
are three major changes for -04 in section 9:

9.1.1. DNS Resource Considerations: Rewritten/expanded.  This is Alessandro 
Vesely's text that he provided me offline and I posted here almost a month ago 
for review.

9.1.3. Bounces:  New subsection provided by Franck Martin that was previously 
published on this list.  What's in the draft is almost exactly what he posted.

9.3. Receivers:  This is new.  I wrote the first two subsections in response to 
comments by Murray Kucherawy.  He provided the text (on this list) for the 
last subsection.

So most of the change in the section you are complaining about was previously 
posted here.  Keep in mind that all of section 9 is non-normative.  If you've 
got actual suggestions to make, please make them.  Vague assertions that it 
could be better don't help me get this done.

Scott K