Skip to main content

Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1
draft-ietf-spfbis-4408bis-21

Yes

(Pete Resnick)

No Objection

(Brian Haberman)
(Gonzalo Camarillo)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Richard Barnes)
(Ted Lemon)

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

Barry Leiba Former IESG member
(was No Objection, Discuss) Yes
Yes (2013-09-26) Unknown
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 Former IESG member
(was Discuss, Yes) Yes
Yes (2013-09-13 for -20) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (2013-09-22 for -20) Unknown
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).
Benoît Claise Former IESG member
No Objection
No Objection (2013-09-12 for -19) Unknown
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
   publication)

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
Brian Haberman Former IESG member
No Objection
No Objection (for -20) Unknown

                            
Gonzalo Camarillo Former IESG member
No Objection
No Objection (for -19) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -19) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -19) Unknown

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -19) Unknown

                            
Richard Barnes Former IESG member
No Objection
No Objection (for -19) Unknown

                            
Sean Turner Former IESG member
No Objection
No Objection (2013-09-12 for -19) Unknown
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.
Spencer Dawkins Former IESG member
No Objection
No Objection (2013-09-07 for -19) Unknown
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 ...
Stephen Farrell Former IESG member
No Objection
No Objection (2013-09-12 for -19) Unknown
- 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.
Stewart Bryant Former IESG member
No Objection
No Objection (2013-09-11 for -19) Unknown
I am voting no objection on the basis of a quick scan indicating that there are no implications for the routing system.
Ted Lemon Former IESG member
No Objection
No Objection (for -19) Unknown