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

From: Scott Kitterman <[email-masked]>
Date: Mon, 02 Jul 2012 19:53:36 -0400

On Friday, June 29, 2012 03:07:49 PM Scott Kitterman wrote:
> On Friday, June 29, 2012 12:04:43 PM [email-masked] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories. This draft is a work item of the SPF Update Working Group of
> > the IETF.
> >
> > 
> >         Title           : Sender Policy Framework (SPF) for Authorizing
> >Use>
> > of Domains in Email, Version 1 Author(s)       : Scott Kitterman
> >
> >         Filename        : draft-ietf-spfbis-4408bis-02.txt
> >         Pages           : 56
> >         Date            : 2012-06-29
> 
> Here's the revision log additions for this version:
...
>               Initial draft of wording to deprecate Type SPF.   
...

This change engendered a fair amount of discussion started by Alessandro 
Vesely here:

http://www.ietf.org/mail-archive/web/spfbis/current/msg01726.html

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. 

A related point:

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 immedialtely remove Type SPF records, to document that the code point 
has been used and it not available, and to make it easy for a future effort to 
pick up it's use again if it were ever warranted).

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.

Scott K

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 03 Jul 2012 13:47:18 +0200

> 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.

> 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.

> 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

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 03 Jul 2012 09:54:48 -0400

On Tuesday, July 03, 2012 01:47:18 PM Alessandro Vesely 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.

Please suggest text that you think would be reasonable.  I think my latest 
attempt covers reasonably what implementors should do.  If there is a gap in 
the why we decided that, I think it should probably be a sentence or two in 
sections 1.1 or 1.2.  What are you thinking needs to be added?

> > 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.
> 

There are a number of people who believe that there is a need for a future SPF 
"Version 3" that will not have backward compatibility requirements.  My view 
is that I'm not even going to think about it until after 4408bis is done.  If 
we postulate such an incompatible update were to be desirable, then it should 
use type SPF from the beginning.  There's nothing in the 4408bis drafts about 
potential future usage and I don't think there should be, so we don't need to 
divine anything.

> > 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.

The first sentence of 3.1.1 is now (in my local copy/the diff I mailed):

   SPF records MUST be published as type TXT [RFC1035].

I think adding your proposed sentence back is redundant.  What do you think it 
would add?

> Otherwise, we might drop the last word of the title.

I fixed the title.

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

I've added this, but not removed any of the existing text.

> I wouldn't insist on "Version 1" more than necessary, since that is

It's a bit difficult to know what to do here.  Personally, I think the chances 
that a non-compatible future SPF revision will get significant deployment are 
small.  Other people feel differently and so I think it is a good idea to be 
explicit that the obsoleteness is relative to version 1 here.

> http://www.ietf.org/mail-archive/web/spfbis/current/msg01719.html

For now, I think it should stay US-ASCII.  When we discuss IDN, then we can 
decide about that change.  We'll need to look very carefully at the backward 
compatibility implications of such a change (I absolutely guarantee you not 
all current SPF libraries are UTF-8 clean).

Scott K