Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-02.txt

Alessandro Vesely <vesely@tana.it> Tue, 03 July 2012 11:47 UTC

Return-Path: <vesely@tana.it>
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 99F0E21F86FE for <spfbis@ietfa.amsl.com>; Tue, 3 Jul 2012 04:47:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.524
X-Spam-Level:
X-Spam-Status: No, score=-4.524 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GKEMrVAMSkv8 for <spfbis@ietfa.amsl.com>; Tue, 3 Jul 2012 04:47:12 -0700 (PDT)
Received: from wmail.tana.it (www.tana.it [62.94.243.226]) by ietfa.amsl.com (Postfix) with ESMTP id 8845021F882D for <spfbis@ietf.org>; Tue, 3 Jul 2012 04:47:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tana.it; s=test; t=1341316038; bh=0P5bW8eaICIQ79JXk+1OBEeT7XrR8F7ALJ3r/DHAuwY=; l=2453; h=Message-ID:Date:From:MIME-Version:To:References:In-Reply-To: Content-Transfer-Encoding; b=OU5n/3e4W5Q5m32o1v31FOQeGLPfL8flFbcBTMemj7FPUA7CBw0nmUMl/W6pX5jH5 NzKtY3GwE61+FI23TkFedT9ok4ivUaQ5Kmee+W+qkNZgYySjgSHrkuTQnRNEAFzQV3 J1nck73q4Xq6R8K7Q4B7j/uJIflkkD8oadQuHcKE=
Received: from [172.25.197.158] (pcale.tana [172.25.197.158]) (AUTH: CRAM-MD5 515, TLS: TLS1.0,256bits,RSA_AES_256_CBC_SHA1) by wmail.tana.it with ESMTPSA; Tue, 03 Jul 2012 13:47:18 +0200 id 00000000005DC039.000000004FF2DBC6.00003F1A
Message-ID: <4FF2DBC6.3040906@tana.it>
Date: Tue, 03 Jul 2012 13:47:18 +0200
From: Alessandro Vesely <vesely@tana.it>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:13.0) Gecko/20120614 Thunderbird/13.0.1
MIME-Version: 1.0
To: spfbis@ietf.org
References: <20120629190443.9297.40140.idtracker@ietfa.amsl.com> <1610254.tmmhToiaLs@scott-latitude-e6320> <1567036.rU5QQqS7VH@scott-latitude-e6320>
In-Reply-To: <1567036.rU5QQqS7VH@scott-latitude-e6320>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Subject: Re: [spfbis] I-D Action: draft-ietf-spfbis-4408bis-02.txt
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: Tue, 03 Jul 2012 11:47:13 -0000

On Tue 03/Jul/2012 01:53:36 +0200 Scott Kitterman wrote:
> 
> There seemed to be a general view that I had too much about Type SPF still in 
> the draft, so I've taken another whack at it and reduced it further. 

IMHO, that whack was a little bit too procrustean.  The experiment I-D
explains a good deal of background info, but does not anticipate what
resolution is made at the protocol level --senders may publish,
verifier should not query, IIRC.

> In my last draft, I left the Type 99/SPF discussion in the IANA considerations 
> section.  I did that on purpose because even though RFC 4408 will be obsolete 
> after 4408bis is published, we still want an active definition for the 
> assignment (to preserve it's use for SPF for the near future since people 
> won't immediately remove Type SPF records, to document that the code point 
> has been used and it not available,

+1, that's needed.

> and to make it easy for a future effort to pick up it's use again
> if it were ever warranted).

I'd keep neutral on this.  We can divine neither what an incompatible
change will want to do, nor how easy or difficult that will be.

> I do think the body of the document needs to at least mention it for clarity, 
> but it should be more minimal than my original attempt.  I'm attaching an 
> rfcdiff from the 02 draft to my current attempt.  You'll see I moved some of 
> the information about type SPF to IANA considerations (not sure if I can do 
> that) and seriously slimmed down the discussion in the body of the draft.

I'd keep something of the last paragraph of Section 3.1.1 (v -02).  At
least:

   An SPF-compliant domain name MUST have an SPF record of type TXT.

Since the subsection's title is "DNS Resource Record Types", we might
choose to concentrate the information on the move there, referring to
Appendix A of [draft-ietf-spfbis-experiment] _for background_.
Otherwise, we might drop the last word of the title.

For the IANA considerations section, I'd limit to:

  IANA is requested to add an annotation to the SPF RRTYPE saying
  "(OBSOLETE - use TXT)" in the DNS Parameters registry.

(to be changed to "has added" upon publication.)

I wouldn't insist on "Version 1" more than necessary, since that is
the same as 4408.

US-ASCII should perhaps be changed to UTF-8 if we are going to allow
that in mailbox names.  See
http://www.ietf.org/mail-archive/web/spfbis/current/msg01719.html

jm2c