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 (NT 4.0 at the 
time) had not directly support the SPF type but more importantly it did 
not support RFC 3597.  Unfortunately, not even MS DNS 5.0 which did add 
direct support for other new RR types (SRV, DNSSEC, AAAA, etc).
In my engineering opinion, the implications of the SPF type removal are 
wide spread as it implies a no confidence in the future of DNS servers 
to support safe, transparent passthru, recursive queries of unnamed types.
If such is the case with the IETF DNS community,  then it makes 
engineering sense to remove the SPF type but also keep in mind new RR 
types are also unrealistic as well. All future DNS DOMAIN policy based 
applications will be TXT only based which may be the acceptable reality 
today.  It wasn't yester-years (during MARID).  The endorsement of DKIM 
as an IS specification is testament of this TXT based solution 
acceptability in the market place.
To me, that would be the reason for removal. Otherwise, if we still have 
confidence in the future of RFC 3597 support in DNS servers across the 
board out of the box, then we should correct and clarify the SPF/TXT 
query method migration path in RFC 4408-bis.
As stated a number of times in the SPF WG, I would support SPF type in 
our implementation once Microsoft DNS server supported at the very least 
unnamed RR type processing.  It can't be provisional software, i.e. 
custom, that would not cut it. It needs to be out of the box for wide 
network query support.
Thanks

--
HLS


[1] http://www.ietf.org/mail-archive/web/spfbis/current/msg00586.html
[2] http://tools.ietf.org/html/rfc3597