ietf
[Top] [All Lists]

Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1) to Proposed Standard

2013-08-21 07:52:32
On Wednesday, August 21, 2013 12:00:56 Måns Nilsson wrote:
Subject: Re: [spfbis] Last Call: <draft-ietf-spfbis-4408bis-19.txt> (Sender
Policy?Framework (SPF) for Authorizing Use of Domains in Email, Version 1)
to Proposed Standard Date: Tue, Aug 20, 2013 at 10:30:41AM -0700 Quoting S
Moonesamy (sm+ietf@elandsys.c
My reading of  the SPFBIS Charter is that the working group was not
tasked to work on the future of DNS servers.  That does not mean
that arguments about the future of DNS servers are not relevant.

The codification of a pessimistic view of the ability of the DNS installed
base to adapt to new RRtypes is - in itself - a statement that influences
the future of DNS. That this was not completely understood in terms of
influence weight is one of the reasons for this debate.

There are several questions:
 (a) Was there an error in RFC 4408?

Yes.

 (b) What was the error in RFC 4408?

The TXT rrtype was not properly decommissioned; it lacked definitiveness,
and neither publication instructions nor selection/query algorithm
satisfy this (originally intended, I suppose and believe) sunset view
of the TXT record rôle vis à vis SPF.

 (c) Why was there an error in RFC 4408?
 
 (d) What should be done about the error?

4408bis needs a better defined depreciation statement for TXT,
accompanied by publication and  query methods that will ensure the
continous phasing-out of SPF data in TXT records.

A clarification here will help in making DNS UI vendors doing the right
thing. I'm quite confident that presently, the UI vendors sleep soundly
after reading 4408 and continuing to ignore SPF/99. That is not
desirable.

There isn't anything that can be done about question (c) except not
to repeat the same mistake.

Is there disagreement on the answers to questions (a) and (b)?

Apparently.

Translated:

RFC 4408 was in error because it didn't abandon it's installed base.  I gather 
this is an error you propose to rectify.

Scott K

<Prev in Thread] Current Thread [Next in Thread>