Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
RFC 7208

Note: This ballot was opened for revision 19 and is now closed.

Barry Leiba (was No Objection, Discuss) Yes

Comment (2013-09-26)
No email
send info
Version -21 addresses all of my non-blocking comments; thanks very much for considering these and dealing with them!

The RFC Editor note takes care of the bits that got left out of -21, and it addresses my DISCUSS.  So all is now clear.

(Pete Resnick) (was Discuss, Yes) Yes

(Jari Arkko) No Objection

(Richard Barnes) No Objection

(Stewart Bryant) No Objection

Comment (2013-09-11 for -19)
No email
send info
I am voting no objection on the basis of a quick scan indicating that there are no implications for the routing system.

(Gonzalo Camarillo) No Objection

(Benoît Claise) No Objection

Comment (2013-09-12 for -19)
No email
send info
disclaimer: I've only reviewed the changes compared to the RFC 4088.

Regarding "Appendix J.  Change History":
   NOTE TO RFC EDITOR: Changes since RFC 4408 (to be removed prior to

Personally, I like it when the new RFC has one section summarizing the changes compared to the initial RFC.
This would be a mix of:
   Appendix J.  Change History", but no needs to mention the editorial changes
   Appendix C.  Changes in implementation requirements from RFC 4408

Regards, Benoit

(Spencer Dawkins) No Objection

Comment (2013-09-07 for -19)
No email
send info
I'm a No-Obj on the document itself, but I look forward to seeing the text mentioned in Pete's Discuss about how obsoleting Type 99 in favor of TXT records is not going to be a precedent for other protocols ...

(Adrian Farrel) No Objection

Comment (2013-09-22 for -20)
No email
send info
I am balloting No Objection based on this work having no obvious impact on the Routing infrastructure, and the more detailed reviews and comment of the other ADs (who are more knowledgeable about this material).

(Stephen Farrell) No Objection

Comment (2013-09-12 for -19)
No email
send info
- 4.1: given that recursion is allowed and that you have
overall limits on how many DNS transactions can be done,
is the "transactions-remaining" value also an implicit
parameter of a check_host() call? This is only a comment 
since check_host is not a formal API but it'd seem to make 
it easier to get right if you make that implicit parameter
explicit. Or do the limits apply to each call as you 
recurse?  That wasn't entirely clear to me.

- I didn't get appendix D at all - what's that do?

- Appendix E.1, 2nd bullet: what's that? I think it needs
a reference if you want it to be understood.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Ted Lemon) No Objection

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2013-09-12 for -19)
No email
send info
Should s11.3 also provide a mitigation via a reference for the spoofed DNS?  Right now it just points to the DNS threats RFC.  I guess the reader can infer they should use DNSSEC if they're worried but adding a pointer to the right RFC would be better.  Something as simple as adding "... and see [RFCXYZ] for a countermeasure" or something like that.