Re: [dnsext] [spfbis] Obsoleting SPF RRTYPE

[Hector Santos <[e-mail]>]

I believe the right engineering design choice in MARID was made.  The 
problem was the DNS Servers have not caught up with the very least of 
having a passthru concept with unnamed query types.  It is was clearly 
known what the issues were in MARID, a migration path was provided with 
the protocol and we fully expected the DNS servers will eventually catch 
up and support unnamed types. [1]  It was a long term migration path 
issue as Doug Barton pointed out.

I still believe having a specific record is the right thing and path. 
Eliminating it will only encourage more TXT-based protocols.  The 
question is whether the DNS servers will support it or at the very least 
a passthru.

I suggest to keep it and to relax the requirements, and basically have 
developers keep it as an software design option, i.e. don't forget about 
it, comment it out, compiler directives, etc.  It would be their choice 
to immediately support the ideal migration path that is currently 
described in 4408 (although I have a small issue with the parallel call 
idea, but that's a different issue), or leave the code ready but disable 
it for a TXT only query.  Lets think ahead here now (again), not later 
and begin to encourage DNS server developers/vendors, DNS Managerment 
Software folks, etc, to support unnamed types processing. [1]

--
HLS

[1] http://tools.ietf.org/html/rfc3597

n 4/25/2013 5:09 PM, Murray S. Kucherawy wrote:
> On Thu, Apr 25, 2013 at 1:54 PM, Doug Barton <[e-mail]> wrote:
>
>> The way forward is simple, spfbis should specify that compliant senders
>> MUST publish the SPF record, and compliant receivers MUST query for it
>> first. Then down the road at some point we can deprecate TXT for this
>> purpose. If that had been done in the beginning we would be celebrating the
>> deprecation of the TXT record right about now, instead of having another
>> round of contentious arguments about doing it the right way in the first
>> place.
>>
>>
> I fail to see how the word "simple" can be legitimately applied here given
> the breadth of the deployed base of SPF that's using TXT.  It may be the
> right thing to do, but I don't think that's a mountain that's easy to
> move.  Certainly it's easy to talk about it though.
>
>
>>
>> Everyone knows the history of how hard it was to get new RRtypes off the
>> ground at the time SPF first came into being. A lot of lessons were learned
>> from that, and the situation is much better now. Everyone also understands
>> that the problem of upgrading 3rd party and/or web-based provisioning
>> systems to accommodate new records is still a problem. But that problem
>> doesn't get better by ignoring it.
>>
>> In short, the proponents of SPF (which by the way, I like and use) should
>> be focusing on doing the right thing here, instead of the expedient thing.
>>
>
> I think that same history gives rise to another way forward.  When SPF came
> into being, the RRtype issue prevented the right thing from happening.  It
> was made worse by late insertion of a sloppy transition mechanism.  It's
> much too late to fix that now, but we can take steps to prevent it from
> happening with future protocols. Thus: Take our licks and leave this one
> alone, but do good work on improving process and provisioning so that it
> can't happen again.
>
> -MSK
>
>
>
> _______________________________________________
> spfbis mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/spfbis
>