Below is the list of issues brought up during Last Call of
draft-ietf-spfbis-4408bis. I have tried to collect together the common
issues and tease out the ones that are slightly different. Below each
issue, I've given what I take to be the answer to the issue (either the
change that needs to be made, or the explanation of why no change is
necessary). I've not put names to the objections or the answers, simply
because multiple people gave different versions of the same objections
or the same answers, and sorting that out seemed useless.
Issues:
1. Overloading of the TXT RR for this use is bad.
- As far as I can tell, there is nobody that disagrees with this
statement. However, it is also not in-and-of-itself an objection to the
document: Nobody seems to have argued that this document should forbid
use of the TXT RR completely in SPF. The only question is whether the
document should provide a transition mechanism to the SPF RR or whether
it is reasonable to go forward with this protocol using only the TXT RR.
There is the "precedent"objection I will discuss in 2 below, but the
specific technical objections seem mostly *not* to be about forbidding
TXT RR use from the get-go. Some of the specific objections could be
taken as arguments against the document going forward if it has no
transition mechanism, but I believe all of those have either been
addressed or can be addressed with clarifying language in the document:
- The only complete solution to many of the problems that fall
under this category is if *all* misuse of TXT RR went away. There has
been no convincing argument put forward that this is plausible in the
foreseeable future.
1a. TXT RR can cause large RDATA.
- In theory, that's certainly true. But I have not seen an
argument that SPF is causing a major problem to date, nor that there is
an expectation that it will in the future.
- There were some suggested text clarifications for section 3.4
to make it clear which size limitations relate to DNS response size, UDP
payload size, or MTU size. They seem reasonable and were not objected
to. I'll work with the editor and others to clarify that text.
1b. Use of TXT RR can cause collisions with other applications.
- Again, there is no indication that this has caused a problem
for SPF (or others) to date, and SPF requires rejection of TXT RR data
that does not conform to the spec, so I see no evidence of the existing
harm, nor of a solid reason to believe there will be future harm.
(Again, I'm leaving aside the "precedent" arguments until 2.)
- There appears to be an effort underway to document (via an
IANA registry) such uses to minimize the potential for these sorts of
collision problems in the future.
1c. Use of TXT RR for multiple purposes makes it impossible to do
access control based on type of data (i.e., to allow delegation of the
management for TXT RRs that are solely for SPF use).
- Many organizations have been managing these records already;
no reasoning was given that this fine-grained management is necessary.
- Delegation is possible by pointing a TXT RR of (e.g.)
example.com to _spf.example.com, delegating the latter.
- All of the above was discussed extensively in the WG and taken
into consideration. Given the charter limitations, a reasonable choice
was made.
2. Use of the TXT RR sets a bad precedent for future use.
- Several people responded that some additional text in 3.1 or
elsewhere (either by way of some sort of applicability guidance or an
overt IESG Statement) would address this issue. I think an IESG
Statement is unnecessary since I have not heard significant objection to
including some guidance, and I think something reasonable along these
lines can be crafted. I'll work with the editor and others to get such
text in the document.
- The impediments that caused SPF to use TXT RR in the first place
are mostly gone. New protocols are unlikely to face the same challenges.
3. Removing SPF RR support is a charter violation.
- Because the original spec has a non-interoperable mechanism for
use, this constituted an "error" in the spec that was to be corrected.
4. A new transition mechanism from TXT RR to SPF RR should be put into
the spec.
- This was extensively considered by the WG.
- Backward compatibility would require support of TXT RR for the
forseeable future anyway.
- The proposed transition mechanisms have technical issues:
Doubling request traffic (e.g., doing queries in parallel), introducing
delays (e.g., querying SPF RR first and running into firewalls, etc).
- This would be a new, unchartered requirement for the WG.
- The widely held conclusion was that such a transition plan would
not be undertaken by implementers. (See also 5.)
5. That there will be a lack of adoption of SPF RR was based on RFC
6686, which does not support the conclusion.
5a. There is some current use of the SPF RR; it will increase if we
put in a new transition mechanism.
- 6686 showed only minimal use, and reports of those in the
industry shows the use dropping (i.e., the momentum is in the other
direction).
- Bigger sites are conservative and will not transition for
fear of breaking current usage.
- No solid case was made for why to believe that the transition
would occur.
5b. Use of SPF RR is on the increase now.
- Claims that use is increasing are only anecdotal, and
disagree with the experience of those in the industry.
5c. Things may have changed since 6686. We should do more data
collection.
- There's no reason to believe that the small amounts of
recently presented data are representative.
- Nobody presented any basis to doubt the folks working in the
industry.
- There has been ample opportunity (and motivation) for folks
outside of the WG to do more data collection; none has been presented.
- It is an unreasonable burden to place on the WG at this point.
There were a few smaller issues:
6. The term "SPF records" is confusing because it could refer to
SPF RR.
- Because the document no longer uses SPF RR, this shouldn't be
a problem in practice.
7. Clarifications are needed regarding the number of lookups to do
in 4.6.4.
- This will be reviewed prior to publication.
8. There should be a limit on PTR lookups.
- This was already considered by the WG and rejected.
The only looming issue large issue is the architectural one:
9. Using TXT RR for this purpose violates the architecture of the DNS.
I list this separately because this is not about the immediate technical
implications (like objection 1) or a claim about precedence setting
(like objection 2), but appears to be a claim that violating the
architecture is in and of itself a reason to not put something on the
standards track. The problem I have with this is, short of actual
technical harm, I'm not sure how to judge this. Our processes judge
whether standards should be adopted on the basis of interoperability,
deployment, and solving a useful problem. We have many examples of
protocols that violate architectural principles, but standardize them
nonetheless. (We can all name our most hated.) We have found it more
useful to document how to interoperate with protocols that may not be
ideal but are widely deployed rather than reject them on principle. I
can't see how to treat this protocol differently.
[There were a number of "straw men": There were responses to objections
that never got brought up during Last Call, and a number of followups to
responses to objections where the response was not one offered. Examples
of these included:
- A response to the objection that we haven't let the Experiment
run long enough. (Nobody ever argued that during Last Call.)
- A followup denying the contention that there is limited server
support for SPF RRs. (Nobody ever said that the reason to use TXT RR now
was because of limited server support.)
I have ignored these threads.]
So, my conclusions in summary are:
- The document needs to make a statement in the document clarifying why
the SPF RR is no longer used in the spec and making it clear that no
precedent should be created by this protocol's continued use of TXT RR.
- A few clarifications are required in the text (size limitations,
perhaps number of lookup limitations).
- The remainder of the objections were fully considered and understood
by the WG, and were addressed to a reasonable extent, and therefore that
there is rough consensus to go forward with this document.
pr
--
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478