Re: [spfbis] SPF TYPE support
On 8/19/2013 7:42 PM, S Moonesamy wrote: At 14:10 19-08-2013, Hector Santos wrote: I'm having a hard time with both sides of the argument, especially the supposed existence of an interop problem which seems to only highlight how to procedurally stump the SPF type advocates with a error correction standpoint. What is that error by the way? In a message dated February 27, 2012, the SPFBIS Chairs commented that the discussion about Issue #9 (SPF RRTYPE) has revealed an interoperability concern in the existing RFC (4408). From RFC 6686: RFC 4408 itself included a faulty transition plan, likely because of the late addition of a requirement to develop one -- it said: An SPF-compliant domain name SHOULD have SPF records of both RR types. A compliant domain name MUST have a record of at least one type. which means both can claim to be fully compliant while failing utterly to interoperate. The consensus of the SPFBIS WG was that this is an interoperability issue and it would have to be corrected. That is what was considered as an error correction. I have a few questions and points: May I ask why was the above was not an area for clarification as oppose as the presumed stated technical reason for removal? There was adequate information for the expected and original optimal migration plan but it could of been further codified and clarified. It would of been on par with BIS level of work. Issue #9 should not have been a reason for removal. I reported issue #25 [1] regarding the complexity of the recommended parallel processing approach. I believe most folks agreed the ideal and optimal migration approach was: Query SPF type first, Fallback to TXT secord. It was common sense, at least to me. Second, I was under the impression interop reports (RFC 6686) were not making any conclusions or recommendations? Is that a correct basic understanding of interop reports? They were observations, collection of available data and while it might be eventually used to rethink a protocol design, I don't think the above RFC 4408 statement is a serious error in the functional description to justify removal. There are other parts of 4408 which helped clarify the migration path. But overall, a correction (not removal) would of suffice. It would of been on par for BIS-like corrections and protocol updates. Third, I believe removal required a more deeper IETF discussion about the initial presumed engineering expectation that DNS servers (all top DNS servers, including and especially Microsoft DNS servers) would eventually directly support a new registered SPF type or at the very least support RFC 3597 (Handling of Unknown DNS Resource Record (RR) Type) [2]. If this is no longer the expectation, then it would make sense to remove the SPF type but also be aware that in general, this will also nix (not help) any future idea for successfully adopting new RR types. It would be added statement that TXT based applications are acceptable. I think the DNS community continues to have a problem with this. I don't believe there was an adequate answer from the advocates of removing the SPF RR type and the repeated assertion that its been discussed at length has not been convincing it was appropriately addressed. It all seem to be a Shut up approach to the problem (always suggest that its been discussed already). This seems to be one of the reasons why the issue will not go away. I personally do not think that it is appropriate to ask any working group participant to shut up. I welcome hearing arguments and I expect a working group to carefully consider them. Regards, S. Moonesamy (as document shepherd) SM, Pete, thank you for the opportunity to clarify my point. For the record, there was no intent to imply it occurred but quite frankly when it is repeatedly stated, this deeply divided issue has not be resolved at any point, it does have an intimidation factor. As Mr. Crocker stated, the burden is on the those who oppose the removal. But my question was always why was the decision made to remove in the first place done when in fact it was quite obvious it would not have industry wide endorsement. The burden should of been to justify removal. Now it has become difficult to effectively add it back. This is why I posed the question in two forums to get community input over the last few years. It was quite obvious to me that the DNS community would be against this removal. So in this vain, it was prematurely removed in the WG without early IETF/IESG/DNS concerns adequately dealt with. Unfortunately, we were advise to raise the issue again in LC, but by that point, all the IETF procedural moves were made making it it a very high burden to add something that should not been removed in the first place. The only reason our own early adoption package did not support the SPF type was because we could not; the Microsoft DNS server
Re: [spfbis] SPF TYPE support
Hi Hector, At 06:30 20-08-2013, Hector Santos wrote: I have a few questions and points: May I ask why was the above was not an area for clarification as oppose as the presumed stated technical reason for removal? The SPFBIS WG had a session at IETF 83. The minutes for that session is at http://www.ietf.org/proceedings/83/minutes/minutes-83-spfbis.txt Item C on the agenda is about SPF RR Type and TXT RR (issue #9). Andrew Sullivan, as SPFBIS Chair, explained that: 'The were people on the mailing list in favor of using the TXT RR appeared to be a modest majority and there were people who argued for SPF RR Type on the grounds of DNS hygiene. The Chair explained that it appears as an empirical matter, overwhelmingly, the TXT RR is used but RRTYPE 99 does not qualify under the unused provision of the SPFBIS charter.' Pete Resnick, as Area Director, commented that: 'the deal with the IESG, as a general statement, the working can removed what is unused and put in what is widely deployed. He pointed out that saying that TXT RR is part of an experiment is contrary to the agreement made with the IESG. His opinion is that either way, the proposal is stuck with TXT RR and that it is not an issue. The only issue is whether the proposal can remove the SPF RRTYPE as unused.' On February 26, 2012, Barry Leiba, as a participant, posted a message ( http://www.ietf.org/mail-archive/web/spfbis/current/msg00654.html ) which I will quote: These two statements make a pretty compelling case that there is, indeed, an error in RFC4408. There are, of course, multiple ways to resolve it, and I have no immediate opinion on which is best. My opinion, as one of the SPFBIS WG Chairs, was that there was an error. As Barry Leiba mentioned, there were several possible ways to fix that. The SPFBIS Chair stated at the meeting that: The conclusion reached by the Chair was that the document will say SHOULD NOT publish RRTYPE 99 and MUST NOT query RRTYPE 99. That statement was posted to the SPFBIS mailing list ( http://www.ietf.org/mail-archive/web/spfbis/current/msg01369.html ). Nobody disagreed. There was adequate information for the expected and original optimal migration plan but it could of been further codified and clarified. It would of been on par with BIS level of work. Issue #9 should not have been a reason for removal. I reported issue #25 [1] regarding the complexity of the recommended parallel processing approach. I believe most folks agreed the ideal and optimal migration approach was: Query SPF type first, Fallback to TXT secord. It was common sense, at least to me. Both Issue #9 and Issue #25 (see SPFBIS tracker) were well-discussed. Was every technical point carefully considered? I don't think so as it is possible that a technical point may have been missed. There is an opportunity for anyone to comment during the Last Call if the person believes that a technical point has been missed or was not addressed appropriately by the working group. In my opinion the SPFBIS WG carefully considered all the comments which were made in reaching its decision. Second, I was under the impression interop reports (RFC 6686) were not making any conclusions or recommendations? Is that a correct basic understanding of interop reports? They were observations, collection of available data and while it might be eventually used to rethink a protocol design, I don't think the above RFC 4408 statement is a serious error in the functional description to justify removal. There are other parts of 4408 which helped clarify the migration path. From the Introduction Section of RFC 6686: In line with the IESG's request to evaluate after a period of time, this document concludes the experiments by presenting evidence regarding both deployment and comparative effect of the two protocols. At the end, it presents conclusions based on the data collected. In my opinion RFC 6686 does make conclusions (see Section 6 of RFC 6686). There is some background information about the RRTYPE issue in Appendix A. But overall, a correction (not removal) would of suffice. It would of been on par for BIS-like corrections and protocol updates. Andrew Sullivan, as SPFBIS WG Chair, mentioned that We have to do _something_, though any action would introduce a backward incompatibility ( http://www.ietf.org/mail-archive/web/spfbis/current/msg03595.html ). Third, I believe removal required a more deeper IETF discussion about the initial presumed engineering expectation that DNS servers (all top DNS servers, including and especially Microsoft DNS servers) would eventually directly support a new registered SPF type or at the very least support RFC 3597 (Handling of Unknown DNS Resource Record (RR) Type) [2]. There were comments about RFC 3567 during the working group discussions (see
Re: [spfbis] SPF TYPE support
On Aug 19, 2013, at 5:10 PM, Hector Santos hsan...@isdg.net wrote: This will allow coders to add the optimized logic for usage. It will also allow for new problem solving seeds to be laid down. It will hopefully get the DNS software vendors to finally add direct support for unnamed TYPE support (query and passthru) not only for SPF but for future DNS application protocols. It would help if you would go review the working group discussion on this point; if you had done so, I do not believe you could make this point with a straight face, because it was soundly refuted by the working group. I tried to make the same point to the working group, and they successfully argued me around. Although I'm sure you're aware that I am quite stubborn, it's possible that they would not succeed in arguing you around as they did me. But you ought at least to do us the service of allowing them to try by reviewing the discussion yourself.
