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 <[email protected] > <mailto:[email protected]>> 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
