And here we come to a conflict between what we as a community would
like, versus what the market decides. This leads to a few questions:
1. Do we have to make a decision at any point from a protocol
standpoint that the market has in fact made a decision? I ask this
question because I performed an experiment along these lines some years
ago, finding quite a number of proposed standards that were nowhere to
be seen on the 'net. Earlier we saw discussion about simplifying code
bases, but generally a developer makes that decision, not the IETF.
2. What are the timescales involved? Is it fair to treat IPv6 the same
as a new DHCP option or a DNS RR? What are the parameters? One could
reasonably argue with the benefit of hindsight that there was no way we
would see IPv6 adoption until we ran out of IPv4 addresses. For DNS
RRs, there are some common inhibitors.
3. What can be done by the IETF to improve likelihood of adoption, and
conversely what should we not bang our heads against?
Eliot
On 5/1/13 7:03 AM, Murray S. Kucherawy wrote:
On Tue, Apr 30, 2013 at 12:52 PM, David Conrad <drc(_at_)virtualized(_dot_)org
<mailto:drc(_at_)virtualized(_dot_)org>> wrote:
SPF using TXT and hence, SPFBIS forces the uniquification of the
DNS response into the application instead of in the DNS library.
Given the ordering of individual TXT RRs within an RRset is not
guaranteed, I suspect the chances that every application is going
to do that parsing correctly is relatively low (btw, the example
in 3.3 in spfbis-14 is a bit misleading: assuming "second string"
is in a separate TXT RR (which is implied), the concatenation
might be "second stringv=spf1 ..... first"). The more interesting
bit is if/when another protocol uses TXT at the same ownername.
Yes, I understand all of that, and I've written code to deal with it.
It's not rocket science.
The RR has been allocated and it is supported in most DNS servers
and resolver libraries in one form or another. Provisioning
systems take much longer, but that isn't surprising and shouldn't
be an argument to deprecate (if it is, we might as well close the
RRtype registry for new entries).
We're not only talking about provisioning systems here. We're also
talking about interference with queries and replies at the DNS
protocol level. The survey work done for RFC6686 showed that
something on the order of thousands of domains in the sample set
suffered from this. It is a very real issue for a deployed protocol.
In the past, the IETF used to make decisions based on long-term
technical/architectural correctness, even in the face of pragmatic
complications (e.g., the choice to mandate strong crypto despite
real world challenges some companies faced in exporting that
crypto in products). In this particular case, there seems to be an
argument to explicitly disallow the long-term
technically/architecturally correct approach because some folks
choose not to add an RR to their zone files or support that RR in
their provisioning systems. As I said in DNSEXT, this seems like
the wrong approach to me.
All things being equal, I would agree with you. And if SPF were
starting anew today, I suspect I might have a different opinion. The
question, then, is the weight of the mitigating circumstances, which
obviously the two communities evaluate quite differently.
-MSK