Hi Patrik,
At 11:58 20-08-2013, Patrik Fältström wrote:
As the bottle is opened, I hereby state my
objection to Section 3.1 of
draft-ietf-spfbis-4408bis-19 for the reasons
explained below. I do agree (as stated below)
that the section of RFC 4408 that specify how to
use both SPF and TXT resource record types
include an error as it does not lead to interoperability.
As the intention with use of both TXT and SPF
originally was to migrate from TXT to SPF I
instead of what is outlined in the draft suggest
that a proper migration strategy is laid out
(look up mandatory to implement SPF and fall
back to TXT). This instead of deprecation of the SPF record.
In general I do believe, for example when
looking at IPv6 and DNSSEC and similar
technologies, that the lifetime of RFC 4408 is
too short to deprecate any of the proposed
records that are in use, specifically as RFC
4408 explicitly do allow use of both.
draft-ietf-spfbis-4408bis-19 is not the usual
Proposed Standard effort. The SPFBIS WG was
tasked to move RFC 4408 to Proposed Standard with
restrictions. One of the restrictions is not to
review the design. I hope that explains why
draft-ietf-spfbis-4408bis-19 is what it is. I
suggested to the working group to review the
issue of the migration strategy (see
http://www.ietf.org/mail-archive/web/spfbis/current/msg03934.html ).
From Section 3.1.1 of RFC 4408:
"It is recognized that the current practice (using a TXT record) is
not optimal, but it is necessary because there are a number of DNS
server and resolver implementations in common use that cannot handle
the new RR type. The two-record-type scheme provides a forward path
to the better solution of using an RR type reserved for this purpose."
There isn't similar text
in draft-ietf-spfbis-4408bis-19. Hector Santos commented that:
"we will add SPF type support in our implementation once the infrastructure
is ready. For us, as a windows shop, namely Microsoft DNS servers."
I read
http://social.technet.microsoft.com/Forums/windowsserver/en-US/5841e884-db22-42a1-8530-615a375662cc/dns-server-support-for-new-or-unamed-rr-type-records
My conclusion is that there is a DNS server that cannot handle the new RR Type.
The question is how to address the objection about the migration strategy.
Regards,
S. Moonesamy (as document shepherd)